Spring Boot YAML vs Properties: Configuration Comparison and Interview Questions 2026

Spring Boot supports two configuration formats out of the box: YAML (application.yml) and Properties (application.properties). Both achieve the same goal, but they differ in syntax, readability, and specific use cases. This comparison breaks down the practical differences and covers the interview questions that come up around Spring Boot externalized configuration.

Spring Boot Properties vs YAML at a Glance

On Spring Boot 4.1, the current release line, both formats feed the same Environment and bind identically. The differences are syntax, a few loading rules, and what happens when both files exist.

The last two rows are the ones candidates usually miss. The Spring Boot external configuration reference states that YAML files cannot be loaded through @PropertySource or @TestPropertySource, and that when application.properties and application.yml sit side by side, the .properties value wins. The official recommendation is to pick one format for the whole application.

Syntax Comparison Between YAML and Properties

The most visible difference is how each format represents hierarchical data. Properties files use dot notation on every line, while YAML uses indentation to express nesting.

# application.properties
server.port=8080
server.servlet.context-path=/api
spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.datasource.username=admin
spring.datasource.password=${DB_PASSWORD}
spring.jpa.hibernate.ddl-auto=validate
spring.jpa.show-sql=false

The equivalent YAML configuration groups related settings visually:

# application.yml
server:
  port: 8080
  servlet:
    context-path: /api

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/mydb
    username: admin
    password: ${DB_PASSWORD}
  jpa:
    hibernate:
      ddl-auto: validate
    show-sql: false

YAML reduces repetition when multiple properties share the same prefix. In the properties file, spring.datasource appears three times, while YAML declares it once.

Profile Management in Spring Boot Configuration

Spring Boot profiles allow different configurations for development, staging, and production environments. Both formats support profile-specific files and multi-document files.

The classic approach uses one file per profile:

# application-dev.properties
server.port=8080
spring.datasource.url=jdbc:h2:mem:devdb
logging.level.root=DEBUG

# application-prod.properties
server.port=80
spring.datasource.url=jdbc:postgresql://prod-server:5432/proddb
logging.level.root=WARN

YAML supports multi-document syntax within a single file using the --- separator:

# application.yml
spring:
  profiles:
    active: dev

---
spring:
  config:
    activate:
      on-profile: dev
server:
  port: 8080
logging:
  level:
    root: DEBUG

---
spring:
  config:
    activate:
      on-profile: prod
server:
  port: 80
logging:
  level:
    root: WARN

Properties files support the same multi-document layout. A line containing only #--- (or !---) splits the file into documents:

# application.properties
spring.profiles.active=dev
#---
spring.config.activate.on-profile=dev
server.port=8080
logging.level.root=DEBUG
#---
spring.config.activate.on-profile=prod
server.port=80
logging.level.root=WARN

The separator must have no leading whitespace and exactly three hyphens. Since Spring Boot 2.4, the spring.config.activate.on-profile property replaced the older spring.profiles syntax, in both formats.

Profile activation, groups and @Profile beans are drilled in the profiles and environment interview module.

Lists and Complex Data Structures

YAML excels at representing lists and nested structures. This matters for configurations like security rules, CORS mappings, or custom beans.

# application.yml
app:
  security:
    allowed-origins:
      - https://sharpskill.dev
      - https://api.sharpskill.dev
    cors:
      allowed-methods:
        - GET
        - POST
        - PUT
        - DELETE
    jwt:
      secret: ${JWT_SECRET}
      expiration-ms: 86400000

The properties equivalent requires index notation:

# application.properties
app.security.allowed-origins[0]=https://sharpskill.dev
app.security.allowed-origins[1]=https://api.sharpskill.dev
app.security.cors.allowed-methods[0]=GET
app.security.cors.allowed-methods[1]=POST
app.security.cors.allowed-methods[2]=PUT
app.security.cors.allowed-methods[3]=DELETE
app.security.jwt.secret=${JWT_SECRET}
app.security.jwt.expiration-ms=86400000

Adding a new origin to the YAML file means appending a line. In properties, every existing index must stay correct, and the new entry needs the next index number.

Type-Safe Configuration with @ConfigurationProperties

Spring Boot binds configuration values to Java classes through @ConfigurationProperties. Both formats work identically with this annotation.

import org.springframework.boot.context.properties.ConfigurationProperties;
import java.util.List;

@ConfigurationProperties(prefix = "app.security")
public record AppSecurityProperties(
    List<String> allowedOrigins,
    CorsConfig cors,
    JwtConfig jwt
) {
    public record CorsConfig(List<String> allowedMethods) {}
    public record JwtConfig(String secret, long expirationMs) {}
}

Spring Boot relaxed binding converts between different naming conventions automatically. The property app.security.allowed-origins binds to allowedOrigins regardless of whether the source is YAML or properties.

import org.springframework.context.annotation.Configuration;
import org.springframework.boot.context.properties.EnableConfigurationProperties;

@Configuration
@EnableConfigurationProperties(AppSecurityProperties.class)
public class SecurityConfig {
    
    private final AppSecurityProperties securityProperties;
    
    public SecurityConfig(AppSecurityProperties securityProperties) {
        this.securityProperties = securityProperties;
    }
    
    // CORS configuration using securityProperties.cors().allowedMethods()
}

For more on Spring Security configuration patterns, see the Spring Security basics module.

Common Interview Questions About Spring Boot Configuration

Configuration is a frequent topic in Spring Boot interviews. Interviewers assess understanding of externalized configuration, environment-specific settings, and property binding.

Question: What is the order of precedence for configuration sources?

Spring Boot loads configuration from multiple sources in a specific order. Higher precedence sources override lower ones (simplified from the official list, which also covers JNDI, servlet parameters and test annotations):

1. Command-line arguments (--server.port=9000)
2. SPRING_APPLICATION_JSON (inline JSON in an environment variable or system property)
3. Java system properties (-Dserver.port=9000)
4. OS environment variables (SERVER_PORT=9000)
5. Config data files (application.yml, application.properties and their profile variants)
6. @PropertySource annotations
7. Default properties via SpringApplication.setDefaultProperties

Inside step 5 there is a second ordering: profile-specific files override generic ones, and files outside the packaged jar override files inside it. Within one location, .properties overrides .yml. A candidate who can explain why a value set in application.yml is silently ignored (a leftover application.properties next to it) shows real debugging experience.

Question: When would you choose properties over YAML?

Properties files have advantages in specific situations:

• @PropertySource loading: YAML cannot be loaded this way, so extra files imported through the annotation must be .properties
• Team familiarity: Properties syntax is simpler for developers new to Spring Boot
• Single-line values: Flat configurations without nesting gain nothing from YAML
• No indentation errors: a misplaced space in YAML silently moves a key under the wrong parent

YAML works better when:

• Configuration has deep nesting (three or more levels)
• Lists require frequent modification
• Readability matters for complex configurations

Question: How do you handle sensitive configuration values?

Never commit secrets to version control. Spring Boot provides several approaches:

# application.yml - reference environment variable
spring:
  datasource:
    password: ${DB_PASSWORD}

For production systems, Spring Cloud Config Server or HashiCorp Vault provide centralized secret management. The Actuator monitoring guide covers securing sensitive endpoints.

Question: What is Jasypt and how does it encrypt Spring Boot properties?

Jasypt Spring Boot decrypts values wrapped in ENC(...) when the Environment is built, so encrypted secrets can live in application.yml or application.properties and still bind like plain values:

# application.properties
spring.datasource.password=ENC(nrmZtkF7T0kjG/VodDvBw93Ct8EgjCA+)

# The master password is supplied at runtime, never committed
java -Djasypt.encryptor.password=$JASYPT_MASTER_KEY -jar app.jar

jasypt.encryptor.password is the only required property, and the default algorithm is PBEWITHHMACSHA512ANDAES_256. The format makes no difference: the same ENC(...) value works in YAML and properties.

The answer that separates a senior candidate: Jasypt does not remove the secret, it moves it. Whoever holds the master password can decrypt every value in the repository, and rotating it means re-encrypting all of them. Vault or a cloud secret manager adds access control, auditing and rotation, which Jasypt does not.

Validating @ConfigurationProperties at Startup

Spring Boot validates @ConfigurationProperties classes at startup when combined with Jakarta Bean Validation annotations.

import jakarta.validation.constraints.NotBlank;
import jakarta.validation.constraints.Positive;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.validation.annotation.Validated;

@Validated
@ConfigurationProperties(prefix = "app.database")
public record DatabaseProperties(
    @NotBlank String url,
    @NotBlank String username,
    @Positive int poolSize
) {}

If app.database.pool-size is missing or negative, the application fails fast during startup with a clear error message. This validation works identically for YAML and properties sources.

Environment-Specific Configuration Files

Spring Boot supports additional configuration file locations beyond the default src/main/resources. The spring.config.import property loads external files:

# application.yml
spring:
  config:
    import:
      - optional:file:./config/
      - optional:configserver:http://config-server:8888

The optional: prefix prevents startup failure when the file does not exist. This pattern enables local development with default values while production pulls configuration from a central server. More practice questions on these files are in the application.properties and YAML interview module.

Sources

• Spring Boot reference: Externalized Configuration: property source order, multi-document #--- properties files, .properties precedence over YAML, no YAML in @PropertySource
• Spring Boot releases: 4.1.2 is the current GA release (October 2026)
• Jasypt Spring Boot README: ENC(...) syntax, default algorithm, Spring Boot 3.5+ requirement

Key Takeaways for Spring Boot Configuration

• YAML reduces repetition for configurations with shared prefixes and handles lists more cleanly
• Properties files work well for flat configurations and teams less familiar with YAML syntax
• Spring Boot 4.1 treats both formats equally for @ConfigurationProperties binding and validation
• Both formats support several profiles in one file: --- in YAML, #--- in properties
• When both files exist in the same location, .properties wins, and only properties files can be loaded with @PropertySource
• Configuration precedence follows a defined order: command-line arguments override environment variables, which override file-based configuration
• Sensitive values belong in environment variables or secret management systems; Jasypt ENC(...) values only move the secret to the master password
• Use spring.config.import to load configuration from external sources in production environments