CKAD Practice Question: Application Environment, Configuration and Security

Answer analysis

Option-by-option breakdown

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

• ✗

  Using 'args' in container spec

  Why it's wrong here

  Args are command-line arguments passed to the container's entrypoint, not environment variables. They are specified in the container spec and can be used to pass configuration, but they do not populate the process environment. To expose secret data as environment variables, you must use the env or envFrom fields rather than args. Additionally, putting secrets in args would expose them in the pod spec and process list, which is insecure.

• ✓

  Using 'env.valueFrom.secretKeyRef'

  Why this is correct

  This is a direct method to expose a single key from a Secret as a named environment variable. In the container spec, you define an env entry with a name and valueFrom.secretKeyRef referencing the Secret and key. Kubernetes decodes the base64 value and injects it into the container's environment. This approach gives precise control over which secret values become env vars and what their variable names are.

• ✗

  Using 'env.valueFrom.configMapKeyRef'

  Why it's wrong here

  configMapKeyRef references a ConfigMap, which stores non-sensitive configuration data in plaintext, not a Secret. While the syntax is similar to secretKeyRef, using it for secret data would either fail or inadvertently expose the data as a ConfigMap if that's what's referenced. Since the question specifically asks for exposing Secret data, the correct reference is secretKeyRef, not configMapKeyRef.

• ✗

  Using 'volumeMounts' with a secret volume

  Why it's wrong here

  Mounting a Secret as a volume presents the secret data as files in a directory, not as environment variables. Each key in the Secret becomes a file with the decoded value. This is a valid method for exposing secrets to a container, but it does not satisfy the requirement of exposing data as environment variables. Applications must explicitly read from the mount path, which is different from env var injection.

• ✓

  Using 'envFrom.secretRef'

  Why this is correct

  This method allows you to inject all keys from a Secret as environment variables in one declaration. By adding envFrom with a secretRef, every key in the Secret becomes an environment variable with its decoded value. It's a convenient bulk approach, but it lacks the ability to rename variables or select only specific keys. Also, if a key is not a valid env var name, the entire injection may fail, depending on Kubernetes version and settings.

Go deeper

Related to this question