Spring Boot YAML vs Properties: Konfigurationsvergleich und Interview-Fragen 2026

Vergleich von application.yml und application.properties in Spring Boot 4.1: Syntax, Multi-Profil-Dateien, Vorrangregeln, mit Jasypt verschlüsselte Secrets und die Konfigurationsfragen aus Interviews.

Spring Boot YAML vs Properties Konfigurationsvergleich

Spring Boot bietet zwei primäre Formate für die Anwendungskonfiguration: YAML und Properties. Beide Formate erfüllen denselben Zweck, unterscheiden sich jedoch erheblich in Syntax, Lesbarkeit und Anwendungsfällen. Der folgende Vergleich zeigt die praktischen Unterschiede und die Interview-Fragen, die rund um die externalisierte Konfiguration in Spring Boot gestellt werden.

Schnelle Entscheidungshilfe

YAML eignet sich für Projekte mit tief verschachtelter Konfiguration oder mehreren Profilen. Properties passen zu einfachen, flachen Konfigurationen oder zu Teams, die mit der YAML-Syntax wenig vertraut sind.

Spring Boot Properties vs YAML im Überblick

Unter Spring Boot 4.1, der aktuellen Release-Linie, speisen beide Formate dasselbe Environment und werden identisch gebunden. Die Unterschiede liegen in der Syntax, in einigen Laderegeln und im Verhalten, wenn beide Dateien vorhanden sind.

MerkmalYAMLProperties
Verschachtelte KonfigurationNative HierarchiePunktnotation
Mehrere Profile in einer DateiTrenner ---Trenner #--- oder !---
ListensyntaxNative YAML-ArraysIndexnotation [0], [1]
Kommentare# in jeder Zeile# oder ! in jeder Zeile
Ladbar mit @PropertySourceNeinJa
Beide Dateien am selben OrtWird überschriebenHat Vorrang
LernkurveEinrückungssensitivMinimal

Die letzten beiden Zeilen übersehen Kandidaten am häufigsten. Die Spring-Boot-Referenz zur externen Konfiguration hält fest, dass YAML-Dateien nicht über @PropertySource oder @TestPropertySource geladen werden können und dass bei application.properties und application.yml im selben Verzeichnis der Wert aus .properties gewinnt. Die offizielle Empfehlung lautet, für die gesamte Anwendung ein einziges Format zu wählen.

Grundlegende Syntaxunterschiede

Der fundamentale Unterschied liegt in der Strukturierung der Konfigurationswerte. Properties-Dateien verwenden eine flache Schlüssel-Wert-Struktur, während YAML hierarchische Daten mit Einrückung darstellt.

Properties-Format

properties
# 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

YAML-Format

yaml
# 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

Vorteile von YAML-Konfiguration

YAML bietet mehrere Vorteile für komplexe Konfigurationen. Die hierarchische Struktur reduziert Redundanz und verbessert die Lesbarkeit erheblich.

yaml
# Mehrere Profile in einer Datei
spring:
  profiles:
    active: development

---
spring:
  config:
    activate:
      on-profile: development
  datasource:
    url: jdbc:h2:mem:devdb
    driver-class-name: org.h2.Driver

logging:
  level:
    root: DEBUG
    com.example: TRACE

---
spring:
  config:
    activate:
      on-profile: production
  datasource:
    url: jdbc:postgresql://prod-server:5432/proddb
    driver-class-name: org.postgresql.Driver

logging:
  level:
    root: WARN
    com.example: INFO

Die Dokumententrennung mit --- ermöglicht die Definition mehrerer Profile in einer einzigen Datei. Diese Konsolidierung vereinfacht die Verwaltung umgebungsspezifischer Einstellungen.

Properties-Dateien unterstützen dasselbe Multi-Dokument-Layout. Eine Zeile, die nur #--- (oder !---) enthält, teilt die Datei in Dokumente:

properties
# 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

Der Trenner darf kein führendes Leerzeichen haben und muss aus genau drei Bindestrichen bestehen. Seit Spring Boot 2.4 ersetzt die Eigenschaft spring.config.activate.on-profile in beiden Formaten die ältere Syntax spring.profiles.

Interview-Falle

"Properties-Dateien brauchen eine Datei pro Profil" ist eine häufige falsche Antwort. Multi-Dokument-Dateien im .properties-Format gibt es seit Spring Boot 2.4. Die eigentliche Einschränkung betrifft YAML: Es lässt sich nicht mit @PropertySource laden.

Profilaktivierung, Profilgruppen und @Profile-Beans werden im Interview-Modul zu Profilen und Umgebungen trainiert.

Listen und komplexe Datenstrukturen

YAML behandelt Listen und verschachtelte Strukturen natürlicher als Properties-Dateien.

yaml
# Liste von Servern
application:
  servers:
    - host: server1.example.com
      port: 8080
      ssl: true
    - host: server2.example.com
      port: 8081
      ssl: false

  allowed-origins:
    - https://example.com
    - https://app.example.com
    - https://admin.example.com

  features:
    authentication:
      enabled: true
      providers:
        - oauth2
        - ldap
    caching:
      enabled: true
      ttl: 3600

Das entsprechende Properties-Format erfordert indexierte Notation:

properties
# Gleiche Konfiguration in Properties
application.servers[0].host=server1.example.com
application.servers[0].port=8080
application.servers[0].ssl=true
application.servers[1].host=server2.example.com
application.servers[1].port=8081
application.servers[1].ssl=false

application.allowed-origins[0]=https://example.com
application.allowed-origins[1]=https://app.example.com
application.allowed-origins[2]=https://admin.example.com

application.features.authentication.enabled=true
application.features.authentication.providers[0]=oauth2
application.features.authentication.providers[1]=ldap
application.features.caching.enabled=true
application.features.caching.ttl=3600

Configuration Properties Binding

Spring Boot ermöglicht typsichere Konfigurationsbindung mit der @ConfigurationProperties-Annotation:

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

@Component
@ConfigurationProperties(prefix = "application")
public class ApplicationConfig {
    
    private List<ServerConfig> servers;
    private List<String> allowedOrigins;
    private FeaturesConfig features;
    
    // Getters and setters
    
    public static class ServerConfig {
        private String host;
        private int port;
        private boolean ssl;
        
        // Getters and setters
    }
    
    public static class FeaturesConfig {
        private AuthConfig authentication;
        private CacheConfig caching;
        
        // Getters and setters
    }
    
    public static class AuthConfig {
        private boolean enabled;
        private List<String> providers;
        
        // Getters and setters
    }
    
    public static class CacheConfig {
        private boolean enabled;
        private int ttl;
        
        // Getters and setters
    }
}

Umgebungsvariablen und Externalisierung

Beide Formate unterstützen die Überschreibung durch Umgebungsvariablen. Spring Boot konvertiert automatisch zwischen den Formaten:

bash
# Überschreiben von Konfigurationswerten
export SPRING_DATASOURCE_URL=jdbc:postgresql://prod:5432/db
export SPRING_DATASOURCE_USERNAME=produser
export SERVER_PORT=9090

# Listen können durch Kommas getrennt werden
export APPLICATION_ALLOWED_ORIGINS=https://a.com,https://b.com
yaml
# Referenzierung von Umgebungsvariablen in YAML
spring:
  datasource:
    url: ${DB_URL:jdbc:h2:mem:default}
    username: ${DB_USER:sa}
    password: ${DB_PASSWORD:}

application:
  api-key: ${API_KEY}
  secret: ${APP_SECRET:default-secret}

Validation mit Bean Validation

Konfigurationseigenschaften können mit Jakarta Bean Validation validiert werden:

java
import jakarta.validation.constraints.*;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.validation.annotation.Validated;

@Validated
@ConfigurationProperties(prefix = "application.security")
public class SecurityConfig {
    
    @NotBlank(message = "JWT secret is required")
    private String jwtSecret;
    
    @Min(value = 300, message = "Token expiration must be at least 5 minutes")
    @Max(value = 86400, message = "Token expiration cannot exceed 24 hours")
    private int tokenExpiration = 3600;
    
    @NotEmpty(message = "At least one allowed origin is required")
    private List<@URL String> allowedOrigins;
    
    @Email
    private String adminEmail;
    
    // Getters and setters
}

Profilspezifische Konfiguration

Spring Boot unterstützt profilspezifische Konfigurationsdateien für beide Formate:

text
src/main/resources/
├── application.yml              # Gemeinsame Konfiguration
├── application-dev.yml          # Entwicklungsumgebung
├── application-staging.yml      # Staging-Umgebung
├── application-prod.yml         # Produktionsumgebung
└── application-test.yml         # Testumgebung
yaml
# application-prod.yml
spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 30000

logging:
  level:
    root: WARN
  file:
    name: /var/log/app/application.log

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics

Weitere Übungsfragen zu diesen Dateien enthält das Interview-Modul zu application.properties und YAML.

Bereit für deine Spring Boot-Interviews?

Übe mit unseren interaktiven Simulatoren, Flashcards und technischen Tests.

Häufige Interview-Fragen

Frage 1: Wann sollte YAML gegenüber Properties bevorzugt werden?

YAML eignet sich besser für komplexe, hierarchische Konfigurationen mit verschachtelten Eigenschaften, Listen und mehreren Profilen. Properties-Dateien sind vorzuziehen für einfache Konfigurationen, Legacy-Systeme oder wenn Team-Mitglieder mit YAML-Syntax nicht vertraut sind. Ein harter Grund für Properties: Zusätzliche Dateien, die über @PropertySource importiert werden, müssen .properties-Dateien sein. Hinzu kommt, dass ein falsch gesetztes Leerzeichen in YAML einen Schlüssel stillschweigend unter den falschen Elternknoten verschiebt.

Frage 2: Wie werden mehrere Konfigurationsdateien geladen?

java
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.PropertySource;

@Configuration
@PropertySource({
    "classpath:database.properties",
    "classpath:messaging.properties"
})
public class AdditionalConfig {
}

YAML-Dateien lassen sich laut Referenzdokumentation weder mit @PropertySource noch mit @TestPropertySource direkt laden. Für YAML muss daher eine eigene PropertySourceFactory verwendet werden:

java
import org.springframework.beans.factory.config.YamlPropertiesFactoryBean;
import org.springframework.core.env.PropertiesPropertySource;
import org.springframework.core.io.support.EncodedResource;
import org.springframework.core.io.support.PropertySourceFactory;

import java.util.Properties;

public class YamlPropertySourceFactory implements PropertySourceFactory {
    
    @Override
    public org.springframework.core.env.PropertySource<?> createPropertySource(
            String name, EncodedResource resource) {
        YamlPropertiesFactoryBean factory = new YamlPropertiesFactoryBean();
        factory.setResources(resource.getResource());
        Properties properties = factory.getObject();
        String sourceName = name != null ? name : resource.getResource().getFilename();
        return new PropertiesPropertySource(sourceName, properties);
    }
}

Frage 3: Was ist die Prioritätsreihenfolge der Konfigurationsquellen?

Spring Boot lädt Konfigurationen in dieser Reihenfolge (höhere überschreiben niedrigere):

  1. Kommandozeilenargumente
  2. SPRING_APPLICATION_JSON (inline JSON)
  3. Servlet-Parameter
  4. JNDI-Attribute
  5. Java System Properties
  6. OS-Umgebungsvariablen
  7. Profilspezifische Dateien (application-.yml)
  8. Anwendungskonfiguration (application.yml)
  9. @PropertySource-Annotationen
  10. Standardwerte

Innerhalb der Konfigurationsdateien gilt eine zweite Ordnung: Profilspezifische Dateien überschreiben generische, und Dateien außerhalb des gepackten JARs überschreiben Dateien im JAR. Am selben Ort überschreibt .properties die .yml. Wer erklären kann, warum ein in application.yml gesetzter Wert stillschweigend ignoriert wird (eine vergessene application.properties daneben), zeigt echte Debugging-Erfahrung.

Frage 4: Wie werden Secrets sicher verwaltet?

yaml
# Verwendung von Spring Cloud Config Server oder Vault
spring:
  cloud:
    vault:
      uri: https://vault.example.com
      token: ${VAULT_TOKEN}
      kv:
        enabled: true
        backend: secret

  config:
    import:
      - vault://secret/application
      - vault://secret/database

Frage 5: Was ist Jasypt und wie verschlüsselt es Spring-Boot-Properties?

Jasypt Spring Boot entschlüsselt in ENC(...) eingeschlossene Werte beim Aufbau des Environment. Verschlüsselte Secrets können so in application.yml oder application.properties liegen und werden wie normale Werte gebunden:

properties
# application.properties
spring.datasource.password=ENC(nrmZtkF7T0kjG/VodDvBw93Ct8EgjCA+)
bash
# The master password is supplied at runtime, never committed
java -Djasypt.encryptor.password=$JASYPT_MASTER_KEY -jar app.jar

jasypt.encryptor.password ist die einzige Pflichteigenschaft, der Standardalgorithmus ist PBEWITHHMACSHA512ANDAES_256. Das Format spielt keine Rolle: Derselbe ENC(...)-Wert funktioniert in YAML und in Properties.

Die Antwort, die einen Senior-Kandidaten auszeichnet: Jasypt entfernt das Secret nicht, es verlagert es. Wer das Master-Passwort besitzt, kann jeden Wert im Repository entschlüsseln, und eine Rotation bedeutet, alle Werte neu zu verschlüsseln. Vault oder ein Secret Manager eines Cloud-Anbieters bringen Zugriffskontrolle, Audit und Rotation mit, Jasypt nicht.

Kompatibilität vor dem Upgrade prüfen

Der Starter 4.0.x (4.0.4, Januar 2026) setzt Java 17 und Spring Boot 3.5+ voraus, seine README nennt Spring Boot 4 nicht. Die zugrunde liegende Jasypt-Bibliothek hat seit Version 1.9.3 im Mai 2019 kein Release mehr erhalten. Vor der Migration eines Jasypt-Projekts auf Spring Boot 4 sollte der Starter auf einem eigenen Branch geprüft werden.

Frage 6: Wie funktioniert Relaxed Binding?

Spring Boot unterstützt verschiedene Schreibweisen für dieselbe Eigenschaft:

yaml
# Alle diese Formen sind äquivalent
application:
  apiKey: value      # Camel Case
  api-key: value     # Kebab Case (empfohlen)
  api_key: value     # Underscore
  API_KEY: value     # Uppercase (für Umgebungsvariablen)

Best Practices für Produktionsumgebungen

yaml
# application-prod.yml mit bewährten Praktiken
spring:
  datasource:
    url: ${DATABASE_URL}
    username: ${DATABASE_USERNAME}
    password: ${DATABASE_PASSWORD}
    hikari:
      maximum-pool-size: ${DB_POOL_SIZE:10}
      leak-detection-threshold: 60000

  jpa:
    open-in-view: false
    properties:
      hibernate:
        jdbc:
          batch_size: 50
        order_inserts: true
        order_updates: true

server:
  shutdown: graceful
  tomcat:
    accept-count: 100
    max-connections: 10000
    threads:
      max: 200
      min-spare: 10

management:
  server:
    port: 8081
  endpoints:
    web:
      exposure:
        include: health,info,prometheus
  endpoint:
    health:
      show-details: when_authorized
      probes:
        enabled: true

logging:
  pattern:
    console: "%d{ISO8601} [%thread] %-5level %logger{36} - %msg%n"
  level:
    root: INFO
    org.springframework.web: WARN
    org.hibernate.SQL: WARN

Quellen

Fang an zu üben!

Teste dein Wissen mit unseren Interview-Simulatoren und technischen Tests.

Was bei der Wahl zwischen YAML und Properties zählt

Die Wahl zwischen YAML und Properties hängt von den spezifischen Projektanforderungen ab. YAML bietet bessere Lesbarkeit und Struktur für komplexe Konfigurationen, während Properties-Dateien Einfachheit und breite Tool-Unterstützung bieten. Moderne Spring-Boot-Anwendungen tendieren zu YAML aufgrund der natürlichen Darstellung hierarchischer Daten und der Möglichkeit, mehrere Profile in einer Datei zu definieren. Properties-Dateien können das inzwischen ebenfalls, mit dem Trenner #---. Liegen beide Dateien am selben Ort, gewinnt .properties, und nur Properties-Dateien lassen sich mit @PropertySource laden. Unabhängig vom gewählten Format sollten sensible Daten immer über Umgebungsvariablen oder externe Konfigurationsdienste wie HashiCorp Vault oder Spring Cloud Config Server bereitgestellt werden. Mit Jasypt verschlüsselte ENC(...)-Werte verlagern das Secret lediglich auf das Master-Passwort.

Tägliche Challenge

Findest du den Bug in Spring Boot?

Ein echter Codeausschnitt, ein versteckter Bug, ein Versuch pro Tag. Zum Ausprobieren ohne Konto.

Anthony Fillion-Maillet

Geschrieben von

Anthony Fillion-Maillet

Gründer von SharpSkill

Seit über 10 Jahren Fullstack-Entwickler. Er leitet SharpSkill und verantwortet alles, was hier erscheint.

Aktualisiert am 27. Oktober 2026

Tags

#spring-boot
#java
#yaml
#properties
#configuration
#interview

Teilen

Verwandte Artikel