Spring Boot Configuration Properties Interview Questions and Answers

Externalized configuration is what lets a Spring Boot app read its settings from files, environment variables and command-line arguments instead of hardcoding them. Interviewers use configuration-properties questions to check whether you bind config in a type-safe, validated way or scatter @Value strings across the codebase. This set covers the questions asked in intermediate rounds — the @ConfigurationProperties versus @Value decision, relaxed binding, enabling, constructor binding, validation and source precedence — each with a spoken answer and the follow-up interviewers use to go deeper.

Why interviewers ask about configuration properties

Configuration is where correctness meets operability: the same code must run with different settings per environment, and those settings must be validated before they cause damage. How you bind configuration reveals whether you treat it as a first-class, testable part of the system or as an afterthought. The mechanics — prefixes, binding rules, precedence — are concrete, so the questions have verifiable right answers.

Q1. @ConfigurationProperties vs @Value — when do you use each?

@ConfigurationProperties binds a whole group of related properties, identified by a prefix, to a type-safe POJO or record — with relaxed binding, nested objects, collections and validation. @Value injects a single property into a single field using SpEL. Use @ConfigurationProperties for any cohesive group of settings; reserve @Value for a one-off value.

The type-safe approach centralizes a feature's configuration in one class you can inject, test and validate, instead of sprinkling string keys through many classes. @Value cannot bind nested structures, does not support relaxed binding, and gives you no validation — it is fine for a single flag but wrong for a settings group.

@ConfigurationProperties(prefix = "app.mail")
public record MailProperties(String host, int port, boolean tls) { }

versus a single value:

@Value("${app.timeout-seconds:30}")
private int timeoutSeconds;     // one value, with a default of 30

Interview note: Follow-up: "why is @Value a poor choice for a group of settings?" No nesting, no relaxed binding, no validation, and the config is scattered rather than centralized in one testable type. Those four gaps are the whole argument.

Q2. How does the prefix and type-safe binding work?

@ConfigurationProperties(prefix = "app.mail") binds every property under app.mail.* to the matching field of the class. app.mail.host maps to host, app.mail.port to port. Spring converts types automatically — strings to int, boolean, Duration, DataSize, enums — during binding at startup.

Because binding is by name under a prefix, the class reads like documentation of that feature's configuration surface. Type conversion means you work with real types, not strings, so a mistyped number fails at binding rather than at first use.

app:
  mail:
    host: smtp.internal
    port: 587
    tls: true

Interview note: Trap: "what happens if app.mail.port is set to abc?" Binding fails at startup with a conversion error — which is a feature, because a bad value is caught immediately rather than surfacing as a runtime bug later.

Q3. What is relaxed binding?

Relaxed binding lets one field match several source spellings. maxPoolSize binds from max-pool-size, max_pool_size, maxPoolSize or MAX_POOL_SIZE. Kebab-case (max-pool-size) is the recommended form in property files, and the uppercase-underscore form is how the field maps to an environment variable.

This is what makes the same configuration portable across YAML files, .properties, environment variables and command-line arguments without you maintaining several spellings. It is especially important for containers, where configuration usually arrives as uppercase environment variables.

Interview note: Follow-up: "how would maxPoolSize be supplied as an environment variable?" As APP_MAXPOOLSIZE (or APP_MAX_POOL_SIZE) — Spring's relaxed binding maps the uppercase-underscore environment form onto the camelCase field.

Q4. How do you enable @ConfigurationProperties?

Three ways: annotate the properties class and register it with @EnableConfigurationProperties(MailProperties.class) on a configuration class; add @ConfigurationPropertiesScan to the application so Spring auto-detects all @ConfigurationProperties types in the scanned packages; or annotate the class with @Component so it is picked up by component scanning.

@ConfigurationPropertiesScan is the cleanest for many properties classes, while @EnableConfigurationProperties is explicit about exactly which types are registered — useful when the properties class comes from a library or you want the registration documented in one place.

@SpringBootApplication
@ConfigurationPropertiesScan          // auto-detects @ConfigurationProperties types
public class Application { }

or explicit registration:

@Configuration
@EnableConfigurationProperties(MailProperties.class)
class MailConfig { }

Interview note: Trap: "you added @ConfigurationProperties but the bean is not being bound — why?" It was never registered. You need one of @EnableConfigurationProperties, @ConfigurationPropertiesScan, or @Component — the annotation alone does not register the type.

Q5. What is constructor binding and how do records help?

Constructor binding sets the values through the constructor instead of setters, which lets the properties class be immutable. Java records are ideal because their canonical constructor is exactly what Spring binds. In Spring Boot 3, a @ConfigurationProperties type with a single constructor gets constructor binding automatically — @ConstructorBinding at the type level is no longer required.

Immutable configuration is a real benefit: nothing can mutate the settings after startup, so they are safe to share across threads and read like a specification. Records give you that with no boilerplate.

@ConfigurationProperties(prefix = "app.mail")
public record MailProperties(
        String host,
        int port,
        boolean tls) {

    public MailProperties {                         // compact constructor: defaults/validation
        if (port == 0) port = 587;
    }
}

Interview note: Follow-up: "where does @ConstructorBinding go now?" In Spring Boot 3 it is inferred for a single-constructor type, so you rarely write it; when a type has multiple constructors you place it on the specific constructor to bind. Knowing it moved off the type level signals current knowledge.

Q6. How do you validate configuration properties?

Put @Validated on the @ConfigurationProperties class and jakarta.validation constraints on its fields — @NotNull, @NotBlank, @Min, @Max, @Email. Spring runs validation during binding at startup, so an invalid or missing value stops the application immediately with a clear message rather than failing later in a request.

Fail-fast configuration is the goal: a missing database URL or an out-of-range pool size should abort startup, not cause a mysterious error under load. You need a validation implementation (spring-boot-starter-validation) on the classpath for the constraints to run.

@Validated
@ConfigurationProperties(prefix = "app.mail")
public record MailProperties(
        @NotBlank String host,
        @Min(1) @Max(65535) int port,
        boolean tls) { }

Interview note: Trap: "your @Min constraint is not being enforced — why?" Either @Validated is missing from the class, or no Bean Validation provider is on the classpath. Both are required for startup validation to actually run.

Q7. What is the precedence order of property sources?

Higher-priority sources override lower ones. From highest: command-line arguments, then OS environment variables and Java system properties, then profile-specific application-{profile} files, then the base application.yml/.properties, then defaults set in code. This is what lets an operator override packaged configuration without rebuilding.

The practical consequence: a value in application.yml is a default that any environment variable or command-line argument can override at deploy time. That ordering is the backbone of twelve-factor configuration and the reason the same artifact runs everywhere.

# command-line arg overrides whatever application.yml says
java -jar app.jar --app.mail.host=smtp.prod.internal

Interview note: Follow-up: "if application-prod.yml sets the host and an environment variable also sets it, which wins?" The environment variable — it sits above profile-specific files in the precedence order. Externalized sources always beat packaged files.

Q8. How do you bind nested objects, lists and maps?

Nested objects bind to nested types or nested records; lists bind from indexed keys (app.servers[0].host) or comma-separated values; maps bind from app.limits.gold=100 style keys. @ConfigurationProperties handles all of these, which is a core reason to prefer it over @Value, which cannot.

Structured binding lets configuration mirror the shape of the domain — a list of endpoints, a map of rate limits per tier — as strongly typed collections you can inject and iterate.

@ConfigurationProperties(prefix = "app")
public record AppProperties(
        List<Server> servers,
        Map<String, Integer> limits) {
    public record Server(String host, int port) { }
}

app:
  servers:
    - host: node-a
      port: 8080
    - host: node-b
      port: 8081
  limits:
    gold: 1000
    silver: 100

Interview note: Trap: "can you also put @ConfigurationProperties on a @Bean method?" Yes — annotate a @Bean factory method with @ConfigurationProperties to bind properties onto a third-party object you construct there, which is how you configure library types you cannot annotate directly.

How to prepare

Convert one feature's settings from a handful of @Value fields into a single @ConfigurationProperties record with a prefix, then add a jakarta.validation constraint and start the app with a bad value to watch it fail at startup. That exercise makes the type-safety and fail-fast arguments concrete, and both are exactly what the interviewer is probing. Then override one value with a command-line argument and confirm the precedence from Q7 yourself.

Build the configuration foundations on the Spring Boot learning path, and read this alongside profiles and auto-configuration, since property binding, per-environment configuration and conditional beans are almost always tested together. A focused mock interview on externalized configuration is the fastest way to find whether your binding-and-precedence story holds up under follow-up pressure.