In a microservices system, why is it best practice to use environment variables for configuration?
Think about how you can change settings without touching the code.
Environment variables let each microservice have its own settings, like database URLs or API keys, without changing the code. This helps keep code clean and flexible.
Which architecture best supports managing environment configurations centrally for many microservices?
Think about a single place to update configs that all services can access.
A centralized config server allows all microservices to fetch their configuration from one place, making updates easier and consistent across services.
You have hundreds of microservices deployed across multiple environments (dev, staging, prod). What is the best approach to scale environment configuration management?
Consider how to manage differences between environments and many services efficiently.
A hierarchical config system lets you define common settings and override them per environment. Combined with a centralized store, it scales well for many services and environments.
What is a key tradeoff when storing sensitive secrets (like API keys) in environment variables for microservices?
Think about what happens if someone gains access to the server or logs.
Environment variables are convenient but not encrypted by default. If the host or logs are accessed by attackers, secrets can be exposed, so additional secret management is recommended.
You have 200 microservices using a centralized config server. You plan to update a common environment variable used by 150 services. What is the best estimate of the impact on the system?
Consider which services actually use the changed variable and how config updates propagate.
Only services that use the updated environment variable need to reload or restart to apply the change. Others remain unaffected, minimizing impact.