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.

• ✓

  env: - name: MY_SECRET valueFrom: secretKeyRef: name: my-secret key: my-key

  Why this is correct

  This is the canonical way to inject a single secret value as an environment variable. The `valueFrom.secretKeyRef` field directly references the named Secret (`my-secret`) and the specific key (`my-key`), and Kubernetes populates `MY_SECRET` with that key's value at container startup. Unlike `envFrom`, this gives you fine-grained control over the exact environment variable name and source, and unlike a volume mount, it does not create a filesystem object. It is the recommended approach when you need just one or a few values from a Secret exposed as env vars.

• ✗

  volumeMounts: - name: secret-volume mountPath: /etc/secret

  Why it's wrong here

  Mounting a Secret as a volume exposes all of its keys as files under the specified mount path (here `/etc/secret`), not as environment variables. The container would see a file named `my-key` (or whatever key exists) at `/etc/secret/my-key`, and the application would need to read from the filesystem. While this is a legitimate way to consume Secrets, the question asks specifically about exposing a secret value as an environment variable, so this option does not satisfy that requirement. It is also worth noting that volume mounts are subject to file permissions and require the application to handle file I/O, unlike direct env var injection.

• ✓

  envFrom: - secretRef: name: my-secret

  Why this is correct

  The `envFrom.secretRef` field is a valid and concise way to expose all key-value pairs from a Secret as environment variables. Each key in the referenced Secret (`my-secret`) becomes an environment variable name, and its value is set accordingly. However, this approach lacks control over individual variable names and can lead to collisions or invalid variable names if keys contain characters not permitted in env var names (e.g., dashes are replaced with underscores, and invalid names are skipped). It is the correct choice when you want to bring in an entire Secret's contents as env vars without writing out each key individually.

• ✗

  env: - name: MY_SECRET value: "$(MY_SECRET)"

  Why it's wrong here

  This option uses the `value:` field with a literal string `"$(MY_SECRET)"`, which does not trigger any Kubernetes expansion mechanism. Kubernetes does NOT perform substitution inside `value` or `valueFrom` fields; the `$(VAR)` syntax is only expanded by the shell inside container `command` or `args`, not within pod spec env definitions. Moreover, even if `MY_SECRET` were set elsewhere in the environment, this would simply assign the literal five-character string `$(MY_SECRET)` to the variable, not the secret's value. To reference a Secret, you must use `valueFrom.secretKeyRef` or the `envFrom` approach.

• ✗

  env: - name: MY_SECRET valueFrom: configMapKeyRef: name: my-secret key: my-key

  Why it's wrong here

  This option incorrectly uses `configMapKeyRef` to source from a Secret. The `configMapKeyRef` field is specifically designed to reference ConfigMaps, not Secrets; referencing a Secret with it will fail with an error like `Error from server: object 'my-secret' not found` or a type mismatch, because the API expects a ConfigMap resource. Even though the YAML structure looks similar to the correct `secretKeyRef`, the `configMapKeyRef` keyword tells the kubelet to look for a ConfigMap, and a Secret cannot fulfill that expectation. Always use `secretKeyRef` when sourcing from a Secret — mixing the two reference types is a common mistake.

Go deeper

Related to this question