Courseiva
Minimize Microservice VulnerabilitiesmediumMultiple ChoiceObjective-mapped

CKS Minimize Microservice Vulnerabilities Practice Question

A developer creates a Deployment with the following container spec:

```yaml containers: - name: app image: myapp:latest env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password ```

Which of the following is a security concern with this approach?

⚠ Common exam trap

A common misconception is that base64 encoding or secret naming is a security concern, when the real issue is the attack surface introduced by environment variable injection versus file-based mounts.

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

The secret is exposed in the container environment variables, which can be accessed via /proc or logs if the container is compromised.

Injecting secrets as environment variables exposes them in the container's process environment, which can be read from /proc/self/environ or /proc/1/environ by any process running in the container. If the container is compromised, an attacker can easily extract the secret from the environment, and it may also leak into logs or error messages. Kubernetes secrets should be mounted as files (e.g., via volumes) to reduce exposure, as environment variables are more accessible to malicious code.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • The secret is not encrypted at rest in etcd.

    Why it's wrong here

    While enabling etcd encryption protects Secret data at rest on disk, it has no bearing on how the Secret is exposed inside the running Pod. The question's vulnerability is at runtime: environment variables are injected into the container process and remain readable throughout its life. Even with etcd encrypted, anyone who compromises the container can inspect /proc/<pid>/environ or application logs containing the variable, so this option does not identify the actual flaw.

  • The secret is exposed in the container environment variables, which can be accessed via /proc or logs if the container is compromised.

    Why this is correct

    Setting a Secret as an environment variable copies its value into the container's process environment, where it can be read from /proc/self/environ, captured by debugging tools, or inadvertently written to logs by the application. If the container is compromised, the attacker can trivially dump these variables and extract the secret in plaintext. Mounting the Secret as a file into a volume is preferred because the value is only present on the filesystem and not exposed in process metadata.

  • The secret name 'db-secret' is too generic.

    Why it's wrong here

    The choice of the name 'db-secret' is purely an organizational naming convention; Kubernetes applies no security decisions based on how descriptive a Secret's name is. Access to a Secret is governed by RBAC and the ServiceAccount bound to the Pod, not by its name. A misleading name does not weaken confidentiality, and a generic name does not strengthen it.

  • The secret is not base64 encoded.

    Why it's wrong here

    Secrets in etcd are stored base64-encoded, but this is merely a serialization scheme that allows arbitrary binary data in JSON/YAML, not any form of encryption or hashing. Base64 can be decoded trivially by anyone with access, so whether the value is encoded or not has no impact on the security of the Secret when exposed via environment variables. The real issue is the exposure itself, not the encoding.

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 →

How Courseiva writes practice questions · Editorial policy

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.