Spring Boot YAML vs Properties: comparación de configuración y preguntas de entrevista 2026

Spring Boot soporta dos formatos de configuración nativos: YAML (application.yml) y Properties (application.properties). Ambos logran el mismo objetivo, pero difieren en sintaxis, legibilidad y casos de uso específicos. Esta comparación desglosa las diferencias prácticas y cubre las preguntas de entrevista que surgen sobre la configuración externalizada de Spring Boot.

Properties vs YAML en Spring Boot de un vistazo

En Spring Boot 4.1, la línea de versiones actual, ambos formatos alimentan el mismo Environment y se vinculan de forma idéntica. Las diferencias están en la sintaxis, en algunas reglas de carga y en lo que ocurre cuando existen los dos archivos.

Las dos últimas filas son las que los candidatos suelen pasar por alto. La referencia de configuración externalizada de Spring Boot indica que los archivos YAML no se pueden cargar mediante @PropertySource ni @TestPropertySource, y que cuando application.properties y application.yml están uno junto al otro, gana el valor del .properties. La recomendación oficial es elegir un solo formato para toda la aplicación.

Comparación de sintaxis entre YAML y Properties

La diferencia más visible es cómo cada formato representa datos jerárquicos. Los archivos Properties usan notación de puntos en cada línea, mientras que YAML usa indentación para expresar anidamiento.

# 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

La configuración YAML equivalente agrupa visualmente las configuraciones relacionadas:

# 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 reduce la repetición cuando múltiples propiedades comparten el mismo prefijo. En el archivo properties, spring.datasource aparece tres veces, mientras que YAML lo declara una sola vez.

Gestión de perfiles en la configuración de Spring Boot

Los perfiles de Spring Boot permiten diferentes configuraciones para entornos de desarrollo, staging y producción. Ambos formatos soportan archivos por perfil y archivos multi-documento.

El enfoque clásico usa un archivo por perfil:

# 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 soporta sintaxis multi-documento dentro de un solo archivo usando el separador ---:

# 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

Los archivos properties admiten la misma organización multi-documento. Una línea que contiene solo #--- (o !---) divide el archivo en documentos:

# 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

El separador no debe tener espacios al inicio de la línea y debe llevar exactamente tres guiones. Desde Spring Boot 2.4, la propiedad spring.config.activate.on-profile reemplazó la sintaxis anterior spring.profiles, en ambos formatos.

La activación de perfiles, los grupos y los beans @Profile se practican en el módulo de entrevista sobre perfiles y entorno.

Listas y estructuras de datos complejas

YAML sobresale en la representación de listas y estructuras anidadas. Esto importa para configuraciones como reglas de seguridad, mapeos CORS o beans personalizados.

# 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

El equivalente en properties requiere notación de índice:

# 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

Agregar un nuevo origen al archivo YAML significa simplemente agregar una línea. En properties, cada índice existente debe permanecer correcto, y la nueva entrada necesita el siguiente número de índice.

Configuración type-safe con @ConfigurationProperties

Spring Boot vincula valores de configuración a clases Java a través de @ConfigurationProperties. Ambos formatos funcionan de manera idéntica con esta anotación.

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) {}
}

El binding relajado de Spring Boot convierte automáticamente entre diferentes convenciones de nomenclatura. La propiedad app.security.allowed-origins se vincula a allowedOrigins independientemente de si la fuente es YAML o 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()
}

Para más información sobre patrones de configuración de Spring Security, consultar el módulo de fundamentos de Spring Security.

Preguntas comunes de entrevista sobre configuración de Spring Boot

La configuración es un tema frecuente en las entrevistas de Spring Boot. Los entrevistadores evalúan la comprensión de la configuración externalizada, configuraciones específicas del entorno y binding de propiedades.

Pregunta: ¿Cuál es el orden de precedencia para las fuentes de configuración?

Spring Boot carga la configuración desde múltiples fuentes en un orden específico. Las fuentes de mayor precedencia sobrescriben las de menor (versión simplificada de la lista oficial, que también incluye JNDI, parámetros de servlet y anotaciones de test):

1. Argumentos de línea de comandos (--server.port=9000)
2. SPRING_APPLICATION_JSON (JSON inline en una variable de entorno o propiedad del sistema)
3. Propiedades del sistema Java (-Dserver.port=9000)
4. Variables de entorno del sistema operativo (SERVER_PORT=9000)
5. Archivos de config data (application.yml, application.properties y sus variantes por perfil)
6. Anotaciones @PropertySource
7. Propiedades por defecto vía SpringApplication.setDefaultProperties

Dentro del paso 5 hay un segundo orden: los archivos específicos de un perfil sobrescriben los genéricos, y los archivos fuera del jar empaquetado sobrescriben los que están dentro. En una misma ubicación, .properties sobrescribe .yml. Un candidato capaz de explicar por qué un valor definido en application.yml se ignora sin aviso (un application.properties olvidado al lado) demuestra experiencia real de depuración.

Pregunta: ¿Cuándo elegir properties sobre YAML?

Los archivos properties tienen ventajas en situaciones específicas:

• Carga con @PropertySource: YAML no se puede cargar de esta forma, así que los archivos adicionales importados con la anotación deben ser .properties
• Familiaridad del equipo: la sintaxis properties es más simple para desarrolladores nuevos en Spring Boot
• Valores de una sola línea: las configuraciones planas sin anidamiento no ganan nada con YAML
• Sin errores de indentación: un espacio mal puesto en YAML mueve una clave bajo el padre equivocado sin ningún aviso

YAML funciona mejor cuando:

• La configuración tiene anidamiento profundo (tres o más niveles)
• Las listas requieren modificaciones frecuentes
• La legibilidad importa para configuraciones complejas

Pregunta: ¿Cómo manejar valores de configuración sensibles?

Nunca hacer commit de secretos al control de versiones. Spring Boot proporciona varios enfoques:

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

Para sistemas de producción, Spring Cloud Config Server o HashiCorp Vault proporcionan gestión centralizada de secretos. La guía de monitoreo de Actuator cubre la seguridad de endpoints sensibles.

Pregunta: ¿Qué es Jasypt y cómo cifra las propiedades de Spring Boot?

Jasypt Spring Boot descifra los valores envueltos en ENC(...) cuando se construye el Environment, de modo que los secretos cifrados pueden vivir en application.yml o application.properties y vincularse como valores en texto plano:

# 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 es la única propiedad obligatoria, y el algoritmo por defecto es PBEWITHHMACSHA512ANDAES_256. El formato no cambia nada: el mismo valor ENC(...) funciona en YAML y en properties.

La respuesta que distingue a un candidato senior: Jasypt no elimina el secreto, lo traslada. Quien tenga la contraseña maestra puede descifrar todos los valores del repositorio, y rotarla obliga a volver a cifrarlos todos. Vault o un gestor de secretos en la nube agrega control de acceso, auditoría y rotación, cosas que Jasypt no ofrece.

Validar @ConfigurationProperties al inicio

Spring Boot valida las clases @ConfigurationProperties al inicio cuando se combinan con anotaciones de Jakarta Bean Validation.

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
) {}

Si app.database.pool-size falta o es negativo, la aplicación falla rápidamente durante el inicio con un mensaje de error claro. Esta validación funciona de manera idéntica para fuentes YAML y properties.

Archivos de configuración específicos del entorno

Spring Boot soporta ubicaciones de archivos de configuración adicionales más allá del src/main/resources por defecto. La propiedad spring.config.import carga archivos externos:

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

El prefijo optional: previene el fallo del inicio cuando el archivo no existe. Este patrón habilita el desarrollo local con valores por defecto mientras producción obtiene la configuración desde un servidor central. Más preguntas de práctica sobre estos archivos están en el módulo de entrevista sobre application.properties y YAML.

Fuentes

• Referencia de Spring Boot: Externalized Configuration: orden de las fuentes de propiedades, archivos properties multi-documento con #---, prioridad de .properties sobre YAML, sin YAML en @PropertySource
• Versiones de Spring Boot: 4.1.2 es la versión GA actual (octubre de 2026)
• README de Jasypt Spring Boot: sintaxis ENC(...), algoritmo por defecto, requisito de Spring Boot 3.5+

Puntos clave para la configuración de Spring Boot

• YAML reduce la repetición para configuraciones con prefijos compartidos y maneja listas de manera más limpia
• Los archivos properties funcionan bien para configuraciones planas y equipos menos familiarizados con la sintaxis YAML
• Spring Boot 4.1 trata ambos formatos de manera igual para binding y validación de @ConfigurationProperties
• Ambos formatos admiten varios perfiles en un solo archivo: --- en YAML, #--- en properties
• Cuando los dos archivos existen en la misma ubicación, gana .properties, y solo los archivos properties se pueden cargar con @PropertySource
• La precedencia de configuración sigue un orden definido: argumentos de línea de comandos sobrescriben variables de entorno, que sobrescriben configuración basada en archivos
• Los valores sensibles pertenecen a variables de entorno o sistemas de gestión de secretos; los valores Jasypt ENC(...) solo trasladan el secreto a la contraseña maestra
• Usar spring.config.import para cargar configuración desde fuentes externas en entornos de producción