GSEC Container Security Practice Question

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 cloud provider credentials in base64-encoded Kubernetes Secret objects and mount them as environment variables.

  Why it's wrong here

  Base64 encoding is merely obfuscation, not encryption at rest. Environment variables are notoriously insecure because they can be easily dumped by malicious processes running inside the container or exposed via debugging interfaces and container inspection logs.

• ✗

  Configure cluster-wide IAM roles on the underlying worker nodes and allow all hosted pods to inherit administrative permissions.

  Why it's wrong here

  Inheriting node-level administrative permissions violates the principle of least privilege. Any compromise of a single low-risk pod would immediately grant an attacker full administrative control over all cloud provider resources accessible by that worker node.

• ✓

  Implement service account token volume projection with short-lived auditable tokens scoped to individual application requirements.

  Why this is correct

  Projected service account tokens provide automatically rotated, cryptographically signed tokens with strict audience limitations. This ensures that even if a token is exfiltrated, its lifespan is extremely short and its usability is strictly bounded to intended APIs.

• ✗

  Embed the static cloud API keys directly into the container base image layers to ensure consistency across deployments.

  Why it's wrong here

  Embedding credentials inside container image layers makes them permanently accessible to anyone who pulls the image from the registry. Image layers persist sensitive data indefinitely even if the files are subsequently deleted in later build stages.