Spring Boot Config Server — Complete Guide

Spring Cloud Config Server is a centralized configuration management system for distributed applications.
Instead of keeping application.properties or application.yml inside each service, you store all configurations in one central Git repository, and all microservices fetch their configs from there.

✅ Why Use Config Server?

1. Centralized Configurations

All app configs stay in one repo, easier to maintain.

2. Environment-specific configs

Supports dev, qa, prod, etc.

auth-service-dev.yml
auth-service-qa.yml
auth-service-prod.yml

auth-service-dev.yml
auth-service-qa.yml
auth-service-prod.yml

3. Dynamic Refresh

Using @RefreshScope + Actuator /refresh or Bus refresh.

4. Version Control

Every config change is tracked via Git.

5. Secure Secrets Management

Can integrate with Vault, AWS Secrets Manager, Azure KeyVault.

🏗️ 1. Create Config Server

Step 1: Add dependencies

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>

Step 2: Enable Config Server

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}

Step 3: Configure application.yml

server:
  port: 8888

spring:
  application:
    name: config-server

  cloud:
    config:
      server:
        git:
          uri: https://github.com/your-org/config-repo
          clone-on-start: true

server:
  port: 8888

spring:
  application:
    name: config-server

  cloud:
    config:
      server:
        git:
          uri: https://github.com/your-org/config-repo
          clone-on-start: true

📁 2. Config Repo Structure

Your Git repo should look like:

config-repo/
 ├── auth-service.yml
 ├── auth-service-dev.yml
 ├── auth-service-qa.yml
 ├── auth-service-prod.yml
 ├── payment-service.yml
 └── gateway-service.yml

config-repo/
 ├── auth-service.yml
 ├── auth-service-dev.yml
 ├── auth-service-qa.yml
 ├── auth-service-prod.yml
 ├── payment-service.yml
 └── gateway-service.yml

🧪 3. How to Access Configs

Hit the URL:

http://localhost:8888/{application}/{profile}

http://localhost:8888/{application}/{profile}

Example for auth-service-dev.yml:

http://localhost:8888/auth-service/dev

http://localhost:8888/auth-service/dev

🛠️ 4. Client Microservice Setup

Add Dependencies

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>

bootstrap.yml

bootstrap.yml loads before application.yml.

spring:
  application:
    name: auth-service

  profiles:
    active: dev

  cloud:
    config:
      uri: http://localhost:8888

spring:
  application:
    name: auth-service

  profiles:
    active: dev

  cloud:
    config:
      uri: http://localhost:8888

🔄 5. Auto Refresh Configuration (Optional)

Add:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Enable:

management:
  endpoints:
    web:
      exposure:
        include: refresh, health, info

management:
  endpoints:
    web:
      exposure:
        include: refresh, health, info

Add to beans:

@RefreshScope
@Component
public class MyConfig {
    @Value("${my.property}")
    private String value;
}

@RefreshScope
@Component
public class MyConfig {
    @Value("${my.property}")
    private String value;
}

Refresh:

POST http://localhost:8080/actuator/refresh

POST http://localhost:8080/actuator/refresh

🔐 6. Secure Config Access

You can add security:

spring:
  security:
    user:
      name: admin
      password: secret

spring:
  security:
    user:
      name: admin
      password: secret

Client:

spring:
  cloud:
    config:
      username: admin
      password: secret

spring:
  cloud:
    config:
      username: admin
      password: secret

🎯 7. Best Practices

Area	Best Practice
File Naming	Use `{app-name}-{profile}.yml`
Secrets	Use Vault / KMS, not plain text
Refresh	Avoid frequent refresh in production
Git Branching	Use `main`, `dev`, `hotfix` branches

Spring Boot Config Server Interview Questions

Here are well-structured, real-world interview questions on Spring Boot Config Server, from beginner to advanced level. These are suitable for developer + architect roles.

Basic Level (1–10)

1. What is Spring Cloud Config Server?
A centralized configuration service for distributed systems. It serves application configuration properties from a backing store (commonly a Git repo) to client applications at startup and optionally at runtime.

2. Why do we use Config Server in microservices architecture?
To centralize config management: single source of truth, environment separation (dev/qa/prod), version control of configs, easier secret management integrations, and dynamic updates without rebuilding services.

3. What are the advantages of centralized configuration management?
Versioning, consistency across services, easier environment-specific overrides, simplified secret rotation/integration, and reduced duplication of config files.

4. What is the difference between bootstrap.yml and application.yml?
bootstrap.yml (or bootstrap.properties) is loaded before application.yml. It’s used for settings required very early — e.g., Config Server URI and application name — so the app can fetch remote config. application.yml is loaded later and may be overridden by values obtained from Config Server.

5. How does a Spring Boot application fetch properties from Config Server?
At startup the client (via spring-cloud-starter-config) contacts the Config Server at spring.cloud.config.uri with {application}/{profile}/{label} (defaults: profile=default, label=main/master) and receives properties that are merged into its environment.

6. How do you structure files in the Git configuration repository?
Common pattern:

application.yml                 # shared defaults
application-dev.yml
auth-service.yml                # app-specific defaults
auth-service-dev.yml
auth-service-prod.yml

application.yml                 # shared defaults
application-dev.yml
auth-service.yml                # app-specific defaults
auth-service-dev.yml
auth-service-prod.yml

Files named {application}-{profile}.yml and application-{profile}.yml are typical.

7. What is the default URL pattern to fetch configuration from Config Server?
http://{config-server}:{port}/{application}/{profile} or the v2 form /{application}/{profile}/{label} (e.g., http://localhost:8888/auth-service/dev).

8. What happens if the Config Server is down? Will the client application start?
By default clients will fail to start if they require remote properties at bootstrap. You can configure fail-fast behavior and retry or provide fallback/local defaults to allow startup. Without fail-fast, some clients may start with local defaults; with fail-fast=true they will fail.

9. What are profile and label in Config Server?

profile = environment variant (dev, qa, prod).
label = Git branch/tag/commit. Used to fetch specific branch or tag from the repo.

10. What happens when you change a configuration file in Git?
Config Server will serve the new config on next request. Clients won’t automatically pick it up unless refreshed (e.g., POST /actuator/refresh, Spring Cloud Bus broadcast, or client restart). Changes are versioned in Git.

Intermediate Level (11–20)

11. How does Config Server internally read data from Git?
It uses an EnvironmentRepository implementation (usually JGit or native Git) to clone/fetch the repository and resolve files for application/profile/label, then parse YAML/Properties and return them as property sources.

12. What is clone-on-start and when should you use it?
spring.cloud.config.server.git.clone-on-start=true clones the Git repo at server startup (instead of on first request). Use it to avoid latency during the first client request and to fail fast on startup if Git is unreachable.

13. How do you secure Spring Cloud Config Server?
Options:

HTTP basic auth / OAuth2 in server and client (set username/password).
TLS (HTTPS) for transport.
Integrate with Vault/KMS for secrets rather than storing them in Git.
Use Git credentials (SSH keys) restricted to the repo.
Also secure actuator endpoints.

14. How do you configure multiple repositories in config server?
Use the spring.cloud.config.server.git.repositories (composite) configuration to map application patterns to different repo URIs, branches, or basedir.

15. How does the config client know which profile to load?
The client sets spring.profiles.active (or SPRING_PROFILES_ACTIVE) and spring.application.name in bootstrap.yml (or environment) — the client sends those to Config Server.

16. What problems can occur when using @RefreshScope?
Drawer of issues:

It creates proxies; beans should be designed for reinitialization.
Stateful beans may lose state unexpectedly on refresh.
Frequent refresh on many beans can cause latency spikes.
Not all beans are proxied correctly (final classes, direct field injection issues).

17. How does Spring Cloud Bus help with config refresh?
Cloud Bus (backed by a message broker like Rabbit or Kafka) broadcasts config-change events across services. You call /actuator/bus-refresh (or push Git webhook to server) and Bus notifies all clients to refresh automatically.

18. How do you version configurations using Git branches?
Use label to pull from branches (e.g., label=release/1.2). Maintain dev, qa, main branches and map pipeline deployments to appropriate label to get controlled config per release.

19. What is the difference between native filesystem mode vs Git-backed mode?

Git-backed: Config Server clones/fetches from Git and uses repo features (history, branches).
Native (filesystem): Loads config directly from server filesystem — faster but less flexible and lacks Git-based versioning/audit.

20. How do you handle config overrides for Dev, QA, Prod?
Use profile-specific files {app}-{profile}.yml and application-{profile}.yml. Use branching/labels for environment-specific sets, and secrets via Vault or environment-specific secret stores.

Advanced Level (21–30)

21. What are common production issues faced with Config Server?
Examples: Git repo connectivity/latency, single point of failure (mitigate with clustering/proxies), serving stale caches, secrets leaked in Git, client startup delays, improper refresh causing downtime, and misconfigured security.

22. How to implement fail-fast behavior in config clients?
Set spring.cloud.config.fail-fast=true and include Spring Retry by adding spring-retry and spring-boot-starter-actuator. Configure retry properties (max attempts, initial interval) so the client retries a few times, then fails.

23. When Config Server is slow, microservice startup becomes slow. How to solve?
Options:

clone-on-start=true on server to reduce per-request latency.
Cache on server or use local filesystem mode.
Use bootstrap local defaults, then async refresh; or start with cached config and refresh later.
Scale config server instances behind a load balancer.

24. How do you encrypt/decrypt secrets using Config Server?
Config Server supports server-side symmetric/asymmetric encryption. Store encrypted values in Git like {cipher}.... Config Server holds the key (keystore or symmetric key) and exposes /encrypt and /decrypt endpoints (secured). Alternatively, use Vault for better secret handling.

25. What if you want to store secrets in Vault or AWS Secrets Manager instead of Git?
Integrate Config Server with Vault using Spring Cloud Vault (Config Server can proxy Vault values) or configure clients to use Vault/AWS Secrets Manager directly. Both avoid storing secrets in Git.

26. How to configure Config Server to load YAML from multiple Git branches?
Use the {label} path or the spring.cloud.config.server.git.uri with branch placeholders. Also set up multiple repositories in spring.cloud.config.server.git.repositories and use repository mappings by pattern.

27. Can Config Server return merged properties? How does property override order work?
Yes — Config Server merges property sources. General rule: more specific sources override generic ones. Typical precedence: {application}-{profile} (most specific) > {application} > application-{profile} > application (global defaults). In short: app+profile overrides generic application properties.

28. What strategies ensure zero-downtime config updates?

Use rolling, incremental refresh (Cloud Bus with selective refresh).
Avoid restarts; use @RefreshScope where appropriate.
Feature flags and gradual rollout.
Canary refresh: refresh small subset, monitor, then broadcast.

29. How can you cache configuration to reduce Git calls?
On server: use local cloned repo and in-memory caching (implement/enable caching layer). On client: avoid frequent refreshes, use caching or store a local fallback snapshot. Use HTTP caching, CDN, or increase Git fetch intervals.

30. How do you integrate Config Server with Kubernetes ConfigMaps/Secrets?
Options:

Use Spring Cloud Kubernetes to read ConfigMaps/Secrets directly.
Mount ConfigMaps/Secrets into pods and let apps read them.
Or run Config Server that reads from Kubernetes API (less common). For cloud-native deployments, prefer Kubernetes-native config management.

Hands-on / Scenario-Based (31–40)

31. You added a new file in Git repo, but it doesn’t appear in /actuator/health → propertySources. What will you check?

Ensure you committed and pushed to the correct branch/label.
Confirm client requested correct label (branch) and profile.
Check Config Server logs for file parsing errors.
Refresh client (/actuator/refresh) or use Bus to broadcast.
Verify the Config Server actually reads that file path (name must follow conventions).

32. Your config client is loading old values even after committing new ones. How do you debug?

Verify Git push succeeded and Config Server is fetching the latest (check server logs).
Check label/branch used.
Confirm client actually called Config Server (logs/network).
If using cache or local clone, refresh or restart server or trigger server-side git pull.
Trigger client refresh (/actuator/refresh) or use Cloud Bus.

33. When using config server in Docker, configurations are not loading. Why?
Common causes: wrong spring.cloud.config.uri (points to localhost inside container), networking issues between containers, missing Git creds/SSH key in container, or volume mounting errors when using native mode. Use container hostnames and ensure network visibility.

34. What steps do you take if label returns 404 in Config Server?

Confirm the branch/tag (label) exists in the remote Git repo.
Check label parameter format and URL encoding.
Validate server’s Git credentials/permissions.
Look at server logs for git exceptions.

35. How do you handle circular dependency between Config Server and Eureka?
Avoid registering Config Server with Eureka until it has loaded required configuration. Solutions: set Config Server to not use Eureka by disabling discovery or use static bootstrap properties for config server registration. Alternatively, run Eureka first with local config.

36. Your Config Server fails to start because Git repository is unreachable. Solutions?

Use clone-on-start=false so server starts even if Git unreachable (but first request will fail).
Provide a local fallback (native profile with filesystem copy).
Fix network/credentials or add retry config.
Use cached clone or pre-seed repo in container image.

37. In your project, each microservice has 100+ properties. How do you organize configs?

Group properties into logical files (database.yml, logging.yml) or use hierarchical keys.
Keep shared defaults in application.yml.
Use profile-specific files for environment variations.
Use property placeholders and secrets manager for sensitive entries. Consider splitting by feature modules.

38. How do you handle cross-application shared configs?
Place common properties in application.yml or a shared config file (e.g., shared.yml) and include them via naming conventions. Use Spring profiles or a shared microservice config and document which apps depend on which keys.

39. How do you configure a fallback configuration when Git is unavailable?
Use local native repository as fallback (spring.profiles.active=native,git) or include local application.yml defaults inside client bootstrap.yml. You can also serve cached snapshots.

40. How do you debug slow refresh operations in a large distributed system?

Measure timing: where is the latency — Config Server fetch from Git, Bus broadcast, individual client refresh?
Check broker throughput (Rabbit/Kafka) for Cloud Bus.
Avoid refreshing many beans at once; refresh only necessary beans.
Use selective or batched refresh and monitor CPU/GC during refresh.
Implement circuit breakers and rate limiting on refresh endpoints.