When a Spring Boot setting looks wrong, inspect the active profiles and property sources before changing code. The same key can be supplied in several places. Its effective value depends on precedence, not on which file you happened to open first.

These Spring Boot interview questions use a public preview flag. It is safe to inspect because it is not a credential. Keep secrets out of logs and do not expose a full configuration dump to diagnose one setting.

How can a setting have a typed owner?

package example;

import org.springframework.boot.context.properties.ConfigurationProperties;

@ConfigurationProperties(prefix = "catalog")
public record CatalogSettings(boolean previewEnabled) { }

Register this record using EnableConfigurationProperties on a configuration class, or use ConfigurationPropertiesScan from your application package. Constructor-bound records are useful for a small immutable settings group in modern Spring Boot. Do not assume an unregistered type is bound automatically.

# application.properties
catalog.preview-enabled=false
# application-test.properties
catalog.preview-enabled=true

With the test profile active and no higher-priority override, the profile-specific value is true. Without that profile, the base value is false. Those expected values depend on the stated configuration, not on a rule that a particular filename always wins.

What can override a file?

Spring Boot supports multiple property sources, including environment variables, system properties and command-line arguments. For example, a command-line setting can override a packaged default. Consult the documented order for your Boot version and any customized configuration loading.

In an interview, list the actual sources in the scenario, then resolve the conflict. Saying “environment always wins” is too broad when command-line arguments or custom sources are also involved.

What does a profile change?

A profile can select configuration documents or beans. It is useful for an intentional environment or capability choice. It is not an authorization mechanism and does not guarantee that a database points to the correct environment.

Use a small set of understandable profiles. Many overlapping profiles can make the effective configuration difficult to predict. Test combinations you support instead of assuming each isolated profile proves every combination works.

How would you diagnose the wrong value?

  1. Confirm the application instance and artifact version.
  2. Check the active profiles.
  3. Find every source that supplies the specific public key.
  4. Check config locations and startup arguments.
  5. Inspect the bound value through an authorized local test.
  6. Change one source and restart or reload according to the application's supported behavior.

A changed file does not prove a running application loaded that file. Container mounts, working directories and external configuration locations can differ from a developer's local run.

How should missing required values fail?

A boolean has a default false value, which is acceptable only if that is the intended fallback. For a required host or range-limited number, add appropriate configuration-property validation with a Bean Validation provider. Verify startup fails with a useful, non-secret message.

Do not silently replace a missing production endpoint with a local one. A convenient fallback can send work to the wrong service. State which settings have safe defaults and which must be provided explicitly.

Practice question

“The test file says true but the application reads false. What do you check?” A strong answer traces the effective sources and registration before proposing a fix. Then it adds a configuration test so the intended profile behavior remains reviewable.

References and next practice

docs.spring.io — spring config

spring-boot question collection · Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud