Configuration precedence order in Spring Boot - Step-by-Step Execution

Concept Flow - Configuration precedence order

Default Properties

↓

application.properties/yml

↓

Profile-specific Properties

↓

Command Line Arguments

↓

Environment Variables

↓

@PropertySource Annotations

↓

Spring Boot Config Files in External Locations

↓

Final Resolved Property

Spring Boot loads configuration properties in a specific order, where later sources override earlier ones.

Execution Sample

Spring Boot

spring.application.name=defaultApp
spring.application.name=profileApp
spring.application.name=cliApp

Shows how the same property is overridden by profile and then command line arguments.

Execution Table

Step	Source	Property Key	Value Loaded	Override Previous?
1	Default Properties	spring.application.name	defaultApp	No
2	application.properties	spring.application.name	defaultApp	No (same value)
3	Profile-specific Properties	spring.application.name	profileApp	Yes
4	Command Line Arguments	spring.application.name	cliApp	Yes
5	Environment Variables	spring.application.name	cliApp	No (same value)
6	@PropertySource Annotations	spring.application.name	cliApp	No (same value)
7	External Config Files	spring.application.name	cliApp	No (same value)
8	Final Resolved Property	spring.application.name	cliApp	Final value after all overrides

💡 All sources checked; final property value is from command line arguments.

Variable Tracker

Property	Default	application.properties	Profile-specific	Command Line	Environment	PropertySource	External	Final
spring.application.name	defaultApp	defaultApp	profileApp	cliApp	cliApp	cliApp	cliApp	cliApp

Key Moments - 2 Insights

Why does the command line argument override profile-specific properties?

Because in the execution_table, step 4 shows command line arguments loaded after profile-specific properties (step 3), so it takes precedence.

If environment variables have the same property, do they always override command line arguments?

No, as shown in step 5, environment variables load after command line arguments but do not override if the value is the same.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the property value change from 'profileApp' to 'cliApp'?

A Step 4

B Step 3

C Step 5

D Step 2

💡 Hint

Check the 'Value Loaded' and 'Override Previous?' columns in execution_table rows 3 and 4.

According to variable_tracker, what is the final value of 'spring.application.name'?

A defaultApp

B profileApp

C cliApp

D environmentApp

💡 Hint

Look at the 'Final' column for 'spring.application.name' in variable_tracker.

If you remove the command line argument, which source provides the final property value?

A Environment Variables

B Profile-specific Properties

C Default Properties

D application.properties

💡 Hint

Refer to the order in concept_flow and execution_table where command line arguments override profile-specific properties.

Concept Snapshot

Spring Boot loads configuration properties in this order:
1. Default properties
2. application.properties or .yml
3. Profile-specific properties
4. Command line arguments
5. Environment variables
6. @PropertySource annotations
7. External config files
Later sources override earlier ones.

Full Transcript

Spring Boot reads configuration properties from multiple sources in a specific order. It starts with default properties, then loads application.properties or application.yml files. Next, it loads profile-specific properties that override previous values. Command line arguments come after and override profile properties. Environment variables and @PropertySource annotations are loaded later, followed by external configuration files. The final property value is the one from the highest precedence source. This order ensures flexible configuration management where you can override settings easily for different environments or runtime needs.