Courseiva

CCNA Application Environment, Configuration and Security Questions

51 of 201 questions · Page 3/3 · Application Environment, Configuration and Security · Answers revealed

Practice these questionsDomain overviewAll questions
151
MCQhard

You need to create a Pod that runs with a specific non-root user (UID 1000), prevents privilege escalation, and mounts the container's filesystem as read-only. Which securityContext field is NOT required to achieve these requirements?

A.runAsUser: 1000
B.runAsGroup: 1000
C.readOnlyRootFilesystem: true
D.allowPrivilegeEscalation: false
AnswerB

The requirement only specifies a non-root user, not a specific group. runAsGroup, if omitted, leaves the container's primary GID unchanged from the image or the user's default group, which does not affect the process's non-root status. Since no group requirement is stated, runAsGroup is optional and therefore the correct answer to a question asking which setting is not required.

Why this answer

(runAsGroup: 1000) is not required because the requirement only specifies a non-root user (UID 1000) and does not mandate a specific group ID. The runAsGroup field sets the primary group for the container's processes, but it is optional; without it, the container will use the default group associated with the user or the container's default group. The other options are necessary: runAsUser: 1000 sets the user, readOnlyRootFilesystem: true makes the filesystem read-only, and allowPrivilegeEscalation: false prevents privilege escalation.

Exam trap

The trap here is that candidates often assume runAsGroup is mandatory alongside runAsUser for non-root execution, but the CKAD exam tests that only the user ID is required unless a specific group is explicitly needed.

How to eliminate wrong answers

Option A is wrong because runAsUser: 1000 is required to run the container as a non-root user with UID 1000, directly addressing the requirement. Option C is wrong because readOnlyRootFilesystem: true is required to mount the container's filesystem as read-only, fulfilling that specific requirement. Option D is wrong because allowPrivilegeEscalation: false is required to prevent privilege escalation, which is explicitly stated in the requirements.

Practice this question →
152
MCQeasy

Which command lists all the secrets in the current namespace?

A.kubectl get configmaps
B.kubectl describe secrets
C.kubectl list secrets
D.kubectl get secrets
AnswerD

The `kubectl get` verb is the standard way to list resources in Kubernetes, and `secrets` is the plural resource name for the Secret API object. Running `kubectl get secrets` in a namespace returns a table of all Secrets in that namespace, showing their name, type, and data size. To list Secrets in all namespaces, you would use `kubectl get secrets --all-namespaces`.

Why this answer

The correct command to list all secrets in the current namespace is `kubectl get secrets`. This command retrieves and displays all Secret resources in the namespace specified by the current context (or the `--namespace` flag). Secrets are stored in etcd as base64-encoded data and are managed via the Kubernetes API, and `kubectl get` is the standard verb for listing resources.

Exam trap

CNCF often tests the distinction between `get` and `describe` verbs, and candidates may confuse `kubectl describe secrets` (which shows details) with listing secrets, or they may incorrectly assume `kubectl list secrets` is a valid command due to familiarity with Linux `ls` or `list` commands.

How to eliminate wrong answers

Option A is wrong because `kubectl get configmaps` lists ConfigMap resources, not Secrets; ConfigMaps store non-sensitive configuration data, while Secrets store sensitive data like credentials. Option B is wrong because `kubectl describe secrets` shows detailed information about a specific Secret (or all Secrets if no name is given), but it does not produce a simple list of Secret names; it outputs verbose details including metadata and data keys. Option C is wrong because `kubectl list secrets` is not a valid kubectl command; the correct verb for listing resources is `get`, not `list`.

Practice this question →
153
MCQhard

A security requirement states that a container must run with a read-only root filesystem. Which field must be set in the container's securityContext?

A.runAsUser: 1000
B.capabilities: drop: ["ALL"]
C.allowPrivilegeEscalation: false
D.readOnlyRootFilesystem: true
AnswerD

readOnlyRootFilesystem: true mounts the container's root filesystem as read-only, meaning the container cannot write to any files in its root filesystem. This directly satisfies the security requirement that the container must run with a read-only root filesystem. Any attempt to write to the root filesystem will fail with a read-only file system error.

Why this answer

Setting `readOnlyRootFilesystem: true` in the container's `securityContext` enforces that the container's root filesystem is mounted as read-only, preventing any writes to the filesystem at the root level. This satisfies the security requirement by ensuring that even if a process is compromised, it cannot modify system binaries, configuration files, or other critical files within the container's root filesystem.

Exam trap

The trap here is that candidates often confuse security context fields that control process privileges (like `runAsUser` or `capabilities`) with filesystem mount restrictions, mistakenly thinking dropping capabilities or disabling privilege escalation will make the filesystem read-only.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 1000` sets the user ID under which the container runs, but does not affect the writability of the root filesystem; it controls process privileges, not filesystem mount permissions. Option B is wrong because `capabilities: drop: ["ALL"]` removes all Linux capabilities from the container, which reduces kernel-level privileges but does not prevent writes to the root filesystem; the filesystem can still be written to unless explicitly mounted read-only. Option C is wrong because `allowPrivilegeEscalation: false` prevents a process from gaining more privileges than its parent (e.g., via setuid binaries), but it does not restrict filesystem write access; a non-privileged process can still modify files on a writable root filesystem.

Practice this question →
154
MCQmedium

A developer creates a pod with the following YAML snippet: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 The pod mounts an emptyDir volume. What is the owner and group of the mounted directory inside the container?

A.Owner: 1000, Group: 3000
B.Owner: 1000, Group: 1000
C.Owner: 1000, Group: 2000
D.Owner: 0, Group: 2000
AnswerC

This is the correct outcome. The `runAsUser: 1000` field determines the owner UID of the pod's processes and, by extension, the ownership of the mounted volume's root directory as seen by the container. The `fsGroup: 2000` field explicitly sets the group ownership for all volume mounts, and also makes that group supplementary for the container's processes, allowing access. Therefore, the volume ends up owned by UID 1000 and GID 2000.

Why this answer

When a pod specifies `fsGroup: 2000`, Kubernetes recursively changes the group ownership of any volume mounted into the pod (including emptyDir) to that GID (2000). The `runAsUser: 1000` sets the container process's UID, but the volume's group ownership is overridden by `fsGroup`. Thus, the mounted emptyDir directory is owned by UID 1000 (the process user) and GID 2000 (the fsGroup).

Exam trap

The trap here is that candidates confuse `runAsGroup` (which sets the primary GID of the container process) with `fsGroup` (which sets the group ownership of mounted volumes), leading them to pick Option A or B instead of recognizing that `fsGroup` overrides the volume's group.

How to eliminate wrong answers

Option A is wrong because it assumes the volume's group is set to `runAsGroup: 3000`, but `fsGroup` overrides the group ownership of mounted volumes, not `runAsGroup`. Option B is wrong because it incorrectly assumes the volume's group matches the user's primary GID (1000), but `fsGroup` explicitly sets a different GID (2000) for volume ownership. Option D is wrong because it claims the owner is root (UID 0), but `runAsUser: 1000` ensures the container process runs as UID 1000, and the volume's owner is the process's UID, not root.

Practice this question →
155
MCQhard

A namespace 'team-a' has a ResourceQuota with 'pods: 10' and a LimitRange with default memory request '256Mi'. A user creates a pod with no resource requests. What happens?

A.Pod is created with a default memory request of 256Mi.
B.Pod creation fails because the ResourceQuota is exceeded.
C.Pod creation fails because the LimitRange is not satisfied.
D.Pod is created with no memory request.
AnswerA

LimitRange acts as a mutating admission controller in Kubernetes. When a Pod is created without specifying a memory request, the LimitRange's default (here 256Mi) is automatically injected into the Pod spec before it is admitted. This defaulted request is then counted against the ResourceQuota, so the Pod is successfully created with a memory request of 256Mi. The ResourceQuota of 10 Pods is unrelated to this default memory value.

Why this answer

When a pod is created in a namespace with a LimitRange that specifies a default memory request, Kubernetes automatically injects that default value into the pod's container spec if no explicit memory request is provided. The ResourceQuota of 'pods: 10' only limits the total number of pods, not the resource consumption of individual pods, so it does not affect this pod's creation. Therefore, the pod is created with a default memory request of 256Mi.

Exam trap

The trap here is that candidates often confuse ResourceQuota (which limits total resource consumption) with LimitRange (which sets per-pod defaults and constraints), leading them to incorrectly assume a quota or limit violation when defaults are applied.

How to eliminate wrong answers

Option B is wrong because a ResourceQuota with 'pods: 10' sets a limit on the total number of pods in the namespace, not on the resource requests of a single pod; creating one pod does not exceed that quota. Option C is wrong because a LimitRange does not cause pod creation to fail when its default values are applied; instead, it ensures the pod meets the namespace's resource constraints by injecting defaults. Option D is wrong because the LimitRange's default memory request of 256Mi is automatically applied to the pod, so it will have a memory request, not be created without one.

Practice this question →
156
MCQmedium

A Pod has the following environment variable definition: - name: DB_HOST valueFrom: configMapKeyRef: name: db-config key: host The ConfigMap 'db-config' exists in the same namespace but does not have a key 'host'. What will happen when the Pod starts?

A.The Pod will start and the environment variable will be set to the key name 'host'
B.The Pod will start and the environment variable will be empty
C.The Pod will start but the variable will be set to the ConfigMap's name
D.The Pod will fail to start because the key is not found
AnswerD

By default, a configMapKeyRef is required: the referenced key must exist in the ConfigMap before the container can be created. When the key 'host' is not found, the kubelet logs an error such as "couldn't find key host in ConfigMap" and the container fails to start, leaving the Pod in a failed state (e.g., CreateContainerError). This is a deliberate design to catch misconfiguration early — you can make the reference optional with `optional: true`, but without that, the missing key is a fatal error.

Why this answer

When a Pod references a ConfigMap key that does not exist, the Pod will fail to start. Kubernetes validates the ConfigMap key reference at Pod creation time; if the key is missing, the kubelet will not start the container, and the Pod will remain in a 'CreateContainerConfigError' or 'RunContainerError' state. This is because environment variables are resolved before the container starts, and a missing key is treated as a fatal configuration error.

Exam trap

The trap here is that candidates may assume Kubernetes will silently default to an empty string or ignore the missing key, but in reality, Kubernetes strictly validates ConfigMap key references and will fail the Pod start to prevent silent misconfiguration.

How to eliminate wrong answers

Option A is wrong because the environment variable will not be set to the key name 'host'; Kubernetes does not fall back to using the key name as a value. Option B is wrong because the environment variable will not be empty; the Pod will fail to start entirely rather than starting with an empty value. Option C is wrong because the variable will not be set to the ConfigMap's name; there is no such fallback behavior in Kubernetes.

Practice this question →
157
MCQeasy

You need to create a ConfigMap named 'app-config' from a file 'config.properties'. Which kubectl command should you use?

A.kubectl create configmap app-config config.properties
B.kubectl create configmap app-config --from-literal=config.properties
C.kubectl create configmap app-config --from-file=config.properties
D.kubectl create configmap app-config --from-env-file=config.properties
AnswerC

The --from-file flag tells kubectl to read the specified file and create a ConfigMap with the file's base name (config.properties) as the key and its entire content as the value. This is the idiomatic Kubernetes way to populate a ConfigMap from a standalone configuration file, preserving all data exactly as-is without requiring a key=value format.

Why this answer

`kubectl create configmap app-config --from-file=config.properties` reads the file `config.properties` and creates a ConfigMap named `app-config` with a data key equal to the filename (`config.properties`) and the value set to the file's contents. This is the standard way to create a ConfigMap from a single file in Kubernetes.

Exam trap

The trap here is that candidates often confuse `--from-file` (which imports the entire file as a single key) with `--from-env-file` (which parses key-value pairs from a file), leading them to choose option D when they intend to import a properties file as a whole, or option B when they think `--from-literal` can accept a file path.

How to eliminate wrong answers

Option A is wrong because `kubectl create configmap` requires a flag (like `--from-file`, `--from-literal`, or `--from-env-file`) to specify the data source; simply listing the filename as a positional argument is invalid syntax and will result in an error. Option B is wrong because `--from-literal` expects a key=value pair (e.g., `--from-literal=key=value`), not a filename; using `--from-literal=config.properties` would treat the string 'config.properties' as a literal key with no value, not read the file. Option D is wrong because `--from-env-file` is used to import environment variables from a file in `key=value` format (one per line), but it does not create a ConfigMap with the file's raw content as a single key; it parses the file line-by-line, which is not the intended behavior for importing a properties file as a whole.

Practice this question →
158
Multi-Selectmedium

Which TWO are valid ways to expose a Secret's data as environment variables in a pod?

Select 2 answers
A.envFrom: - secretRef: name: my-secret prefix: SECRET_
B.- name: PASSWORD valueFrom: secretKeyRef: name: my-secret key: password
C.envFrom: - fieldRef: fieldPath: metadata.namespace
D.envFrom: - literal: key: value
E.envFrom: - configMapRef: name: my-secret
AnswersA, B

Using envFrom with a secretRef and a prefix is valid because envFrom bulk-imports every entry from the referenced Secret as an environment variable. The optional prefix field prepends a string to each variable name, so for a Secret containing a key "password", the resulting variable would be SECRET_password. This is a clean way to inject all Secret data at once, and the prefix helps avoid name collisions or namespace-like organization.

Why this answer

The `envFrom` field in a pod spec can reference a Secret using `secretRef`, and the optional `prefix` field prepends a string to each key from the Secret when exposing them as environment variables. This allows all key-value pairs from the Secret to be injected as environment variables with a common prefix, which is a concise and valid method.

Exam trap

The trap here is that candidates confuse `envFrom` with `env` and assume `fieldRef` or `literal` are valid subfields of `envFrom`, when in fact `envFrom` only supports `configMapRef`, `secretRef`, and `prefix`.

Practice this question →
159
MCQeasy

How can you set the environment variable 'DATABASE_URL' in a pod to the value stored in a Kubernetes Secret named 'db-secret' under the key 'url'?

A.env: - name: DATABASE_URL valueFrom: configMapKeyRef: name: db-secret key: url
B.env: - name: DATABASE_URL valueFrom: secretRef: name: db-secret
C.env: - name: DATABASE_URL valueFrom: secretKeyRef: name: db-secret key: url
D.env: - name: DATABASE_URL value: secretKeyRef: name: db-secret key: url
AnswerC

This is the correct syntax because `secretKeyRef` unambiguously tells Kubernetes to fetch the value of the `url` key from the Secret named `db-secret`. The `name` field identifies the Secret, and the `key` field selects the exact data entry to load into the `DATABASE_URL` environment variable. This is the standard, documented mechanism for injecting Secret data as environment variables.

Why this answer

The `env.valueFrom.secretKeyRef` field in a Pod spec is the proper mechanism to inject a specific key from a Kubernetes Secret as an environment variable. The `name` field identifies the Secret (`db-secret`), and the `key` field specifies which key within that Secret (`url`) to use. This is defined in the Kubernetes API for exposing Secret data as environment variables.

Exam trap

The trap here is that candidates confuse `secretKeyRef` with `configMapKeyRef` or misremember the syntax as `secretRef` (which is used for volume mounts), leading them to pick options that either reference the wrong resource type or use the wrong field structure.

How to eliminate wrong answers

Option A is wrong because it uses `configMapKeyRef`, which references a ConfigMap, not a Secret; ConfigMaps store non-sensitive data, while Secrets store sensitive data like database URLs, and the syntax for referencing a Secret key is `secretKeyRef`. Option B is wrong because `secretRef` is not a valid field under `valueFrom` for environment variables; `secretRef` is used in `volumes` to mount an entire Secret as a volume, not to expose a single key as an env var. Option D is wrong because it uses `value:` with a nested object `secretKeyRef`, but `value` expects a literal string, not a reference; the correct syntax requires `valueFrom` to indicate the value is sourced from an external reference.

Practice this question →
160
MCQeasy

Which of the following is the correct way to set a CPU request of 250 millicores and a memory limit of 512 Mi in a container?

A.resources: requests: cpu: 250 limits: memory: 512M
B.resources: requests: cpu: 250 limits: memory: 512MB
C.resources: requests: cpu: 0.25 limits: memory: 512MB
D.resources: requests: cpu: 250m limits: memory: 512Mi
AnswerD

This is the only correct option. '250m' specifies 250 millicores, i.e., 0.25 of a CPU core, which is the proper fractional-core notation. '512Mi' uses the binary suffix 'Mi' to request 512 mebibytes, a standard and unambiguous Kubernetes memory limit.

Why this answer

In Kubernetes, CPU requests are specified in millicores (e.g., 250m) and memory limits use binary units like Mi (Mebibytes). The value '250m' equals 0.25 CPU cores, and '512Mi' is 512 Mebibytes (512 * 1024^2 bytes), which is the standard unit for memory limits.

Exam trap

The trap here is that candidates confuse the 'M' (Megabyte, decimal) and 'Mi' (Mebibyte, binary) suffixes, or forget that CPU values without 'm' are interpreted as whole cores, leading to accidentally requesting 250 CPUs instead of 0.25.

How to eliminate wrong answers

Option A is wrong because it uses 'cpu: 250' without the 'm' suffix, which would be interpreted as 250 full CPU cores, not 250 millicores; also 'memory: 512M' uses the ambiguous 'M' suffix, which Kubernetes interprets as 512 Megabytes (decimal), not Mebibytes. Option B is wrong because it uses 'cpu: 250' (again 250 cores) and 'memory: 512MB' with 'MB' suffix, which Kubernetes interprets as 512 Megabytes (decimal), not the intended 512 Mebibytes. Option C is wrong because while 'cpu: 0.25' is valid for 250 millicores, 'memory: 512MB' uses the decimal 'MB' suffix instead of the binary 'Mi' suffix, which is the standard for memory limits in Kubernetes.

Practice this question →
161
MCQhard

You apply a Pod Security Admission label 'pod-security.kubernetes.io/enforce: restricted' to a namespace. A pod with the following securityContext is created: securityContext: runAsUser: 1000 runAsNonRoot: true capabilities: drop: ["ALL"] seccompProfile: type: RuntimeDefault allowPrivilegeEscalation: false readOnlyRootFilesystem: true Will the pod be admitted?

A.Yes, the pod satisfies all restricted profile requirements
B.No, because runAsUser must not be set
C.No, because seccompProfile type must be 'Localhost'
D.No, because the pod must not set capabilities at all
AnswerA

The pod satisfies the restricted Pod Security Standard because it includes the required security contexts: runAsNonRoot: true, allowPrivilegeEscalation: false, a seccompProfile of type RuntimeDefault, and a capabilities block that drops ALL privileges. Additionally, any user-supplied runAsUser value is a non-zero UID, which aligns with the restricted profile's prohibition on running as root. Consequently, all mandatory fields are set correctly, and the pod passes the restricted policy.

Why this answer

The Pod Security Admission (PSA) restricted profile requires that pods drop all capabilities, set `runAsNonRoot: true`, set `seccompProfile.type` to `RuntimeDefault` or `Localhost`, set `allowPrivilegeEscalation: false`, and restrict `runAsUser` to a non-root user (which is satisfied by `runAsUser: 1000`). The provided pod meets all these requirements, so it will be admitted. The `runAsUser` field is allowed as long as the user ID is not 0 (root), and the `seccompProfile.type` is correctly set to `RuntimeDefault`, which is one of the permitted values.

Exam trap

The trap here is that candidates often think the restricted profile forbids setting `runAsUser` entirely or requires `seccompProfile.type` to be `Localhost`, but the actual requirement is that `runAsUser` must not be root and `seccompProfile.type` can be either `RuntimeDefault` or `Localhost`.

How to eliminate wrong answers

Option B is wrong because the restricted profile does not forbid setting `runAsUser`; it only requires that the user is not root (UID 0), and `runAsUser: 1000` is a non-root user. Option C is wrong because the restricted profile allows `seccompProfile.type` to be either `RuntimeDefault` or `Localhost`, not exclusively `Localhost`. Option D is wrong because the restricted profile requires that all capabilities are dropped (via `capabilities.drop: ["ALL"]`), not that the `capabilities` field is absent entirely.

Practice this question →
162
MCQmedium

A deployment runs a container that needs to read a file from a host path '/var/log/app' on the node. The file must be available to all pods on that node. Which volume type should be used?

A.emptyDir
B.hostPath
C.persistentVolumeClaim
D.configMap
AnswerB

This is the only volume type that directly mounts a file or directory from the host node into the pod, making it the correct way to access a pre-existing host file such as /etc/hosts or a custom configuration file. By specifying the path and type, Kubernetes ensures the container sees the exact content stored on that node. However, because it is node-specific, it requires careful scheduling and carries security implications, but for this use case it unambiguously satisfies the requirement.

Why this answer

B is correct because hostPath mounts a file or directory from the host node's filesystem into the pod, making it available to all pods scheduled on that node. This is the only volume type that directly accesses a specific host path like '/var/log/app', ensuring the file is shared across all pods on the same node.

Exam trap

CNCF often tests hostPath vs. emptyDir by emphasizing 'available to all pods on that node' — candidates mistakenly choose emptyDir because it is shared among containers in the same pod, but it is not shared across different pods on the same node.

How to eliminate wrong answers

Option A is wrong because emptyDir creates an empty directory that is tied to the pod's lifecycle and is not backed by a host path; it is ephemeral and not shared across pods on the same node. Option C is wrong because persistentVolumeClaim abstracts storage from the node's filesystem and is typically used for persistent, cluster-wide storage, not for accessing a specific host path. Option D is wrong because configMap is used to inject configuration data (key-value pairs or files) from Kubernetes resources, not to mount arbitrary host filesystem paths.

Practice this question →
163
MCQmedium

A Deployment named 'web' runs in namespace 'prod'. The team wants every container in that Deployment to receive the environment variable 'LOG_LEVEL' from the ConfigMap 'app-config' key 'log.level', and the ConfigMap may be updated later. The application reads environment variables only at startup. Which single change to the Deployment's Pod template actually delivers the value?

A.Add an env entry with name 'LOG_LEVEL' and valueFrom.configMapKeyRef referencing name 'app-config' and key 'log.level'.
B.Add envFrom with configMapRef referencing 'app-config', and set the container's command to export LOG_LEVEL before starting the application.
C.Add a volume that mounts the 'app-config' ConfigMap at /etc/config, then add an env entry with valueFrom.configMapKeyRef referencing 'app-config' and key 'log.level'.
D.Add a projected volume that combines the 'app-config' ConfigMap with a downwardAPI source, then reference the mount path in the container's env valueFrom.fieldRef.
AnswerA

The configMapKeyRef inside a container's env valueFrom selects one key from a ConfigMap and presents it to the container as the named environment variable. Since the application reads environment variables at startup, this is exactly the mechanism required, and it maps the key 'log.level' onto the variable 'LOG_LEVEL' without needing a volume or any application change.

Why this answer

Environment variables sourced from a ConfigMap key use env.valueFrom.configMapKeyRef, which names the ConfigMap and the specific key. Because the application only reads environment variables at startup, the value must be present as an environment variable rather than as a mounted file. Referencing 'app-config' key 'log.level' under the name 'LOG_LEVEL' satisfies the requirement with a single, supported field.

Exam trap

The trap here is assuming that mounting a ConfigMap as a volume also exposes its values as environment variables.

Practice this question →
164
MCQhard

A pod has securityContext with capabilities.add: ['NET_ADMIN'] and capabilities.drop: ['ALL']. What effective capabilities does the container have?

A.No capabilities
B.All capabilities
C.Only NET_ADMIN
D.All capabilities except NET_ADMIN
AnswerC

This is correct. When a securityContext capabilities block contains drop: ["ALL"] and add: ["NET_ADMIN"], the container runtime first removes all capabilities from the container's default capability perimeter, then applies the add list to grant only NET_ADMIN. The result is a capability set with a single entry: CAP_NET_ADMIN, which permits privileged network operations such as interface configuration and firewall changes. All other capabilities, including common defaults like CHOWN or DAC_OVERRIDE, remain dropped because the drop ALL operation preceded the add. This narrow, explicit grant is often a deliberate least-privilege pattern, but it should be paired with a recognized need for network administration only.

Why this answer

When a container's securityContext specifies both `capabilities.drop: ['ALL']` and `capabilities.add: ['NET_ADMIN']`, the `drop: ['ALL']` first removes all capabilities, and then `add: ['NET_ADMIN']` adds back only the NET_ADMIN capability. The final effective set is exactly `[NET_ADMIN]`. This is the intended Kubernetes behavior: `drop` is processed before `add` within the same container spec.

Exam trap

The trap here is that candidates mistakenly think `drop: ['ALL']` overrides any `add` directives, or that the order of `drop` and `add` in the YAML matters, when in fact Kubernetes always processes `drop` first regardless of the order they are listed.

How to eliminate wrong answers

Option A is wrong because it ignores the `add: ['NET_ADMIN']` directive, which explicitly adds the NET_ADMIN capability after dropping all others. Option B is wrong because dropping all capabilities and then adding only one does not result in 'all capabilities'; it results in only the added one. Option D is wrong because it reverses the logic: NET_ADMIN is added, not dropped, so the container has NET_ADMIN, not 'all except NET_ADMIN'.

Practice this question →
165
MCQeasy

Which of the following YAML fields can be used to mount a Secret as a volume in a Pod?

A.volumes
B.imagePullSecrets
C.annotations
D.envFrom
AnswerA

The `volumes` field in a Pod's spec is the correct place to define a volume that uses a Secret as its source (e.g., `secret.secretName`). Once defined, the same volume is mounted into a specific container using `volumeMounts` at the desired path, allowing the Secret's keys to appear as files. This is the standard Kubernetes mechanism for mounting a Secret as a volume.

Why this answer

The `volumes` field in a Pod spec allows you to define a volume of type `secret`, which can then be mounted into a container using the `volumeMounts` field. This is the standard Kubernetes mechanism for exposing Secret data as files in the container's filesystem.

Exam trap

The trap here is that candidates confuse `envFrom` (which injects Secret data as environment variables) with volume mounting, or they mistakenly think `imagePullSecrets` or `annotations` can serve as volume sources, when in fact only the `volumes` field supports the `secret` volume type.

How to eliminate wrong answers

Option B is wrong because `imagePullSecrets` is used to specify credentials for pulling container images from private registries, not for mounting Secrets as volumes. Option C is wrong because `annotations` are metadata key-value pairs attached to objects for non-identifying information, and they cannot be used to mount Secrets as volumes. Option D is wrong because `envFrom` is used to populate environment variables from a ConfigMap or Secret, but it does not mount the Secret as a volume; it injects data as environment variables instead.

Practice this question →
166
Multi-Selectmedium

You need to create a Secret to store a TLS certificate and private key for use by an Ingress resource. Which two statements are correct? (Choose two.)

Select 2 answers
A.kubectl create secret tls my-tls --cert=cert.pem --key=key.pem
B.The Secret type should be 'kubernetes.io/tls' and the data keys must be 'tls.crt' and 'tls.key'.
C.Use 'kubectl create secret generic tls-secret --from-file=cert.pem --from-file=key.pem' with type Opaque.
D.The keys in the data section must be 'cert' and 'key'.
E.The Ingress resource references the Secret's data keys directly.
AnswersA, B

The 'kubectl create secret tls' command is purpose-built for TLS secrets: it automatically sets the secret type to 'kubernetes.io/tls' and populates the data keys 'tls.crt' and 'tls.key' using the provided certificate and key files. This is the recommended imperative way to create a TLS secret because it eliminates the risk of misnaming keys or using an incorrect secret type. Unlike a generic secret, this command guarantees the structure that controllers such as the Ingress controller expect.

Why this answer

`kubectl create secret tls my-tls --cert=cert.pem --key=key.pem` is the dedicated command to create a TLS secret, which automatically sets the type to `kubernetes.io/tls` and stores the certificate under the key `tls.crt` and the private key under `tls.key`. This is the standard method for creating secrets intended for use with Ingress resources.

Exam trap

The trap here is that candidates often think any secret containing a certificate and key will work with an Ingress, but the Ingress controller strictly requires the secret type to be `kubernetes.io/tls` and the data keys to be exactly `tls.crt` and `tls.key`, not generic Opaque secrets or custom key names.

Practice this question →
167
MCQeasy

What is the primary purpose of a Kubernetes ServiceAccount?

A.To provide an identity for processes running in a Pod
B.To grant permissions to users
C.To define network policies for Pods
D.To store Docker registry credentials
AnswerA

A ServiceAccount supplies a distinct identity that the Kubernetes API server associates with processes in a Pod. Workloads authenticate as that account when calling the API, and RBAC bindings grant the account specific permissions, decoupling Pod identity from individual users.

Why this answer

A Kubernetes ServiceAccount provides an identity for processes running in a Pod, allowing them to authenticate to the Kubernetes API server and to external services. When a Pod is created, it can be assigned a ServiceAccount, and the API server then associates that identity with the Pod's requests. This is distinct from user accounts, which are for human users.

Exam trap

CKAD often tests the confusion between ServiceAccounts (workload identity) and user accounts (human identity) — candidates pick the option about granting permissions to users because they conflate authentication with authorization.

How to eliminate wrong answers

Option B is wrong because granting permissions to users is done through RBAC roles and bindings for user accounts, not ServiceAccounts; ServiceAccounts are for workloads. Option C is wrong because network policies are defined by NetworkPolicy resources and control pod-to-pod traffic, not by ServiceAccounts. Option D is wrong because Docker registry credentials are stored in Kubernetes Secrets (of type kubernetes.io/dockerconfigjson) and referenced in Pod specs, not in ServiceAccounts.

Practice this question →
168
MCQmedium

A pod uses a ServiceAccount with automountServiceAccountToken set to false. The pod still needs to access the Kubernetes API. How can you mount the service account token in this pod?

A.Set automountServiceAccountToken: true in the pod spec
B.Create a secret with the token and mount it manually
C.Use a ConfigMap to store the token
D.Set serviceAccountName: default and automountServiceAccountToken: true in the pod spec
AnswerA

Setting automountServiceAccountToken: true directly in the pod spec is the correct, explicit override when the referenced ServiceAccount has automount disabled. This field takes precedence over the ServiceAccount's setting, causing the kubelet to project the service account token into the pod at /var/run/secrets/kubernetes.io/serviceaccount/token. That mounted token lets in-cluster clients authenticate to the Kubernetes API server without any extra steps.

Why this answer

Setting `automountServiceAccountToken: true` in the pod spec overrides the ServiceAccount-level setting of `false`. This allows the pod to mount the service account token automatically, enabling it to authenticate to the Kubernetes API without manual intervention.

Exam trap

The trap here is that candidates may think they need to manually create a Secret or ConfigMap to inject the token, when in fact the pod spec override of `automountServiceAccountToken` is the correct and simplest approach.

How to eliminate wrong answers

Option B is wrong because service account tokens are not stored as Secrets; they are automatically mounted via a projected volume, and manually creating a Secret with the token is unnecessary and insecure. Option C is wrong because ConfigMaps are designed for non-sensitive configuration data and cannot securely store service account tokens, which are sensitive credentials. Option D is wrong because setting `serviceAccountName: default` is irrelevant; the pod already uses a ServiceAccount, and the key issue is overriding `automountServiceAccountToken` to true, which is already covered by Option A.

Practice this question →
169
Multi-Selecteasy

Which two commands can create a ConfigMap from an environment file? (Select TWO.)

Select 2 answers
A.kubectl create configmap my-config --from-literal=app.env
B.kubectl create configmap my-config --from-env-file=app.env
C.kubectl create configmap my-config --from-file=app.env
D.kubectl create configmap my-config --from-file=key1=app.env
E.kubectl create configmap my-config --from-env=app.env
AnswersB, C

The --from-env-file flag is specifically designed to import environment variables from a file formatted as KEY=VALUE lines. It parses each line and creates a separate data entry in the ConfigMap for each key, automatically ignoring blank lines and comments. This is the correct method when the goal is to load the env file's variable definitions into the ConfigMap for later use as environment variables in a pod.

Why this answer

`--from-env-file=app.env` is the dedicated flag for creating a ConfigMap from an environment file, where each line in the file is parsed as a key=value pair. Option C is also correct because `--from-file=app.env` creates a ConfigMap with the file's entire contents stored under the filename as the key, which is a valid method even though it does not parse the file as environment variables.

Exam trap

The trap here is that candidates often confuse `--from-env-file` (which parses key=value pairs) with `--from-file` (which stores the file as a single entry), and may incorrectly assume that `--from-file` also parses environment files, or that `--from-env` is a valid flag.

Practice this question →
170
Multi-Selecthard

A Pod is configured with a securityContext that sets runAsUser: 1000 and runAsGroup: 3000 at the pod level. A container within that Pod has its own securityContext that sets runAsUser: 2000 but does not set runAsGroup. The container process attempts to create a file in a directory owned by group 3000 with group write permissions. Which two statements are true regarding the effective user and group of the container process? (Choose two.)

Select 2 answers
A.The container process runs with UID 1000 because pod-level settings take precedence.
B.The container process runs with UID 2000.
C.The container process runs with GID 3000.
D.The container process runs with GID 2000 because the container's runAsUser implies a matching group.
E.The container process cannot write to the directory because the group ID does not match the directory's group owner.
AnswersB, C

The container-level securityContext overrides the pod-level setting for runAsUser. Since the container specifies runAsUser: 2000, the process inside that container will run as UID 2000. This is a fundamental principle of securityContext inheritance: more specific scopes override broader ones. The pod-level runAsUser: 1000 is superseded for this container.

Why this answer

Container-level securityContext overrides pod-level for the same field, so runAsUser: 2000 applies. For runAsGroup, the container does not specify it, so it inherits the pod-level runAsGroup: 3000. Thus the process runs as UID 2000 and GID 3000, allowing write access to the group-writable directory.

Exam trap

The trap here is assuming that setting runAsUser at the container level also changes the group, or that pod-level settings override container-level settings.

Practice this question →
171
MCQeasy

Which command creates a Docker registry secret from an existing Docker config file?

A.kubectl create secret tls my-reg --cert=... --key=...
B.kubectl create secret generic my-reg --from-file=.dockerconfigjson=config.json
C.kubectl create secret docker-registry my-reg --docker-server=... --docker-username=...
D.kubectl create secret docker-registry my-reg --from-file=.dockerconfigjson=config.json
AnswerB

This is the correct approach because `kubectl create secret generic` with `--from-file=.dockerconfigjson=config.json` directly places the contents of your existing `config.json` file under the exact data key that Kubernetes expects. The secret is created as type `Opaque`, but the kubelet reads the `.dockerconfigjson` key regardless of the secret type, so it works as an imagePullSecret. This method preserves all registry entries and authentication tokens from the original file, making it ideal when you already have a `docker login` output.

Why this answer

`kubectl create secret generic` with `--from-file=.dockerconfigjson=config.json` creates a generic secret that stores the contents of an existing Docker config file (typically `~/.docker/config.json`) under the key `.dockerconfigjson`. This is the standard method for importing a pre-existing Docker configuration as a Kubernetes secret, which can then be used for image pull authentication.

Exam trap

CNCF often tests the distinction between `kubectl create secret docker-registry` (which creates a new secret from individual flags) and `kubectl create secret generic` with `--from-file` (which imports an existing config file), leading candidates to incorrectly choose option D because they assume `docker-registry` supports `--from-file`.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret tls` creates a TLS secret for serving certificates, not a Docker registry authentication secret. Option C is wrong because `kubectl create secret docker-registry` with `--docker-server`, `--docker-username`, etc. creates a new secret from individual credentials, not from an existing Docker config file. Option D is wrong because `kubectl create secret docker-registry` does not support the `--from-file` flag; that flag is only valid for `kubectl create secret generic`.

Practice this question →
172
MCQeasy

A Secret named 'db-secret' of type Opaque contains a key 'password'. How do you reference this key as an environment variable named 'DB_PASSWORD' in a pod spec?

A.env: - name: DB_PASSWORD valueFrom: configMapKeyRef: name: db-secret key: password
B.env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password
C.envFrom: - secretRef: name: db-secret key: password
D.env: - name: DB_PASSWORD value: "db-secret.password"
AnswerB

This is the correct way to consume a specific key from a Secret as an environment variable. The secretKeyRef field tells the kubelet to read the value associated with the password key from the Secret named db-secret in the same namespace, then assign it to DB_PASSWORD. The Secret must exist before the Pod starts, otherwise the container creation will fail with a resolution error.

Why this answer

It uses the `secretKeyRef` field under `valueFrom` to reference a specific key from a Kubernetes Secret of type Opaque. The `secretKeyRef` is the proper mechanism to inject a single key from a Secret as an environment variable, mapping the key 'password' to the environment variable name 'DB_PASSWORD'.

Exam trap

The trap here is confusing `configMapKeyRef` with `secretKeyRef` — CNCF often tests whether candidates know that Secrets require `secretKeyRef` while ConfigMaps use `configMapKeyRef`, and that `envFrom` with `secretRef` injects all keys, not a single key.

How to eliminate wrong answers

Option A is wrong because it uses `configMapKeyRef`, which is used to reference keys from a ConfigMap, not a Secret; Secrets require `secretKeyRef`. Option C is wrong because `envFrom` with `secretRef` injects all keys from the Secret as environment variables, not a single key, and the syntax shown incorrectly includes a `key` field which is not valid under `secretRef`. Option D is wrong because it uses a static `value` string, which does not dynamically reference the Secret's key; Kubernetes will treat the string literally as 'db-secret.password' rather than fetching the actual password value.

Practice this question →
173
MCQmedium

Which command correctly creates a Role named 'pod-reader' that allows get, list, and watch on pods?

A.kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
B.kubectl create role pod-reader --verb=get,list,watch --resource=Pod
C.kubectl create role pod-reader --verb=get,list,watch --resource=pods
D.kubectl create role pod-reader --verbs=get,list,watch --resources=pods
AnswerC

This is the correct syntax because it supplies all three verbs as a single comma-separated value for the --verb flag and specifies the resource using the standard lowercase plural name pods. The kubectl create role command uses this input to generate or directly create a Role object that grants get, list, and watch permissions on pods in the active namespace. This exactly matches the documented command line syntax for kubectl create role, making it the only valid option among the four.

Why this answer

The `kubectl create role` command uses the `--verb` flag (singular) with comma-separated values and the `--resource` flag (singular) with the lowercase plural resource name 'pods'. This matches the Kubernetes API convention where resources are specified as lowercase plurals (e.g., 'pods', 'deployments') and verbs are comma-separated.

Exam trap

The trap here is that candidates often confuse the singular `--verb`/`--resource` flags with the plural `--verbs`/`--resources` or incorrectly use repeated `--verb` flags, leading to syntax errors or incorrect RBAC rule generation.

How to eliminate wrong answers

Option A is wrong because it uses multiple `--verb` flags, which is not the correct syntax; `kubectl create role` expects a single `--verb` flag with comma-separated values, not repeated flags. Option B is wrong because it uses 'Pod' with a capital P, but Kubernetes resource names must be lowercase plural (e.g., 'pods'). Option D is wrong because it uses `--verbs` (plural) and `--resources` (plural), but the correct flags are the singular forms `--verb` and `--resource`.

Practice this question →
174
Multi-Selecthard

You are troubleshooting a Pod that cannot start because it fails with 'Error: container has runAsNonRoot and image will run as root'. The Pod's SecurityContext has 'runAsNonRoot: true' and no explicit 'runAsUser'. Which three actions could resolve this? (Choose three.)

Select 3 answers
A.Remove 'runAsNonRoot: true' from the SecurityContext.
B.Set 'readOnlyRootFilesystem: true' in the SecurityContext.
C.Use a container image that runs as a non-root user by default.
D.Set 'runAsGroup: 3000' in the SecurityContext.
E.Set 'runAsUser: 1000' in the SecurityContext.
AnswersA, C, E

The 'runAsNonRoot: true' field tells the kubelet to reject the pod if the container would start as UID 0. Because this image runs as root by default, that validation triggers the failure. Removing the flag disables the admission-time check and lets the container start with root privileges, though it also drops this particular security hardening control.

Why this answer

Removing 'runAsNonRoot: true' eliminates the constraint that the container image must run as a non-root user. Since the image runs as root by default and no 'runAsUser' is set, the Pod fails. Removing the flag allows the container to start with its default root user.

Exam trap

The trap here is that candidates may think setting 'runAsGroup' or 'readOnlyRootFilesystem' can indirectly fix the user mismatch, but neither changes the effective UID, so they do not resolve the runAsNonRoot violation.

Practice this question →
175
MCQmedium

A pod uses a ServiceAccount 'my-sa' but the pod's container needs to list pods in the namespace. Which RBAC resources are necessary?

A.Role and RoleBinding
B.Role and ClusterRoleBinding
C.ServiceAccount and RoleBinding only
D.ClusterRole and ClusterRoleBinding
AnswerA

This combination is correct because the pod's ServiceAccount needs permissions only within its own namespace. A Role defines namespace-scoped rules—such as get/list pods in the specified namespace—and the RoleBinding links that Role to the ServiceAccount as the subject. Since both the Role and the ServiceAccount exist in the same namespace, the RoleBinding can directly grant the pod's identity exactly the permissions it needs without exposing them cluster-wide.

Why this answer

A Role and RoleBinding are necessary because the pod's ServiceAccount 'my-sa' needs permissions to list pods within a specific namespace. A Role defines the allowed API operations (e.g., 'list pods') scoped to a namespace, and a RoleBinding binds that Role to the ServiceAccount, granting those permissions within that namespace. This is the standard RBAC pattern for namespace-scoped access in Kubernetes.

Exam trap

CNCF often tests the distinction between namespace-scoped and cluster-scoped RBAC resources, trapping candidates who assume that any 'list pods' operation requires a ClusterRole, when in fact a Role and RoleBinding are sufficient for a single namespace.

How to eliminate wrong answers

Option B is wrong because a ClusterRoleBinding would grant cluster-wide permissions, which is excessive and unnecessary for listing pods in a single namespace; a RoleBinding is sufficient. Option C is wrong because a ServiceAccount alone does not grant permissions; it requires a Role (or ClusterRole) to define the allowed actions, and a RoleBinding to associate them. Option D is wrong because a ClusterRole and ClusterRoleBinding grant permissions across all namespaces, which is overkill and violates the principle of least privilege for a namespace-scoped operation.

Practice this question →
176
MCQeasy

A pod is scheduled but remains in 'Pending' state. Running 'kubectl describe pod mypod' shows: '0/1 nodes are available: 1 Insufficient memory'. What is the most likely cause?

A.The pod's memory request exceeds the available memory on any node
B.The pod is using too many CPU resources
C.The pod's memory limit is too low
D.The pod's container is crashing due to a bug
AnswerA

The Kubernetes scheduler only assigns a pod to a node when it can satisfy the pod's total resource requests against the node's allocatable capacity. If the sum of memory requests across all containers in the pod exceeds the available (unrequested) memory on every node, the pod remains in Pending with a scheduling failure. The event 'Insufficient memory' confirms that no node has enough unreserved memory to guarantee the requested amount. Remember that requests, not limits, are the scheduling constraint.

Why this answer

The '0/1 nodes are available: 1 Insufficient memory' message indicates that the Kubernetes scheduler attempted to place the pod on a node but found that the node's allocatable memory is less than the pod's memory request. The pod's memory request must be satisfied by at least one node for scheduling to succeed; if no node has enough unallocated memory, the pod remains Pending. This is a resource request, not a limit, that gates scheduling.

Exam trap

The trap here is that candidates confuse memory requests with memory limits, assuming that setting a low limit (or no limit) would fix scheduling, when in fact the scheduler only evaluates requests, not limits.

How to eliminate wrong answers

Option B is wrong because the error message explicitly mentions 'Insufficient memory', not CPU; insufficient CPU would produce a different message like 'Insufficient cpu'. Option C is wrong because a low memory limit does not prevent scheduling—limits are enforced at runtime by the kubelet, not by the scheduler; the scheduler only considers requests. Option D is wrong because a crashing container would result in a CrashLoopBackOff or Error state, not a Pending state; Pending means the pod has not been scheduled to a node yet.

Practice this question →
177
MCQmedium

You have a service account 'my-sa' in the default namespace. You want a pod to use this service account and also prevent the pod from mounting the service account token. Which pod spec configuration is correct?

A.spec: serviceAccountName: my-sa automountServiceAccountToken: true
B.spec: serviceAccount: my-sa automountServiceAccountToken: true
C.spec: serviceAccountName: my-sa automountServiceAccountToken: false
D.spec: serviceAccountName: default automountServiceAccountToken: false
AnswerC

This is the correct configuration: it sets serviceAccountName to 'my-sa', giving the pod the RBAC identity and permissions associated with that service account, and sets automountServiceAccountToken: false to prevent the kubelet from placing the service account token inside the container. This ensures the pod can authenticate or be authorized as 'my-sa' where needed, but the token is not exposed on the filesystem, exactly as the requirement demands. The combination is the canonical way to decouple service account identity from token accessibility.

Why this answer

Setting `automountServiceAccountToken: false` in the pod spec prevents the automatic mounting of the service account token, while `serviceAccountName: my-sa` specifies the desired service account. This satisfies both requirements: using the custom service account and disabling token mounting.

Exam trap

CNCF often tests the distinction between the deprecated `serviceAccount` field and the current `serviceAccountName` field, as well as the default `true` value of `automountServiceAccountToken`, leading candidates to overlook the need to explicitly set it to `false` when token mounting must be prevented.

How to eliminate wrong answers

Option A is wrong because `automountServiceAccountToken: true` explicitly mounts the token, which contradicts the requirement to prevent token mounting. Option B is wrong because it uses the deprecated `serviceAccount` field (instead of `serviceAccountName`) and sets `automountServiceAccountToken: true`, which again mounts the token. Option D is wrong because it specifies the `default` service account instead of `my-sa`, failing to use the required service account.

Practice this question →
178
Multi-Selectmedium

Which TWO of the following are valid ways to consume environment variables from a ConfigMap in a pod?

Select 2 answers
A.envFrom: - configMapRef: name: myconfig
B.env: - name: VAR configMapRef: name: myconfig key: mykey
C.volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: myconfig
D.env: - name: VAR valueFrom: configMapKeyRef: name: myconfig key: mykey
E.env: - name: VAR valueFrom: configMapRef: name: myconfig key: mykey
AnswersA, D

The envFrom field injects all key-value pairs from the referenced ConfigMap as environment variables into the container. Each key in the ConfigMap becomes an environment variable name, provided the key is a valid environment variable name; invalid keys are skipped. This is a bulk injection method, unlike the selective method used with valueFrom.configMapKeyRef.

Why this answer

`envFrom` with a `configMapRef` injects all key-value pairs from the named ConfigMap as environment variables into the container. This is a concise way to consume multiple variables without specifying each key individually, as defined in the Kubernetes API for Pods.

Exam trap

The trap here is confusing `envFrom` with `env` syntax: candidates often misremember that `configMapRef` can be used directly under `env` (like in Option B), or they confuse `configMapKeyRef` with `configMapRef` (Option E), which is only valid under `envFrom`.

Practice this question →
179
MCQeasy

Which kubectl command creates a Secret named 'db-secret' with key 'password' and value 'mypwd'?

A.kubectl create secret generic db-secret password=mypwd
B.kubectl create secret generic db-secret --from-file=password=mypwd
C.kubectl create secret generic db-secret --from-literal=password=mypwd
D.kubectl create secret generic db-secret --from-env-file=password=mypwd
AnswerC

This is the canonical syntax for creating an Opaque Secret from a single inline key-value pair. The `--from-literal=password=mypwd` flag tells kubectl to split the string on the first `=`, then store the value `mypwd` under the key `password` in the Secret's `data` field (base64-encoded by the API). It is unambiguous and works as intended, though it is worth remembering that the secret value is visible in the shell command and process list, so for production secrets you would normally use `--from-file` or an external secrets manager to avoid exposing credentials.

Why this answer

`kubectl create secret generic` with `--from-literal` allows you to specify key-value pairs directly on the command line. The syntax `--from-literal=password=mypwd` creates a secret with key 'password' and value 'mypwd', which is the exact requirement.

Exam trap

The trap here is that candidates confuse `--from-literal` with `--from-file` or the bare `key=value` syntax, mistakenly thinking any `key=value` format works without the correct flag.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret generic` does not accept a bare `key=value` syntax; it requires a flag like `--from-literal` to specify literal key-value pairs. Option B is wrong because `--from-file` expects a file path, not a literal key-value pair; using `--from-file=password=mypwd` would try to read a file named 'password=mypwd', which does not exist. Option D is wrong because `--from-env-file` expects a file containing environment variables in key=value format, not a single literal key-value pair on the command line.

Practice this question →
180
MCQhard

You want to enforce that all pods in a namespace run with the 'restricted' Pod Security Standard (Pod Security Admission). Which label should you set on the namespace?

A.pod-security.kubernetes.io/warn=restricted
B.pod-security.kubernetes.io/enforce=baseline
C.pod-security.kubernetes.io/enforce=restricted
D.pod-security.kubernetes.io/audit=restricted
AnswerC

The pod-security.kubernetes.io/enforce=restricted label is correct because it instructs the Pod Security Admission controller to use the most secure level of the Kubernetes Pod Security Standards. All pods (and pod templates in workloads) are checked against the restricted profile during admission, and if they fail—for example, by allowing privilege escalation, setting privileged: true, or omitting a required seccompProfile—the API server rejects the request. This guarantees that every pod running in the namespace adheres to a hardened, baseline-plus configuration. Using enforce mode (rather than warn or audit) is the only option that actually blocks non-compliant pods.

Why this answer

The `pod-security.kubernetes.io/enforce=restricted` label enforces the 'restricted' Pod Security Standard on the namespace, preventing any pod that violates the restricted policy from being created. This label directly activates Pod Security Admission (PSA) enforcement mode, which blocks non-compliant pods at admission time.

Exam trap

The trap here is that candidates often confuse the three PSA modes (enforce, warn, audit) and select a 'warn' or 'audit' label thinking it blocks non-compliant pods, when only 'enforce' actually prevents pod creation.

How to eliminate wrong answers

Option A is wrong because `pod-security.kubernetes.io/warn=restricted` only generates a warning for non-compliant pods but does not enforce the policy, so pods violating the restricted standard would still be created. Option B is wrong because `pod-security.kubernetes.io/enforce=baseline` enforces the 'baseline' standard, which is less restrictive than 'restricted' and allows some privileged configurations that the restricted standard would block. Option D is wrong because `pod-security.kubernetes.io/audit=restricted` only logs violations to the audit log without blocking or warning, so pods violating the restricted standard would still be admitted.

Practice this question →
181
MCQmedium

You need to set environment variables in a pod from a ConfigMap 'app-config' that has keys 'APP_ENV' and 'APP_DEBUG'. Which approach exposes all keys as environment variables?

A.envFrom: - secretRef: name: app-config
B.env: - name: APP_ENV valueFrom: configMapKeyRef: name: app-config key: APP_ENV - name: APP_DEBUG valueFrom: configMapKeyRef: name: app-config key: APP_DEBUG
C.envFrom: - configMapRef: name: app-config
D.volumeMounts: - name: config mountPath: /etc/config volumes: - name: config configMap: name: app-config
AnswerC

envFrom with configMapRef automatically creates an environment variable for each key in the ConfigMap, using the key name as the variable name. This is the intended way to inject an entire ConfigMap into the pod's environment without explicitly mapping each key. Note that keys that are not valid environment variable names are skipped, and this snapshot is taken at pod creation.

Why this answer

`envFrom` with `configMapRef` is the Kubernetes-native way to expose all keys from a ConfigMap as environment variables in a pod. This injects each key-value pair from the ConfigMap 'app-config' as an environment variable, matching the requirement to expose all keys without manual enumeration.

Exam trap

CNCF often tests the distinction between `configMapRef` and `secretRef`, and the trap here is that candidates confuse ConfigMaps with Secrets or assume that mounting a ConfigMap as a volume is equivalent to setting environment variables, leading them to pick Option A or D.

How to eliminate wrong answers

Option A is wrong because it uses `secretRef` which references a Secret, not a ConfigMap; Secrets are for sensitive data (e.g., passwords) and cannot read from a ConfigMap. Option B is wrong because it manually enumerates each key using `configMapKeyRef`, which works but does not expose 'all keys' automatically; it requires explicit listing of each key, violating the requirement. Option D is wrong because it mounts the ConfigMap as a volume at `/etc/config`, creating files named after the keys (e.g., `APP_ENV` and `APP_DEBUG`), not environment variables; this is a different mechanism for injecting configuration.

Practice this question →
182
MCQeasy

Which of the following is the correct way to set an environment variable 'APP_COLOR' from a ConfigMap key 'color'?

A.env: - name: APP_COLOR valueFrom: configMapRef: name: my-config key: color
B.envFrom: - configMapKeyRef: name: my-config key: color
C.env: - name: APP_COLOR valueFrom: configMapKeyRef: name: my-config key: color
D.env: - name: APP_COLOR value: "configMap.color"
AnswerC

This is correct because it uses the `env` array to define a single environment variable named `APP_COLOR`, then sources its value from the ConfigMap named `my-config` via `valueFrom.configMapKeyRef`, specifying the exact `key: color`. The `configMapKeyRef` field is the precise mechanism for pulling one key's value into an environment variable—it is the Kubernetes-standard way to make a ConfigMap value available inside a container under a chosen env var name.

Why this answer

It uses the `configMapKeyRef` field under `valueFrom` in the `env` array to inject a specific key from a ConfigMap as an environment variable. This is the standard Kubernetes syntax for referencing a single key from a ConfigMap, where `name` specifies the ConfigMap object and `key` specifies the key within that ConfigMap whose value will be assigned to the environment variable `APP_COLOR`.

Exam trap

The trap here is confusing `configMapRef` (used in `envFrom` to import all keys) with `configMapKeyRef` (used in `env` to import a single key), leading candidates to choose Option A or B due to similar naming.

How to eliminate wrong answers

Option A is wrong because `configMapRef` is not a valid field under `valueFrom`; `configMapRef` is used in `envFrom` to load all keys from a ConfigMap, not a single key. Option B is wrong because `envFrom` uses `configMapRef` (not `configMapKeyRef`) and cannot target a specific key; it imports all key-value pairs from the ConfigMap as environment variables, and the syntax shown (`configMapKeyRef`) is invalid. Option D is wrong because it attempts to set a literal string value `"configMap.color"` rather than referencing the ConfigMap key, which would not resolve to the actual value from the ConfigMap.

Practice this question →
183
MCQeasy

To mount a ConfigMap as a volume, which field type must be used in the pod spec's volumes and volumeMounts?

A.configMap
B.emptyDir
C.secret
D.hostPath
AnswerA

The configMap volume type is the only correct choice because it directly references a ConfigMap object in the volumes field of a pod spec. When this type is used, the kubelet retrieves the ConfigMap's key-value data and materializes it as files in the volume, making the configuration accessible to containers via mountPath. You can further control the projection with items for selecting specific keys and defaultMode for file permissions.

Why this answer

To mount a ConfigMap as a volume in a Pod, the `configMap` field type must be specified in the `volumes` array of the Pod spec, and the corresponding `volumeMounts` entry references that volume by name. This tells Kubernetes to populate the volume with the key-value pairs from the ConfigMap, making them available as files in the container's filesystem.

Exam trap

The trap here is that candidates often confuse `configMap` with `secret` because both are used to inject configuration data, but the question specifically asks for the field type to mount a ConfigMap, not a Secret.

How to eliminate wrong answers

Option B (emptyDir) is wrong because it creates an empty, ephemeral directory that is not backed by any ConfigMap or Secret; it is used for scratch space or sharing data between containers. Option C (secret) is wrong because it mounts a Secret, not a ConfigMap; while both are volume types, they are distinct resources with different data sources and use cases. Option D (hostPath) is wrong because it mounts a file or directory from the host node's filesystem, not from a Kubernetes ConfigMap object.

Practice this question →
184
MCQmedium

A pod manifest includes the following securityContext: securityContext: { runAsUser: 1000, runAsGroup: 3000, fsGroup: 2000 }. What UID will be used for processes in the container?

A.0 (root)
B.3000
C.2000
D.1000
AnswerD

runAsUser: 1000 is the correct UID because it directly sets the numeric user ID for the container's primary process. When a container starts, the process is launched with this UID unless an image-level USER directive is overridden by this field. The securityContext's runAsUser takes precedence over the image's default user, so the process runs as UID 1000.

Why this answer

The `runAsUser` field in the pod's securityContext explicitly sets the user ID (UID) for all processes in the container. In this manifest, `runAsUser: 1000` overrides the default UID (usually 0, root) and ensures that the container's main process runs with UID 1000. The `runAsGroup` and `fsGroup` fields affect group IDs and file ownership, not the process UID.

Exam trap

CNCF often tests the distinction between `runAsUser` (process UID), `runAsGroup` (process GID), and `fsGroup` (volume ownership GID), and the trap here is that candidates confuse `fsGroup` or `runAsGroup` with the process UID, leading them to select 2000 or 3000 instead of 1000.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 1000` explicitly overrides the default root UID (0), so processes do not run as root. Option B is wrong because `runAsGroup: 3000` sets the primary group ID (GID) for the process, not the UID. Option C is wrong because `fsGroup: 2000` is used to set the group ownership of mounted volumes and any files created in them, but it does not affect the UID of the container's processes.

Practice this question →
185
MCQeasy

Which kubectl command creates a Secret from literal username and password values?

A.kubectl create secret generic my-secret --literal username=admin password=secret123
B.kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secret123
C.kubectl create secret generic my-secret --from-file=username --from-file=password
D.kubectl create secret generic my-secret --from-env-file=creds.txt
AnswerB

The --from-literal flag supplies key-value pairs directly on the command line, creating a generic Secret without files. This satisfies the requirement to build a Secret from literal username and password values in a single imperative command.

Why this answer

`kubectl create secret generic` with `--from-literal` is the proper syntax for specifying literal key-value pairs directly in the command. Each literal must be prefixed with `--from-literal=key=value`, and multiple literals can be provided to create a Secret containing both the username and password keys.

Exam trap

The trap here is that candidates confuse `--from-literal` with the non-existent `--literal` flag, or assume that multiple key-value pairs can be passed in a single `--from-literal` argument, leading them to choose Option A.

How to eliminate wrong answers

Option A is wrong because it uses `--literal` instead of the correct `--from-literal` flag, and the syntax `--literal username=admin password=secret123` is invalid — kubectl requires each literal to be specified with its own `--from-literal=key=value` flag. Option C is wrong because `--from-file` creates a Secret from file contents, not literal values; it would read the files named 'username' and 'password' from the filesystem, not use inline strings. Option D is wrong because `--from-env-file` imports key-value pairs from a file in the format `KEY=VALUE`, but it does not accept literal values directly on the command line.

Practice this question →
186
MCQmedium

You need to mount a Secret 'db-secret' as a volume in a pod, making its keys appear as individual files. Which volume definition is correct?

A.volumes: - name: secret-vol emptyDir: medium: Secret
B.volumes: - name: secret-vol secret: secretName: db-secret items: - key: password path: credentials.txt
C.volumes: - name: secret-vol configMap: name: db-secret
D.volumes: - name: secret-vol secret: secretName: db-secret
AnswerD

This is the correct way to mount a Secret as a volume. The secret volume source with secretName: db-secret tells Kubernetes to create a volume backed by the db-secret Secret. By default, the volume contains a separate file for each key in the Secret, with the filename matching the key and the file content holding the corresponding decoded value. This satisfies the requirement of mounting the db-secret secret as a volume with all keys exposed as individual files.

Why this answer

It defines a volume of type `secret` with the `secretName` field set to `db-secret`, which mounts the entire Secret as a volume. By default, each key in the Secret becomes a file named after the key, satisfying the requirement that keys appear as individual files.

Exam trap

The trap here is that candidates often confuse the `items` field (which projects specific keys into custom filenames) with the default behavior (which mounts all keys as individual files), leading them to pick Option B even though it does not meet the requirement of making all keys appear as individual files.

How to eliminate wrong answers

Option A is wrong because `emptyDir` volumes are ephemeral storage directories, not Secret mounts; the `medium` field accepts values like `Memory`, not `Secret`. Option B is wrong because it uses the `items` field to project only a single key (`password`) into a file named `credentials.txt`, which does not make all keys appear as individual files. Option C is wrong because `configMap` references a ConfigMap, not a Secret; Secrets and ConfigMaps are separate resource types with different handling (e.g., Secrets are base64-encoded).

Practice this question →
187
MCQmedium

A pod is stuck in Pending state. You run 'kubectl describe pod my-pod' and see the event: '0/4 nodes are available: 1 Insufficient cpu, 3 Insufficient memory'. What is the most likely cause?

A.The pod's resource requests exceed the available node resources
B.The pod uses too many secrets
C.The pod's resource limits are too low
D.The pod's container is failing health checks
AnswerA

The Kubernetes scheduler selects a node based on the resource requests (CPU and memory) declared in the pod spec. If no node has enough allocatable resources to satisfy those requests after accounting for the requests of existing pods, the scheduler cannot place the pod, leaving it in Pending state. This is the most common cause of Pending, and `kubectl describe` typically shows FailedScheduling events with reasons like 'Insufficient cpu' or 'Insufficient memory'.

Why this answer

The event '0/4 nodes are available: 1 Insufficient cpu, 3 Insufficient memory' indicates that the Kubernetes scheduler could not find any node that satisfies the pod's resource requests. The pod's resource requests (spec.containers[].resources.requests) define the minimum CPU and memory the pod requires to run. If the sum of requests across all pods on a node exceeds the node's allocatable resources, the scheduler marks the node as unschedulable for that pod, leaving it in Pending state.

Exam trap

The trap here is that candidates often confuse resource requests with resource limits, thinking that low limits cause scheduling failures, but Kubernetes only uses requests for scheduling decisions, not limits.

How to eliminate wrong answers

Option B is wrong because using too many secrets does not affect pod scheduling; secrets are mounted as files or environment variables and do not consume node resources like CPU or memory. Option C is wrong because resource limits (spec.containers[].resources.limits) are not used for scheduling decisions; limits only control how much a container can use after it starts, and low limits would not cause a Pending state. Option D is wrong because failing health checks (liveness/readiness probes) cause the pod to be restarted or marked as Unhealthy after it is already running, not while it is still in Pending state before any container starts.

Practice this question →
188
MCQmedium

A developer wants to enforce that containers in a namespace cannot run as privileged. Which Pod Security Standard profile should they apply to the namespace?

A.privileged
B.restricted
C.baseline
D.custom
AnswerC

`baseline` is the correct standard because it was designed to prevent the most well-known privilege escalations while preserving typical workload functionality. It disallows privileged containers, hostNetwork, hostPID, and hostIPC namespaces, and drops dangerous capabilities (such as CAP_SYS_ADMIN), yet still permits common capabilities like NET_BIND_SERVICE. This directly meets the developer's requirement without imposing the stricter, workload-breaking rules found in `restricted`, making it the intended middle-ground security policy.

Why this answer

(baseline) is correct because the baseline Pod Security Standard (PSS) profile enforces the minimum restrictions necessary to prevent known privilege escalations, including the prohibition of privileged containers (i.e., `privileged: true` in the security context). This profile is designed to be applied to namespaces where most workloads run, blocking the most common security issues without breaking typical applications. The restricted profile would also block privileged containers but imposes additional constraints (e.g., dropping all capabilities, read-only root filesystem) that are not required by the question's specific goal.

Exam trap

The trap here is that candidates often confuse the 'restricted' profile as the only option to block privileged containers, not realizing that 'baseline' also blocks them and is the appropriate choice when the goal is simply to prevent privileged escalation without imposing the full set of restricted constraints.

How to eliminate wrong answers

Option A is wrong because the privileged profile allows all known privilege escalations, including running containers as privileged, which is the opposite of what the developer wants to enforce. Option B is wrong because the restricted profile, while also blocking privileged containers, goes beyond the requirement by enforcing additional restrictions like dropping all capabilities, setting `runAsNonRoot: true`, and requiring a read-only root filesystem, which may break workloads that do not need such strictness. Option D is wrong because 'custom' is not a valid Pod Security Standard profile; the three standard profiles defined by Kubernetes are privileged, baseline, and restricted.

Practice this question →
189
MCQhard

A pod must run with a seccomp profile that only allows specific syscalls. Which SecurityContext field is used to specify the seccomp profile type?

A.appArmorProfile
B.seLinuxOptions
C.seccomp
D.seccompProfile
AnswerD

The seccompProfile field within the securityContext is the correct way to specify a seccomp profile. It supports three types: RuntimeDefault (the container runtime's default syscall filter), Localhost (a custom profile stored on the node), and Unconfined (no seccomp filtering). Setting this field ensures the Pod's containers run with the specified seccomp syscall restrictions.

Why this answer

`seccompProfile` is the field within the Pod or container `SecurityContext` that specifies the seccomp profile type (e.g., `RuntimeDefault`, `Localhost`, or `Unconfined`). This field was introduced in Kubernetes v1.19 (beta) and replaces the older annotation-based seccomp configuration, allowing you to define the profile type directly in the pod spec.

Exam trap

The trap here is that candidates confuse the older annotation-based approach (`seccomp.security.alpha.kubernetes.io/pod`) with the newer native `seccompProfile` field, or they mistakenly think the field is simply named `seccomp` instead of `seccompProfile`.

How to eliminate wrong answers

Option A is wrong because `appArmorProfile` is not a valid field in the Kubernetes SecurityContext; AppArmor profiles are configured via annotations (e.g., `container.apparmor.security.beta.kubernetes.io`), not a dedicated field. Option B is wrong because `seLinuxOptions` is used to set SELinux labels (e.g., user, role, type, level) for a container, not to specify seccomp profiles. Option C is wrong because `seccomp` is not a field in the SecurityContext; the correct field name is `seccompProfile`, which contains the `type` and optionally `localhostProfile` subfields.

Practice this question →
190
Multi-Selectmedium

Which TWO of the following are valid ways to expose a Secret as an environment variable in a pod? (Select two.)

Select 2 answers
A.envFrom: - secretRef: name: db-secret
B.volumes: - name: secret-volume secret: secretName: db-secret
C.env: - secretRef: name: db-secret
D.envFrom: - configMapRef: name: db-secret
E.env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password
AnswersA, E

The `envFrom` field with `secretRef` injects all key-value pairs from the `db-secret` Secret as environment variables, each key becoming a variable name. This satisfies the stem’s requirement for exposing a Secret as an environment variable without needing individual key references, leveraging the `envFrom` mechanism for bulk injection in a Pod spec.

Why this answer

`envFrom` with a `secretRef` allows all key-value pairs from a Secret to be injected as environment variables into a container. This is a concise method to expose multiple secret entries without specifying each one individually.

Exam trap

The trap here is that candidates confuse `envFrom` with `env` syntax, or mistakenly think a volume mount (option B) or a ConfigMap reference (option D) can expose Secrets as environment variables.

Practice this question →
191
MCQmedium

You want to enforce that all pods in a namespace have a minimum memory request of 100Mi and a maximum memory limit of 1Gi. Which resource should you create?

A.PodSecurityPolicy
B.LimitRange with limits: - max: memory: 128Mi min: memory: 100Mi
C.ResourceQuota
D.LimitRange
AnswerD

LimitRange is the correct mechanism because it applies admission-time validation and defaulting to every pod and container created in a namespace, allowing you to set minimum and maximum request and limit values. This directly enforces that all pods have a memory request within the specified range and, if configured, that a memory limit of 1Gi is not exceeded. It is the standard Kubernetes primitive for this exact use case.

Why this answer

A LimitRange (option D) is the correct resource because it allows you to set default, minimum, and maximum resource constraints (CPU/memory) at the namespace level, which are enforced per pod or container. In this case, you can define a LimitRange with a `min` of 100Mi and a `max` of 1Gi for memory, ensuring every pod in the namespace adheres to these bounds.

Exam trap

The trap here is that candidates confuse ResourceQuota (which sets namespace-wide totals) with LimitRange (which sets per-pod constraints), or they misconfigure the LimitRange with incorrect `max`/`min` values that don't match the requirement.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (PSP) is a deprecated cluster-level resource that controls security-related pod specifications (e.g., privileged containers, host namespaces), not resource requests or limits. Option B is wrong because the `max` value of 128Mi contradicts the requirement of a maximum memory limit of 1Gi, and the `min` value of 100Mi is correct but the `max` is too restrictive; also, the syntax shown is incomplete (missing `default` and `defaultRequest` fields) and does not match the required LimitRange structure. Option C is wrong because ResourceQuota sets aggregate resource consumption limits for the entire namespace (e.g., total memory across all pods), not per-pod minimum or maximum constraints.

Practice this question →
192
MCQmedium

A developer wants to ensure a container runs as a non-root user with user ID 1000 and group ID 2000. Which SecurityContext fields should be set?

A.runAsUser: 1000, runAsGroup: 2000, runAsNonRoot: false
B.runAsUser: 1000, runAsGroup: 2000, runAsNonRoot: true
C.runAsUser: 1000, runAsGroup: 2000, allowPrivilegeEscalation: false
D.runAsUser: 1000, fsGroup: 2000, runAsNonRoot: true
AnswerB

This is the correct setup because runAsUser: 1000 forces the container's primary process to execute with UID 1000, and runAsGroup: 2000 sets its primary GID to 2000. The runAsNonRoot: true flag performs a validation at container start, refusing to launch any container whose effective user is UID 0, even if the image's USER directive specifies root. Together these fields completely fulfill the requirement to guarantee non-root execution.

Why this answer

Setting `runAsUser: 1000` and `runAsGroup: 2000` ensures the container's processes run with user ID 1000 and group ID 2000, while `runAsNonRoot: true` enforces that the container cannot run as root (UID 0), providing a security best practice for non-root execution.

Exam trap

The trap here is confusing `fsGroup` (which controls group ownership of mounted volumes) with `runAsGroup` (which sets the container process's primary group ID), leading candidates to pick option D instead of B.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot: false` explicitly allows root execution, contradicting the requirement to run as a non-root user. Option C is wrong because `allowPrivilegeEscalation: false` only prevents privilege escalation (e.g., via setuid binaries) but does not enforce a specific non-root user or group; the container could still run as root. Option D is wrong because `fsGroup: 2000` sets the group ID for volume ownership, not the container's primary group ID; the correct field for the container's group is `runAsGroup`, not `fsGroup`.

Practice this question →
193
MCQhard

You need to create a Secret of type 'kubernetes.io/tls' for ingress. Which command is correct?

A.kubectl create secret generic my-tls --from-file=cert.pem --from-file=key.pem
B.kubectl create secret tls my-tls --certificate=cert.pem --private-key=key.pem
C.kubectl create secret tls my-tls --from-file=tls.crt=cert.pem --from-file=tls.key=key.pem
D.kubectl create secret tls my-tls --cert=cert.pem --key=key.pem
AnswerD

`kubectl create secret tls` builds a `kubernetes.io/tls` Secret directly from a PEM certificate and its matching private key, satisfying the ingress TLS requirement. The `--cert` and `--key` flags map to the `tls.crt` and `tls.key` data fields that ingress controllers expect, avoiding manual base64 encoding.

Why this answer

`kubectl create secret tls` is the dedicated command for creating a TLS secret, and it uses the `--cert` and `--key` flags to specify the certificate and private key files respectively. This creates a Secret of type `kubernetes.io/tls`, which is required for Ingress resources to terminate HTTPS traffic.

Exam trap

The trap here is that candidates confuse the `--from-file` syntax from `kubectl create secret generic` with the dedicated TLS command, or misremember the flag names as `--certificate`/`--private-key` instead of the correct `--cert`/`--key`.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret generic` creates a generic (Opaque) Secret, not a `kubernetes.io/tls` type, and Ingress requires the TLS-specific type to correctly interpret the certificate and key data. Option B is wrong because the flags `--certificate` and `--private-key` are not valid for `kubectl create secret tls`; the correct flags are `--cert` and `--key`. Option C is wrong because `--from-file` is used with `kubectl create secret generic`, not with `kubectl create secret tls`, and the `tls.crt`/`tls.key` key names are automatically set by the `tls` subcommand when using the correct flags.

Practice this question →
194
MCQmedium

A Pod spec includes 'securityContext' with 'runAsUser: 1000' and 'runAsGroup: 3000'. The container process inside the pod is expected to write to a mounted volume. Which securityContext field should be set to ensure the volume's group ownership is 3000?

A.supplementalGroups: [3000]
B.fsGroup: 1000
C.fsGroup: 3000
D.runAsGroup: 3000
AnswerC

fsGroup: 3000 is the correct mechanism because it simultaneously changes the group ownership of the volume's root directory to GID 3000 and adds that GID to the container's supplementary groups. With the process running as UID 1000, the group permissions on the volume now allow access via group 3000. This is exactly the Kubernetes-defined meaning of fsGroup: it alters the volume's ownership metadata to match the group that should be permitted.

Why this answer

The `fsGroup` field in the Pod's `securityContext` specifies the group ID (GID) that Kubernetes should assign to any volume mounted into the Pod. When `fsGroup: 3000` is set, Kubernetes recursively changes the ownership of the volume's files and directories to group ID 3000, and any new files created by the container process will inherit that group ownership. This ensures the container process, which runs with `runAsGroup: 3000`, can write to the volume without permission errors.

Exam trap

The trap here is that candidates often confuse `fsGroup` with `supplementalGroups` or `runAsGroup`, mistakenly thinking that setting the container's group ID alone will automatically adjust the volume's permissions, when in fact `fsGroup` is the only field that modifies the volume's ownership.

How to eliminate wrong answers

Option A is wrong because `supplementalGroups` adds additional group IDs to the container process's supplementary group list, but it does not change the ownership of the mounted volume; the volume's group ownership remains unchanged unless `fsGroup` is set. Option B is wrong because `fsGroup: 1000` would set the volume's group ownership to GID 1000, not 3000, which would not match the container's `runAsGroup: 3000` and could cause write permission issues. Option D is wrong because `runAsGroup: 3000` already sets the primary group ID for the container process, but it does not affect the ownership of the mounted volume; the volume's group ownership must be explicitly set via `fsGroup`.

Practice this question →
195
MCQmedium

A namespace 'test' has a LimitRange that sets default memory request to 256Mi and default memory limit to 512Mi. A pod in that namespace does not specify any resources. What memory request and limit will the pod get?

A.request: 0, limit: 0 (none)
B.request: 256Mi, limit: 512Mi
C.request: 512Mi, limit: 256Mi
D.request: 256Mi, limit: 256Mi
AnswerB

This is the correct outcome because the LimitRange specifies a defaultRequest of 256Mi and a defaultLimit of 512Mi. During pod admission, the controller automatically assigns these values to any container that omits memory resources. This ensures the pod has a guaranteed request of 256Mi and a hard limit of 512Mi, matching the namespace's configured defaults.

Why this answer

When a LimitRange exists in a namespace with default memory request and limit values, any pod that does not specify resource requests or limits will automatically have those defaults injected by the admission controller. This ensures the pod is subject to resource constraints even without explicit specification.

Exam trap

The trap here is that candidates might assume no resources means zero, or confuse the default request and limit values, but the LimitRange admission controller automatically injects the specified defaults.

How to eliminate wrong answers

Option A is wrong because a LimitRange with defaults means the pod will receive those defaults, not zero values. Option C is wrong because it swaps the request and limit values, which would violate the typical constraint that limit >= request. Option D is wrong because it sets both request and limit to 256Mi, ignoring the default limit of 512Mi specified in the LimitRange.

Practice this question →
196
MCQhard

An administrator creates a Role and RoleBinding in the 'dev' namespace to allow a ServiceAccount 'sa-dev' to list Pods. Which YAML snippet correctly defines the Role?

A.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: {name: pod-reader, namespace: dev} rules: - apiGroups: [""] resources: ["pods"] verbs: ["create"]
B.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: {name: pod-reader, namespace: dev} rules: - apiGroups: ["v1"] resources: ["pods"] verbs: ["list"]
C.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: {name: pod-reader, namespace: dev} rules: - apiGroups: ["apps/v1"] resources: ["pods"] verbs: ["get"]
D.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: {name: pod-reader, namespace: dev} rules: - apiGroups: [""] resources: ["pods"] verbs: ["list"]
AnswerD

This Role correctly uses apiGroups: [""] to target the core API group, resources: ["pods"] to specify the pod resource, and verbs: ["list"] to permit listing pods in the dev namespace. Because it is a Role (not a ClusterRole) bound to the dev namespace, it grants permissions only within that namespace, which matches the requirement.

Why this answer

It uses the empty string `""` for `apiGroups`, which represents the core API group where Pods reside, and specifies the `list` verb to allow listing Pods. This matches the requirement to allow the ServiceAccount 'sa-dev' to list Pods in the 'dev' namespace.

Exam trap

The trap here is that candidates often confuse the core API group with the version string `v1` or mistakenly use `apps/v1` for Pods, and they may also confuse `list` with `get` or `create`, leading to incorrect verb selection.

How to eliminate wrong answers

Option A is wrong because it uses the verb `create` instead of `list`, which would allow creating Pods but not listing them. Option B is wrong because it incorrectly specifies `apiGroups: ["v1"]`; the core API group is represented by an empty string `""`, not `"v1"`. Option C is wrong because it uses `apiGroups: ["apps/v1"]`, which is for resources like Deployments, not Pods (Pods are in the core API group), and the verb `get` does not allow listing.

Practice this question →
197
MCQmedium

A Pod is running in a namespace with a ResourceQuota that sets 'limits.memory: 2Gi'. The pod's container spec has 'resources.limits.memory: 1Gi' and 'resources.requests.memory: 512Mi'. The pod is in 'Running' state but consumes 1.5Gi of memory. What happens?

A.The pod will be evicted by the kubelet due to namespace quota violation
B.The container will continue running because the namespace quota allows up to 2Gi
C.The container will be OOMKilled because it exceeds its own memory limit of 1Gi
D.The pod will be throttled by the kernel to stay within 1Gi
AnswerC

When a container has a memory limit of 1Gi, the kubelet configures a cgroup memory limit for that container. If the container's memory usage exceeds this limit, the kernel's OOM killer terminates the container's processes, and Kubernetes reports the reason as OOMKilled. This is a hard enforcement mechanism independent of any namespace quota or available node memory.

Why this answer

The container has a hard memory limit of 1Gi set in its resources.limits.memory. When the container's memory usage exceeds this limit (1.5Gi > 1Gi), the Linux kernel's OOM killer terminates the container process. The namespace ResourceQuota of 2Gi is not violated because the pod's limit (1Gi) is within the quota, so the kubelet does not evict the pod.

Exam trap

The trap here is that candidates confuse namespace-level ResourceQuota enforcement with container-level memory limit enforcement, assuming the quota's higher value allows the container to exceed its own limit.

How to eliminate wrong answers

Option A is wrong because the namespace quota sets a limit of 2Gi, and the pod's configured limit of 1Gi is within that quota; the kubelet only evicts pods when the total usage exceeds the quota, not when a single container exceeds its own limit. Option B is wrong because the container cannot continue running when it exceeds its own hard memory limit of 1Gi; the kernel enforces the container's limit independently of the namespace quota. Option D is wrong because memory is not throttled like CPU; exceeding a memory limit triggers an OOM kill, not throttling.

Practice this question →
198
MCQeasy

A Secret of type kubernetes.io/tls requires two data keys. What are they?

A.ca.crt and tls.key
B.certificate and key
C.cert.crt and cert.key
D.tls.crt and tls.key
AnswerD

According to the Kubernetes documentation for TLS secrets, the type kubernetes.io/tls requires exactly two data keys: tls.crt, which contains the PEM-encoded public certificate (or certificate chain), and tls.key, which contains the PEM-encoded private key. These keys are the standard interface that ingress controllers, kubelet, and other components rely on to configure TLS termination. Creating a secret with these keys ensures it is immediately usable for securing applications.

Why this answer

Kubernetes requires that a Secret of type `kubernetes.io/tls` contain exactly two data keys: `tls.crt` for the TLS certificate and `tls.key` for the private key. This is mandated by the Kubernetes API specification for TLS secrets, which are used to secure ingress and other TLS-terminated endpoints.

Exam trap

The trap here is that candidates often confuse the required key names with common file extensions or generic terms like `certificate` and `key`, but Kubernetes enforces the exact keys `tls.crt` and `tls.key` for TLS secrets.

How to eliminate wrong answers

Option A is wrong because `ca.crt` is an optional key for a CA certificate, not a required key for a TLS secret; the required keys are `tls.crt` and `tls.key`. Option B is wrong because `certificate` and `key` are generic names that do not match the exact key names (`tls.crt` and `tls.key`) required by the Kubernetes API for TLS secrets. Option C is wrong because `cert.crt` and `cert.key` are not the standard key names; Kubernetes specifically expects `tls.crt` and `tls.key` as defined in the Secret type `kubernetes.io/tls`.

Practice this question →
199
Multi-Selectmedium

Which TWO of the following are valid ways to consume a Secret named 'db-secret' in a Pod? (Choose two.)

Select 2 answers
A.As environment variables using env with valueFrom.configMapKeyRef
B.As environment variables using envFrom with secretRef
C.As a command-line argument using $(DB_PASSWORD)
D.As files mounted via a volume with secret.secretName
E.As an imagePullSecrets entry
AnswersB, D

A container can consume a Secret in its entirety by using envFrom with a secretRef in the container's environment specification. Kubernetes enumerates every key in the referenced Secret and creates an environment variable for each, provided the key is a valid environment variable name. This is one of the two officially supported ways to inject Secret data into a running container.

Why this answer

`envFrom` with `secretRef` allows a Pod to consume all key-value pairs from a Secret named 'db-secret' as environment variables. This is a standard Kubernetes feature for injecting Secret data into containers without needing to specify each key individually.

Exam trap

CNCF often tests the distinction between `configMapKeyRef` and `secretKeyRef` — candidates mistakenly use `configMapKeyRef` for Secrets because both are key-value stores, but Secrets require `secretKeyRef` for individual key injection.

Practice this question →
200
MCQmedium

You need to create a Secret of type kubernetes.io/tls for use with an Ingress. Which kubectl command should you use?

A.kubectl create secret tls my-tls --cert=cert.pem --key=key.pem
B.kubectl create secret docker-registry my-tls --docker-username=user --docker-password=pass
C.kubectl create secret generic my-tls --from-file=cert.pem --from-file=key.pem
D.kubectl create secret tls my-tls --from-file=tls.crt --from-file=tls.key
AnswerA

This command correctly creates a Secret with type kubernetes.io/tls by using the dedicated --cert and --key flags. kubectl reads the PEM-encoded certificate and private key, stores them under the canonical data keys tls.crt and tls.key, and sets the type so Ingress resources can consume it for TLS termination. No other command form produces a TLS-typed Secret with both required data fields.

Why this answer

`kubectl create secret tls` is the dedicated command for creating a TLS secret, which automatically stores the certificate and key under the expected keys `tls.crt` and `tls.key` respectively. This secret type (`kubernetes.io/tls`) is required by Ingress controllers to serve HTTPS traffic, and the command directly accepts `--cert` and `--key` flags for the PEM-encoded files.

Exam trap

The trap here is that candidates confuse the `--from-file` pattern (used with `generic` secrets) with the `tls` subcommand, or mistakenly think any secret containing a cert and key will work for Ingress, when in fact the secret must be of type `kubernetes.io/tls` with the exact keys `tls.crt` and `tls.key`.

How to eliminate wrong answers

Option B is wrong because `kubectl create secret docker-registry` creates a secret of type `kubernetes.io/dockerconfigjson` for container registry authentication, not for TLS certificates. Option C is wrong because `kubectl create secret generic` creates a generic Opaque secret, which stores files as arbitrary keys (e.g., `cert.pem` and `key.pem`) but does not set the required `tls.crt` and `tls.key` keys, and the type will not be `kubernetes.io/tls`, so Ingress will not recognize it. Option D is wrong because `kubectl create secret tls` does not accept `--from-file` flags; it requires the `--cert` and `--key` flags to correctly populate the secret's data fields.

Practice this question →
201
MCQhard

You have a pod that needs to mount a Secret as a volume. The Secret has keys 'username' and 'password'. How should the volumes and volumeMounts be configured to mount the secret at /etc/secret with each key as a file?

A.volumes: - name: secret-vol hostPath: path: /etc/secret containers: - volumeMounts: - name: secret-vol mountPath: /etc/secret
B.volumes: - name: secret-vol configMap: name: my-secret containers: - volumeMounts: - name: secret-vol mountPath: /etc/secret
C.volumes: - name: secret-vol emptyDir: {} containers: - volumeMounts: - name: secret-vol mountPath: /etc/secret
D.volumes: - name: secret-vol secret: secretName: my-secret containers: - volumeMounts: - name: secret-vol mountPath: /etc/secret
AnswerD

This is the idiomatic Kubernetes approach: the secret volume source references a Secret object by name, and kubelet populates the volume with files named after the Secret's keys and containing their values. When mounted at /etc/secret, each key becomes a file in that directory, and the container can read them securely. The volume is backed by tmpfs (in-memory) to avoid writing sensitive data to disk, and the Secret's data is automatically injected without manual steps.

Why this answer

It uses the `secret` volume type with `secretName: my-secret`, which mounts the specified Kubernetes Secret as a volume. When mounted at `/etc/secret`, each key in the Secret (e.g., 'username' and 'password') becomes a file in that directory, with the file name matching the key and the file content being the decoded value of the key. This is the standard method for exposing Secret data as files in a pod.

Exam trap

The trap here is that candidates may confuse the `secret` volume type with `configMap` (Option B) or incorrectly assume that `hostPath` (Option A) can be used to reference a Secret, when in fact only the `secret` volume type with the correct `secretName` field will mount the Secret's keys as files.

How to eliminate wrong answers

Option A is wrong because `hostPath` mounts a directory from the host node's filesystem, not a Kubernetes Secret; it does not provide the Secret's key-value pairs as files. Option B is wrong because `configMap` is used for ConfigMaps, not Secrets; while the syntax is similar, Secrets require the `secret` volume type to properly handle base64-encoded data and access control. Option C is wrong because `emptyDir` creates an empty temporary directory that is shared between containers; it does not inject any Secret data into the pod.

Practice this question →
← PreviousPage 3 of 3 · 201 questions total

Ready to test yourself?

Try a timed practice session using only Application Environment, Configuration and Security questions.

Start 20-question session