Introduction

Yes, but there is an important detail: Spring Boot does not think only in terms of "loaded properties files." It builds an ordered list of PropertySource objects, and some of those come from files while others come from environment variables, system properties, command-line arguments, or external configuration imports.

The key concept is PropertySource

If you want to see where configuration came from, inspect the Spring Environment. In a Boot application, that environment contains a chain of property sources in precedence order.

That means the answer is usually not "give me the exact file list" but "show me the property sources that are currently active." Some of those sources represent files such as application.properties or application.yml, while others do not correspond to files at all.

Listing active property sources

The simplest approach is to inject ConfigurableEnvironment and print its property sources at startup:

1import org.springframework.boot.ApplicationArguments;
2import org.springframework.boot.ApplicationRunner;
3import org.springframework.core.env.ConfigurableEnvironment;
4import org.springframework.core.env.PropertySource;
5import org.springframework.stereotype.Component;
6
7@Component
8public class PropertySourcePrinter implements ApplicationRunner {
9
10    private final ConfigurableEnvironment environment;
11
12    public PropertySourcePrinter(ConfigurableEnvironment environment) {
13        this.environment = environment;
14    }
15
16    @Override
17    public void run(ApplicationArguments args) {
18        for (PropertySource<?> propertySource : environment.getPropertySources()) {
19            System.out.println(propertySource.getName());
20        }
21    }
22}

This will show sources such as system properties, environment variables, command-line arguments, and file-based config data. The exact names depend on your Spring Boot version and configuration setup.

Focusing on file-backed configuration

If you care mostly about property files, you can filter for sources whose names suggest config data or whose implementation type is file-backed:

1import org.springframework.boot.ApplicationArguments;
2import org.springframework.boot.ApplicationRunner;
3import org.springframework.core.env.ConfigurableEnvironment;
4import org.springframework.core.env.PropertySource;
5import org.springframework.stereotype.Component;
6
7@Component
8public class FilePropertySourcePrinter implements ApplicationRunner {
9
10    private final ConfigurableEnvironment environment;
11
12    public FilePropertySourcePrinter(ConfigurableEnvironment environment) {
13        this.environment = environment;
14    }
15
16    @Override
17    public void run(ApplicationArguments args) {
18        for (PropertySource<?> propertySource : environment.getPropertySources()) {
19            String name = propertySource.getName();
20
21            if (name.contains("applicationConfig") || name.contains("Config resource")) {
22                System.out.println("File-backed source: " + name);
23            }
24        }
25    }
26}

This is not a perfect API guarantee, but it is often enough for debugging startup configuration and seeing which config files Boot actually loaded.

Using Actuator to inspect configuration

If you already use Spring Boot Actuator, the env endpoint can help you inspect effective configuration values and their origins. In a trusted environment, you can expose the endpoint:

management.endpoints.web.exposure.include=env

Then query it:

curl http://localhost:8080/actuator/env

This is useful when you need runtime visibility without adding temporary logging code. Be careful with security, though, because configuration endpoints can reveal sensitive operational details.

Why the file list can be incomplete or surprising

Spring Boot configuration may come from several places:

• 'application.properties or application.yml on the classpath'
• external files passed through spring.config.location
• additional files from spring.config.additional-location
• profile-specific files such as application-prod.yml
• environment variables and system properties

Because of that, there is not always a one-to-one mapping between the final environment and a set of plain .properties files. The application may be using YAML, imported config trees, or non-file sources that override file values.

Common Pitfalls

• Expecting every property source to correspond to a physical .properties file.
• Assuming the source names are identical across all Spring Boot versions.
• Looking only at classpath config and forgetting external locations or active profiles.
• Exposing Actuator configuration endpoints in production without proper access control.

Summary

• The practical way to inspect loaded config in Spring Boot is to list Environment property sources.
• Some property sources come from files, while others come from environment variables or runtime arguments.
• 'ConfigurableEnvironment#getPropertySources() is the simplest programmatic entry point.'
• Actuator can help inspect active configuration, but it should be exposed carefully.