Spring Boot YAML vs Properties: comparação de configuração e perguntas de entrevista 2026

O Spring Boot oferece suporte nativo a dois formatos de configuração: YAML (application.yml) e Properties (application.properties). Ambos alcançam o mesmo objetivo, mas diferem em sintaxe, legibilidade e casos de uso específicos. Esta comparação detalha as diferenças práticas e aborda as perguntas de entrevista que surgem sobre configuração externalizada do Spring Boot.

Properties vs YAML no Spring Boot: visão geral

No Spring Boot 4.1, a linha de versões atual, os dois formatos alimentam o mesmo Environment e fazem o binding de forma idêntica. As diferenças estão na sintaxe, em algumas regras de carregamento e no que acontece quando os dois arquivos existem.

As duas últimas linhas são as que os candidatos costumam esquecer. A referência de configuração externalizada do Spring Boot informa que arquivos YAML não podem ser carregados via @PropertySource nem @TestPropertySource, e que, quando application.properties e application.yml ficam lado a lado, o valor do .properties vence. A recomendação oficial é escolher um único formato para a aplicação inteira.

Comparação de sintaxe entre YAML e Properties

A diferença mais visível está em como cada formato representa dados hierárquicos. Arquivos Properties usam notação de ponto em cada linha, enquanto YAML usa indentação para expressar aninhamento.

# 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

A configuração YAML equivalente agrupa visualmente as configurações 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 reduz a repetição quando múltiplas propriedades compartilham o mesmo prefixo. No arquivo properties, spring.datasource aparece três vezes, enquanto YAML o declara apenas uma vez.

Gerenciamento de perfis na configuração do Spring Boot

Os perfis do Spring Boot permitem diferentes configurações para ambientes de desenvolvimento, staging e produção. Ambos os formatos suportam arquivos por perfil e arquivos multi-documento.

A abordagem clássica usa um arquivo 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 suporta sintaxe multi-documento dentro de um único arquivo usando o 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

Arquivos properties aceitam a mesma organização multi-documento. Uma linha contendo apenas #--- (ou !---) divide o arquivo em 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

O separador não pode ter espaços no início da linha e deve ter exatamente três hifens. Desde o Spring Boot 2.4, a propriedade spring.config.activate.on-profile substituiu a sintaxe antiga spring.profiles, nos dois formatos.

Ativação de perfis, grupos e beans @Profile são praticados no módulo de entrevista sobre perfis e ambiente.

Listas e estruturas de dados complexas

YAML se destaca na representação de listas e estruturas aninhadas. Isso importa para configurações como regras de segurança, mapeamentos CORS ou 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

O equivalente em properties requer notação 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

Adicionar uma nova origem ao arquivo YAML significa simplesmente adicionar uma linha. Em properties, cada índice existente deve permanecer correto, e a nova entrada precisa do próximo número de índice.

Configuração type-safe com @ConfigurationProperties

O Spring Boot vincula valores de configuração a classes Java através de @ConfigurationProperties. Ambos os formatos funcionam de forma idêntica com esta anotação.

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

O binding relaxado do Spring Boot converte automaticamente entre diferentes convenções de nomenclatura. A propriedade app.security.allowed-origins se vincula a allowedOrigins independentemente de a fonte ser YAML ou 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 mais informações sobre padrões de configuração do Spring Security, consultar o módulo de fundamentos do Spring Security.

Perguntas comuns de entrevista sobre configuração do Spring Boot

A configuração é um tema frequente nas entrevistas de Spring Boot. Os entrevistadores avaliam a compreensão da configuração externalizada, configurações específicas de ambiente e binding de propriedades.

Pergunta: Qual é a ordem de precedência para as fontes de configuração?

O Spring Boot carrega a configuração de múltiplas fontes em uma ordem específica. Fontes de maior precedência sobrescrevem as de menor (versão simplificada da lista oficial, que também cobre JNDI, parâmetros de servlet e anotações de teste):

1. Argumentos de linha de comando (--server.port=9000)
2. SPRING_APPLICATION_JSON (JSON inline em uma variável de ambiente ou propriedade do sistema)
3. Propriedades do sistema Java (-Dserver.port=9000)
4. Variáveis de ambiente do sistema operacional (SERVER_PORT=9000)
5. Arquivos de config data (application.yml, application.properties e suas variantes por perfil)
6. Anotações @PropertySource
7. Propriedades padrão via SpringApplication.setDefaultProperties

Dentro do passo 5 existe uma segunda ordem: arquivos específicos de perfil sobrescrevem os genéricos, e arquivos fora do jar empacotado sobrescrevem os que estão dentro dele. Em um mesmo local, .properties sobrescreve .yml. Um candidato que consegue explicar por que um valor definido no application.yml é ignorado sem aviso (um application.properties esquecido ao lado) mostra experiência real de depuração.

Pergunta: Quando escolher properties em vez de YAML?

Arquivos properties têm vantagens em situações específicas:

• Carregamento com @PropertySource: YAML não pode ser carregado dessa forma, então arquivos extras importados pela anotação precisam ser .properties
• Familiaridade da equipe: a sintaxe properties é mais simples para desenvolvedores novos no Spring Boot
• Valores de uma única linha: configurações planas sem aninhamento não ganham nada com YAML
• Sem erros de indentação: um espaço fora do lugar no YAML move uma chave para o pai errado sem nenhum aviso

YAML funciona melhor quando:

• A configuração tem aninhamento profundo (três ou mais níveis)
• Listas requerem modificações frequentes
• A legibilidade importa para configurações complexas

Pergunta: Como lidar com valores de configuração sensíveis?

Nunca fazer commit de segredos no controle de versão. O Spring Boot fornece várias abordagens:

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

Para sistemas de produção, o Spring Cloud Config Server ou HashiCorp Vault fornecem gerenciamento centralizado de segredos. O guia de monitoramento do Actuator aborda a segurança de endpoints sensíveis.

Pergunta: O que é o Jasypt e como ele criptografa propriedades do Spring Boot?

O Jasypt Spring Boot descriptografa valores envolvidos em ENC(...) quando o Environment é construído, então segredos criptografados podem ficar no application.yml ou no application.properties e ainda fazer o binding como valores em texto puro:

# 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 é a única propriedade obrigatória, e o algoritmo padrão é PBEWITHHMACSHA512ANDAES_256. O formato não faz diferença: o mesmo valor ENC(...) funciona em YAML e em properties.

A resposta que separa um candidato sênior: o Jasypt não elimina o segredo, apenas o desloca. Quem tem a senha mestra consegue descriptografar todos os valores do repositório, e trocá-la exige criptografar todos de novo. O Vault ou um gerenciador de segredos em nuvem acrescenta controle de acesso, auditoria e rotação, o que o Jasypt não oferece.

Validar @ConfigurationProperties na inicialização

O Spring Boot valida classes @ConfigurationProperties na inicialização quando combinadas com anotações do 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
) {}

Se app.database.pool-size estiver ausente ou for negativo, a aplicação falha rapidamente durante a inicialização com uma mensagem de erro clara. Essa validação funciona de forma idêntica para fontes YAML e properties.

Arquivos de configuração específicos do ambiente

O Spring Boot suporta localizações de arquivos de configuração adicionais além do src/main/resources padrão. A propriedade spring.config.import carrega arquivos externos:

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

O prefixo optional: previne falha na inicialização quando o arquivo não existe. Esse padrão permite desenvolvimento local com valores padrão enquanto produção obtém a configuração de um servidor central. Mais perguntas de prática sobre esses arquivos estão no módulo de entrevista sobre application.properties e YAML.

Fontes

• Referência do Spring Boot: Externalized Configuration: ordem das fontes de propriedades, arquivos properties multi-documento com #---, prioridade do .properties sobre YAML, sem YAML em @PropertySource
• Versões do Spring Boot: 4.1.2 é a versão GA atual (outubro de 2026)
• README do Jasypt Spring Boot: sintaxe ENC(...), algoritmo padrão, requisito de Spring Boot 3.5+

Pontos-chave para configuração do Spring Boot

• YAML reduz a repetição para configurações com prefixos compartilhados e lida com listas de forma mais limpa
• Arquivos properties funcionam bem para configurações planas e equipes menos familiarizadas com a sintaxe YAML
• O Spring Boot 4.1 trata ambos os formatos igualmente para binding e validação de @ConfigurationProperties
• Os dois formatos aceitam vários perfis em um único arquivo: --- no YAML, #--- no properties
• Quando os dois arquivos existem no mesmo local, .properties vence, e só arquivos properties podem ser carregados com @PropertySource
• A precedência de configuração segue uma ordem definida: argumentos de linha de comando sobrescrevem variáveis de ambiente, que sobrescrevem configuração baseada em arquivos
• Valores sensíveis pertencem a variáveis de ambiente ou sistemas de gerenciamento de segredos; valores Jasypt ENC(...) apenas deslocam o segredo para a senha mestra
• Utilizar spring.config.import para carregar configuração de fontes externas em ambientes de produção