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.