CKS Minimize Microservice Vulnerabilities Practice Question
A DevOps team deploys a microservice that needs to access a third-party API using credentials stored in a Kubernetes Secret. The team wants to minimize the risk of credential exposure. Which approach best achieves this goal while following security best practices?
⚠ Common exam trap
CNCF often tests the misconception that environment variables are safe for secrets, but the trap here is that environment variables can be exposed via `/proc/self/environ`, logs, or debug endpoints, making volume mounts with strict permissions and RBAC the more secure choice.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Store the credentials in a Secret, mount it as a read-only volume, and use a dedicated service account with RBAC limiting access to that secret.
Mounting the Secret as a read-only volume prevents runtime modification, and using a dedicated service account with RBAC ensures only the specific microservice can access the Secret. This follows the principle of least privilege and minimizes exposure, as the credentials are never injected as environment variables (which can be leaked via /proc or logs) and are only available to the intended pod.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store the credentials in a Secret and mount it as a volume with default permissions.
Why it's wrong here
Mounting a Secret as a volume with default permissions (typically 0644) makes the secret readable by any container or process in the pod, including unrelated sidecars, because the file mode grants world-read access. Without a dedicated service account and RBAC restrictions, any workload that can create a pod or reference the Secret in the same namespace could obtain the credentials. Thus, it exposes the secret to a wider attack surface.
- ✓
Store the credentials in a Secret, mount it as a read-only volume, and use a dedicated service account with RBAC limiting access to that secret.
Why this is correct
This approach is correct because it combines confidentiality, integrity, and least privilege: mounting the Secret as a read-only volume prevents containers from modifying the credentials at runtime, while a dedicated ServiceAccount paired with a Role and RoleBinding strictly limits which pods can get or list the Secret through the Kubernetes API. The RBAC policy ensures that only the microservice's own service account can access the Secret, reducing the risk of unauthorized retrieval by other workloads in the cluster.
- ✗
Use a sidecar container that reads the secret from a file and exposes it via a Unix socket, running the container as root.
Why it's wrong here
Running a sidecar container as root defeats the principle of least privilege; if the sidecar is compromised, the attacker gains root access to the container and potentially the node (depending on kernel hardening). Exposing the secret via a Unix socket adds unnecessary complexity and still requires the secret to be stored somewhere in the pod, but provides no real security isolation beyond what a mounted volume would offer. The root requirement introduces more risk than benefit.
- ✗
Store the credentials in a ConfigMap and inject them as environment variables.
Why it's wrong here
ConfigMaps are intended for non-sensitive configuration data, not credentials, and they store data in plaintext in etcd unless encryption at rest is specifically enabled for secrets—but ConfigMaps themselves are not even subject to the same secret-specific controls like secret encryption. Injecting credentials as environment variables makes them visible via /proc/<pid>/environ, accessible through kubectl exec or logs, and they can leak into container crash dumps. Therefore, this is an insecure pattern for secrets.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 114-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are deploying an application that needs to access a database password stored in a Kubernetes Secret. To minimize risk, you should mount the Secret as a volume rather than using environment variables. Which of the following is the primary security benefit of using mounted volumes over environment variables?
medium- ✓ A.Environment variables can be leaked through commands like 'env' or 'cat /proc/1/environ', while mounted files are only accessible if the container has a shell and reads the file.
- B.Mounted volumes are not visible in /proc, making them inaccessible to other processes.
- C.Environment variables are stored in etcd in plaintext, while volumes are encrypted at rest.
- D.Mounted volumes automatically rotate the secret when the Secret object is updated.
Why A: Environment variables are inherited by all processes in the container and can be read via commands like `env` or by accessing `/proc/1/environ` from any process, even without a shell. In contrast, secrets mounted as volumes are only accessible to processes that explicitly read the file path, and only if the container has a shell or the process has file system access. This reduces the attack surface by limiting exposure to processes that need the secret.
Variation 2. Which TWO actions help minimize vulnerabilities in microservices by securing secrets? (Choose two)
medium- A.Base64 encode the secret in the YAML manifest
- B.Set the secret as a label on the pod
- ✓ C.Mount Secrets as volumes instead of environment variables
- ✓ D.Use an external secrets manager like HashiCorp Vault
- E.Store secrets in ConfigMaps to leverage ConfigMap encryption
Why C: Mounting secrets as volumes is more secure than using environment variables. When secrets are injected as environment variables, they can be exposed through the process environment (e.g., via `/proc/self/environ` or `env` command) and are more likely to be accidentally logged or leaked. Mounting as a volume ensures the secret is only available as a file in the container's filesystem, and the secret data is not visible in the process list or environment dumps, reducing the attack surface.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.