CCNA Application Environment, Configuration and Security Questions — Page 3 of 4

151

MCQhard

You need to create a Pod that mounts a Secret named 'mysecret' as an environment variable 'SECRET_DATA'. The secret has a key 'password'. Which YAML snippet correctly achieves this?

A.env: - name: SECRET_DATA valueFrom: configMapKeyRef: name: mysecret key: password

B.env: - name: SECRET_DATA valueFrom: secretKeyRef: name: mysecret key: password

C.env: - name: SECRET_DATA valueFrom: secretKeyRef: name: password key: mysecret

D.volumeMounts: - name: secret-volume mountPath: /etc/secret volumes: - name: secret-volume secret: secretName: mysecret items: - key: password path: secret.txt

AnswerB

Correct. secretKeyRef uses name for the secret and key for the key within the secret.

Why this answer

Option B is correct because it uses the `secretKeyRef` field under `valueFrom` to reference a specific key from a Secret named 'mysecret' and inject its value into the environment variable `SECRET_DATA`. This is the standard Kubernetes syntax for exposing a Secret's key-value pair as an environment variable.

Exam trap

The trap here is that candidates often confuse `configMapKeyRef` with `secretKeyRef` or swap the `name` and `key` fields, leading them to pick options that either reference the wrong resource type or misorder the required fields.

How to eliminate wrong answers

Option A is wrong because it uses `configMapKeyRef` instead of `secretKeyRef`; ConfigMaps are for non-sensitive data, while Secrets require `secretKeyRef`. Option C is wrong because it swaps the `name` and `key` fields: `name` should be the Secret's name ('mysecret'), and `key` should be the key within that Secret ('password'). Option D is wrong because it mounts the Secret as a file via a volume, not as an environment variable, which does not meet the requirement to expose the value as `SECRET_DATA`.

Practice this question →

152

Multi-Selecteasy

Which TWO of the following are valid types for a Kubernetes Secret? (Choose two.)

Select 2 answers

A.kubernetes.io/tls

B.kubernetes.io/basic-auth

C.kubernetes.io/configmap

D.Opaque

E.kubernetes.io/ssh-auth

AnswersA, D

Correct.

Why this answer

Option A is correct because `kubernetes.io/tls` is a built-in Secret type used to store TLS certificates and private keys, typically for ingress TLS termination. This type expects the data keys `tls.crt` and `tls.key` and is automatically validated by Kubernetes to ensure the certificate and key are properly paired.

Exam trap

CNCF often tests the distinction between valid Secret types and common but incorrect type names, such as confusing `kubernetes.io/basic-auth` (which is valid) with `kubernetes.io/configmap` (which is not a Secret type), or assuming that only `Opaque` and `kubernetes.io/tls` are valid while forgetting that other service-specific types like `kubernetes.io/dockercfg` also exist.

Practice this question →

153

Multi-Selectmedium

Which TWO actions can help prevent a container from being compromised if an attacker gains access? (Select 2)

Select 2 answers

A.Setting securityContext.readOnlyRootFilesystem: true

B.Setting automountServiceAccountToken: true

C.Setting securityContext.capabilities.drop: ["ALL"]

D.Setting securityContext.allowPrivilegeEscalation: true

E.Setting securityContext.runAsUser: 0

AnswersA, C

Prevents writes to container filesystem.

Why this answer

Setting `securityContext.readOnlyRootFilesystem: true` makes the container's root filesystem read-only, preventing an attacker who gains access from modifying system binaries, libraries, or configuration files. This is a key defense-in-depth measure that limits the impact of a compromise by restricting write access to only explicitly mounted volumes.

Exam trap

CNCF often tests the misconception that running as a non-root user (e.g., `runAsUser: 1000`) is sufficient, but the trap here is that `runAsUser: 0` explicitly sets root, which is a common mistake when candidates confuse 'default' with 'secure'—always drop all capabilities and make the filesystem read-only for defense in depth.

Practice this question →

154

MCQhard

You create a Pod with a securityContext set to 'runAsNonRoot: true' and a container image that runs as root (user 0). What will happen when you create the Pod?

A.The Pod will run but with root user, ignoring the setting

B.The Pod will not be created and you will see an error about securityContext violation

C.The Pod will be created but the container will be in a CrashLoopBackOff

D.The Pod will run with root but the container will be killed by a security policy

AnswerB

The kubelet will reject the Pod because runAsNonRoot is true but the container image runs as root.

Why this answer

When a Pod has `runAsNonRoot: true` in its security context and the container image runs as root (UID 0), the Pod will not be created. Kubernetes validates this at admission time (via the PodSecurity admission controller or a validating webhook) and rejects the Pod with an error indicating a security context violation. This is because `runAsNonRoot: true` enforces that the container must not run as UID 0, and the image's default user is root, so the Pod fails creation immediately.

Exam trap

CNCF often tests the distinction between Pod creation failure (admission-time rejection) and runtime failures like CrashLoopBackOff, leading candidates to incorrectly choose a runtime error when the Pod is never scheduled.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot: true` is not ignored; it is a mandatory security constraint that causes the Pod to be rejected, not silently bypassed. Option C is wrong because the Pod is never created, so it cannot enter a CrashLoopBackOff state; CrashLoopBackOff occurs only after a container starts and then repeatedly fails. Option D is wrong because the container is never started, so there is no running process to be killed by a security policy; the rejection happens before any container execution.

Practice this question →

155

Multi-Selecthard

Which THREE of the following are characteristics of Pod Security Admission (PSA) standards? (Select three.)

Select 3 answers

A.PSA can be configured to warn or audit violations without blocking

B.There are three predefined security levels: privileged, baseline, restricted

C.PSA requires Open Policy Agent (OPA) Gatekeeper to function

D.A namespace can be labeled to enforce a security level for all pods in that namespace

E.PSA is a CustomResourceDefinition (CRD) that must be installed separately

AnswersA, B, D

PSA supports modes: enforce, audit, and warn.

Why this answer

Option A is correct because Pod Security Admission (PSA) supports three modes: enforce (blocks violations), audit (logs violations in audit logs), and warn (returns a warning to the user). This allows administrators to test or monitor PSA policies without immediately blocking pod creation, which is critical for gradual adoption.

Exam trap

The trap here is that candidates confuse PSA with third-party tools like OPA Gatekeeper or think it requires a CRD, when in fact PSA is a built-in, label-driven admission controller that works out of the box in Kubernetes v1.23+.

Practice this question →

156

MCQmedium

A Role named 'pod-reader' in namespace 'ns1' grants get, list, and watch on pods. Which RoleBinding correctly binds this role to a ServiceAccount 'sa1' in the same namespace?

A.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: ns1

B.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: User name: sa1

C.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: ClusterRole, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: ns1

D.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: default

AnswerA

Correct. RoleBinding references the Role and ServiceAccount in the same namespace.

Why this answer

Option A is correct because a RoleBinding in the same namespace as the Role and ServiceAccount must specify the Role's kind as 'Role' (not ClusterRole) and include the ServiceAccount's namespace in the subjects list. The roleRef references the 'pod-reader' Role with the correct apiGroup and kind, and the subject specifies the ServiceAccount 'sa1' in namespace 'ns1', which matches the Role's namespace, allowing the binding to grant the permissions.

Exam trap

The trap here is that candidates often forget to include the ServiceAccount's namespace in the subjects list or mistakenly use 'kind: User' for a ServiceAccount, leading to a binding that either fails or applies to the wrong entity.

How to eliminate wrong answers

Option B is wrong because it uses 'kind: User' instead of 'kind: ServiceAccount', and a ServiceAccount cannot be bound via a User subject; the subject must match the actual entity type. Option C is wrong because it uses 'kind: ClusterRole' in the roleRef, but the question specifies a Role (namespaced), not a ClusterRole; a RoleBinding can only reference a Role in the same namespace or a ClusterRole (which would then be scoped to the namespace), but here the role is a Role, so the kind must be 'Role'. Option D is wrong because it specifies 'namespace: default' in the subject, but the ServiceAccount 'sa1' is in namespace 'ns1', so the subject's namespace must match the ServiceAccount's actual namespace for the binding to work.

Practice this question →

157

Multi-Selectmedium

Which TWO commands can be used to create a Secret named 'db-creds' with keys 'username' and 'password'? (Select TWO.)

Select 2 answers

A.kubectl create secret generic db-creds --from-literal=username=admin --from-literal=password=secret123

B.kubectl create secret generic db-creds --from-file=username=admin --from-file=password=secret123

C.kubectl create secret opaque db-creds --from-literal=username=admin

D.echo -e 'username: admin\npassword: secret123' | kubectl apply -f -

E.kubectl create secret tls db-creds --cert=cert.pem --key=key.pem

AnswersA, D

Correct. This creates a generic secret with the specified literals.

Why this answer

Option A is correct because `kubectl create secret generic` with `--from-literal` is the standard way to create a generic (Opaque) Secret from key-value pairs directly in the command line. Each `--from-literal` flag specifies a key=value pair, and the command creates a Secret named 'db-creds' with keys 'username' and 'password'.

Exam trap

CNCF often tests the distinction between `--from-literal` and `--from-file`, and the fact that `kubectl create secret generic` is the only valid subcommand for Opaque Secrets, not `opaque` or `tls`.

Practice this question →

158

Multi-Selecthard

An administrator wants to implement Pod Security Admission (PSA) to enforce the 'restricted' policy for pods in the 'secure' namespace, but allow certain pods to use privileged containers by applying an exemption label. Which three steps are required? (Choose three.)

Select 3 answers

A.Use 'pod-security.kubernetes.io/audit=restricted' to log violations without enforcement.

B.Enable the PodSecurity feature gate on the API server and kubelet.

C.Create a ServiceAccount for exempted pods and label it with 'pod-security.kubernetes.io/enforce=privileged'.

D.Install a custom container runtime that supports privilege escalation.

E.Set the namespace label 'pod-security.kubernetes.io/enforce=restricted' on the 'secure' namespace.

AnswersB, C, E

PSA is enabled by default in v1.23+, but for older clusters you may need to enable it.

Why this answer

Option B is correct because Pod Security Admission (PSA) is a built-in admission controller that requires the PodSecurity feature gate to be enabled on the API server (and, for enforcement, the kubelet must also support it) to activate the admission webhook. Without this feature gate, the PSA labels on namespaces are ignored, and the restricted policy cannot be enforced.

Exam trap

The trap here is that candidates often confuse 'audit' mode (which only logs) with 'enforce' mode (which blocks violations), and may incorrectly think that a custom runtime is needed for privilege escalation, when PSA handles this via security context validation at the admission level.

Practice this question →

159

MCQmedium

A cluster administrator wants to prevent all pods in a namespace from running with privileged escalation. Which Pod Security Admission standard enforces this?

A.baseline

B.restricted

C.privileged

D.high

AnswerB

The restricted profile disallows privilege escalation and enforces many security constraints.

Why this answer

The 'restricted' Pod Security Admission (PSA) standard enforces the most stringent security controls, including preventing privileged escalation by setting `securityContext.AllowPrivilegeEscalation` to `false` and requiring containers to run as non-root. This directly addresses the cluster administrator's goal of blocking privilege escalation in all pods within a namespace.

Exam trap

CNCF often tests the distinction between 'baseline' and 'restricted' standards, where candidates mistakenly choose 'baseline' because it blocks some privilege escalation but fails to recognize that 'restricted' is the only standard that explicitly and comprehensively prohibits `AllowPrivilegeEscalation`.

How to eliminate wrong answers

Option A is wrong because the 'baseline' standard only prevents known privilege escalation attacks (e.g., via `CAP_SYS_ADMIN`) but does not explicitly require `AllowPrivilegeEscalation` to be `false`; it allows some flexibility for legacy workloads. Option C is wrong because the 'privileged' standard is the most permissive, allowing unrestricted access including privilege escalation, which is the opposite of what the question asks. Option D is wrong because 'high' is not a valid Pod Security Admission standard; the three defined standards are 'privileged', 'baseline', and 'restricted'.

Practice this question →

160

MCQmedium

You create a ResourceQuota in a namespace that sets requests.cpu: '1' and limits.cpu: '2'. A pod spec has no resource limits or requests. What happens when you try to create this pod?

A.The pod is created without limits, but the quota is enforced at runtime

B.The pod creation is denied because the spec does not specify resource limits or requests

C.The pod is created and the quota is ignored

D.The pod is created with default limits from the LimitRange

AnswerB

ResourceQuota requires that all pods in the namespace have resource limits/requests when quota is set.

Why this answer

When a ResourceQuota is defined with requests.cpu and limits.cpu, Kubernetes requires that every pod in that namespace have explicit resource requests and limits that match the quota constraints. If a pod spec omits these fields, the API server denies the pod creation because it cannot determine whether the pod complies with the quota. This is enforced at admission time, not at runtime.

Exam trap

The trap here is that candidates assume a LimitRange will automatically apply default resource values, but without a LimitRange, the pod creation is denied outright due to the missing fields required by the ResourceQuota.

How to eliminate wrong answers

Option A is wrong because the quota is enforced at admission time, not at runtime; the pod is never created if it lacks required resource specifications. Option C is wrong because the quota is never ignored; it is a hard constraint that the API server enforces during admission. Option D is wrong because a LimitRange can provide default values, but the question does not mention a LimitRange existing in the namespace; without one, the pod creation is denied due to missing resource fields.

Practice this question →

161

MCQmedium

A pod in the 'staging' namespace is in a CrashLoopBackOff state. You run 'kubectl logs pod -n staging' and see: 'Error: container has been OOMKilled'. The pod YAML has resources: requests: memory: 256Mi, limits: memory: 256Mi. Which change should you make first?

A.Increase the memory limit to 512Mi.

B.Increase the CPU limit to 1.

C.Reduce the memory request to 128Mi.

D.Set memory request to 512Mi and memory limit to 256Mi.

AnswerA

Increasing the limit gives the container more memory before OOM.

Why this answer

The pod is in CrashLoopBackOff due to OOMKill, meaning the container exceeded its memory limit and was terminated. Since the current memory limit is 256Mi and the container needs more, increasing the limit to 512Mi directly addresses the out-of-memory condition. This is the correct first step because it provides the container with the additional memory it requires to run without being killed.

Exam trap

CNCF often tests the distinction between requests and limits, and the trap here is that candidates might confuse reducing the request (option C) as a solution, when in fact the OOMKill is caused by hitting the limit, not the request.

How to eliminate wrong answers

Option B is wrong because the issue is memory exhaustion (OOMKill), not CPU; increasing the CPU limit does not resolve the out-of-memory condition. Option C is wrong because reducing the memory request to 128Mi would lower the guaranteed memory, potentially worsening the OOM situation and increasing the risk of the container being killed. Option D is wrong because setting the memory request higher than the limit (512Mi request vs 256Mi limit) is invalid in Kubernetes; the request must be less than or equal to the limit, and this configuration would be rejected by the API server.

Practice this question →

162

MCQmedium

Which command creates a TLS secret named 'tls-secret' using certificate file 'tls.crt' and key file 'tls.key'?

A.kubectl create secret docker-registry tls-secret --docker-server=...

B.kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key

C.kubectl create secret generic tls-secret --from-file=tls.crt --from-file=tls.key

D.kubectl create secret generic tls-secret --from-literal=tls.crt=...

AnswerB

Correct syntax for creating a TLS secret.

Why this answer

Option B is correct because the `kubectl create secret tls` command is specifically designed to create a TLS secret from a certificate and key pair. The `--cert` and `--key` flags directly reference the PEM-encoded certificate file (`tls.crt`) and private key file (`tls.key`), which Kubernetes stores as `tls.crt` and `tls.key` data entries in the Secret object.

Exam trap

The trap here is that candidates often choose Option C because they think `--from-file` can create a TLS secret, but they overlook that the secret type must be `kubernetes.io/tls` and the data keys must be exactly `tls.crt` and `tls.key` — a generic secret with arbitrary keys will not work for TLS termination.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret docker-registry` creates a Docker registry authentication secret, not a TLS secret; it uses `--docker-server`, `--docker-username`, etc. Option C is wrong because `kubectl create secret generic` with `--from-file` stores the entire file contents under arbitrary keys (e.g., the filename), not under the standard `tls.crt` and `tls.key` keys required for TLS secrets; the resulting secret would not be recognized as a TLS secret by ingress controllers or other components. Option D is wrong because `--from-literal` expects a literal key=value pair, not a file path; it would store the string 'tls.crt=...' as a literal, not the certificate content.

Practice this question →

163

Multi-Selectmedium

Which TWO of the following are valid fields in a container's SecurityContext to restrict privilege escalation? (Select two.)

Select 2 answers

A.allowPrivilegeEscalation

B.readOnlyRootFilesystem

C.runAsNonRoot

D.privileged

E.capabilities

AnswersA, E

Setting this to false prevents privilege escalation.

Why this answer

A is correct because `allowPrivilegeEscalation` directly controls whether a process can gain more privileges than its parent, such as via setuid binaries or file capabilities. Setting it to `false` prevents privilege escalation, which is a core security requirement for restricting container breakout.

Exam trap

CNCF often tests the distinction between fields that *prevent* privilege escalation versus fields that enforce other security constraints like filesystem immutability or user identity, leading candidates to confuse `readOnlyRootFilesystem` or `runAsNonRoot` with escalation control.

Practice this question →

164

MCQeasy

You create a ConfigMap named 'app-config' with the command 'kubectl create configmap app-config --from-literal=key1=value1'. Which of the following correctly mounts this ConfigMap as environment variables in a pod?

A.env: - name: key1 valueFrom: configMapKeyRef: name: app-config key: key1

B.volumes: - name: config-volume configMap: name: app-config volumeMounts: - name: config-volume mountPath: /etc/config

C.env: - name: key1 valueFrom: configMapRef: name: app-config

D.envFrom: - configMapRef: name: app-config

AnswerD

envFrom with configMapRef injects all key-value pairs from the ConfigMap as environment variables.

Why this answer

Option D is correct because `envFrom` with `configMapRef` is the Kubernetes mechanism to expose all key-value pairs from a ConfigMap as environment variables in a pod. This directly mounts the ConfigMap created with `--from-literal=key1=value1` so that `key1` becomes an environment variable with value `value1`.

Exam trap

The trap here is that candidates confuse `envFrom` with `env` and `configMapRef` with `configMapKeyRef`, or they incorrectly think volume mounts are equivalent to environment variable injection.

How to eliminate wrong answers

Option A is wrong because while the syntax is valid for a single key reference, it requires explicitly listing each key, which is not the 'correctly mounts this ConfigMap' approach when the question implies using the entire ConfigMap; it is a valid but incomplete method for the scenario. Option B is wrong because it describes mounting the ConfigMap as files in a volume at `/etc/config`, not as environment variables. Option C is wrong because `configMapRef` is not a valid field under `env`; the correct field is `configMapKeyRef`.

Practice this question →

165

MCQmedium

A Deployment is configured with 'resources.requests.memory: 256Mi' and 'resources.limits.memory: 512Mi'. The node runs out of memory. Which pods will be the first to be evicted?

A.The node will not evict pods if limits are set

B.This pod will be evicted first because it has a memory limit

C.BestEffort pods first, then this Burstable pod, then Guaranteed pods last

D.All pods are evicted simultaneously

AnswerC

QoS classes determine eviction order: BestEffort first, then Burstable, then Guaranteed.

Why this answer

C is correct because Kubernetes evicts pods based on their Quality of Service (QoS) class when a node runs out of memory. BestEffort pods (no requests/limits) are evicted first, followed by Burstable pods (requests < limits, as in this case), and Guaranteed pods (requests == limits) are evicted last. This ensures that pods with stricter resource guarantees are more protected during memory pressure.

Exam trap

CNCF often tests the misconception that setting a memory limit alone protects a pod from eviction, but the key factor is the QoS class derived from the relationship between requests and limits, not just the presence of limits.

How to eliminate wrong answers

Option A is wrong because the node will evict pods when memory is exhausted, regardless of whether limits are set; the kubelet uses the QoS class to determine eviction order. Option B is wrong because this Burstable pod will not be evicted first; BestEffort pods (with no resource specifications) are evicted before any Burstable pod. Option D is wrong because eviction is not simultaneous; pods are evicted in a specific order based on their QoS class, starting with BestEffort, then Burstable, and finally Guaranteed.

Practice this question →

166

MCQhard

Which of the following is a valid YAML snippet for a container that sets the seccomp profile to 'RuntimeDefault' in a PodSecurityContext?

A.securityContext: seccompProfile: type: RuntimeDefault

B.securityContext: seccompProfile: profile: RuntimeDefault

C.securityContext: seccomp: RuntimeDefault

D.securityContext: seccomp: type: RuntimeDefault

AnswerA

Correct. This sets the seccomp profile to RuntimeDefault.

Why this answer

Option A is correct because in a PodSecurityContext, the seccomp profile is configured under the `seccompProfile` field with a `type` key set to `RuntimeDefault`. This tells the container runtime (e.g., containerd) to use the default seccomp profile provided by the runtime, which blocks a set of syscalls that are not typically needed by containers.

Exam trap

The trap here is that candidates confuse the `type` key (which specifies the profile type, e.g., RuntimeDefault, Localhost, Unconfined) with a `profile` key, or they flatten the YAML structure by omitting the `seccompProfile` nesting, leading to invalid configuration.

How to eliminate wrong answers

Option B is wrong because it uses `profile: RuntimeDefault` instead of `type: RuntimeDefault`; the correct key under `seccompProfile` is `type`, not `profile`. Option C is wrong because it uses `seccomp: RuntimeDefault` as a flat key-value pair, but the seccomp configuration must be nested under `seccompProfile` with a `type` field. Option D is wrong because it uses `seccomp: type: RuntimeDefault` as a flat key-value pair, which is invalid YAML structure; the correct nesting requires `seccompProfile` as an intermediate key.

Practice this question →

167

MCQmedium

A pod has 'automountServiceAccountToken: false' in its spec. What is the effect?

A.The pod uses the default service account token from the namespace

B.The service account token is mounted but not updated

C.The pod cannot communicate with the Kubernetes API

D.The service account token is not mounted into the pod

AnswerD

When set to false, the token is not automatically mounted, reducing the attack surface.

Why this answer

Setting `automountServiceAccountToken: false` in a Pod spec explicitly prevents the automatic mounting of the service account token into the Pod's containers. By default, Kubernetes mounts a token at `/var/run/secrets/kubernetes.io/serviceaccount/token` for API authentication; disabling it means the token is not present in the container filesystem, so the Pod cannot authenticate to the Kubernetes API using that default mechanism.

Exam trap

The trap here is that candidates often confuse `automountServiceAccountToken: false` with disabling API access entirely, but it only disables the automatic token mount—the pod can still use other authentication methods to reach the API.

How to eliminate wrong answers

Option A is wrong because `automountServiceAccountToken: false` does not cause the pod to use the default service account token; it prevents any token from being mounted. Option B is wrong because the token is not mounted at all, so there is no token to be updated or not updated. Option C is wrong because while the pod cannot use the default mounted token for API communication, it can still communicate with the Kubernetes API if it uses an alternative authentication method (e.g., a custom token injected via a volume or a client certificate).

Practice this question →

168

MCQeasy

A developer needs to expose a database password to a Pod as an environment variable, securely. What should they do?

A.Hardcode the password in the Pod YAML

B.Store the password in a ConfigMap and use configMapKeyRef

C.Create a Secret and use secretKeyRef in the env definition

D.Use a ConfigMap with binaryData field

AnswerC

Secrets store sensitive data, and secretKeyRef injects them as environment variables.

Why this answer

Option C is correct because Kubernetes Secrets are the recommended mechanism for storing sensitive data like passwords. By referencing the Secret's key via `secretKeyRef` in the `env` definition of a Pod, the password is injected as an environment variable without being exposed in the Pod manifest or stored in plaintext. This approach ensures the data is base64-encoded at rest (and can be encrypted at rest with etcd encryption) and avoids the security risks of hardcoding or using ConfigMaps for secrets.

Exam trap

The trap here is that candidates confuse ConfigMaps with Secrets, thinking that `binaryData` or `configMapKeyRef` can securely store sensitive data, when in fact ConfigMaps lack encryption and access control mechanisms that Secrets provide.

How to eliminate wrong answers

Option A is wrong because hardcoding the password in the Pod YAML exposes the credential in plaintext in version control and manifests, violating security best practices. Option B is wrong because ConfigMaps are designed for non-sensitive configuration data; storing a password in a ConfigMap leaves it unencrypted and accessible to anyone with cluster access, and `configMapKeyRef` does not provide the security guarantees needed for secrets. Option D is wrong because while `binaryData` in a ConfigMap can store binary data, it still does not provide encryption or access control; ConfigMaps are not intended for secrets, and using `binaryData` does not make the data secure.

Practice this question →

169

Drag & Dropmedium

Arrange the steps to create a ConfigMap from a file and mount it as a volume in a Pod.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

Create ConfigMap first, then define Pod with volume and volumeMount, apply, and verify.

Practice this question →

170

MCQmedium

You are designing a Pod that runs a legacy application requiring a specific configuration file mounted at /etc/config/app.conf. The configuration is stored in a Kubernetes ConfigMap named 'app-config' with key 'config.yaml'. Which approach ensures the configuration is mounted correctly and the container automatically receives updates when the ConfigMap changes?

A.Create a ConfigMap volume mount at /etc/config, mounting the entire ConfigMap, and ensure the application reads /etc/config/config.yaml.

B.Create a hostPath volume at /etc/config and copy the ConfigMap content to the node.

C.Use the ConfigMap to set an environment variable CONFIG and have the application read it from the environment.

D.Create a ConfigMap volume mount at /etc/config/app.conf using subPath: config.yaml.

AnswerA

This mounts all keys as files; the app reads config.yaml. Changes to the ConfigMap are reflected automatically (with a delay).

Why this answer

Option A is correct because mounting the entire ConfigMap as a volume at /etc/config creates a symlink-based directory where each key becomes a file. When the ConfigMap is updated, kubelet automatically refreshes the symlink targets, so the container sees the new content without requiring a restart. This satisfies the requirement of mounting the configuration file at /etc/config/app.conf (the file will be /etc/config/config.yaml) and receiving live updates.

Exam trap

The trap here is that candidates often choose subPath (Option D) because it allows mounting a specific key to a specific file path, but they forget that subPath disables automatic ConfigMap updates, which is a critical requirement in the question.

How to eliminate wrong answers

Option B is wrong because hostPath volumes bypass Kubernetes' ConfigMap update mechanism; you would have to manually copy the ConfigMap content to each node, and the container would not automatically receive updates when the ConfigMap changes. Option C is wrong because environment variables are set at container start and are not updated when the ConfigMap changes; the application would need to be restarted to pick up new values. Option D is wrong because using subPath breaks the automatic update mechanism; when a subPath is used, the file is a direct mount of the ConfigMap data at creation time and kubelet does not update it when the ConfigMap changes.

Practice this question →

171

Multi-Selecthard

Which THREE statements about ResourceQuota are correct? (Select 3)

Select 3 answers

A.ResourceQuota can specify both requests and limits for compute resources

B.ResourceQuota can limit the maximum CPU limit for a single pod

C.ResourceQuota can limit the total number of ConfigMaps in a namespace

D.ResourceQuota applies to all pods in a namespace

E.ResourceQuota applies across all namespaces

AnswersA, C, D

Yes, you can set requests.cpu, limits.cpu, etc.

Why this answer

Option A is correct because a ResourceQuota can specify both `requests` and `limits` for compute resources such as CPU and memory. This allows the quota to enforce constraints on the minimum requested resources and the maximum allowed usage across all pods in a namespace, ensuring fair resource distribution and preventing resource exhaustion.

Exam trap

The trap here is that candidates often confuse ResourceQuota's aggregate namespace-level enforcement with per-pod limits, which are actually handled by LimitRange, not ResourceQuota.

Practice this question →

172

MCQmedium

A user wants to create a Kubernetes Secret for storing Docker registry credentials (username and password). Which type of Secret should they use?

A.kubernetes.io/tls

B.Opaque

C.kubernetes.io/dockerconfigjson

D.kubernetes.io/basic-auth

AnswerC

This type stores a .dockerconfigjson file for Docker registry authentication.

Why this answer

Option C is correct because `kubernetes.io/dockerconfigjson` is the dedicated Secret type for storing Docker registry credentials in the format expected by `docker login`. It automatically encodes the username and password into a `.dockerconfigjson` field, which is used by Kubernetes to pull images from private registries. This type is required when referencing a `imagePullSecret` in a Pod spec.

Exam trap

The trap here is that candidates often choose `Opaque` (Option B) because they think any secret can be used for Docker credentials, but the CKAD exam expects you to know that only `kubernetes.io/dockerconfigjson` provides the correct format and automatic integration with image pull secrets.

How to eliminate wrong answers

Option A is wrong because `kubernetes.io/tls` is used for TLS certificates and private keys, not for Docker registry credentials. Option B is wrong because `Opaque` is a generic secret type for arbitrary key-value pairs, but it does not provide the correct structure or automatic handling required by the container runtime for registry authentication. Option D is wrong because `kubernetes.io/basic-auth` is intended for HTTP basic authentication credentials (username/password for web services), not for Docker registry login data.

Practice this question →

173

Multi-Selecteasy

Which TWO of the following are valid Kubernetes Secret types? (Select two.)

Select 2 answers

A.kubernetes.io/password

B.kubernetes.io/ssh-auth

C.kubernetes.io/configmap

D.kubernetes.io/tls

E.Opaque

AnswersD, E

Used to store TLS certificates.

Why this answer

Option D is correct because `kubernetes.io/tls` is a built-in Kubernetes Secret type used to store TLS certificates and private keys, typically for securing ingress or pod-to-pod communication. Option E is correct because `Opaque` is the default Secret type for arbitrary user-defined key-value pairs, such as passwords or API tokens.

Exam trap

CNCF often tests the distinction between valid Secret types and invalid or misnamed types, such as `kubernetes.io/password` or `kubernetes.io/configmap`, which candidates might confuse with real types like `Opaque` or `kubernetes.io/tls`.

Practice this question →

174

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

runAsGroup is optional. The requirements do not specify a group.

Why this answer

Option B (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 →

175

MCQmedium

A pod is in 'CrashLoopBackOff' state. 'kubectl logs pod' shows: 'Error: listen tcp :8080: bind: permission denied'. The container runs as user '1000'. Which securityContext setting is missing?

A.readOnlyRootFilesystem: false

B.runAsUser: 0 (root)

C.capabilities.add: ["NET_BIND_SERVICE"]

D.seccompProfile: type: RuntimeDefault

AnswerC

Although port 8080 is non-privileged, some container runtimes may require this capability for binding. It's a common fix for permission denied errors on ports.

Why this answer

The error 'listen tcp :8080: bind: permission denied' indicates the container process (running as user 1000) lacks the CAP_NET_BIND_SERVICE capability, which is required to bind to a privileged port (ports below 1024). Adding this capability via `capabilities.add: ["NET_BIND_SERVICE"]` grants the non-root user permission to bind to port 8080 without running as root.

Exam trap

The trap here is that candidates often assume the only fix for a 'permission denied' bind error is to run as root (runAsUser: 0), but the CKAD exam expects you to know that specific Linux capabilities can be added to non-root users to solve such issues without compromising security.

How to eliminate wrong answers

Option A is wrong because `readOnlyRootFilesystem: false` controls whether the container's filesystem is read-only, not network binding permissions; the error is about port binding, not filesystem access. Option B is wrong because running as root (runAsUser: 0) would bypass the permission issue but violates the principle of least privilege and is not the minimal fix required; the question asks for the missing setting, and the container already runs as user 1000. Option D is wrong because `seccompProfile: type: RuntimeDefault` applies a default seccomp profile that restricts system calls, but it does not grant the specific `CAP_NET_BIND_SERVICE` capability needed to bind to a privileged port.

Practice this question →

176

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

Correct. get secrets lists all secrets in the namespace.

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 →

177

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

This makes the container's root filesystem read-only.

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 →

178

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

The volume's group is set to fsGroup (2000), and the owner is the runAsUser (1000).

Why this answer

Option C is correct because 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 →

179

MCQmedium

A pod needs to mount a ConfigMap as a volume so that when the ConfigMap is updated, the pod automatically gets the updates. Which volume type should be used?

A.configMap volume

B.emptyDir volume

C.projected volume with configMap source

D.downwardAPI volume

AnswerA

configMap volumes use the kubelet to sync updates to the pod automatically.

Why this answer

A configMap volume type directly mounts a ConfigMap as a volume in a pod. When the ConfigMap is updated, the kubelet periodically syncs the volume's content (default sync period is 60 seconds), so the pod automatically sees the updated data without requiring a restart. This makes it the correct choice for live updates from a ConfigMap.

Exam trap

The trap here is that candidates confuse the projected volume's ability to combine multiple sources with automatic update behavior, but projected volumes do not refresh content from ConfigMaps after the initial mount unless the pod is restarted.

How to eliminate wrong answers

Option B is wrong because an emptyDir volume is a temporary, empty directory that exists only as long as the pod runs; it cannot source data from a ConfigMap or provide automatic updates from external configuration. Option C is wrong because a projected volume with a configMap source can mount multiple sources (including ConfigMaps) into a single directory, but it does not automatically update the pod when the ConfigMap changes — the content is projected at mount time and not refreshed. Option D is wrong because a downwardAPI volume exposes pod metadata (e.g., labels, annotations) to the container, not ConfigMap data, and it does not support automatic updates from a ConfigMap.

Practice this question →

180

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 applies default resource requests to pods that don't specify them.

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 →

181

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, configMapKeyRef is required. Missing key leads to 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 →

182

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

Correct syntax to create a ConfigMap from a file.

Why this answer

Option C is correct because `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 →

183

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

envFrom with secretRef imports all keys as env vars.

Why this answer

Option A is correct because 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 →

184

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

secretKeyRef references a specific key from a Secret.

Why this answer

Option C is correct because 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 →

185

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

Correct. '250m' means 250 millicores, and '512Mi' means 512 mebibytes.

Why this answer

Option D is correct because 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 →

186

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

All required fields are set correctly.

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 →

187

Multi-Selectmedium

Which TWO of the following are valid ways to consume a ConfigMap in a Pod? (Select TWO)

Select 3 answers

A.Using envFrom with secretRef

B.Using env with valueFrom.configMapKeyRef to inject a specific key

C.Mounting the ConfigMap as a volume using volumes and volumeMounts

D.Using env with value directly set to a key name

E.Using envFrom to inject all keys as environment variables

AnswersB, C, E

This is also a valid way to consume a specific key from a ConfigMap as an environment variable.

Why this answer

Option B is correct because `env.valueFrom.configMapKeyRef` allows you to inject a specific key from a ConfigMap as an environment variable into a container. This is a standard Kubernetes API pattern for selective key injection, where you reference the ConfigMap name and the desired key, and the value is set at pod creation time.

Exam trap

The trap here is that candidates often confuse `envFrom` with `configMapRef` (which injects all keys) with `env.valueFrom.configMapKeyRef` (which injects a single key), or mistakenly think `secretRef` works with ConfigMaps, leading them to select option A or miss that option E is also correct.

Practice this question →

188

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

Correctly mounts host node path.

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 →

189

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

Drop ALL removes all capabilities, then add NET_ADMIN grants only that capability.

Why this answer

Option C is correct because 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 →

190

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

In the pod spec, you define a volume with 'secret' type and then mount it using volumeMounts in the container.

Why this answer

Option A is correct because 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 →

191

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

Correct command to create a TLS secret.

Why this answer

Option A is correct because `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 →

192

MCQhard

A namespace 'dev' has a ResourceQuota that sets 'requests.cpu: 4' and 'limits.cpu: 8'. A pod is created with a container that has 'resources.requests.cpu: 1' and 'resources.limits.cpu: 3'. However, the pod remains in Pending state. The output of 'kubectl describe quota -n dev' shows 'used requests.cpu: 3.5' and 'used limits.cpu: 7'. What is the most likely reason the pod is pending?

A.The pod's CPU limit exceeds the remaining quota.

B.The pod's CPU request exceeds the remaining quota.

C.The pod's memory request is not set.

D.The namespace does not have a LimitRange set.

AnswerA

Adding 3 to the used 7 would exceed the 8 limit quota.

Why this answer

The ResourceQuota in namespace 'dev' has a limit of 8 CPUs for limits.cpu, with 7 already used, leaving only 1 CPU remaining. The pod's container requests a limit of 3 CPUs, which exceeds the available 1 CPU, causing the scheduler to reject the pod and leave it in Pending state. ResourceQuota enforcement occurs at admission time, and the scheduler will not schedule a pod that would cause the namespace to exceed its quota limits.

Exam trap

The trap here is that candidates often focus on the request (1 CPU) being within the remaining quota (0.5 CPU) and overlook that the limit (3 CPUs) exceeds the remaining limit quota (1 CPU), which is the actual blocking constraint.

How to eliminate wrong answers

Option B is wrong because the pod's CPU request is 1, and the remaining quota for requests.cpu is 0.5 (4 - 3.5), so the request does not exceed the remaining quota. Option C is wrong because memory request is not required for scheduling; the pod can be pending due to CPU quota exhaustion even if memory is not set. Option D is wrong because a LimitRange is not required for ResourceQuota enforcement; the pod's resource limits are explicitly set, so the quota can be evaluated without a LimitRange.

Practice this question →

193

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

ServiceAccount is used to identify the Pod when it interacts with the Kubernetes API or other services.

Why this answer

A ServiceAccount provides an identity for processes running in a Pod. Option B is partially correct but too narrow; option C is about NetworkPolicy; option D is about RBAC, but ServiceAccount itself is the identity, not the rules.

Practice this question →

194

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

This overrides the ServiceAccount's setting and mounts the token.

Why this answer

Option A is correct because 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 →

195

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

This creates a ConfigMap by parsing the env file as key-value pairs.

Why this answer

Option B is correct because `--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 →

196

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 creates a generic secret with the required key, which can be used for image pull secrets.

Why this answer

Option B is correct because `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 →

197

Multi-Selectmedium

Which TWO of the following commands create a ConfigMap named 'my-config' from a file named 'app.properties'? (Choose two.)

Select 3 answers

A.kubectl create configmap my-config --from-file=app.properties --from-literal=extra=value

B.kubectl create configmap my-config --from-file=app.properties=app.properties

C.kubectl create configmap my-config --from-env-file=app.properties

D.kubectl create configmap my-config --from-literal=app.properties

E.kubectl create configmap my-config --from-file=app.properties

AnswersB, C, E

Correct: explicitly sets the key to 'app.properties'.

Why this answer

Option B is correct because `--from-file` can take a key-value pair in the form `--from-file=<key>=<source>`, which creates a ConfigMap entry with the key `app.properties` and the value from the file `app.properties`. Option C is correct because `--from-env-file` reads a file containing key=value lines and creates a ConfigMap with each line as a separate entry. Option E is also correct because `--from-file=app.properties` creates a ConfigMap with a single entry whose key is the filename and value is the file content.

Exam trap

The trap here is that candidates often confuse `--from-file` with `--from-env-file` and think `--from-literal` can read a file, or they miss that `--from-file=app.properties=app.properties` is a valid key=source syntax that overrides the default key.

Practice this question →

198

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

Correct. secretKeyRef references the key from the named Secret.

Why this answer

Option B is correct because 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 →

199

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 correctly uses comma-separated verbs and specifies the resource.

Why this answer

Option C is correct because 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 →

200

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

Disables the requirement; the container can run as root.

Why this answer

Option A is correct because 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 →

201

MCQhard

A ConfigMap named 'env-config' has keys 'DB_HOST' and 'DB_PORT'. A pod needs to set the environment variable 'DATABASE_HOST' to the value of 'DB_HOST' from the ConfigMap, and 'DB_PORT' directly as 'DB_PORT'. Which YAML snippet correctly achieves this?

A.env: - name: DB_PORT valueFrom: configMapKeyRef: name: env-config key: DB_PORT envFrom: - configMapRef: name: env-config

B.env: - name: DATABASE_HOST valueFrom: configMapKeyRef: name: env-config key: DB_HOST envFrom: - configMapRef: name: env-config

C.envFrom: - configMapRef: name: env-config env: - name: DATABASE_HOST value: DB_HOST

D.envFrom: - configMapRef: name: env-config prefix: DATABASE_

AnswerB

This sets DATABASE_HOST from the ConfigMap key DB_HOST, and then loads all keys (DB_HOST and DB_PORT) as env vars, but note that envFrom might overwrite DATABASE_HOST if the key DB_HOST is also loaded. Actually, the order: env is processed first, then envFrom. So DATABASE_HOST will be set, then envFrom will set DB_HOST as an env var, but since DATABASE_HOST is already set, it remains. However, there would be both DATABASE_HOST and DB_HOST env vars. That's acceptable.

Why this answer

Option B is correct: for 'DATABASE_HOST', it uses valueFrom with configMapKeyRef mapping key 'DB_HOST' to the env var. For 'DB_PORT', it uses envFrom with configMapRef to load all keys. Option A uses envFrom for both, but that would not rename 'DB_HOST'.

Option C uses envFrom for DATABASE_HOST, which won't rename. Option D uses env with configMapKeyRef for DB_PORT, but then envFrom overrides it? Actually, order matters: envFrom is processed after env, so env would be overwritten. But the correct approach is to use env for the renamed variable and envFrom for the rest.

Practice this question →

202

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

A Role defines permissions within a namespace, and a RoleBinding binds it to a user, group, or ServiceAccount.

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 →

203

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

Insufficient memory means the pod's request cannot be met by any node.

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 →

204

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

Correctly sets SA and disables token mount.

Why this answer

Option C is correct because 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 →

205

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

envFrom loads all keys from the ConfigMap as environment variables.

Why this answer

Option A is correct because `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 →

206

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

Correct syntax for creating a secret from a literal key-value pair.

Why this answer

Option C is correct because `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 →

207

MCQhard

A pod is running with 'securityContext: { runAsUser: 1000, fsGroup: 2000, runAsNonRoot: true }'. The container image has USER root set in Dockerfile. What happens when the pod is created?

A.The pod runs as user 1000 but group remains root

B.The pod runs successfully as user 1000 with group 2000

C.The pod runs as root because the image's USER directive takes precedence

D.The pod fails with 'container has runAsNonRoot and image will run as root'

AnswerB

The securityContext sets runAsUser: 1000, which overrides the image's USER, and fsGroup sets the group. runAsNonRoot is satisfied.

Why this answer

Option B is correct because the pod's securityContext settings override the USER directive in the container image. The runAsUser: 1000 sets the container process to run as user 1000, and fsGroup: 2000 sets the group ownership of any mounted volumes to group 2000. The runAsNonRoot: true ensures the container does not run as root, but since the securityContext explicitly sets a non-root user, the check passes and the pod runs successfully.

Exam trap

The trap here is that candidates assume the image's USER directive is immutable or that runAsNonRoot checks the image's USER before securityContext is applied, when in fact Kubernetes applies the securityContext first and then validates runAsNonRoot against the resulting effective user.

How to eliminate wrong answers

Option A is wrong because the fsGroup: 2000 in the securityContext sets the group for the container process and any volume mounts, not just the image's default group; the group is changed to 2000, not left as root. Option C is wrong because the pod's securityContext takes precedence over the image's USER directive; Kubernetes applies the securityContext at runtime, overriding the Dockerfile's USER instruction. Option D is wrong because the runAsNonRoot: true check evaluates the effective user after securityContext is applied, not the image's USER; since runAsUser: 1000 is set, the container runs as a non-root user, so the check passes and the pod does not fail.

Practice this question →

208

MCQhard

A pod uses a service account 'my-sa' with a RoleBinding that grants get and list on pods in namespace 'app'. The pod runs a process that calls the Kubernetes API to list pods. However, the API call returns 403. What is the most likely cause?

A.The API server is not running.

B.The RoleBinding is in the wrong namespace.

C.The pod does not have the service account token mounted.

D.The Role does not include list permission.

AnswerC

If automountServiceAccountToken is false, no token is available.

Why this answer

Option C is correct because the pod must have the service account token mounted to authenticate to the Kubernetes API server. By default, Kubernetes automatically mounts the service account token into pods via a projected volume at /var/run/secrets/kubernetes.io/serviceaccount/token. If the pod is configured with automountServiceAccountToken: false or the token is not mounted, the API client cannot authenticate, resulting in a 403 Forbidden error even if the RoleBinding grants the correct permissions.

Exam trap

CNCF often tests the distinction between authentication (who you are) and authorization (what you can do); the trap here is that candidates assume a 403 always means a missing RBAC permission, when in fact it can also result from a missing or invalid service account token causing authentication failure.

How to eliminate wrong answers

Option A is wrong because if the API server were not running, the API call would fail with a connection error (e.g., connection refused or timeout), not a 403 HTTP status code. Option B is wrong because RoleBindings are namespace-scoped and must exist in the same namespace as the service account; the question states the RoleBinding is in namespace 'app', which matches the service account's namespace, so this is not the issue. Option D is wrong because the RoleBinding grants 'get' and 'list' on pods, which includes the list permission; the error is not due to missing permissions but due to authentication failure.

Practice this question →

209

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

This enforces the restricted policy, rejecting pods that violate it.

Why this answer

Option C is correct because 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 →

210

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

Exposes all keys from the ConfigMap as environment variables.

Why this answer

Option C is correct because `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 →

211

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

Correct. This correctly references the key from the named ConfigMap.

Why this answer

Option C is correct because 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 →

212

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

Correct volume type for ConfigMap.

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 →

213

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 defines the UID for the container's main process.

Why this answer

Option D is correct because 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 →

214

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

This creates a Secret from literal key=value pairs.

Why this answer

Option B is correct because `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 →

215

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

Correct. This creates a Secret volume from db-secret.

Why this answer

Option D is correct because 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 →

216

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 scheduler cannot place the pod because no node has enough free resources to satisfy the requests.

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 →

217

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 prevents privileged containers among other things.

Why this answer

Option C (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 →

218

MCQmedium

A developer runs 'kubectl create secret generic tls-secret --cert=cert.crt --key=key.pem'. What type of Secret is created?

A.kubernetes.io/tls

B.Opaque

C.kubernetes.io/dockerconfigjson

D.kubernetes.io/ssh-auth

AnswerA

The --cert and --key flags are specifically for creating TLS secrets.

Why this answer

The command `kubectl create secret generic tls-secret --cert=cert.crt --key=key.pem` creates a Secret of type `kubernetes.io/tls`. This is because the `--cert` and `--key` flags automatically set the type to TLS, which is used to store TLS certificates and private keys for ingress or other TLS termination. The `generic` subcommand is a misnomer here; it does not create an Opaque secret when these specific flags are provided.

Exam trap

The trap here is that candidates assume `kubectl create secret generic` always creates an Opaque secret, but the `--cert` and `--key` flags automatically change the type to `kubernetes.io/tls`, which is a common point of confusion in CKAD exams.

How to eliminate wrong answers

Option B is wrong because Opaque secrets are created with `kubectl create secret generic` without the `--cert` and `--key` flags, or with `--from-literal`/`--from-file`; the presence of `--cert` and `--key` overrides the default type to `kubernetes.io/tls`. Option C is wrong because `kubernetes.io/dockerconfigjson` is created using `kubectl create secret docker-registry` or by manually specifying the type with a `.dockerconfigjson` data field, not via `--cert` and `--key`. Option D is wrong because `kubernetes.io/ssh-auth` is created using `kubectl create secret generic --from-file=ssh-privatekey=...` with the type explicitly set, or via `kubectl create secret ssh-auth`, and does not involve TLS certificate and key files.

Practice this question →

219

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 in securityContext specifies the seccomp profile to use.

Why this answer

Option D is correct because `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 →

220

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

Injects all keys from the Secret as environment variables.

Why this answer

Option A is correct because `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 →

221

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 allows setting min/max resource constraints for pods/containers in a namespace.

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 →

222

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

Correct fields to set the user and group and enforce non-root.

Why this answer

Option B is correct because 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 →

223

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

This command creates a tls secret with the provided certificate and key files.

Why this answer

Option D is correct because `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 →

224

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

Correct. fsGroup changes the group ownership of the volume to the specified GID and makes the container's processes part of that supplementary group.

Why this answer

Option C is correct because 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 →

225

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

The LimitRange defaults are applied.

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 →