@ConfigurationProperties vs @Value
Fast recall
Quick revision
Core answer
@Value injects a single property value using SpEL and is convenient for one-off values, but it has no validation, no relaxed binding, no IDE autocompletion, and no support for nested types. @ConfigurationProperties binds an entire prefix of related properties to a typed POJO, supports JSR-303 Bean Validation, relaxed binding (camelCase, kebab-case, UPPER_SNAKE_CASE), constructor binding for immutability, and generates IDE metadata. The rule: @Value for one or two isolated values; @ConfigurationProperties for any group sharing a prefix.Whether the candidate knows the practical limitations of `@Value` and can justify when the more verbose `@ConfigurationProperties` approach is worth it
Using `@Value` for every property, even large groups of related config, resulting in classes littered with `@Value` fields and no validation
Mention that `@ConfigurationProperties` requires `@EnableConfigurationProperties` or `@ConfigurationPropertiesScan`, supports constructor binding via Java records, and that `spring-boot-configuration-processor` generates IDE metadata
Interview-ready guide
Interview answer
@Value and @ConfigurationProperties both inject external configuration, but they are designed for different scales. Choosing the wrong one creates code that is hard to test, hard to validate, and hard for teammates to discover.
`@Value` — for isolated one-off values
@Value("${api.key}")injects a single property; works fine for one or two standalone values- No validation at startup — a missing required property causes an NPE at the first call site, not at startup
- No type conversion for structured types —
Duration,DataSize,Listrequire manual parsing
`@ConfigurationProperties` — for groups of related properties
- Binds an entire prefix to a POJO:
@ConfigurationProperties(prefix = "payment")mapspayment.url,payment.timeout,payment.retriesto fields automatically - Add
@Validatedand JSR-303 annotations — missing required fields cause a clear startup failure with every violation listed - Auto-converts
Duration(30s),DataSize(256MB),List(comma-separated strings) - Generates IDE auto-completion metadata when
spring-boot-configuration-processoris added as an annotation processor
Activation
- The class needs either
@Component,@EnableConfigurationProperties(MyConfig.class)in a@Configurationclass, or@ConfigurationPropertiesScanon the main class
The rule: @Value for a single isolated key, @ConfigurationProperties for anything that has a prefix and more than two properties.
@ConfigurationProperties vs @Value
Direct Answer
@Value injects a single property value using SpEL and is convenient for one-off values, but it has no validation, no relaxed binding, no IDE autocompletion, and no support for nested types. @ConfigurationProperties binds an entire prefix of related properties to a typed POJO, supports JSR-303 Bean Validation, relaxed binding (camelCase, kebab-case, UPPER_SNAKE_CASE), constructor binding for immutability, and generates IDE metadata. The rule: @Value for one or two isolated values; @ConfigurationProperties for any group sharing a prefix.
Common Mistakes & Pitfalls
Using @Value for every property, even large groups of related config, resulting in classes littered with @Value fields and no validation
Check your understanding
Answer these without looking back at the article.
- How do you enable constructor binding (immutable `@ConfigurationProperties`) in Spring Boot 2.6+?
- How does `@ConfigurationProperties` interact with `@Profile`?
- What happens at startup if a required `@ConfigurationProperties` field is missing or invalid?
- Can `@ConfigurationProperties` properties be refreshed at runtime via Spring Cloud?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.