Spring Boot Configuration, Profiles & Secrets — Interview Questions

How to use this lesson

Configuration problems cause a surprising share of production incidents: the wrong profile, a leaked secret, a property that silently didn't bind. Show that you know where Boot looks for configuration, in what order, and how to keep secrets out of Git.

Q1. What advantages does YAML have over .properties, and what are its limitations?

Short answer: YAML is hierarchical, so it's less repetitive and more readable for nested and list configuration. It supports multi-document files (---), for per-profile sections. Its limitations:

• It's indentation-sensitive (a misplaced space silently changes the meaning).
• Implicit typing surprises: on/no/yes, leading zeros, and version numbers like 1.10 read as a float.
• @PropertySource doesn't load YAML files (without a custom factory).

payments:
  timeout: 3s
  providers:
    - name: razorpay
      url: https://api.razorpay.example
    - name: stripe
      url: https://api.stripe.example

Key points to cover:

• Quote strings that look like other types (version: "1.10").
• Pick one format per project.

Q2. How do Spring Boot profiles work?

Short answer: A profile is a named set of beans and properties that's active only when the profile is:

• Properties: application-{profile}.yml files, or sections of a multi-document YAML file guarded by spring.config.activate.on-profile. They override the default application.yml.
• Beans and configuration classes: @Profile("prod"), with expressions such as !prod and cloud & kafka.
• Activation: spring.profiles.active, through a command-line argument, the SPRING_PROFILES_ACTIVE environment variable, a system property, or @ActiveProfiles in tests. Groups (spring.profiles.group.prod=db,observability) bundle profiles together.

spring:
  profiles:
    group:
      prod: "postgres,observability"
---
spring:
  config:
    activate:
      on-profile: dev
  datasource:
    url: jdbc:h2:mem:shop

Learn it in depth → Configuration Management

Q3. Why use profiles?

Short answer: The same artifact can then run in every environment. Only the configuration changes, so you test exactly the binary you ship. Profiles switch data sources, endpoints, logging levels, feature toggles, mock or real integrations, and dev-only beans (such as seed data), without code changes or rebuilds.

Key points to cover:

• Don't overuse them. Environment values (URLs, credentials) belong in environment variables or a config server. Use profiles for genuinely different behaviour or wiring.

Q4. How does Spring Boot help manage secrets and sensitive configuration across environments?

Short answer:

1. Externalised configuration, so secrets never live in the code or JAR. They come from environment variables, mounted files, or a secrets store.
2. Config-tree support (spring.config.import=configtree:/run/secrets/) reads Kubernetes secret volumes as properties.
3. Integrations with HashiCorp Vault (Spring Cloud Vault), and cloud secret managers (AWS Secrets Manager or Parameter Store, Azure Key Vault, GCP Secret Manager), via spring.config.import.
4. Actuator masking hides sensitive values in /env and /configprops.

spring:
  config:
    import: "optional:configtree:/run/secrets/,aws-secretsmanager:prod/shop/db"
  datasource:
    password: ${db-password}

Key points to cover:

• Rotate secrets. Prefer short-lived, dynamic credentials (Vault database secrets, IAM roles) to static passwords.

Q5. How would you manage externalised configuration and secure sensitive properties in a microservices architecture?

Short answer:

• Centralise non-secret configuration, either in Spring Cloud Config Server (backed by Git, versioned and audited) or in a platform-native equivalent (Kubernetes ConfigMaps plus GitOps).
• Keep secrets in a dedicated secrets manager (Vault or a cloud secrets manager), accessed with per-service identity and least-privilege policies.
• Encrypt anything unavoidable at rest (Config Server {cipher} values).
• Enforce TLS for configuration traffic.
• Support dynamic refresh where it's safe (@RefreshScope, Spring Cloud Bus).

Key points to cover:

• Keep an audit trail of configuration changes, and roll them out gradually. A bad configuration push can take down every service at once.

Q6. How does Spring Boot support internationalization (i18n)?

Short answer: Boot auto-configures a MessageSource when it finds messages.properties (plus messages_hi.properties, messages_fr.properties…) on the classpath. The request's locale comes from a LocaleResolver: the default uses Accept-Language, while session or cookie resolvers with a LocaleChangeInterceptor allow switching languages. Messages are resolved in templates (#{…}), in code (messageSource.getMessage(...)), and in Bean Validation error messages.

spring:
  messages:
    basename: messages,errors
    fallback-to-system-locale: false     # fall back to messages.properties, not the server's OS locale

Key points to cover:

• Localise error responses too: ProblemDetail titles and details can be resolved from the MessageSource.

Q7. What does "relaxed binding" mean?

Short answer: When binding to @ConfigurationProperties, Boot accepts several spellings of the same property name, so the same setting can come from YAML, a system property or an environment variable:

Common trap: saying server-port is the same as server.port. Dots separate the levels of the hierarchy, and relaxed binding only varies the form within each name segment. Also, @Value supports only limited relaxed binding. Prefer @ConfigurationProperties.

Q8. Scenario: your app behaves differently in development and production. How do you manage the differences with profiles?

Short answer:

• Keep shared defaults in application.yml.
• Put environment overrides in application-dev.yml and application-prod.yml, or better, inject environment values through environment variables.
• Switch beans with @Profile: a stub payment gateway in dev, and a real one in prod.
• Activate with SPRING_PROFILES_ACTIVE.
• Make the differences explicit and minimal. Every behavioural difference is something you can't test before production.

@Configuration
class GatewayConfig {
    @Bean @Profile("dev")  PaymentGateway fakeGateway()  { return new FakePaymentGateway(); }
    @Bean @Profile("!dev") PaymentGateway realGateway(PaymentProperties p) { return new RazorpayGateway(p); }
}

Key points to cover:

• Log the active profiles at startup, and fail fast if production starts without the expected profile.

Q9. Scenario: the app must switch between several data sources at runtime, based on the request (for example, per region or tenant). How do you implement it?

Short answer:

1. Use Spring's AbstractRoutingDataSource, which wraps several target DataSources and chooses one per connection through determineCurrentLookupKey().
2. Store the routing key in a ThreadLocal context, set by a filter or interceptor from the request (a header, JWT claim or subdomain), and cleared in finally.
3. The key must be set before the transaction opens its connection.

public class RegionRoutingDataSource extends AbstractRoutingDataSource {
    @Override protected Object determineCurrentLookupKey() { return RegionContext.get(); }   // "EU", "APAC"
}

@Bean
DataSource dataSource(DataSource euDs, DataSource apacDs) {
    var routing = new RegionRoutingDataSource();
    routing.setTargetDataSources(Map.of("EU", euDs, "APAC", apacDs));
    routing.setDefaultTargetDataSource(euDs);
    return routing;
}

// in a OncePerRequestFilter
RegionContext.set(resolveRegion(request));
try { chain.doFilter(request, response); } finally { RegionContext.clear(); }

Key points to cover:

• Pitfalls:
  • The connection is chosen once per transaction, so switching regions mid-transaction does nothing.
  • @Async and other threads need the context propagated.
  • Each target database needs its own pool, sized appropriately.
  • Schema migrations must run on every target.
• For read/write splitting, the same pattern routes read-only transactions to replicas, using TransactionSynchronizationManager.isCurrentTransactionReadOnly() and LazyConnectionDataSourceProxy.

Follow-up questions this topic invites — and their answers

Q: In what order does Spring Boot load configuration? A: From lowest to highest priority (simplified):

1. Defaults.
2. application.yml inside the JAR.
3. Profile-specific files inside the JAR.
4. Files outside the JAR (./config/).
5. Environment variables.
6. System properties.
7. Command-line arguments.

Later sources override earlier ones for the same key.

Q: How do you validate configuration at startup? A: Annotate the @ConfigurationProperties class with @Validated, and add constraints (@NotBlank, @Min, @DurationMin). A misconfigured deployment then fails immediately with a clear message, instead of misbehaving later.

Q: How do you refresh configuration without restarting? A: With Spring Cloud Config, use @RefreshScope beans plus /actuator/refresh (or Spring Cloud Bus to broadcast the refresh). @ConfigurationProperties beans are rebound on refresh. Many teams prefer immutable configuration plus a rolling restart, because it's simpler to reason about.

Q: Where should feature flags live? A: For simple on/off switches, in properties with @ConditionalOnProperty (read at startup). For runtime toggles, percentage rollouts and per-user targeting, use a feature-flag service (Unleash, LaunchDarkly, Flagsmith) through the OpenFeature SDK.