Environment configuration in Microservices - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is environment configuration in microservices?

Environment configuration is the setup of variables and settings that control how microservices behave in different environments like development, testing, and production.

beginner

Why should environment configurations be separated from code?

Separating configuration from code allows the same code to run in different environments without changes, making deployments safer and easier.

intermediate

Name three common ways to manage environment configuration in microservices.

1. Environment variables
2. Configuration files
3. Centralized configuration services (like Consul or Spring Cloud Config)

intermediate

What is a centralized configuration service and why is it useful?

A centralized configuration service stores and manages configuration for many microservices in one place. It helps keep configurations consistent and makes updates easier without redeploying services.

advanced

How can environment configuration impact microservices scalability?

Proper configuration allows microservices to scale by adjusting resource limits, connection strings, or feature flags without changing code, enabling flexible and efficient scaling.

Which method is NOT commonly used for environment configuration in microservices?

A Configuration files

B Environment variables

C Hardcoded values in source code

D Centralized configuration services

Hardcoding values in source code is discouraged because it makes changing configurations for different environments difficult and error-prone.

What is a key benefit of using a centralized configuration service?

A It allows configuration changes without redeploying microservices

B It automatically scales microservices

C It eliminates the need for environment variables

D It stores source code

Centralized configuration services let you update configurations centrally and have microservices pick up changes without redeployment.

Why is separating configuration from code important?

A To make code harder to read

B To allow the same code to run in multiple environments

C To increase deployment time

D To reduce security

Separating configuration from code enables the same codebase to be used across different environments by changing only the configuration.

Which of these is a common environment configuration variable?

A User interface color scheme

B Programming language version

C Source code comments

D Database connection string

Database connection strings are often configured per environment to connect to the correct database instance.

How can environment configuration help with feature management?

A By using feature flags to enable or disable features per environment

B By hardcoding features in code

C By removing unused features

D By changing the programming language

Feature flags in configuration allow turning features on or off without code changes, useful for testing or gradual rollouts.

Explain how environment configuration is managed in a microservices system and why it matters.

Think about how different environments need different settings without changing the code.

Describe the role of centralized configuration services in microservices and their benefits.

Imagine managing many microservices and wanting one place to change settings.

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