ConfigMaps and Secrets in Microservices - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a ConfigMap in microservices architecture?

A ConfigMap is a way to store non-sensitive configuration data separately from application code, allowing microservices to access configuration without rebuilding images.

beginner

How do Secrets differ from ConfigMaps?

Secrets store sensitive data like passwords or tokens in an encrypted or base64-encoded form, while ConfigMaps store non-sensitive configuration data in plain text.

intermediate

Why should sensitive data be stored in Secrets rather than ConfigMaps?

Storing sensitive data in Secrets helps protect it by restricting access and encrypting it, reducing the risk of exposure compared to ConfigMaps which are not encrypted.

intermediate

How can microservices access ConfigMaps and Secrets at runtime?

Microservices can access ConfigMaps and Secrets by mounting them as files in containers or by injecting them as environment variables during container startup.

advanced

What is a common best practice when updating ConfigMaps or Secrets in a running microservices environment?

A common best practice is to update ConfigMaps or Secrets carefully and trigger rolling restarts of microservices to reload the new configuration without downtime.

Which of the following is true about ConfigMaps?

A They cannot be updated without rebuilding the application.

B They store sensitive data encrypted by default.

C They store non-sensitive configuration data.

D They are only used for secrets like passwords.

ConfigMaps store non-sensitive configuration data separately from application code.

What is the main purpose of Secrets in microservices?

A To store container images.

B To store non-sensitive configuration.

C To store application logs.

D To store sensitive information securely.

Secrets are designed to store sensitive information like passwords and tokens securely.

How can microservices consume Secrets at runtime?

A By mounting Secrets as files or injecting as environment variables.

B By storing them in public repositories.

C By embedding them directly in the source code.

D By hardcoding them in container images.

Secrets can be accessed by mounting them as files or injecting them as environment variables.

Which practice helps safely update ConfigMaps or Secrets without downtime?

A Triggering rolling restarts of microservices.

B Ignoring updates until next deployment.

C Rebuilding container images immediately.

D Deleting and recreating all microservices.

Rolling restarts allow microservices to reload updated ConfigMaps or Secrets without downtime.

Why should sensitive data not be stored in ConfigMaps?

A Because ConfigMaps are encrypted by default.

B Because ConfigMaps are stored in plain text and less secure.

C Because ConfigMaps cannot be updated.

D Because ConfigMaps are only for logs.

ConfigMaps store data in plain text and do not provide encryption or strict access controls.

Explain the difference between ConfigMaps and Secrets in microservices and why each is important.

Think about security and configuration management.

Describe how you would update a Secret in a running microservices environment without causing downtime.

Consider safe update and reload strategies.

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