Auto-configuration mechanics, configuration precedence, actuator, and production-readiness concerns.
5 questions in Java & Spring.
First stop the kills: add a Kubernetes startup probe with a budget longer than the worst observed start, and point liveness and readiness at Actuator's separate health groups. Then measure where the 50 seconds goes before tuning, because lazy initialisation only moves the cost onto the first requests.
Ask the running application, not the files. Actuator's env endpoint queried for that property lists the property sources in precedence order with the value each holds, the first holder winning. Then trace it: an environment variable matched by relaxed binding, a profile file, a command-line argument or a JVM system property.
Expose health to the platform, metrics to the scraper, and nothing else over HTTP without authentication, ideally on a separate management port. The quiet leak is heapdump: masking protects the env and configprops responses, but a heap dump holds every secret, token and customer record in memory unmasked.
@Value injects one expression per field with no grouping, no relaxed name matching and no validation. @ConfigurationProperties binds a whole subtree onto a typed object, matches names loosely, handles lists and nested types, and combined with @Validated it fails the context refresh when the environment is wrong.
Spring Boot auto-configuration loads candidate classes from AutoConfiguration.imports, applies conditional annotations, and backs off when your own beans or properties already define the needed behavior.