Configuration Management.

Configuration is the thermostat of a microservice: if the setting is wrong, the whole room feels broken. Interviewers love this question because it tests whether you can keep code flexible without hard-coding environment details.

Question: What is configuration management in Spring Boot microservices?

Answer: Configuration management means keeping settings outside the code so the same service can run in dev, test, and prod with different URLs, timeouts, credentials, and feature flags. Spring Boot reads those values from property files, environment variables, command-line args, and optionally a central config server, then binds them into beans. The core idea is simple: code stays the same, configuration changes per environment.

Interview-Ready Answer: In Spring Boot microservices, I manage configuration by externalizing settings instead of hard-coding them. I usually bind related settings with @ConfigurationProperties, use profiles like dev and prod, and keep secrets separate from normal config. In larger systems, I also use a centralized source like Spring Cloud Config so every service can share consistent values, while environment variables and command-line args still override safely when needed.

What it means

In Spring Boot, a property source is just a place where config can come from: application.yml, application-prod.yml, environment variables, command-line args, or a remote config service. Spring keeps these sources in an ordered list, so higher-priority values override lower-priority ones. A binder is the part that maps raw text values into Java objects, and relaxed binding means Spring can match checkout.request-timeout-ms, checkout.requestTimeoutMs, and CHECKOUT_REQUEST_TIMEOUT_MS to the same field.

How Spring Boot does it under the hood

1. Spring Boot starts and creates an Environment, which is the object that holds all config values.
2. It loads config data from the local app files first, then profile-specific files, then any imported sources such as spring.config.import=configserver:.
3. It decides which profiles are active, for example dev, test, or prod. That choice changes which files and values are loaded.
4. When a bean asks for configuration, Spring uses the binder to convert text into the right type: strings, numbers, booleans, lists, durations, or nested objects.
5. If you use @ConfigurationProperties, Spring binds a whole group of related settings at once, which is safer than scattering single values through the code.
6. Validation runs after binding if you add @Validated plus constraints like @Min or @NotBlank. This is a big win because bad config fails early at startup instead of failing under traffic.
7. If you add Spring Cloud refresh support, some beans can be reloaded at runtime, but that should be used carefully because it can create mixed old/new values during rollout.

What to use and when

Rule of thumb: use @ConfigurationProperties for most application settings because it keeps related values together, is easier to test, and is safer to validate. Use a config server when many services must share the same source of truth, such as gateway routes, API endpoints, and feature flags.

Version notes, performance, and edge cases

In Spring Boot 2.4 and newer, the Config Data API changed how config is loaded; modern apps usually prefer spring.config.import instead of relying on the old bootstrap context. That detail matters in interviews because older examples on the internet can be outdated. Binding itself is roughly O(n) in the number of properties being bound, which is small in practice; the bigger cost is a remote config call, which often adds about 50-300 ms to startup depending on network and server load. For microservices, common starting values are around 2s request timeouts, 3 retries, and pool sizes in the 10-20 range, then tuned with real traffic.

• If a property is missing, you can supply a default in code or a default file, but do not hide missing secrets with fake values.
• Lists and maps can be tricky: replacing a list usually overwrites the whole list, so order and file precedence matter.
• If a config server is down, fail-fast=true makes the service stop immediately, which is often safer for payments than booting with partial config.
• Secrets such as passwords, tokens, and private keys should live in a secret manager or encrypted store, not in Git.

Real-world story

Imagine an ecommerce checkout service. It needs payment.gateway.base-url, payment.request-timeout-ms, and payment.retry-attempts. The team keeps these in a config repo and deploys the same jar to every environment. Production points to the real payment gateway, staging points to a sandbox, and dev uses local mocks. One day, someone activates the wrong profile, so prod loads application-dev.yml and starts sending traffic to the sandbox URL.

What goes wrong: users click Pay and see a spinner, then a generic failure. Logs fill up with 404s or TLS errors from the wrong endpoint, and retries make the problem louder by multiplying the traffic. If the team uses Spring Cloud Config with a bad timeout value, they may also see ReadTimeoutException or a startup failure if validation catches the mistake. The user impact is simple and painful: orders are abandoned, revenue drops, and support gets flooded with complaints.

Why configuration management matters here: the bug is not in the payment logic; it is in how environment-specific values are delivered and validated. Good config management lets the team fix the value once, roll it out safely, and avoid rebuilding the application for every environment change.

Follow-up & Tricky Questions

• How is @ConfigurationProperties different from @Value? @ConfigurationProperties binds a whole group of related settings into one object, which is easier to validate and test. @Value is fine for one simple value, but it becomes messy when you have many fields.
• How do Spring profiles work? A profile is a named environment, like dev or prod. When a profile is active, Spring loads matching config files such as application-prod.yml and can switch beans or values for that environment.
• How do you refresh config without restarting? In Spring Cloud, you can use refresh support plus @RefreshScope on beans that should be reloaded. The catch is that runtime refresh is not free; it can create temporary inconsistency, so use it for values like feature flags more than for core infrastructure.
• How do you keep secrets safe? Put passwords, tokens, and keys in a secret manager or encrypted store, not in source control. Spring Boot can read them the same way as other properties, but the storage and access policy should be stricter.
• What changed in Spring Boot 2.4+? The config loading model moved to the Config Data API, and modern Spring Cloud Config setups usually use spring.config.import=configserver:. That is why old bootstrap.yml examples may not match current projects.
• Does application-prod.yml load automatically? No. It loads only when the prod profile is active. Many candidates forget that the file name is not enough; the profile must be turned on too.
• Do environment variables override YAML? Yes, in the common case they have higher precedence than local files. That is why ops can safely override a container setting without editing the jar.
• Tricky: Does Spring Cloud Config automatically refresh every bean? No. Only beans designed for refresh will update, usually through @RefreshScope or a custom refresh strategy. Without that, the app keeps the old value until restart.
• Tricky: Are lists merged across files? Usually not the way people expect; later config often replaces the whole list rather than merging item by item. This bites teams that think they are only adding one entry but accidentally remove the rest.

Common Mistakes:

• Hard-coding URLs or timeouts in Java code. Fix: keep environment-specific values in external config so the same jar works everywhere.
• Using @Value for large config objects. Fix: switch to @ConfigurationProperties so settings stay grouped and testable.
• Forgetting to activate the right profile. Fix: always set spring.profiles.active intentionally in each deployment target.
• Putting secrets in Git. Fix: store them in a secret manager or encrypted configuration store.

Memory Hook: Think of a microservice like a restaurant: the code is the kitchen layout, but configuration is today’s menu, prices, and supplier list. Same restaurant, different day, different setup.

Cheat Sheet:

• Externalize settings; never hard-code environment details.
• Use @ConfigurationProperties for grouped settings.
• Profiles choose environment-specific config like dev and prod.
• Command-line args and environment variables override file values.
• Use Spring Cloud Config when many services need one source of truth.
• Validate config early so bad values fail at startup.

Practice Tasks:

• Add a new property called checkout.discount-enabled and use it in the response.
• Create a prod profile file and override the currency and timeout.
• Deliberately set checkout.request-timeout-ms=50 and observe startup validation failure.