Environment configuration in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use environment variables in microservices?

In a microservices system, why is it best practice to use environment variables for configuration?

A They allow each service to have different settings without changing code.

B They force all services to share the same configuration values.

C They automatically encrypt sensitive data without extra setup.

D They make the code run faster by caching configuration.

💡 Hint

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.

❓ Architecture

intermediate

Centralized configuration management in microservices

Which architecture best supports managing environment configurations centrally for many microservices?

A Use a centralized config server that microservices query at startup or runtime.

B Each microservice reads its own local config file stored inside its container.

C Hardcode all configuration values in the microservices source code.

D Store configuration in a shared database that microservices update frequently.

💡 Hint

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.

❓ scaling

advanced

Scaling environment configuration for hundreds of microservices

You have hundreds of microservices deployed across multiple environments (dev, staging, prod). What is the best approach to scale environment configuration management?

A Store all environment variables in each service’s container image to avoid external dependencies.

B Use a hierarchical configuration system with environment-specific overrides and a centralized config store.

C Manually update environment variables on each server hosting the microservices.

D Use a single flat configuration file shared by all microservices regardless of environment.

💡 Hint

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.

❓ tradeoff

advanced

Tradeoffs of storing secrets in environment variables

What is a key tradeoff when storing sensitive secrets (like API keys) in environment variables for microservices?

A They automatically rotate secrets without manual intervention.

B Environment variables are encrypted by default, so no extra security is needed.

C They cannot be changed without rebuilding the microservice container image.

D They are easy to use but can be exposed if the host system is compromised or logs environment data.

💡 Hint

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.

❓ estimation

expert

Estimating configuration update impact in a microservices system

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?

A All services will lose connectivity temporarily during the update.

B All 200 services will restart automatically to apply the new config immediately.

C Only the 150 services using the variable need to reload or restart to apply the change.

D No services will be affected until the centralized config server is restarted.

💡 Hint

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.

Practice

1. What is the main purpose of environment configuration in microservices?

easy

A. To write all configuration directly inside the code

B. To hardcode database credentials in the source files

C. To separate settings from code for easier management

D. To avoid using any configuration for faster deployment

Solution

1. Step 1: Understand environment configuration role

   Environment configuration means keeping settings like URLs, credentials, and flags outside the code.

2. Step 2: Identify benefits of separating settings

   This separation allows the same code to run in different environments (dev, test, prod) safely and easily.

3. Final Answer:

   To separate settings from code for easier management -> Option C

4. Quick Check:

   Settings separate from code = B [OK]

Hint: Settings outside code means environment configuration [OK]

Common Mistakes:

• Confusing configuration with code logic
• Hardcoding sensitive data inside source files
• Ignoring environment differences

2. Which of the following is the correct way to access an environment variable named DB_HOST in a microservice?

easy

A. getEnv('DB_HOST')

B. config.get('DB_HOST')

C. env.DB_HOST()

D. process.env.DB_HOST

Solution

1. Step 1: Identify common environment variable access syntax

   In many microservice platforms, environment variables are accessed via process.env.VARIABLE_NAME.

2. Step 2: Match the correct syntax for DB_HOST

   The correct way is process.env.DB_HOST, which reads the variable from the environment.

3. Final Answer:

   process.env.DB_HOST -> Option D

4. Quick Check:

   Environment variables use process.env = A [OK]

Hint: Use process.env.VAR to read environment variables [OK]

Common Mistakes:

• Using function calls instead of direct access
• Confusing config libraries with environment variables
• Using incorrect object names like env or getEnv

3. Given this code snippet in a microservice:

const port = process.env.PORT || 3000;
console.log(port);

If the environment variable PORT is set to 8080, what will be printed?

medium

A. 8080

B. undefined

C. null

D. 3000

Solution

1. Step 1: Understand the fallback logic

   The code uses process.env.PORT || 3000, meaning if PORT is set, use it; otherwise, use 3000.

2. Step 2: Apply the given environment variable value

   Since PORT is set to 8080, the variable port will be 8080.

3. Final Answer:

   8080 -> Option A

4. Quick Check:

   PORT set to 8080 means output 8080 [OK]

Hint: If env var exists, use it; else fallback value [OK]

Common Mistakes:

• Assuming fallback value always prints
• Confusing undefined with fallback
• Ignoring environment variable presence

4. A microservice fails to read environment variables after deployment. Which is the most likely cause?

medium

A. Environment variables were not set in the deployment environment

B. The code uses process.env to read variables

C. The microservice has no network connection

D. The source code has syntax errors unrelated to config

Solution

1. Step 1: Identify common reasons for missing environment variables

   If the microservice cannot read environment variables, often they were not set or loaded properly in the deployment environment.

2. Step 2: Eliminate other options

   Using process.env is correct syntax; network issues or unrelated syntax errors won't cause missing env vars.

3. Final Answer:

   Environment variables were not set in the deployment environment -> Option A

4. Quick Check:

   Missing env vars usually mean not set in environment [OK]

Hint: Check if env vars are set in deployment environment [OK]

Common Mistakes:

• Blaming code syntax for missing env vars
• Ignoring deployment environment setup
• Assuming network issues cause env var problems

5. You want to deploy the same microservice code to development, staging, and production environments. Which approach best uses environment configuration to handle different database URLs safely?

hard

A. Hardcode all database URLs in the source code and comment/uncomment as needed

B. Use environment variables to set the database URL for each environment separately

C. Store all database URLs in a single config file checked into source control

D. Use a random database URL generated at runtime

Solution

1. Step 1: Understand the need for environment-specific settings

   Each environment (dev, staging, prod) has different database URLs for safety and isolation.

2. Step 2: Choose a method that separates config from code and supports environment differences

   Using environment variables allows setting different URLs without changing code or risking secrets in source control.

3. Step 3: Evaluate other options

   Hardcoding or single config files risk errors and security issues; random URLs are impractical.

4. Final Answer:

   Use environment variables to set the database URL for each environment separately -> Option B

5. Quick Check:

   Env vars per environment = safe config management [OK]

Hint: Use env vars for environment-specific secrets and URLs [OK]

Common Mistakes:

• Hardcoding secrets in code
• Checking sensitive config into source control
• Using random or unsafe config values