Application Deployment and Security →mediumMultiple Select

200-901 Application Deployment and Security Practice Question

A development team is implementing security controls for a containerized application deployed on Kubernetes. They need to ensure that containers run with least privilege and that sensitive information is protected. Which TWO measures should be implemented? (Choose two.)

⚠ Common exam trap

The trap here is assuming that environment variables are a secure way to store secrets, when they are actually visible and unencrypted.

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

✓

Use Kubernetes Secrets to store sensitive data and mount them as volumes.

Running containers as non-root and using Kubernetes Secrets mounted as volumes are two key measures for least privilege and sensitive data protection. Non-root execution limits the impact of a breach, while Secrets avoid exposing confidential data in environment variables or images. The other options either weaken security or are insecure practices.

Answer analysis

Option-by-option breakdown

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

✓
Use Kubernetes Secrets to store sensitive data and mount them as volumes.
Why this is correct
Kubernetes Secrets are designed to hold confidential data such as passwords and tokens. Mounting them as volumes avoids exposing them in environment variables or image layers. This limits access to only the containers that need them and supports encryption at rest if configured. It is a recommended practice for protecting sensitive information in Kubernetes.
✗
Disable read-only root filesystem to allow applications to write logs.
Why it's wrong here
A read-only root filesystem enhances security by preventing attackers from modifying system files. Disabling it to allow logging is unnecessary because logs can be written to mounted volumes or external systems. Keeping the root filesystem read-only is a best practice for immutable infrastructure and reduces the risk of persistent compromise.
✗
Store sensitive data in environment variables within the pod specification.
Why it's wrong here
Environment variables are visible in the pod specification and can be accessed by any process in the container. They are not encrypted and can be exposed through debugging tools or logs. Storing sensitive data this way violates the principle of protecting secrets. Kubernetes Secrets, mounted as volumes, are a more secure alternative, though even they require careful access control.
✓
Run containers as a non-root user by setting securityContext.runAsNonRoot to true.
Why this is correct
Setting runAsNonRoot to true enforces that the container process does not run as the root user, reducing the potential impact of a container compromise. This is a fundamental least-privilege practice in Kubernetes. It prevents attackers from gaining root-level access within the container, which could be leveraged to escalate privileges or access sensitive host resources.
✗
Set the privileged flag to true in the container security context.
Why it's wrong here
Setting privileged to true gives the container almost all capabilities of the host, effectively disabling isolation. This directly contradicts the principle of least privilege and increases the attack surface. It should be avoided unless absolutely necessary for specific system-level tasks, and even then, it should be tightly controlled.

Go deeper

200-901 Application Deployment and Security Practice Question

Why each option matters

Option-by-option breakdown

Related to this question