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 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.
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.
| Merkmal | YAML | Properties |
|---|---|---|
| Verschachtelte Konfiguration | Native Hierarchie | Punktnotation |
| Mehrere Profile in einer Datei | Trenner --- | Trenner #--- oder !--- |
| Listensyntax | Native YAML-Arrays | Indexnotation [0], [1] |
| Kommentare | # in jeder Zeile | # oder ! in jeder Zeile |
Ladbar mit @PropertySource | Nein | Ja |
| Beide Dateien am selben Ort | Wird überschrieben | Hat Vorrang |
| Lernkurve | Einrückungssensitiv | Minimal |
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
# 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=falseYAML-Format
# 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: falseVorteile von YAML-Konfiguration
YAML bietet mehrere Vorteile für komplexe Konfigurationen. Die hierarchische Struktur reduziert Redundanz und verbessert die Lesbarkeit erheblich.
# 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: INFODie 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:
# 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=WARNDer 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.
"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.
# 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: 3600Das entsprechende Properties-Format erfordert indexierte Notation:
# 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=3600Configuration Properties Binding
Spring Boot ermöglicht typsichere Konfigurationsbindung mit der @ConfigurationProperties-Annotation:
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:
# Ü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# 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:
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:
src/main/resources/
├── application.yml # Gemeinsame Konfiguration
├── application-dev.yml # Entwicklungsumgebung
├── application-staging.yml # Staging-Umgebung
├── application-prod.yml # Produktionsumgebung
└── application-test.yml # Testumgebung# 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,metricsWeitere Ü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?
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:
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):
- Kommandozeilenargumente
- SPRING_APPLICATION_JSON (inline JSON)
- Servlet-Parameter
- JNDI-Attribute
- Java System Properties
- OS-Umgebungsvariablen
- Profilspezifische Dateien (application-.yml)
- Anwendungskonfiguration (application.yml)
- @PropertySource-Annotationen
- 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?
# 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/databaseFrage 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:
# 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.jarjasypt.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.
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:
# 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
# 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: WARNQuellen
- Spring-Boot-Referenz: Externalized Configuration: Reihenfolge der Property-Quellen, Multi-Dokument-Properties mit
#---, Vorrang von.propertiesvor YAML, kein YAML in@PropertySource - Spring Boot Releases: 4.1.2 ist das aktuelle GA-Release (Oktober 2026)
- README von Jasypt Spring Boot: Syntax
ENC(...), Standardalgorithmus, Voraussetzung Spring Boot 3.5+
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.
Findest du den Bug in Spring Boot?
Ein echter Codeausschnitt, ein versteckter Bug, ein Versuch pro Tag. Zum Ausprobieren ohne Konto.

Geschrieben von
Anthony Fillion-MailletGründer von SharpSkill
Seit über 10 Jahren Fullstack-Entwickler. Er leitet SharpSkill und verantwortet alles, was hier erscheint.
Aktualisiert am 27. Oktober 2026
Tags
Teilen
Verwandte Artikel

Spring Boot Interview: Transaktions-Propagation erklärt
Beherrsche die Spring Boot Transaktions-Propagation: REQUIRED, REQUIRES_NEW, NESTED und mehr. 12 Interview-Fragen mit Code und typischen Fallstricken.

30 Spring Boot Interviewfragen: Vollständiger Leitfaden für Java-Entwickler
Bereiten Sie sich auf Ihre Spring-Boot-Interviews mit diesen 30 essenziellen Fragen zu Auto-Konfiguration, Startern, Spring Data JPA, Security 7 und Tests vor.

Spring GraphQL Interview: Resolver, DataLoader und Lösungen für das N+1-Problem
Vorbereitung auf Spring GraphQL Interviews mit diesem vollständigen Leitfaden. Resolver, DataLoader, Umgang mit dem N+1-Problem, Mutationen und Best Practices für technische Fragen.