skip to content

Externalized Configuration

4 roadmaps36 questions

Configuration for a fleet rather than one app: a config server over git or Vault, the client side, refresh, cluster-wide broadcast, encryption, and the Kubernetes-native alternatives. Interviewers ask how a password gets to fifty instances without being committed anywhere.

part ofSpring Frameworkoverview, primer and where to startread it →
on this pageshow

explore

questions

page 2 of 2

As an architect, how do you decide between @RefreshScope runtime refresh, plain @ConfigurationProperties rebind, and a full restart/redeploy for a config change — and what are the tradeoffs and risks?

level: principalimportance: should knowfreq 25%

basics

~20 s

Use @ConfigurationProperties rebind for simple tunables that change in place; add @RefreshScope only when a bean must fully rebuild on config change. Prefer a restart/redeploy for structural or safety-critical changes, since runtime refresh has weaker guarantees and audit trail.

open as a page

Explain how Spring Cloud Vault integrates the PKI secret engine, and how you'd architect Vault as a startup dependency (auth, fail-fast, availability) for a production service.

level: principalimportance: should knowfreq 22%

basics

~20 s

Vault's PKI engine issues short-lived X.509 certificates. Spring Cloud Vault requests a cert from pki/issue/<role> and can expose it as a Java KeyStore for TLS, renewing before expiry via leases. Architecturally you pick a non-token auth (AppRole/Kubernetes), set fail-fast per risk tolerance, and treat Vault HA/availability as a boot dependency.

open as a page

As an architect, how would you automate cluster-wide config propagation with the Bus, and what are its trade-offs versus alternatives at scale?

level: principalimportance: nice to knowfreq 20%

basics

~20 s

Instead of curling busrefresh by hand, wire the Config Server's git webhook to spring-cloud-config-monitor so a push auto-fires the Bus refresh. Trade-offs: you add broker infrastructure, get eventual (not atomic) propagation, and no strong ordering — fine for config, not for critical coordination.

open as a page

Design a resilient Config Client startup: reconcile fail-fast, retry, optional:, and precedence for a service that must not boot with wrong config but should survive Config Server restarts. What trade-offs do you weigh?

level: principalimportance: nice to knowfreq 34%

basics

~20 s

Use a non-optional configserver: import with fail-fast=true plus spring-retry so brief outages are retried but a truly missing server aborts startup. Keep secrets from env vars winning via override-system-properties=false, and let central config override local defaults.

open as a page

You're designing at-rest secret protection for config repos across many services using Spring Cloud Config's {cipher} encryption. What are the key-management, rotation, and threat-model concerns, and when would you move beyond {cipher} entirely?

level: principalimportance: nice to knowfreq 20%

basics

~20 s

The encryption key is the single point of trust: protect its custody, plan rotation (which requires re-encrypting values), lock down /decrypt, and use TLS. When you need dynamic secrets, leasing, fine-grained access, and audit, move to a real secrets backend like Vault instead of static {cipher} values.

open as a page

How would you design a Config Server that maps different applications to different git repositories and combines multiple backends? What ordering rules apply?

level: principalimportance: nice to knowfreq 26%

basics

~20 s

Use pattern-based git repos (spring.cloud.config.server.git.repos) to route apps to specific repositories by name pattern, and the composite backend to combine sources like git plus Vault. Property sources from all matched repos are aggregated in configured order, most-specific first.

open as a page

showing 31–36 of 36