Environment-based configuration in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use environment-based configuration in microservices?

In a microservices system, why is environment-based configuration important?

A It removes the need for any configuration management tools.

B It allows each microservice to have different settings for development, testing, and production without changing code.

C It forces all microservices to share the same configuration regardless of environment.

D It makes microservices slower because they must read config files every time they run.

💡 Hint

Think about how settings like database URLs or API keys change between environments.

Environment-based configuration lets microservices adapt to different environments by changing settings without code changes. This supports safer deployments and easier testing.

❓ Architecture

intermediate

Best practice for storing environment configs in microservices

Which approach is best for storing environment-specific configuration in a microservices architecture?

A Hardcode all configs inside the microservice source code for consistency.

B Keep configs in a shared database that all microservices query on every request.

C Store configs in environment variables injected into each service container at runtime.

D Use local config files inside each microservice image that never change.

💡 Hint

Consider security, flexibility, and ease of updates without rebuilding images.

Environment variables injected at runtime allow secure, flexible config changes without rebuilding or redeploying microservices.

❓ scaling

advanced

Scaling environment configuration management for many microservices

You have 50 microservices deployed across multiple environments. What is the best way to manage environment-based configuration at scale?

A Store configs in a shared file system accessed by all microservices.

B Manually update environment variables on each microservice host for every environment.

C Embed all configs inside each microservice image to avoid external dependencies.

D Use a centralized configuration service that microservices query at startup or on config change events.

💡 Hint

Think about automation, consistency, and reducing manual errors.

A centralized config service provides a single source of truth, simplifies updates, and supports dynamic config changes at scale.

❓ tradeoff

advanced

Tradeoff of using environment variables vs config files in microservices

What is a key tradeoff when choosing environment variables over config files for environment-based configuration in microservices?

A Environment variables are easier to inject but harder to version control compared to config files.

B Config files are always more secure than environment variables.

C Environment variables require rebuilding the microservice image for every change.

D Config files cannot be encrypted while environment variables can.

💡 Hint

Consider how changes are tracked and managed in source control.

Environment variables are injected at runtime and not stored in source control, making versioning harder. Config files can be versioned but may require more management.

❓ estimation

expert

Estimating configuration update impact in a microservices system

You have 100 microservices deployed in production. You plan to update a shared environment variable used by 60 of them. How many microservices will need to be restarted or reloaded to apply the new config?

A 60 microservices need restart or reload to pick up the new environment variable.

B All 100 microservices need restart because environment variables are global.

C None need restart because environment variables update automatically at runtime.

D Only 1 microservice needs restart since it can broadcast the change.

💡 Hint

Think about how environment variables are loaded by processes.

Environment variables are loaded when a process starts. To apply changes, each affected microservice must restart or reload config.

Practice

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

easy

A. To store configuration only in the database

B. To hardcode all settings inside the service code

C. To make services dependent on a single environment

D. To separate configuration settings from code for flexibility

Solution

1. Step 1: Understand configuration separation

   Environment-based configuration means keeping settings like URLs, keys, and flags outside the code so they can change without rewriting code.

2. Step 2: Identify the benefit in microservices

   This separation allows microservices to adapt easily to different environments (development, testing, production) without code changes.

3. Final Answer:

   To separate configuration settings from code for flexibility -> Option D

4. Quick Check:

   Configuration separation = Flexibility [OK]

Hint: Configuration outside code means flexibility across environments [OK]

Common Mistakes:

• Thinking configuration must be hardcoded
• Assuming one config fits all environments
• Storing config only in databases

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

easy

A. process.env.DB_HOST

B. env.DB_HOST()

C. getEnv('DB_HOST')

D. System.getenv('DB_HOST')

Solution

1. Step 1: Recall Node.js environment variable syntax

   In Node.js, environment variables are accessed via the global object process.env.

2. Step 2: Match the correct syntax

   The correct way to get DB_HOST is process.env.DB_HOST. Other options are invalid or from other languages.

3. Final Answer:

   process.env.DB_HOST -> Option A

4. Quick Check:

   Node.js env var = process.env.VAR [OK]

Hint: Node.js env vars use process.env.VAR_NAME [OK]

Common Mistakes:

• Using function calls like getEnv() which don't exist
• Confusing syntax with other languages like Java
• Trying to access env vars without process.env

3. Given this Python snippet in a microservice startup:

import os

env = os.getenv('ENVIRONMENT', 'development')
if env == 'production':
    db_url = os.getenv('PROD_DB_URL')
else:
    db_url = os.getenv('DEV_DB_URL')
print(db_url)

What will be printed if ENVIRONMENT is not set and DEV_DB_URL is set to "localhost:5432/dev"?

medium

A. "localhost:5432/prod"

B. None

C. "localhost:5432/dev"

D. Error: ENVIRONMENT not set

Solution

1. Step 1: Check default environment value

   The code uses os.getenv('ENVIRONMENT', 'development'), so if ENVIRONMENT is missing, it defaults to 'development'.

2. Step 2: Determine which DB URL is selected

   Since env is 'development', the else branch runs, setting db_url to os.getenv('DEV_DB_URL'), which is "localhost:5432/dev".

3. Final Answer:

   "localhost:5432/dev" -> Option C

4. Quick Check:

   Default env 'development' selects DEV_DB_URL [OK]

Hint: Default env triggers DEV_DB_URL print [OK]

Common Mistakes:

• Assuming ENVIRONMENT must be set or error occurs
• Confusing production and development branches
• Expecting None if variable missing

4. A microservice fails to load its configuration from environment variables and crashes. Which is the most likely cause?

medium

A. The service code has a syntax error unrelated to config

B. Environment variables were not set before service startup

C. The service uses hardcoded values instead of env vars

D. The database is down

Solution

1. Step 1: Understand environment variable loading

   Microservices read environment variables at startup. If variables are missing, config loading fails.

2. Step 2: Identify cause of crash

   If env vars are not set before starting, the service cannot find needed config and may crash or error out.

3. Final Answer:

   Environment variables were not set before service startup -> Option B

4. Quick Check:

   Missing env vars cause config load failure [OK]

Hint: Set env vars before starting service [OK]

Common Mistakes:

• Blaming unrelated syntax errors
• Assuming hardcoded values cause crashes
• Confusing database issues with config loading

5. You have a microservice deployed in three environments: development, staging, and production. You want to use environment-based configuration to manage database URLs securely and avoid code changes. Which approach is best?

hard

A. Use environment variables for DB URLs and load them at startup

B. Store all DB URLs in code and comment/uncomment per environment

C. Use a single DB URL for all environments to simplify config

D. Hardcode production DB URL and pass dev/staging URLs as query params

Solution

1. Step 1: Evaluate configuration management options

   Hardcoding or commenting code per environment is error-prone and unsafe. Using a single DB URL ignores environment differences.

2. Step 2: Choose secure, flexible best practice

   Using environment variables allows each environment to have its own DB URL securely without code changes, loaded at service startup.

3. Final Answer:

   Use environment variables for DB URLs and load them at startup -> Option A

4. Quick Check:

   Env vars for config = secure + flexible [OK]

Hint: Env vars separate config from code for all environments [OK]

Common Mistakes:

• Hardcoding config in code for each environment
• Using same DB URL everywhere ignoring environment needs
• Passing sensitive info in query parameters