ConfigMaps and Secrets in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding the primary purpose of ConfigMaps

What is the main purpose of using ConfigMaps in a microservices architecture?

A To manage network policies between microservices

B To store sensitive data like passwords and API keys securely

C To provide configuration data to containers in a decoupled way

D To monitor the health status of microservices

💡 Hint

Think about how configuration data is separated from application code.

ConfigMaps are used to inject configuration data into containers without rebuilding images. They are not meant for sensitive data.

❓ Architecture

intermediate

Choosing between ConfigMaps and Secrets

You need to store database credentials for your microservices. Which Kubernetes resource should you use and why?

A Secrets, because they provide base64 encoding and better access control for sensitive data

B ConfigMaps, because they are designed for storing all types of configuration data

C ConfigMaps, because they automatically encrypt data at rest

D Secrets, because they are only accessible by the Kubernetes master node

💡 Hint

Consider security and access control for sensitive information.

Secrets are designed to store sensitive data securely with base64 encoding and tighter access controls, unlike ConfigMaps.

❓ scaling

advanced

Scaling microservices with ConfigMaps and Secrets updates

When you update a ConfigMap or Secret used by multiple microservice pods, what is the best practice to ensure all pods receive the updated data without downtime?

A Create new ConfigMaps or Secrets with different names and update pod specs to use them

B Update the ConfigMap or Secret and rely on pods to automatically reload the data without restart

C Manually delete all pods so they restart and pick up the new data

D Use a rolling update strategy to restart pods gradually with the new ConfigMap or Secret

💡 Hint

Think about minimizing downtime and ensuring consistency.

Rolling updates allow pods to restart gradually, picking up new ConfigMaps or Secrets without causing downtime.

❓ tradeoff

advanced

Tradeoffs of storing secrets in environment variables vs mounted files

What is a key tradeoff when choosing to expose Secrets as environment variables compared to mounting them as files inside containers?

A Environment variables are more secure because they are encrypted in memory

B Environment variables can be easily viewed in process listings, risking exposure

C Mounted files cannot be accessed by the application code

D Mounted files allow easier secret rotation without restarting the container

💡 Hint

Consider how secrets might be exposed inside a running container.

Secrets in environment variables can be exposed via process listings or logs, while mounted files are less exposed but may require restarts for updates.

❓ estimation

expert

Estimating capacity for ConfigMaps and Secrets in a large cluster

You manage a Kubernetes cluster with 1000 microservice pods, each requiring 5 ConfigMaps and 3 Secrets. If each ConfigMap averages 10 KB and each Secret averages 5 KB, estimate the total storage needed for ConfigMaps and Secrets assuming no sharing and no compression.

A 65 MB

B 80 MB

C 100 MB

D 50 MB

💡 Hint

Calculate total size by multiplying counts and sizes, then sum.

Total ConfigMaps size = 1000 pods * 5 ConfigMaps * 10 KB = 50,000 KB (approx 48.8 MB).
Total Secrets size = 1000 pods * 3 Secrets * 5 KB = 15,000 KB (approx 14.6 MB).
Total = 65,000 KB ≈ 63.5 MB, closest to 65 MB.

Practice

1. What is the primary purpose of a ConfigMap in a microservices environment?

easy

A. To store encrypted passwords and tokens securely

B. To store non-sensitive configuration data separately from application code

C. To manage network traffic between microservices

D. To monitor the health of microservices

Solution

1. Step 1: Understand ConfigMap role

   A ConfigMap is designed to hold configuration data that is not sensitive, such as environment variables or config files, separate from the application code.

2. Step 2: Differentiate from Secrets

   Secrets are used for sensitive data like passwords, not ConfigMaps.

3. Final Answer:

   To store non-sensitive configuration data separately from application code -> Option B

4. Quick Check:

   ConfigMap = Non-sensitive config [OK]

Hint: ConfigMaps hold safe config, Secrets hold sensitive info [OK]

Common Mistakes:

• Confusing ConfigMaps with Secrets
• Thinking ConfigMaps encrypt data
• Assuming ConfigMaps manage network or health

2. Which of the following is the correct way to create a Secret in Kubernetes using a literal value?

easy

A. kubectl create secret generic mysecret --from-literal=password=12345

B. kubectl create configmap mysecret --from-literal=password=12345

C. kubectl secret create mysecret --from-file=password.txt

D. kubectl create secret mysecret --password=12345

Solution

1. Step 1: Recall Kubernetes Secret creation syntax

   The correct command uses kubectl create secret generic with --from-literal to create a secret from a literal key-value pair.

2. Step 2: Eliminate incorrect options

   kubectl create configmap mysecret --from-literal=password=12345 uses configmap instead of secret, kubectl secret create mysecret --from-file=password.txt uses wrong command syntax, kubectl create secret mysecret --password=12345 uses invalid flag.

3. Final Answer:

   kubectl create secret generic mysecret --from-literal=password=12345 -> Option A

4. Quick Check:

   Secret creation uses 'kubectl create secret generic' [OK]

Hint: Secret creation uses 'kubectl create secret generic' [OK]

Common Mistakes:

• Using configmap command instead of secret
• Wrong flags like --password
• Confusing file and literal input

3. Given this Kubernetes pod spec snippet, what will be the value of environment variable API_KEY inside the container?

env:
  - name: API_KEY
    valueFrom:
      secretKeyRef:
        name: mysecret
        key: api_key

medium

A. An empty string because 'api_key' is not defined

B. The literal string 'api_key'

C. The value stored under key 'api_key' in the Secret named 'mysecret'

D. The value of a ConfigMap named 'mysecret'

Solution

1. Step 1: Understand env var from secretKeyRef

   The environment variable API_KEY is set from a Secret named mysecret, specifically the key api_key.

2. Step 2: Clarify what value is assigned

   The value assigned is the secret data stored under that key, not the literal string or empty.

3. Final Answer:

   The value stored under key 'api_key' in the Secret named 'mysecret' -> Option C

4. Quick Check:

   secretKeyRef pulls secret value by key [OK]

Hint: secretKeyRef uses secret's key value, not literal text [OK]

Common Mistakes:

• Assuming it uses the key name as string
• Confusing ConfigMap with Secret
• Thinking it defaults to empty if key missing

4. A developer tries to mount a Secret as a volume in a pod but gets an error. Which of these is the most likely cause?

medium

A. The Secret does not exist or has a different name than specified

B. The ConfigMap is missing required keys

C. The pod spec uses configMapKeyRef instead of secretKeyRef

D. The volume mount path is outside the container filesystem

Solution

1. Step 1: Identify common Secret mount errors

   Mounting a Secret as a volume requires the Secret to exist with the exact name referenced.

2. Step 2: Evaluate other options

   ConfigMap keys missing affect ConfigMaps, not Secrets. Using configMapKeyRef instead of secretKeyRef is for env vars, not volumes. Volume mount path errors cause different errors.

3. Final Answer:

   The Secret does not exist or has a different name than specified -> Option A

4. Quick Check:

   Secret volume mount fails if Secret missing [OK]

Hint: Check Secret name exists before mounting volume [OK]

Common Mistakes:

• Mixing ConfigMap and Secret references
• Ignoring Secret existence before mount
• Confusing env var refs with volume mounts

5. You want to securely provide database credentials to multiple microservices without exposing them in code or logs. Which approach best uses ConfigMaps and Secrets together?

hard

A. Embed credentials directly in microservice code and use ConfigMaps for feature flags

B. Store credentials in ConfigMaps and encrypt them manually; use Secrets for logging configs

C. Put all configs and secrets in ConfigMaps for simplicity; avoid Secrets

D. Store all credentials in a Secret and non-sensitive configs in ConfigMaps; mount both as environment variables

Solution

1. Step 1: Separate sensitive and non-sensitive data

   Best practice is to keep sensitive data like credentials in Secrets and non-sensitive configs in ConfigMaps.

2. Step 2: Use environment variables for flexibility

   Mounting both as environment variables allows microservices to access configs securely without code changes.

3. Final Answer:

   Store all credentials in a Secret and non-sensitive configs in ConfigMaps; mount both as environment variables -> Option D

4. Quick Check:

   Secrets for sensitive, ConfigMaps for safe config [OK]

Hint: Secrets for sensitive data, ConfigMaps for safe config [OK]

Common Mistakes:

• Putting secrets in ConfigMaps unencrypted
• Embedding credentials in code
• Using Secrets for non-sensitive data