Detailed explanation
application.properties and application.yml are two formats for supplying configuration to Spring Boot, not different configuration mechanisms. Both support the same property names, placeholders such as ${DB_URL}, profile-based configuration, and relaxed binding through @ConfigurationProperties. For example, server.port=8081 in properties is equivalent to server:\n port: 8081 in YAML. Choose based on readability, configuration structure, and team conventions rather than assuming either format offers more Spring Boot features. Spring Boot also recognises the .yaml extension.
A properties file normally expresses configuration as flat key=value entries, repeating prefixes such as spring.datasource for related settings. YAML expresses the same structure through indentation, making nested configuration easier to scan. Lists use indexed keys such as app.allowed-hosts[0]=api.example.com in properties, while YAML allows a sequence of '- item' entries beneath allowed-hosts. Under the hood, Spring Boot loads these files into property sources exposed through its Environment. YAML mappings and sequences are represented as property paths and indexed entries; the Binder then converts values into the fields and types declared by @ConfigurationProperties classes.
YAML requires greater care with syntax. Use spaces for indentation: tabs cannot be used for indentation, and incorrect nesting can produce valid YAML with unintended property names. YAML scalar parsing may also interpret values as numbers or booleans; quoting a version such as "1.10" preserves its string representation. Treatment of words such as on and off depends on the YAML parser and schema, so quote them when they must remain strings. Properties avoids indentation-related mistakes but still has escaping and continuation rules.
Configuration precedence is determined by property-source ordering, not readability. If both formats exist in the same location, properties takes precedence for overlapping keys. Command-line arguments and environment variables normally override application-file values, while profile-specific files override their corresponding base files. YAML supports multiple documents separated by ---, but modern Spring Boot also supports multi-document properties using a #--- separator. Both can activate documents with spring.config.activate.on-profile. Finally, @PropertySource does not load YAML directly without custom support. Interviewers generally expect equivalent functionality, syntax differences, precedence, and practical pitfalls—not an unsupported claim that YAML is inherently better for cloud deployments.
Key points to remember
- Both formats populate Spring Boot’s Environment and support the same configuration keys and binding features.
- Properties uses flat entries; YAML uses indentation, nested mappings, and natural list syntax.
- YAML needs careful indentation and quoting; properties has its own escaping rules.
- For overlapping keys in the same location, application.properties takes precedence over application.yml.
- Both support profiles and, in modern Spring Boot, multiple documents; @PropertySource does not support YAML directly.
Common mistakes candidates make
- Claiming that only YAML supports lists, profiles, or multi-document configuration.
- Using tabs for YAML indentation or leaving string-like numbers unquoted.
- Assuming YAML always overrides properties, or that file values override environment variables.
Likely follow-up questions
What happens if both files define server.port?
When both files are in the same location, the value in application.properties takes precedence. A higher-priority source, such as a command-line argument, can still override that value.
How do you configure different environments?
Use files such as application-dev.properties or application-prod.yml and activate the required profile, for example with --spring.profiles.active=prod. Alternatively, use separate documents activated through spring.config.activate.on-profile.
Does @ConfigurationProperties work differently with YAML?
No; it binds from the Environment rather than depending on the original file format. Equivalent properties entries and YAML structures bind to the same Java fields, including nested objects and lists.
Interview tip: Start with “same configuration mechanism, different syntax,” show one equivalent property, and then explain readability, precedence, and YAML pitfalls.