1. Explain the difference between Thread.sleep() and Object.wait() in Java. When would you use each one in a backend application?

Thread.sleep() blocks the current thread for a specified duration and does not release any locks it holds, making it unsuitable for waiting on shared resources. Object.wait() releases the monitor lock on the object and puts the thread into a waiting state until another thread calls notify() or notifyAll(), making it the proper choice for inter-thread communication in synchronized blocks. In a backend context, use sleep() for simple delays (like retry backoff), and wait() when coordinating access to shared state like a bounded queue or connection pool.

2. What is a race condition? Describe a realistic scenario in a Java backend service where a race condition could occur without proper synchronization.

A race condition occurs when two or more threads access shared mutable state concurrently and at least one performs a write, with the final result depending on the order of execution. A realistic example is incrementing a counter in an HTTP request handler without synchronization: if two requests arrive simultaneously and both read the current value, increment it, and write it back, one increment is lost. Another common case is lazy initialization of a singleton database connection pool, where two threads might both see the connection object as null and create duplicate pools, wasting resources.

3. What does the volatile keyword guarantee in Java? Is it sufficient for thread-safe counters or accumulators?

The volatile keyword ensures that reads and writes to a variable are atomic and that changes are immediately visible across all threads; it prevents instruction reordering and caching of the value in CPU registers. However, volatile is NOT sufficient for compound operations like increment (read-modify-write) because those consist of multiple steps and can still race. For thread-safe counters, you must use AtomicInteger or synchronize the entire operation, though volatile alone is fine for flag variables (e.g., volatile boolean shutdown flag) or single value writes.

4. Your team is building a request-scoped cache for a REST API. Multiple threads might request the same resource simultaneously. How would you prevent duplicate expensive computations using Double-Checked Locking?

Use a ConcurrentHashMap to store cached results and a volatile reference to a computation-in-progress marker; the first thread acquires a lock, checks again if the value was computed by another thread, and only then performs the expensive operation. The volatile keyword ensures visibility of the completion marker across threads without locking on every read, reducing contention on subsequent accesses. Pattern: read the map without lock, if miss then synchronized block re-checks the map before computing, then stores result and notifies waiters. Note: this is better solved with ConcurrentHashMap.computeIfAbsent() in modern Java, which handles the synchronization internally.

5. Explain what a deadlock is and give an example of how it could occur in a multithreaded Java backend service.

A deadlock occurs when two or more threads are blocked forever waiting for each other to release locks, creating a circular dependency. Example: Thread A locks Resource 1 and tries to acquire Resource 2, while Thread B locks Resource 2 and tries to acquire Resource 1. In a backend context, this might happen in payment processing where Thread A locks a customer account and tries to lock a ledger account, while Thread B does the opposite; if both operations run simultaneously, they deadlock. Prevention strategies include always acquiring locks in the same global order, using timeouts with tryLock(), or switching to lock-free structures like ConcurrentHashMap.

6. When would you use ReentrantLock instead of the synchronized keyword in a Java backend application? What benefits does it provide?

ReentrantLock provides more flexible locking than synchronized, including support for tryLock() with timeouts (preventing deadlocks), condition variables for fine-grained thread signaling, and fair lock queuing to prevent thread starvation. Use it when you need to acquire a lock with a timeout to fail gracefully rather than block indefinitely, or when you need to wait on multiple conditions. For example, in a connection pool, ReentrantLock with a condition variable lets you efficiently wake only idle threads waiting for connections rather than using notifyAll(). For simple, short critical sections, synchronized is preferred because it's simpler and benefits from JVM optimizations like biased locking.

7. Your team has a Java service that processes orders. The order object is passed between multiple threads (validation thread, payment thread, fulfillment thread). How would you ensure thread-safe visibility of updates to the order state?

Use immutable objects or explicitly synchronize access to the order; prefer immutability by creating new order objects with updated fields at each stage rather than mutating shared state. If mutation is necessary, ensure all reads and writes are protected by the same lock (or use atomic classes for primitive fields), and mark mutable fields volatile if using a publication mechanism like message passing. Alternatively, use thread-safe queues (BlockingQueue) to pass order objects between stages, ensuring each thread owns the object during its stage and passing ownership via the queue, which provides visibility guarantees.

8. What is the difference between CountDownLatch and CyclicBarrier? In what backend scenario would you choose one over the other?

CountDownLatch allows threads to wait for a count to reach zero (one-way, not reusable), while CyclicBarrier allows a fixed number of threads to wait for each other and can be reused after all threads arrive. Use CountDownLatch when you need worker threads to wait for initialization to complete (like a service startup waiting for all components to initialize), and CyclicBarrier when threads need to synchronize at multiple points (like multiple worker threads processing batches and waiting for all to finish before starting the next batch). In a backend batch processing job, CyclicBarrier is ideal for coordinating worker threads that process data in phases.

9. Your service uses a thread pool (ExecutorService) to handle incoming requests. What are the risks of submitting blocking I/O operations (like database queries) to the pool, and how should you handle it?

If threads block on I/O, they hold onto executor resources and reduce the pool's capacity to handle new requests, potentially causing thread starvation and cascading failures under load. Solutions include: use a larger thread pool sized for I/O-heavy workloads (using Executors.newCachedThreadPool() or custom ThreadPoolExecutor with high corePoolSize), use non-blocking I/O libraries (like async database drivers), or delegate I/O to a separate thread pool so it doesn't starve request-handling threads. Best practice for backend services is sizing the thread pool based on the workload type: CPU-bound tasks use threads equal to CPU cores, while I/O-bound tasks use threads equal to expected concurrent I/O operations.

10. What is the Java Memory Model (JMM) and why is it important for writing correct concurrent code?

The Java Memory Model defines guarantees about visibility and ordering of memory operations across threads, ensuring that properly synchronized code behaves predictably across different processor architectures and JVM implementations. Without the JMM, compiler and CPU optimizations could reorder operations or cache values in ways that break multi-threaded correctness on some architectures but not others. The JMM guarantees that happens-before relationships established by synchronized blocks, volatile reads/writes, and lock operations ensure that changes made by one thread are visible to another, preventing subtle bugs that only appear under specific hardware or load conditions.

11. You're debugging a race condition in a service where user balance updates are lost. The code uses multiple synchronized blocks on different objects. What is the underlying problem and how would you fix it?

The problem is likely broken atomicity: synchronizing on different objects (like synchronizing reads on one object and writes on another) does not prevent race conditions because the locks don't coordinate access to the shared state. The fix is to ensure all operations on a shared resource use the same lock object, or refactor to use a single synchronized method/block, or switch to atomic classes like AtomicLong. In a banking scenario, if balances are updated with separate locks for read and write, another thread can read stale data between the read and write operations; the solution is to synchronize the entire deposit/withdraw operation on the same account lock.

12. Explain what thread-local storage (ThreadLocal) is and provide a realistic use case in a Java backend service. What are the risks?

ThreadLocal allows each thread to have its own isolated copy of a variable, useful for storing request context (like current user ID, correlation ID, or database transaction) without passing it through every method signature in a backend handler. Example use case: storing the current HTTP request context (user info, locale, authorization) in a ThreadLocal so service methods can access it without adding parameters. Risks include memory leaks if ThreadLocal values are not explicitly cleaned up (especially in thread pools where threads are reused), and confusion about which thread owns which value; best practice is to always call threadLocal.remove() in a try-finally block or use automatic cleanup in frameworks like Spring.

13. What is generational garbage collection, and why is it a good fit for typical Java backend applications?

Generational GC divides the heap into young and old generations, assuming most objects die young and few survive to old age. Young generation collections are fast and frequent because they only scan a small region; old generation collections are rare and slower. This matches the typical lifecycle in backend services where request-scoped objects are created and destroyed quickly, while long-lived objects like connection pools or caches persist. The result is that most GC work happens on fast young collections, keeping pause times low.

14. You notice your Java backend service has a memory leak where heap usage keeps growing even after requests complete. How would you approach diagnosing this problem?

Start by taking a heap dump using jmap or a monitoring tool like JConsole to see which object types are consuming memory. Analyze the dump with tools like Eclipse MAT or JProfiler to find objects with unexpectedly high reference counts. Common culprits in backend services include unbounded caches (e.g., a HashMap that never evicts entries), static collections that accumulate data, or objects retained by thread pools. Write a simple test to reproduce the leak in isolation, then add explicit lifecycle management like cache eviction or object pooling.

15. What is the difference between the heap and the stack in Java, and why does the JVM manage them differently?

The stack stores primitive values and object references with automatic memory management via function call/return, while the heap stores actual object instances with dynamic allocation. The JVM manages them differently because stack memory is thread-local and automatically freed when a method exits, whereas heap memory is shared across threads and requires garbage collection to reclaim unused objects. Stack is faster and limited in size, while heap is larger but subject to GC pauses.

16. Explain what happens during a Full GC pause in a Java application. What does the application do during this time?

During a Full GC, the garbage collector stops all application threads (stop-the-world event) to trace all reachable objects across the entire heap, identify garbage, and compact memory. The application is completely frozen and cannot execute any user code, process requests, or respond to inputs during this time. For a junior backend developer, this means requests in flight may timeout and latency spikes occur; understanding Full GC frequency and duration is critical for backend service reliability.

17. Your backend application uses the G1GC collector and you see occasional 200ms pause times. Is this acceptable, and what would you check first to improve it?

For many backend services, 200ms is on the high side for tail latency; SLA-critical services often target under 50ms pauses. Check heap size and allocation rate: if objects are promoted to old generation too quickly, G1GC will spend more time on mixed collections. Reduce object creation by examining hot paths in request handlers, use object pooling for frequently allocated objects, or increase heap size if it's undersized. Also verify G1GC tuning flags like MaxGCPauseMillis; lowering the target may reduce pause time but increase GC frequency.

18. What is the difference between WeakReference and SoftReference in Java, and when would you use each in a backend service?

WeakReference objects are cleared as soon as the garbage collector runs if there are no strong references, while SoftReference objects are only cleared when memory is low. Use SoftReference for caches that you want to keep as long as possible (e.g., a query result cache that survives light GC pressure), and WeakReference for metadata or listener registries where you don't want to prevent object cleanup (e.g., storing request context that should not extend an object's lifetime). In a backend service, SoftReference is more practical for performance-critical caches because it avoids re-computation on every request.

19. You are designing a backend service that processes 10,000 requests per second. What JVM heap size would you start with, and what factors would influence your choice?

A reasonable starting point might be 2-4 GB for a single instance, but this depends on average object lifetime, allocation rate, and acceptable GC pause frequency. If each request allocates 100 KB of short-lived objects, that is roughly 1 GB per second of garbage; a smaller heap forces frequent young GC but keeps pauses short, while a larger heap allows objects to live longer before collection. Also consider the trade-off between pause time (larger heap = longer pauses) and throughput (smaller heap = more frequent GC overhead); monitor GC logs with tools like GCEasy to find the sweet spot.

20. What is object promotion, and why does premature promotion of young objects to the old generation harm backend service latency?

Promotion happens when a young object survives several young GC cycles and is moved to the old generation. Premature promotion is harmful because old generation collections are much slower and more expensive than young collections; if short-lived request objects are promoted, they trigger old generation GC unnecessarily. This causes longer pause times that affect all concurrent requests. Common causes include heap size being too small, objects living longer than expected, or survivor spaces configured poorly; reduce promotion by increasing heap size, reducing object lifetime, or using flags like -XX:MaxTenuringThreshold to tune promotion age.

21. Explain the concept of GC overhead limit and what the exception 'java.lang.OutOfMemoryError: GC overhead limit exceeded' means for a running backend service.

The JVM throws this exception when garbage collection consumes more than 98% of total runtime for more than 2 consecutive seconds without freeing significant memory (usually defined as less than 2% of heap). This indicates the application is thrashing: creating objects faster than GC can reclaim them, or the heap is too small for the workload. For a backend service, this typically means either a memory leak, an unexpectedly large allocation spike, or insufficient heap size for the traffic. The fix is to identify the allocation source via heap dumps, fix the leak, increase heap size, or reduce per-request object creation.

22. You are choosing between CMS and G1GC for a backend service running on a 16-core machine with 8 GB heap. What are the trade-offs?

CMS is simpler and has lower complexity, but uses concurrent marking that can interfere with application threads and may cause fragmentation over time, leading to full GC stalls. G1GC is more sophisticated, handles fragmentation better, and is more predictable for pause time (good for SLA-sensitive services), but has higher overhead on small heaps and more complex tuning. For an 8 GB heap on 16 cores, G1GC is generally preferred because the larger core count gives overhead room and the predictable pause times are more valuable for backend latency than CMS's simplicity. Modern Java versions deprecate CMS anyway, so G1GC is the safer long-term choice.

23. A backend API endpoint returns data in 50ms normally, but occasionally spikes to 500ms. You suspect GC. How would you confirm this and what metrics would you log?

Enable GC logging with flags like -Xlog:gc*:file=gc.log:time,level,tags:filecount=5,filesize=100m, then correlate spike timestamps in application logs with GC events in the GC log. Key metrics to monitor are young GC pause time, old GC pause time, allocation rate, and promotion rate. Use tools like JFR (Java Flight Recorder) to capture low-overhead runtime data and analyze which requests align with GC pauses. If 500ms spikes correlate with old GC events, the issue is likely premature promotion or large allocation; if aligned with young GC, increase young generation size or reduce per-request allocation.

24. Explain the term 'safepoint' in the JVM and why it matters for garbage collection pause times.

A safepoint is a point in the JVM execution where the garbage collector can safely pause a thread because the thread's state is consistent and no references into the heap are being actively used. The JVM can only begin a stop-the-world GC pause after all application threads reach a safepoint; the time to reach safepoint is part of GC pause latency. Long safepoint times occur when threads are in JNI calls, tight loops without safepoint polls, or blocked I/O that does not check for safepoint requests. For a backend service, safepoint delays are usually negligible unless you use JNI heavily or have long-running synchronized blocks; understanding this helps explain why actual pause times are sometimes longer than GC time alone.

25. Explain the difference between checked and unchecked exceptions in Java. When building a REST API backend, how would you decide which type of exception to throw from a service method?

Checked exceptions are verified at compile time and must be declared in the method signature or caught; unchecked exceptions (RuntimeException subclasses) are not enforced by the compiler. In a REST backend, use checked exceptions for recoverable business logic failures like 'UserNotFoundException' that the caller can handle gracefully, and unchecked exceptions for programmer errors like 'NullPointerException' or 'IllegalArgumentException' that indicate bugs. For example, if a user lookup fails due to an invalid ID, throw a checked exception that the controller catches and converts to a 404 response; if a required field is null, throw an unchecked exception to fail fast. Most Spring-based backends favor unchecked exceptions for service layers to reduce boilerplate and let the framework's global exception handler centralize error responses.

26. You are writing a repository method that queries a database using JDBC. The method opens a Connection, prepares a statement, and executes it. If an exception occurs during result processing, the Connection is never closed. How would you fix this, and why is this pattern problematic?

The connection leaks because the exception prevents the cleanup code from running, exhausting the connection pool over time. You should use try-with-resources to automatically close resources: wrap the Connection and PreparedStatement in try-with-resources blocks, which guarantees closure even if an exception occurs. Alternatively, use a connection pool framework like HikariCP (common in Spring Boot) that manages connection lifecycle automatically. Connection leaks are critical in backend services because each unclosed connection consumes memory and pool slots, eventually blocking new requests with 'unable to get a connection' errors. Modern Java backends rarely write raw JDBC; instead, they use frameworks like JPA/Hibernate or Spring JDBC that handle resource management transparently.

27. Your backend service receives a request to create a user account. The service must validate the email format, check if the email already exists in the database, hash the password, and insert the record. In what order would you perform these steps, and why?

Perform validation (email format, password strength) before any database operations to fail fast without I/O overhead. Next, check if the email exists with a database query; if it does, return an error immediately. Only after all validations pass should you hash the password and insert the record. This order minimizes wasted database queries and computation—for example, if the email format is invalid, you avoid a database lookup entirely. Additionally, validate early to provide immediate feedback to the client. If you hashed the password before checking uniqueness, you would waste CPU on hashing invalid data, and if you inserted before validating format, you would create invalid records that corrupt your database state.

28. Explain what the @Transactional annotation does in a Spring backend service. What happens if a RuntimeException is thrown inside a @Transactional method?

The @Transactional annotation wraps a method in a database transaction, automatically committing changes if the method completes successfully or rolling back all changes if an exception occurs. When a RuntimeException is thrown inside a @Transactional method, Spring catches it, rolls back the transaction (undoing all database modifications made during that method), and then re-throws the exception to the caller. This ensures data consistency: if a payment is deducted but the order fails to insert due to an error, both operations are undone rather than leaving the database in a corrupt state. Checked exceptions do not trigger rollback by default; you must configure @Transactional(rollbackFor = CustomCheckedException.class) to rollback on checked exceptions. Spring's transactional support is critical in backend services because it frees developers from manual begin/commit/rollback logic.

29. You are designing a caching layer for a backend service that retrieves user profiles by ID. The profile is expensive to compute (multiple database joins). How would you implement this cache, and what is a key challenge you must address?

Use an in-memory cache like a ConcurrentHashMap or a library like Caffeine or Redis to store profile objects keyed by user ID. When a request arrives, check the cache first; if found, return immediately; if not found, compute the profile, insert it into the cache, and return it. A critical challenge is cache invalidation: if a user updates their profile, you must remove or update the stale cache entry, or the service will return outdated data. Without proper invalidation, caches become sources of data corruption. For example, if a user changes their email but the old email remains cached, subsequent requests return the wrong email. You must decide on a strategy: explicit invalidation (remove from cache when a write occurs), TTL-based expiration (entry expires after N minutes), or write-through updates (always write to cache and database together). Redis is preferred in production because it supports atomic operations and can be shared across multiple backend instances.

30. Your backend service accepts JSON requests via a REST endpoint. The JSON payload contains a 'birth_date' field in the format YYYY-MM-DD. How would you deserialize this into a Java object, and what is a common pitfall?

Use a LocalDate field in your Java class and annotate it with @JsonFormat(pattern = 'yyyy-MM-dd') in Jackson or configure a custom deserializer. Jackson will automatically parse the string into a LocalDate object; if the format doesn't match, it throws a JsonMappingException. A common pitfall is using java.util.Date instead of LocalDate or LocalDateTime, which leads to timezone confusion: Date uses epoch milliseconds and doesn't preserve timezone information, so the same date string deserializes differently depending on the server's timezone. For example, '2000-01-01' might deserialize to December 31, 1999 if the server is in UTC-7. Always use java.time classes (LocalDate, LocalDateTime, ZonedDateTime) in new Java code. Another pitfall is forgetting to annotate the field, causing Jackson to fail or produce unexpected results. Spring Boot backends typically use Jackson auto-configuration, so proper annotation is essential for correct serialization and deserialization.

31. You are debugging a backend service where some POST requests return 500 errors intermittently, but the error logs show no stack traces. How would you investigate this, and what could be the cause?

Intermittent 500 errors without logged stack traces suggest the error occurs outside the application code—likely in the framework, container, or infrastructure layer. First, check if the global exception handler is misconfigured or if exceptions are being swallowed silently (caught but not logged). Next, examine the application server logs (Tomcat, Jetty) for socket errors, connection pool exhaustion, or timeouts. Check the database: if queries hang and the connection pool is exhausted, new requests fail waiting for a connection. Verify thread pool settings in the backend; if the thread pool is saturated, requests queue and timeout. Use application monitoring tools like Spring Boot Actuator or micrometer to track active threads, queue depth, and connection pool metrics. A real scenario: if a database query takes 30 seconds but the request timeout is 10 seconds, the client receives a 500 error, but no application exception is logged because the timeout occurs at the framework level before your code completes. Enable query logging (hibernate.show_sql or Spring JPA debug logs) to catch slow queries.

32. Your team uses JUnit 5 and Mockito to test a service method that calls a repository and processes results. The method is: 'public List<User> getActiveUsers() { return repository.findAll().stream().filter(u -> u.isActive()).collect(toList()); }'. How would you write a unit test, and what should you mock?

Mock the repository and configure it to return a predefined list of users using Mockito.when(). Test that getActiveUsers() filters correctly: mock the repository to return a list with both active and inactive users, call the method, and assert that only active users are returned. For example: 'when(repository.findAll()).thenReturn(Arrays.asList(activeUser1, inactiveUser2, activeUser3)); List<User> result = service.getActiveUsers(); assertEquals(2, result.size());'. Mock only external dependencies (repository); never mock the class under test. Avoid over-mocking by ensuring the test exercises the actual filter logic and stream processing. A common pitfall is mocking the stream operations themselves, which defeats the purpose of testing the business logic. Unit tests should be fast and isolated; if the test queries a real database, it is an integration test, not a unit test. In a junior backend role, focus on mocking external I/O (database, HTTP calls) and testing the core business logic in isolation.

33. You are implementing a search API endpoint that accepts optional filters (e.g., ?status=active&minPrice=10&maxPrice=100). How would you build the database query dynamically, and what is a critical security concern?

Use a query builder pattern or Spring Data's Specification class to dynamically construct WHERE clauses based on provided filters. For example, if status is provided, add 'WHERE status = ?1' to the query; if minPrice is provided, add 'AND price >= ?2'. A critical security concern is SQL injection: if you concatenate user input directly into the query string, an attacker can inject malicious SQL. For example, if a filter value is 'active' OR '1'='1', concatenating it into the query bypasses authorization. Always use parameterized queries (prepared statements with ? placeholders) or an ORM like Hibernate that automatically parameterizes queries. Spring Data repositories with method names like 'findByStatusAndPriceBetween()' or Specification objects handle parameterization automatically. Never use string concatenation for user input in SQL. Additionally, validate filter inputs: ensure enums like status are from a whitelist, and ensure numeric ranges are reasonable to prevent expensive queries. Using Spring Data's query DSL (QueryDSL or Criteria API) makes building dynamic, safe queries much easier than raw SQL.

34. Your backend service has a method that retries a failed API call up to 3 times with exponential backoff. How would you implement this, and what is a risk you should be aware of?

Implement exponential backoff by catching the exception, incrementing a retry counter, sleeping for an exponentially increasing duration (e.g., 100ms, 200ms, 400ms), and retrying the operation. Use a loop or recursion to handle multiple attempts: 'for (int attempt = 1; attempt <= 3; attempt++) { try { return callExternalApi(); } catch (IOException e) { if (attempt == 3) throw e; Thread.sleep((long) Math.pow(2, attempt) * 100); } }'. A critical risk is that Thread.sleep() blocks the entire thread, wasting resources if many requests are retrying simultaneously. In a high-concurrency backend, blocking threads exhausts the thread pool, and new requests queue indefinitely. A better approach is to use Spring's @Retryable annotation with backoff configuration or async/non-blocking libraries like CompletableFuture or reactive frameworks (Project Reactor). Another risk is cascading failures: if the external service is overloaded, retrying with backoff reduces strain, but retrying immediately can worsen the outage. Use circuit breakers (like Hystrix or Resilience4j) to stop retrying when the external service is down, failing fast instead of wasting retries.

35. A junior developer on your team submits a pull request where a service method is marked as synchronized. When you review the code, you see multiple threads calling this method, which performs a database query and an HTTP call. What is the problem, and how would you refactor it?

The synchronized keyword serializes all threads accessing the method, meaning only one thread can execute at a time. If multiple threads need to query the database or call an external HTTP service concurrently, synchronizing the entire method creates a massive bottleneck: all threads wait in line, and the backend cannot handle concurrent requests efficiently. This defeats the purpose of multithreading and kills throughput. The refactor depends on the intent: if the method is thread-safe already (most database drivers and HTTP clients are thread-safe), remove the synchronized keyword entirely. If you need to protect a shared mutable state (e.g., a cache or counter), synchronize only that specific state, not the entire method—use fine-grained locking on a small object. For example, synchronize only the cache lookup/update, not the database query. A better pattern is to use immutable objects or thread-safe collections (ConcurrentHashMap) to avoid synchronization altogether. In modern Java backends, avoid synchronized whenever possible; instead, use thread-safe libraries, message queues, or async processing. Synchronized methods are appropriate only for protecting small, fast operations that hold the lock briefly.

36. Your backend service reads configuration values from environment variables (e.g., database URL, API keys) at startup. The service is deployed to multiple environments (dev, staging, production). How would you organize and inject these configuration values, and what is a security best practice?

Use Spring Boot's application.properties or application.yml files with environment-specific profiles: application-dev.properties, application-staging.properties, application-prod.properties. Spring automatically loads the matching profile based on the 'spring.profiles.active' environment variable. Inject configuration values into beans using @Value('${property.name}') or @ConfigurationProperties classes for strongly-typed, validated configuration. For sensitive values like API keys and database passwords, never commit them to the repository; instead, inject them from environment variables or secure vaults. Spring Boot automatically maps environment variables to properties (spring.datasource.password maps to SPRING_DATASOURCE_PASSWORD), keeping secrets out of code. A security best practice: store secrets in a secure vault (AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault) rather than environment variables, and retrieve them at runtime. Never log configuration values that contain secrets. In development, use a .env file (not committed to git) for local configuration. For junior developers, the key principle is: code and configuration are separate, and secrets are never in the codebase. Spring Cloud Config or similar tools enable dynamic configuration updates without redeploying the application.