CCNA Ckad Config Security Questions — Page 2 of 4

MCQeasy

A pod needs to run as a non-root user. Which securityContext field should be set to enforce this?

A.runAsGroup: 3000

B.runAsUser: 1000

C.readOnlyRootFilesystem: true

D.runAsNonRoot: true

AnswerD

This enforces that the container cannot run as root.

Why this answer

Option D is correct because setting `runAsNonRoot: true` in the pod's securityContext explicitly enforces that the container must not run as the root user (UID 0). If the container image attempts to run as root, the Pod will fail to start, ensuring compliance with non-root security policies.

Exam trap

The trap here is that candidates often confuse `runAsUser: 1000` with enforcing non-root execution, but it only sets a user ID and does not prevent the container from running as root if the image's entrypoint ignores the UID setting.

How to eliminate wrong answers

Option A is wrong because `runAsGroup: 3000` only sets the primary group ID for the container's processes, not the user ID, so it does not prevent running as root. Option B is wrong because `runAsUser: 1000` sets a specific user ID (1000) but does not enforce that the container cannot run as root; if the image runs as root, this field is ignored unless the image respects the user ID override. Option C is wrong because `readOnlyRootFilesystem: true` makes the root filesystem read-only but does not restrict the user ID, so the container could still run as root.

Practice this question →

MCQmedium

You want to set environment variable 'DB_URL' in a pod from the key 'url' in ConfigMap 'db-config'. Which YAML snippet is correct?

A.envFrom: - configMapRef: name: db-config

B.env: - name: DB_URL valueFrom: configMapKeyRef: name: db-config key: url

C.env: - name: DB_URL valueFrom: secretKeyRef: name: db-config key: url

D.env: - name: DB_URL valueFrom: configMap: name: db-config key: url

AnswerB

Correct: configMapKeyRef references the ConfigMap key.

Why this answer

Option B is correct because it uses the `configMapKeyRef` field under `valueFrom` to inject a specific key ('url') from a ConfigMap ('db-config') into the environment variable 'DB_URL'. This is the precise syntax required to reference a single key from a ConfigMap in a pod's environment variable definition.

Exam trap

CNCF often tests the distinction between `envFrom` (inject all keys) and `env` with `configMapKeyRef` (inject a single key), and the trap here is that candidates confuse `configMapKeyRef` with the invalid `configMap` or mistakenly use `secretKeyRef` for ConfigMap data.

How to eliminate wrong answers

Option A is wrong because `envFrom` with `configMapRef` injects all key-value pairs from the ConfigMap as environment variables, not a single specific key into a named variable. Option C is wrong because `secretKeyRef` is used to reference keys from a Secret, not a ConfigMap; using it here would cause a runtime error or fail to resolve the value. Option D is wrong because `configMap` is not a valid field under `valueFrom`; the correct field is `configMapKeyRef`.

Practice this question →

MCQeasy

Which of the following is a valid Pod Security Admission standard?

A.Privileged, Default

B.Default

C.Restricted

D.Secure

AnswerC

Restricted is one of the three standards (privileged, baseline, restricted).

Why this answer

The Pod Security Admission (PSA) standard defines three levels: Privileged, Baseline, and Restricted. Option C is correct because 'Restricted' is one of the three valid standards, designed to enforce the most restrictive pod security policies.

Exam trap

The trap here is that candidates may confuse 'Default' with the 'Baseline' standard, or assume 'Secure' is a valid level, when in fact only Privileged, Baseline, and Restricted are defined in the Kubernetes documentation.

How to eliminate wrong answers

Option A is wrong because 'Default' is not a valid Pod Security Admission standard; the three standards are Privileged, Baseline, and Restricted. Option B is wrong because 'Default' alone is not a valid standard; the valid standards are Privileged, Baseline, and Restricted. Option D is wrong because 'Secure' is not a valid Pod Security Admission standard; the valid standards are Privileged, Baseline, and Restricted.

Practice this question →

MCQeasy

Which kubectl command creates a ConfigMap named 'app-config' from a file 'config.properties'?

A.kubectl create configmap app-config --from-file=config.properties

B.kubectl create configmap app-config --file config.properties

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

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

AnswerA

This is the correct syntax to create a ConfigMap from a file.

Why this answer

Option A is correct because `kubectl create configmap` with the `--from-file` flag creates a ConfigMap from a file, using the filename as the key and the file content as the value. This is the standard Kubernetes method to import configuration data from a local file into a ConfigMap resource.

Exam trap

The trap here is confusing `--from-file` (which stores the entire file as a single entry) with `--from-env-file` (which parses key-value pairs), leading candidates to choose option C when they need to preserve the file's original format.

How to eliminate wrong answers

Option B is wrong because `--file` is not a valid flag for `kubectl create configmap`; the correct flag is `--from-file`. Option C is wrong because `--from-env-file` imports the file as environment variables (key=value pairs per line), not as a single key-value entry, which changes the data structure. Option D is wrong because `--from-literal` is used to specify key-value pairs directly on the command line (e.g., `--from-literal=key=value`), not to reference a file.

Practice this question →

MCQeasy

You are a Kubernetes administrator responsible for a production cluster. A development team has deployed a Pod named 'app-pod' that runs a container with a PostgreSQL database. The team reports that the Pod is failing to start with an error: 'Error: container has runAsNonRoot and image will run as root (runtime error)'. The Pod YAML is as follows: ```yaml apiVersion: v1 kind: Pod metadata: name: app-pod spec: containers: - name: db image: postgres:latest securityContext: runAsNonRoot: true ``` The team wants to ensure the container runs securely without running as root. What is the BEST course of action?

A.Add `runAsUser: 999` to the container's securityContext to run the container as the postgres user.

B.Remove `runAsNonRoot: true` from the securityContext to allow the container to run as root.

C.Increase the Pod's resource limits because the error is due to insufficient memory.

D.Create a PodSecurityPolicy that allows running as root.

AnswerA

This explicitly sets the user to a non-root user, satisfying runAsNonRoot.

Why this answer

Option A is correct because the PostgreSQL official image runs as the 'postgres' user with UID 999 by default. Adding `runAsUser: 999` to the container's securityContext overrides the user to a non-root UID, satisfying the `runAsNonRoot: true` constraint and allowing the container to start without the runtime error.

Exam trap

The trap here is that candidates may think removing `runAsNonRoot` is the simplest fix, but the question explicitly requires the container to run securely without root, so the correct action is to specify a non-root user ID rather than disabling the security constraint.

How to eliminate wrong answers

Option B is wrong because removing `runAsNonRoot: true` would allow the container to run as root, which violates the security requirement to run securely without running as root. Option C is wrong because the error message explicitly states a security context violation (runAsNonRoot vs. root image), not a resource constraint; increasing resource limits would not resolve a security context error. Option D is wrong because a PodSecurityPolicy (PSP) is a cluster-level admission controller that can enforce policies, but it does not change the container's user ID; the immediate fix is to set a non-root user in the Pod spec, and PSPs are deprecated in Kubernetes 1.21+ and removed in 1.25.

Practice this question →

MCQeasy

Which command creates a ConfigMap named 'app-config' with two keys: 'key1=value1' and 'key2=value2'?

A.kubectl create configmap app-config --from-literal key1=value1 --from-literal key2=value2

B.kubectl create configmap app-config --from-literal=key1=value1,key2=value2

C.kubectl create configmap app-config --from-file key1=value1 --from-file key2=value2

D.kubectl create configmap app-config --from-env-file=key1=value1 --from-env-file=key2=value2

AnswerA

Correct: uses two --from-literal flags.

Why this answer

Option A is correct because `kubectl create configmap` with the `--from-literal` flag allows you to specify key-value pairs directly on the command line. Each `--from-literal` flag creates one entry in the ConfigMap, so using two separate flags correctly creates a ConfigMap named 'app-config' with keys 'key1' and 'key2' mapped to 'value1' and 'value2' respectively.

Exam trap

The trap here is that candidates confuse `--from-literal` with `--from-file` or `--from-env-file`, or incorrectly assume that `--from-literal` accepts comma-separated syntax, leading them to choose options that either attempt to read nonexistent files or create a single malformed key.

How to eliminate wrong answers

Option B is wrong because `--from-literal` does not accept comma-separated key-value pairs; it expects a single key=value argument per flag, and using a comma would create a single key named 'key1=value1,key2=value2' instead of two separate keys. Option C is wrong because `--from-file` is used to load data from files on disk, not to specify literal key-value pairs; using it with 'key1=value1' would attempt to read a file named 'key1=value1' which does not exist. Option D is wrong because `--from-env-file` is used to load multiple key-value pairs from a file formatted as environment variables (e.g., a .env file), not to specify individual literals on the command line.

Practice this question →

MCQmedium

You need to grant a ServiceAccount named 'app-sa' in namespace 'default' read-only access to Pods in that namespace. Which RBAC resources should you create?

A.A ClusterRole with rules for pods (get, list, watch) and a ClusterRoleBinding to the ServiceAccount

B.A ClusterRole with rules for pods (get, list, watch) and a RoleBinding to the ServiceAccount

C.A Role with rules for pods (get, list, watch) and a RoleBinding to the ServiceAccount

D.A Role with rules for pods (get, list, watch, create) and a RoleBinding to the ServiceAccount

AnswerC

Correct: Role scoped to namespace with read-only permissions, bound to the ServiceAccount.

Why this answer

Option C is correct because the ServiceAccount 'app-sa' requires read-only access to Pods only within the 'default' namespace. A Role is namespace-scoped and can define rules for pods with verbs get, list, watch. A RoleBinding then binds that Role to the ServiceAccount within the same namespace, granting the permissions exactly where needed.

Exam trap

The trap here is that candidates often confuse ClusterRole with Role, assuming ClusterRole is always needed for 'cluster' resources like nodes, but for namespace-scoped resources like Pods, a Role is the correct and more secure choice.

How to eliminate wrong answers

Option A is wrong because a ClusterRole is cluster-scoped and a ClusterRoleBinding would grant the permissions across all namespaces, which is excessive and violates the requirement of namespace-scoped access. Option B is wrong because while a RoleBinding is namespace-scoped, using a ClusterRole (even with a RoleBinding) is unnecessary and can lead to unintended broader access if the ClusterRole is later modified; a Role is the correct namespace-scoped resource. Option D is wrong because it includes the 'create' verb, which grants write access to Pods, violating the 'read-only' requirement.

Practice this question →

Multi-Selecthard

Which THREE capabilities are commonly dropped in a pod's securityContext to adhere to restricted pod security standards?

Select 3 answers

A.ALL

B.SYS_ADMIN

C.SETUID

D.NET_RAW

E.CHOWN

AnswersB, C, D

SYS_ADMIN is a powerful capability often dropped.

Why this answer

Option B (SYS_ADMIN) is correct because the restricted pod security standard (PSS) requires dropping all capabilities via `ALL` and then adding back only those needed. However, `SYS_ADMIN` is a highly privileged capability that grants broad system administration access, such as mounting filesystems and performing privileged syscalls, and is explicitly forbidden in restricted profiles. Dropping it is mandatory to comply with restricted PSS.

Exam trap

The trap here is that candidates confuse the wildcard `ALL` (used to drop all capabilities) with a specific capability, or they assume `CHOWN` is dangerous because it relates to ownership, when in fact it is permitted under restricted PSS.

Practice this question →

MCQmedium

A ClusterRole named 'pod-reader' allows get, list, and watch on pods. A RoleBinding 'read-pods' in namespace 'default' binds this ClusterRole to user 'jane'. Which statement is true?

A.User 'jane' can read pods in all namespaces because ClusterRole is cluster-scoped

B.The RoleBinding must be changed to a ClusterRoleBinding for it to work

C.User 'jane' can read pods and also delete them because ClusterRole gives full access

D.User 'jane' can read pods only in the 'default' namespace

AnswerD

A RoleBinding grants permissions in its namespace only. The ClusterRole provides the rules, but the scope is limited by the RoleBinding.

Why this answer

A RoleBinding in a specific namespace binds a ClusterRole to a subject only within that namespace. Since the RoleBinding 'read-pods' is in the 'default' namespace, user 'jane' receives the permissions defined in the 'pod-reader' ClusterRole (get, list, watch on pods) only within the 'default' namespace, not across all namespaces.

Exam trap

The trap here is that candidates often assume a ClusterRole always grants cluster-wide permissions, forgetting that a RoleBinding scopes those permissions to a single namespace, while a ClusterRoleBinding is needed for true cluster-wide access.

How to eliminate wrong answers

Option A is wrong because a RoleBinding binds a ClusterRole to a subject only within the namespace where the RoleBinding exists, not across all namespaces; a ClusterRoleBinding would be required for cluster-wide access. Option B is wrong because a RoleBinding can bind a ClusterRole to a subject within a specific namespace, so it works correctly as is; no change to a ClusterRoleBinding is needed. Option C is wrong because the 'pod-reader' ClusterRole only grants get, list, and watch permissions on pods, not delete; a ClusterRole does not imply full access, only the permissions explicitly defined in its rules.

Practice this question →

Multi-Selectmedium

Which TWO are correct about LimitRange?

Select 2 answers

A.LimitRange can set default resource requests for containers that don't specify them

B.LimitRange can be applied only to pods in the default namespace

C.LimitRange is a cluster-scoped resource

D.LimitRange can enforce quotas on total resource usage across all pods

E.LimitRange can set maximum resource limits for containers

AnswersA, E

Yes, via spec.default.

Why this answer

Option A is correct because a LimitRange can define default resource requests and limits for containers in a namespace. When a container is created without specifying resource requests or limits, the LimitRange admission controller automatically applies the default values defined in the LimitRange object. This ensures that containers have baseline resource guarantees even if the pod spec omits them.

Exam trap

The trap here is confusing LimitRange (per-container constraints and defaults) with ResourceQuota (aggregate namespace limits), leading candidates to incorrectly select option D.

Practice this question →

MCQmedium

A developer creates a Secret using the command: 'kubectl create secret generic db-secret --from-literal=password=myPass'. Which way to consume this Secret in a pod is CORRECT?

A.env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password

B.volumes: - name: secret-vol secret: secretName: db-secret containers: - volumeMounts: - name: secret-vol mountPath: /etc/secret

C.envFrom: - secretRef: name: db-secret

D.env: - name: DB_PASSWORD valueFrom: configMapKeyRef: name: db-secret key: password

AnswerA

This correctly references the secret key 'password' from the Secret named 'db-secret'.

Why this answer

Option A is correct because `secretKeyRef` under `valueFrom` in an `env` entry is the proper way to inject a single key from a Kubernetes Secret into a container environment variable. The Secret was created with key `password` and value `myPass`, so `secretKeyRef` with `name: db-secret` and `key: password` correctly references that key.

Exam trap

The trap here is that candidates often confuse `configMapKeyRef` with `secretKeyRef` or assume that `envFrom` is the only way to consume Secrets, but the exam tests the precise syntax for referencing a single key from a Secret into a specific environment variable.

How to eliminate wrong answers

Option B is wrong because it shows a valid volume mount of the entire Secret, but the question asks for consuming the Secret in a pod, and while this is a valid method, it is not the only correct method; however, the question expects the specific correct way among the options, and B is technically correct but not the only correct answer, but the trap is that B is also a valid consumption method, but the question asks for 'which way is CORRECT' and both A and B are correct, but the exam expects A as the most direct answer for environment variable injection. Option C is wrong because `envFrom` with `secretRef` is valid for loading all keys from a Secret as environment variables, but it does not specify a single key; the question implies consuming the specific `password` key, and `envFrom` would expose all keys, which is not incorrect but less precise; however, the real issue is that `envFrom` is a valid method, but the question's answer set expects a single correct answer, and A is the most precise. Option D is wrong because `configMapKeyRef` is used to reference a ConfigMap, not a Secret; using it with a Secret name will fail because Secrets and ConfigMaps are separate resource types with different API objects.

Practice this question →

Multi-Selecteasy

A developer wants to restrict a Pod's resource usage. Which two API resources can be used to enforce limits at the namespace level? (Choose two.)

Select 2 answers

A.PodSecurityPolicy

B.HorizontalPodAutoscaler

C.LimitRange

D.ResourceQuota

E.NetworkPolicy

AnswersC, D

Sets default resource limits and requests for containers in a namespace.

Why this answer

LimitRange (C) is correct because it allows administrators to set default resource requests and limits, as well as minimum and maximum constraints, for Pods and containers within a namespace. This enforces resource boundaries at the namespace level, ensuring that individual Pods cannot exceed defined limits.

Exam trap

CNCF often tests the distinction between namespace-level resource enforcement (LimitRange and ResourceQuota) and cluster-level or scaling mechanisms, leading candidates to confuse HorizontalPodAutoscaler (which scales Pods) with resource limits.

Practice this question →

MCQeasy

Which of the following is a valid way to expose a Secret as an environment variable in a Pod?

A.env: - name: DB_PASSWORD valueFrom: configMapKeyRef: ...

B.env: - name: DB_PASSWORD value: $(DB_PASSWORD_SECRET)

C.env: - name: DB_PASSWORD valueFrom: fieldRef: ...

D.env: - name: DB_PASSWORD valueFrom: secretKeyRef: ...

AnswerD

secretKeyRef is the correct way to reference a Secret key as an environment variable.

Why this answer

Option D is correct because `secretKeyRef` is the Kubernetes API field used to reference a specific key from a Secret object and expose its value as an environment variable in a Pod. This is defined in the Pod spec under `env[].valueFrom.secretKeyRef`, which requires the `name` of the Secret and the `key` within that Secret.

Exam trap

CNCF often tests the distinction between `configMapKeyRef`, `secretKeyRef`, and `fieldRef`, and the trap here is that candidates confuse `configMapKeyRef` (for non-sensitive data) with `secretKeyRef` (for sensitive data), or think that variable substitution like `$(VAR_NAME)` can directly pull from a Secret.

How to eliminate wrong answers

Option A is wrong because `configMapKeyRef` references a ConfigMap, not a Secret; ConfigMaps are for non-sensitive data, while Secrets are for sensitive data like passwords. Option B is wrong because `$(DB_PASSWORD_SECRET)` is a variable substitution syntax used for referencing other environment variables or container arguments, not for directly exposing a Secret's value. Option C is wrong because `fieldRef` is used to expose Pod metadata (e.g., `metadata.name`, `status.podIP`) via the downward API, not Secret data.

Practice this question →

Multi-Selecthard

Which three security contexts can be set at the pod level (as opposed to container level)? (Select THREE.)

Select 3 answers

A.readOnlyRootFilesystem

B.fsGroup

C.runAsGroup

D.capabilities

E.runAsUser

AnswersB, C, E

fsGroup can be set at the pod level for volume ownership.

Why this answer

B is correct because `fsGroup` is a Pod-level security context field that applies a supplemental group ID to all containers in the Pod, ensuring that volumes mounted with that group ownership are accessible. It is set under `spec.securityContext.fsGroup`, not at the container level, making it a Pod-scoped setting.

Exam trap

The trap here is that candidates confuse Pod-level and container-level security contexts, often selecting `capabilities` or `readOnlyRootFilesystem` because they are commonly used, but they are only valid at the container level in the Kubernetes API.

Practice this question →

Multi-Selecthard

Which THREE configurations are part of Pod Security Admission's 'restricted' profile? (Select THREE.)

Select 3 answers

A.runAsNonRoot: true

B.seccompProfile.type: RuntimeDefault

C.capabilities must drop ALL

D.allowPrivilegeEscalation: true

E.Privileged containers allowed

AnswersA, B, C

Correct. Containers must run as non-root.

Why this answer

The 'restricted' profile in Pod Security Admission enforces the most stringent security standards. Option A is correct because `runAsNonRoot: true` is a required field in the restricted profile, ensuring containers cannot run as the root user, which mitigates privilege escalation risks.

Exam trap

The trap here is that candidates often confuse the 'restricted' profile with the 'baseline' profile, mistakenly thinking that options like `allowPrivilegeEscalation: true` or privileged containers are acceptable, when in fact the restricted profile explicitly prohibits them.

Practice this question →

MCQhard

A Pod is configured with automountServiceAccountToken: false. The application inside the pod needs to access the Kubernetes API. What should be done?

A.Create a new Secret of type kubernetes.io/dockerconfigjson

B.Mount the service account token manually by adding a volume and volumeMount

C.The application cannot access the API; the setting is final

D.Add a ConfigMap with the token

AnswerB

You can manually mount the token by using a projected volume with serviceAccountToken.

Why this answer

Setting automountServiceAccountToken: false prevents automatic mounting of the service account token. To still access the Kubernetes API, you must manually mount the token by adding a volume of type projected (or secret) containing the service account token, and a corresponding volumeMount in the container. This allows the application to authenticate with the API server using the mounted token.

Exam trap

The trap here is that candidates assume automountServiceAccountToken: false permanently blocks API access, but the CKAD exam tests that you can override this by manually mounting the token, often using a projected volume or a secret reference.

How to eliminate wrong answers

Option A is wrong because a Secret of type kubernetes.io/dockerconfigjson is used for pulling images from private registries, not for API authentication. Option C is wrong because the application can still access the API if the token is manually mounted; the setting is not final. Option D is wrong because ConfigMaps store non-sensitive configuration data, not service account tokens, which are sensitive and must be stored in Secrets or projected volumes.

Practice this question →

MCQhard

A cluster administrator wants to enforce that all pods in a namespace run with the 'restricted' Pod Security Standard. Which of the following is the correct way to label the namespace?

A.pod-security.kubernetes.io/enforce: restricted

B.pod-security.kubernetes.io/warn: restricted

C.pod-security.kubernetes.io/audit: restricted

D.pod-security.kubernetes.io/enforce: restricted

AnswerA, D

Correct. enforce level enforces the policy, rejecting pods that violate.

Why this answer

The 'restricted' Pod Security Standard is enforced by applying the label `pod-security.kubernetes.io/enforce: restricted` to the namespace. This label causes the Pod Security Admission controller to reject any pod that violates the restricted policy, ensuring compliance. The other labels (`warn` and `audit`) only generate warnings or audit annotations without blocking non-compliant pods.

Exam trap

CNCF often tests the distinction between `enforce`, `warn`, and `audit` labels, trapping candidates who assume any of these labels will block non-compliant pods, when only `enforce` actually rejects them.

How to eliminate wrong answers

Option B is wrong because `pod-security.kubernetes.io/warn: restricted` only generates a warning event when a pod violates the restricted policy, but does not enforce it or block the pod from running. Option C is wrong because `pod-security.kubernetes.io/audit: restricted` only adds an audit annotation to the pod's audit log entry for violations, without any enforcement or warning to the user.

Practice this question →

MCQhard

A Pod in a namespace with a ResourceQuota that sets 'limits.cpu: 4' and 'limits.memory: 8Gi' is being created with the following container resources: requests: cpu: 2, memory: 4Gi; limits: cpu: 4, memory: 8Gi. The namespace also has a LimitRange with default limits of cpu: 500m, memory: 512Mi. Which statement is true about this resource configuration?

A.The Pod will have its limits overridden by the LimitRange defaults because limits must be set

B.The Pod will be admitted because it respects both the ResourceQuota and the LimitRange

C.The Pod will be rejected because the limits exceed the LimitRange default

D.The Pod will be rejected because requests must equal limits

AnswerB

The pod's limits do not exceed the quota, and since limits are specified, LimitRange defaults are not applied.

Why this answer

B is correct because the Pod explicitly sets its own limits (cpu: 4, memory: 8Gi) and requests (cpu: 2, memory: 4Gi), which are within the ResourceQuota's 'limits.cpu: 4' and 'limits.memory: 8Gi' constraints. The LimitRange default limits only apply to containers that do not specify limits; since this Pod specifies limits, the defaults are ignored. The Pod is admitted as it satisfies both admission controllers.

Exam trap

The trap here is that candidates assume LimitRange defaults always override Pod specifications, but in reality defaults only apply when the Pod does not set its own limits, and the Pod's explicit limits take precedence.

How to eliminate wrong answers

Option A is wrong because LimitRange defaults only apply to containers that do not have limits set; here limits are explicitly defined, so no override occurs. Option C is wrong because the Pod's limits exactly match the ResourceQuota's maximum (4 CPU, 8Gi memory), not exceed it, and the LimitRange default is irrelevant when limits are set. Option D is wrong because Kubernetes does not require requests to equal limits; they can differ, and the ResourceQuota only enforces the maximum limits, not equality.

Practice this question →

MCQeasy

To prevent a container from running as root, which field should be set in the securityContext?

A.runAsUser: 1000

B.runAsNonRoot: true

C.allowPrivilegeEscalation: false

D.readOnlyRootFilesystem: true

AnswerB

Enforces that the container must not run as root; if the image runs as root, the container will fail.

Why this answer

The `runAsNonRoot: true` field in the securityContext explicitly prevents the container from running as the root user (UID 0). When set, Kubernetes will refuse to start the container if the image is configured to run as root, enforcing a non-root execution policy at the pod or container level. This is the direct and intended mechanism for ensuring the container does not run with root privileges.

Exam trap

The trap here is that candidates often confuse `runAsNonRoot: true` with `runAsUser: 1000`, mistakenly thinking that setting a non-zero user ID alone guarantees the container does not run as root, when in fact `runAsUser` only sets the UID and does not enforce a root check, leaving the container vulnerable if the image defaults to root.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 1000` sets a specific user ID for the container process but does not prevent running as root; if the image runs as root, this field overrides it only if explicitly set, and it does not enforce a non-root check. Option C is wrong because `allowPrivilegeEscalation: false` controls whether a process can gain more privileges than its parent (e.g., via setuid binaries), but it does not prevent the container from initially running as root. Option D is wrong because `readOnlyRootFilesystem: true` makes the container's root filesystem read-only, which is a security hardening measure but does not affect the user identity under which the container runs.

Practice this question →

MCQmedium

A developer wants to expose a Secret named 'db-secret' as environment variables in a Pod. The Secret has keys 'username' and 'password'. Which Pod spec snippet correctly achieves this?

A.envFrom: - secretRef: name: db-secret

B.volumes: - name: secret-volume secret: secretName: db-secret volumeMounts: - mountPath: /etc/secret name: secret-volume

C.env: - name: USERNAME valueFrom: secretKeyRef: name: db-secret key: username - name: PASSWORD valueFrom: secretKeyRef: name: db-secret key: password

D.env: - name: db-secret valueFrom: configMapKeyRef: name: db-secret key: username

AnswerA

Correct: envFrom with secretRef injects all keys as env vars.

Why this answer

Option A is correct because `envFrom` with `secretRef` allows you to inject all key-value pairs from a Secret as environment variables into a Pod in a single declaration. This is the most concise and intended method when you want to expose every key from a Secret (here 'username' and 'password') as individual environment variables without manually listing each one.

Exam trap

CNCF often tests the distinction between `envFrom` (bulk injection) and `env` with `secretKeyRef` (individual key injection), and the trap here is that candidates may choose option C because it works, missing that option A is the more efficient and correct approach for exposing all keys from a Secret as environment variables.

How to eliminate wrong answers

Option B is wrong because it mounts the Secret as files in a volume at `/etc/secret`, not as environment variables; the question specifically asks for environment variables. Option C is wrong because while it correctly uses `secretKeyRef` to expose individual keys as environment variables, it requires explicit enumeration of each key ('username' and 'password'), which is not the most efficient approach when the goal is to expose all keys from the Secret; the question asks for the snippet that 'correctly achieves this', and A is more direct and concise. Option D is wrong because it uses `configMapKeyRef` instead of `secretKeyRef`, and references a ConfigMap named 'db-secret' rather than a Secret, which would fail to read the Secret's data and would not expose the correct values.

Practice this question →

MCQmedium

A pod is scheduled but stays in Pending state. 'kubectl describe pod' 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 has a liveness probe configured incorrectly.

C.The namespace has a ResourceQuota that blocks the pod.

D.The pod's memory limit is set too low.

AnswerA

Correct: the scheduler cannot find a node with enough unallocated memory.

Why this answer

The '0/1 nodes are available: 1 Insufficient memory' message indicates that the Kubernetes scheduler could not find a node with enough allocatable memory to satisfy the pod's memory request. The pod's memory request (spec.containers[].resources.requests.memory) must be less than or equal to a node's allocatable memory for the pod to be scheduled. Since no node meets this requirement, the pod remains in Pending state.

Exam trap

The trap here is that candidates confuse memory requests with memory limits, assuming a low limit causes scheduling failure, when in fact the scheduler only evaluates requests, and limits only affect runtime OOM behavior.

How to eliminate wrong answers

Option B is wrong because a misconfigured liveness probe would cause the pod to be restarted or marked as unhealthy after it starts, not prevent it from being scheduled; scheduling failures occur before the pod runs. Option C is wrong because a ResourceQuota would cause an error like 'exceeded quota' or 'forbidden' when creating the pod, not a node-level 'Insufficient memory' message from the scheduler. Option D is wrong because a memory limit that is set too low would affect the pod's runtime behavior (e.g., OOMKill) but does not impact scheduling; the scheduler only considers the memory request, not the limit, when determining node fit.

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.envFrom: - secretRef: name: my-config

B.volumes: - name: config-vol configMap: configMapName: my-config

C.envFrom: - configMapRef: name: my-config

D.env: - name: MY_VAR valueFrom: configMapKeyRef: name: my-config key: my-key

E.volumes: - name: config-vol configMap: name: my-config containers: - volumeMounts: - name: config-vol mountPath: /etc/config

AnswersC, E

This exposes all keys from the ConfigMap as environment variables.

Why this answer

Option C is correct because `envFrom` with a `configMapRef` is a valid method to consume a ConfigMap as environment variables in a pod. This injects all key-value pairs from the ConfigMap named `my-config` as environment variables into the container. Option E is also correct as it demonstrates mounting a ConfigMap as a volume using the `configMap` volume source with the correct `name` field and then mounting that volume into the container at `/etc/config`.

Exam trap

CNCF often tests the distinction between `configMapRef` and `secretRef`, and the correct field name for a ConfigMap volume source is `name`, not `configMapName`, which is a common misremembered field from older documentation or other resource types.

Practice this question →

Multi-Selecthard

Which TWO of the following are valid ways to mount a Secret into a pod as environment variables? (Select exactly 2)

Select 2 answers

A.env: - name: SECRET_KEY valueFrom: configMapKeyRef: name: my-secret key: key

B.env: - name: SECRET_KEY valueFrom: secretEnvRef: name: my-secret key: key

C.envFrom: - configMapRef: name: my-secret

D.env: - name: SECRET_KEY valueFrom: secretKeyRef: name: my-secret key: key

E.envFrom: - secretRef: name: my-secret

AnswersD, E

Correct: references a specific key from a Secret.

Why this answer

Option D is correct because `secretKeyRef` is the standard Kubernetes API field for referencing a specific key from a Secret object and injecting its value as an environment variable. Option E is correct because `envFrom` with `secretRef` allows you to load all key-value pairs from a Secret as environment variables into the pod, which is a valid and common pattern.

Exam trap

The trap here is that candidates often confuse `configMapKeyRef`/`configMapRef` with `secretKeyRef`/`secretRef`, or invent non-existent fields like `secretEnvRef`, because the syntax for Secrets and ConfigMaps is nearly identical except for the resource-specific keyword.

Practice this question →

MCQmedium

A developer wants to restrict network traffic so that only pods with label 'app: frontend' can communicate with pods labeled 'app: backend' on port 8080. Which Kubernetes resource should be used?

A.NetworkPolicy

B.ResourceQuota

C.PodSecurityPolicy

D.RoleBinding

AnswerA

NetworkPolicy defines ingress/egress rules based on pod labels.

Why this answer

A NetworkPolicy is the correct Kubernetes resource because it defines ingress and egress rules to control pod-to-pod communication based on labels, namespaces, and ports. By specifying a podSelector matching 'app: backend', an ingress rule allowing traffic from pods with label 'app: frontend' on port 8080, and a policyTypes field including 'Ingress', this resource enforces the desired restriction at the network layer using iptables or eBPF under the hood.

Exam trap

The trap here is that candidates confuse NetworkPolicy with RBAC or security context controls, mistakenly thinking RoleBinding or PodSecurityPolicy can restrict network traffic, when in fact only NetworkPolicy (with a compatible CNI) provides pod-level network access control.

How to eliminate wrong answers

Option B is wrong because ResourceQuota limits aggregate resource consumption (CPU, memory, storage) per namespace, not network traffic between pods. Option C is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21, removed in 1.25) controls security context constraints for pods, such as privileged mode or host namespaces, not network connectivity. Option D is wrong because RoleBinding grants RBAC permissions to users or service accounts within a namespace, but does not affect network traffic between pods.

Practice this question →

100

Multi-Selectmedium

Which TWO resources are used to enforce resource quotas at the namespace level? (Select TWO.)

Select 2 answers

A.HorizontalPodAutoscaler

B.NetworkPolicy

C.ResourceQuota

D.PodDisruptionBudget

E.LimitRange

AnswersC, E

Correct. ResourceQuota sets aggregate resource limits for a namespace.

Why this answer

ResourceQuota (C) is correct because it is a Kubernetes object that sets hard limits on aggregate resource consumption (e.g., total CPU, memory, persistent volume claims) per namespace, preventing any single namespace from exhausting cluster resources. LimitRange (E) is correct because it enforces minimum and maximum resource requests/limits at the pod or container level within a namespace, complementing ResourceQuota by defining per-pod constraints.

Exam trap

CNCF often tests the distinction between cluster-level and namespace-level resource controls, and the trap here is that candidates confuse HorizontalPodAutoscaler (which scales pods) with ResourceQuota (which caps total usage), or think NetworkPolicy enforces resource limits due to its 'policy' name.

Practice this question →

101

Multi-Selecthard

Which THREE of the following are valid fields in a PodSecurityContext?

Select 3 answers

A.fsGroup

B.capabilities

C.seccompProfile

D.runAsNonRoot

E.allowPrivilegeEscalation

AnswersA, C, D

Valid at pod level; sets group ownership of volumes.

Why this answer

Option A is correct because `fsGroup` is a valid field in a PodSecurityContext. It specifies the supplemental group ID applied to all containers in the pod when accessing volumes, ensuring proper file ownership and permissions for shared storage.

Exam trap

CNCF often tests the distinction between PodSecurityContext and container SecurityContext, trapping candidates who assume all security-related fields (like capabilities or allowPrivilegeEscalation) are valid at the pod level when they are actually container-specific.

Practice this question →

102

MCQeasy

A container runs as root (UID 0) but the security policy requires the container to run as non-root user 1000. Which pod security context setting should be added?

A.runAsNonRoot: true

B.runAsUser: 1000

C.fsGroup: 1000

D.privileged: false

AnswerB

Directly sets the container's user ID to 1000.

Why this answer

Option B is correct because `runAsUser: 1000` explicitly sets the container's user ID to 1000, ensuring the container process runs as a non-root user. This directly satisfies the security policy requirement to run as UID 1000, overriding the default root (UID 0) behavior.

Exam trap

The trap here is that candidates often confuse `runAsNonRoot: true` with setting a specific user ID, not realizing it only enforces non-root but does not guarantee UID 1000, which the question explicitly requires.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot: true` only prevents the container from running as root (UID 0) but does not specify which non-root UID to use; it relies on the container image's default user, which may not be UID 1000. Option C is wrong because `fsGroup: 1000` sets the group ID for volume ownership, not the user ID the container process runs as. Option D is wrong because `privileged: false` is the default setting and only disables privileged mode; it does not enforce a specific non-root user.

Practice this question →

103

MCQhard

Refer to the exhibit. A Pod is defined with security contexts at both the container and Pod level. Which of the following statements accurately describes the effective security configuration?

A.The Pod will fail to start because runAsNonRoot conflicts with the container's runAsUser.

B.The container runs as user 1000, but the Pod-level runAsNonRoot overrides the container's runAsUser to enforce non-root.

C.The container runs as user 1000, group 2000, with NET_ADMIN capability added, and the Pod-level runAsNonRoot: true is also enforced.

D.The container runs as root because the Pod-level runAsNonRoot is ignored when container-level capabilities are set.

AnswerC

Container-level securityContext merges with Pod-level, but Pod-level runAsNonRoot is an additional constraint.

Why this answer

Option C is correct because Kubernetes merges Pod-level and container-level security contexts, with the container-level settings taking precedence for fields that overlap, but Pod-level settings that are not overridden (like runAsNonRoot) remain enforced. In this case, the container runs as user 1000, group 2000, with NET_ADMIN capability added, and the Pod-level runAsNonRoot: true is also enforced, ensuring the container does not run as root.

Exam trap

CNCF often tests the misconception that Pod-level runAsNonRoot overrides container-level runAsUser, when in fact they are complementary checks, and the container's runAsUser must be non-root for the Pod to start.

How to eliminate wrong answers

Option A is wrong because runAsNonRoot: true does not conflict with runAsUser: 1000; it only prevents the container from running as UID 0, and user 1000 is non-root, so the Pod starts successfully. Option B is wrong because runAsNonRoot does not override runAsUser; it is an additional check that the container's effective UID is not 0, and user 1000 satisfies that condition. Option D is wrong because Pod-level runAsNonRoot is not ignored when container-level capabilities are set; capabilities like NET_ADMIN do not affect the user ID, and runAsNonRoot remains enforced.

Practice this question →

104

Multi-Selectmedium

Which TWO of the following are valid ways to inject configuration data into a Kubernetes Pod?

Select 2 answers

A.Mounting a ServiceAccount token as a volume.

B.Using a ConfigMap to set environment variables in the Pod spec.

C.Using a PersistentVolumeClaim to store configuration files.

D.Referencing a NetworkPolicy in the Pod spec.

E.Mounting a Secret as a volume in the Pod.

AnswersB, E

ConfigMaps are designed to hold configuration data and can be exposed as environment variables.

Why this answer

Option B is correct because a ConfigMap is specifically designed to inject configuration data into Pods, and one of the primary methods is by setting environment variables in the Pod spec using `envFrom` or `valueFrom: configMapKeyRef`. This allows decoupling configuration from container images, enabling environment-specific settings without rebuilding images.

Exam trap

The trap here is that candidates often confuse 'injecting configuration data' with 'providing storage' or 'network policies', leading them to select PersistentVolumeClaim or NetworkPolicy as valid options, when in fact only ConfigMaps and Secrets (for sensitive data) are the native Kubernetes resources for injecting configuration into Pods.

Practice this question →

105

MCQeasy

A pod needs to mount a Secret named 'db-secret' as a volume at /etc/secret. Which volume mount definition is correct?

A.volumes: - name: secret-volume secret: secretName: db-secret

B.volumes: - name: secret-volume secretVolumeSource: secretName: db-secret

C.volumes: - name: db-secret secret: secretName: db-secret

D.volumes: - name: secret-volume secret: name: db-secret

AnswerA

This is the correct syntax: 'secret' with 'secretName' field.

Why this answer

Option A is correct because it uses the proper `secret` key under the `volumes` field to reference a Secret object by its `secretName`. When this volume is mounted at `/etc/secret`, Kubernetes automatically creates a file for each key in the Secret, with the file content being the decoded value of the key. This is the standard syntax for mounting a Secret as a volume.

Exam trap

The trap here is that candidates often confuse the `secret` volume source with the `configMap` volume source, or incorrectly use `secretVolumeSource` (which is not a valid field) instead of the correct `secret` key, leading them to choose option B.

How to eliminate wrong answers

Option B is wrong because `secretVolumeSource` is not a valid field in the volume definition; the correct field is `secret`. Option C is wrong because the volume name is `db-secret`, which is not technically invalid but is misleading — the volume name should be a descriptive identifier (e.g., `secret-volume`) and is not required to match the Secret name. Option D is wrong because it uses `name: db-secret` under the `secret` block, but the correct key is `secretName`, not `name`.

Practice this question →

106

MCQeasy

Which flag in a kubectl run command sets environment variables from a ConfigMap?

A.--env

B.--configmap

C.--env-from

D.--from-env-config

AnswerC

Correct. --env-from takes a ConfigMap name to populate environment variables.

Why this answer

Option C is correct because `kubectl run` supports the `--env-from` flag to inject environment variables from a ConfigMap (or Secret) into a pod. This flag allows you to specify a ConfigMap name, and Kubernetes will populate the container's environment with all key-value pairs from that ConfigMap, which is the intended mechanism for bulk environment variable injection.

Exam trap

The trap here is that candidates often confuse `--env-from` with the non-existent `--from-env-config` or assume `--configmap` is a valid flag, because they recall the concept of using ConfigMaps but not the exact kubectl syntax.

How to eliminate wrong answers

Option A is wrong because `--env` is used to set individual environment variables directly in the command (e.g., `--env=KEY=VALUE`), not to source variables from a ConfigMap. Option B is wrong because `--configmap` is not a valid flag in `kubectl run`; ConfigMaps are referenced via `--env-from` or mounted as volumes, not by a dedicated `--configmap` flag. Option D is wrong because `--from-env-config` does not exist as a kubectl flag; the correct syntax uses `--env-from` with a ConfigMap name, and the `--from-env-config` option is a common misremembering of the actual flag.

Practice this question →

107

Multi-Selectmedium

Which THREE of the following fields are part of a Pod's securityContext that can restrict container capabilities? (Choose three.)

Select 2 answers

A.capabilities.drop

B.seccompProfile

C.allowPrivilegeEscalation

D.capabilities.add

E.runAsUser

AnswersA, D

Correct.

Why this answer

Option A is correct because `capabilities.drop` in a Pod's `securityContext` explicitly removes Linux capabilities from all containers in the Pod, thereby restricting what privileged operations they can perform. This is a key mechanism for adhering to the principle of least privilege by dropping capabilities such as `NET_RAW` or `SYS_ADMIN` that are not needed.

Exam trap

CNCF often tests the distinction between capability management (`capabilities.drop`/`capabilities.add`) and other security context fields like `seccompProfile` or `runAsUser`, so candidates mistakenly think any security-related field can restrict capabilities.

Practice this question →

108

MCQmedium

You have a LimitRange in namespace 'ns' that sets default limits.cpu to 500m and default requests.cpu to 200m. You create a pod without specifying any CPU resources. What CPU values will be applied to the container?

A.The pod will be rejected by the admission controller

B.request: 200m, limit: 500m

C.request: 0, limit: 0 (no limits enforced)

D.request: 500m, limit: 500m

AnswerB

Correct. LimitRange defaults apply to containers that don't specify resource requirements.

Why this answer

When a LimitRange is configured in a namespace with default CPU limits and requests, any pod created without specifying CPU resources will have those defaults injected by the admission controller. The LimitRange sets default limits.cpu to 500m and default requests.cpu to 200m, so the container will receive request: 200m and limit: 500m. This is enforced by the LimitRanger admission plugin during pod creation.

Exam trap

The trap here is that candidates often assume a pod without resource specs will be rejected or have no limits, but the LimitRange admission controller silently applies defaults, making option B correct.

How to eliminate wrong answers

Option A is wrong because the pod is not rejected; the LimitRange admission controller applies defaults rather than rejecting the pod. Option C is wrong because the LimitRange explicitly sets default values, so the container will not have zero CPU requests and limits; the defaults are applied automatically. Option D is wrong because it confuses default limits with default requests; the default request is 200m, not 500m, and the limit is 500m, not equal to the request.

Practice this question →

109

MCQeasy

Which command creates a generic secret named 'db-secret' with key 'password' and value 'p@ss'?

A.kubectl create secret generic db-secret --from-file=password=p@ss

B.kubectl create secret generic db-secret --from-literal=password=p@ss

C.kubectl create secret tls db-secret --from-literal=password=p@ss

D.kubectl create secret docker-registry db-secret --from-literal=password=p@ss

AnswerB

Correct. 'generic' creates an Opaque secret with literal values.

Why this answer

Option B 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=p@ss` creates a generic secret with the key 'password' and the literal value 'p@ss', which matches the requirement exactly.

Exam trap

The trap here is that candidates often confuse `--from-file` with `--from-literal`, mistakenly thinking `--from-file=key=value` will treat the value as a literal string, when in fact it treats it as a file path.

How to eliminate wrong answers

Option A is wrong because `--from-file=password=p@ss` treats 'p@ss' as a filename, not a literal value; it would attempt to read a file named 'p@ss' and store its contents under the key 'password', which is not the intended behavior. Option C is wrong because `kubectl create secret tls` is used specifically for TLS certificates and keys, not for arbitrary key-value pairs; it expects `--cert` and `--key` flags, not `--from-literal`. Option D is wrong because `kubectl create secret docker-registry` is used for Docker registry authentication credentials and requires flags like `--docker-username`, `--docker-password`, and `--docker-email`; `--from-literal` is not supported for this secret type.

Practice this question →

110

Matchingmedium

Match each Kubernetes concept to its definition.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Virtual cluster for resource isolation

Runs one pod per node for system services

Runs a pod to completion; for batch processing

Automatically scales pods based on CPU/memory

Controls traffic flow between pods

Why these pairings

These concepts cover scheduling, scaling, and networking.

Practice this question →

111

MCQmedium

You create a Role named 'pod-reader' in the 'default' namespace with rules to get, list, and watch pods. A ServiceAccount 'app-sa' in the same namespace needs to be bound to this role. Which YAML snippet correctly creates the RoleBinding?

A.kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io

B.kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa apiGroup: '' roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io

C.kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io

D.kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa namespace: default roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io

AnswerB

Correct structure: RoleBinding binds a ServiceAccount to a Role.

Why this answer

Option B is correct because it creates a RoleBinding in the 'default' namespace that binds the ServiceAccount 'app-sa' to the Role 'pod-reader' using the correct 'kind: Role' in the roleRef. The RoleBinding must reference a Role (not a ClusterRole) when the Role exists in the same namespace, and the apiGroup for the roleRef must be 'rbac.authorization.k8s.io'.

Exam trap

CNCF often tests the distinction between Role and ClusterRole in the roleRef of a RoleBinding, where candidates mistakenly use 'kind: ClusterRole' when the actual resource is a namespaced Role, or use 'kind: ClusterRoleBinding' for a namespaced binding.

How to eliminate wrong answers

Option A is wrong because the roleRef uses 'kind: ClusterRole' instead of 'kind: Role', but the Role 'pod-reader' is a namespaced Role, not a ClusterRole. Option C is wrong for the same reason as A: it incorrectly references a ClusterRole instead of a Role. Option D is wrong because it uses 'kind: ClusterRoleBinding' which is cluster-scoped and cannot bind a namespaced Role; also, a ClusterRoleBinding requires a ClusterRole, not a Role.

Practice this question →

112

MCQhard

An administrator wants to enforce that all pods in namespace 'secured' must run with a seccomp profile set to 'RuntimeDefault' at the container level. Which Pod Security Admission policy standard achieves this?

A.Set the namespace label 'pod-security.kubernetes.io/enforce=privileged'

B.Set the namespace label 'pod-security.kubernetes.io/enforce=baseline'

C.Set the namespace label 'pod-security.kubernetes.io/enforce=restricted'

D.Set the namespace label 'pod-security.kubernetes.io/enforce=seccomp'

AnswerC

The restricted profile requires seccomp profile 'RuntimeDefault' or 'Localhost'.

Why this answer

The 'restricted' Pod Security Admission (PSA) policy standard enforces the most stringent security controls, including requiring that pods use a seccomp profile set to 'RuntimeDefault' at the container level. This is defined in the Kubernetes Pod Security Standards documentation, where the restricted profile mandates 'seccomp: RuntimeDefault' as a baseline requirement. Therefore, option C is correct because it directly matches the policy that enforces this specific seccomp constraint.

Exam trap

The trap here is that candidates often confuse the 'baseline' standard with 'restricted', assuming baseline covers seccomp requirements, but baseline only addresses basic privilege escalation and does not mandate a specific seccomp profile.

How to eliminate wrong answers

Option A is wrong because the 'privileged' PSA standard imposes no restrictions on seccomp profiles, allowing any profile or no profile at all. Option B is wrong because the 'baseline' PSA standard only prevents known privilege escalations but does not mandate a specific seccomp profile like 'RuntimeDefault'. Option D is wrong because 'pod-security.kubernetes.io/enforce=seccomp' is not a valid PSA standard; the valid standards are 'privileged', 'baseline', and 'restricted', and seccomp is a control within the restricted standard, not a standalone policy level.

Practice this question →

113

MCQmedium

You need to ensure that a pod in namespace 'dev' cannot consume more than 256Mi of memory. Which approach should you take?

A.Add annotation 'memory-limit: 256Mi' to the pod

B.Create a ResourceQuota with 'limits.memory: 256Mi' in the namespace

C.Set 'resources.limits.memory: 256Mi' in the container spec

D.Create a LimitRange with 'max: memory: 256Mi' in the namespace

AnswerC

Setting memory limits at the container level ensures that the container cannot exceed that amount.

Why this answer

To limit a pod's memory usage, you set 'resources.limits.memory' in the container spec. Option A sets a limit on the container, which is the correct way. Option B uses a LimitRange, which sets default limits but does not enforce a hard limit on a specific pod if the pod does not specify limits.

Option C uses a ResourceQuota which sets total limits for the namespace, not per-pod. Option D uses annotations which are not used for resource limits.

Practice this question →

114

MCQmedium

A pod is using a Secret to authenticate to a private registry. The Secret type must be 'kubernetes.io/dockerconfigjson'. Which of the following is the correct way to create such a Secret using kubectl?

A.kubectl create secret generic regcred --type=kubernetes.io/dockercfg --from-literal=.dockercfg=...

B.kubectl create secret generic regcred --from-file=.dockerconfigjson=/root/.docker/config.json

C.kubectl create secret tls regcred --cert=cert.crt --key=key.key

D.kubectl create secret docker-registry regcred --docker-server=my-registry.example.com --docker-username=myuser --docker-password=mypassword --docker-email=myemail@example.com

AnswerD

This correctly creates a dockerconfigjson Secret.

Why this answer

Option D is correct because `kubectl create secret docker-registry` is the dedicated command to create a Secret of type `kubernetes.io/dockerconfigjson`. It automatically generates the required `.dockerconfigjson` field with the base64-encoded Docker credentials in the correct JSON format, which the kubelet uses to authenticate to a private registry when pulling images.

Exam trap

The trap here is that candidates may think any Secret with a `.dockerconfigjson` key works, but without the correct `kubernetes.io/dockerconfigjson` type, the kubelet will not interpret the data properly, leading to image pull failures.

How to eliminate wrong answers

Option A is wrong because it uses `--type=kubernetes.io/dockercfg` (which corresponds to the legacy `.dockercfg` format) instead of `kubernetes.io/dockerconfigjson`, and `--from-literal=.dockercfg=...` does not produce the required `.dockerconfigjson` key. Option B is wrong because `--from-file=.dockerconfigjson` would create a generic Secret with that key, but the Secret type would remain `Opaque` unless explicitly set to `kubernetes.io/dockerconfigjson`; the command does not specify the required type. Option C is wrong because `kubectl create secret tls` creates a Secret of type `kubernetes.io/tls` for TLS certificates and keys, not for Docker registry authentication.

Practice this question →

115

MCQmedium

A Pod in a namespace with a ResourceQuota fails to create with the error: 'exceeded quota: compute-quota, requested: pods=1, used: pods=5, limited: pods=5'. What is the issue?

A.The Pod's service account does not have permission to create Pods.

B.The Pod's resource requests exceed the quota.

C.The namespace has reached its maximum number of Pods allowed by the ResourceQuota.

D.The Pod is trying to mount a Secret that does not exist.

AnswerC

Correct: the quota limits pods to 5, and all 5 slots are used.

Why this answer

The error message explicitly states 'requested: pods=1, used: pods=5, limited: pods=5'. This means the ResourceQuota named 'compute-quota' has a hard limit of 5 pods in the namespace, and that limit has already been reached. The Pod creation fails because the quota's `count/pods` scope is exhausted, not because of resource requests or permissions.

Exam trap

CNCF often tests the distinction between count-based quotas (e.g., `count/pods`) and resource-based quotas (e.g., `requests.cpu`), leading candidates to incorrectly assume the error is about resource requests when the message clearly references pod count.

How to eliminate wrong answers

Option A is wrong because a ServiceAccount permission issue would produce a 'Forbidden' or 'Unauthorized' error, not a quota-exceeded error. Option B is wrong because the error message mentions 'pods=1' (count of pods), not CPU or memory resource requests; a resource request exceed would show 'requested: cpu=...' or 'memory=...'. Option D is wrong because a missing Secret would cause a 'MountVolume.SetUp failed' or 'secret not found' error during Pod startup, not a quota-exceeded error at creation time.

Practice this question →

116

MCQmedium

A pod has a container with envFrom referencing a ConfigMap. The ConfigMap has keys 'APP_DEBUG=true' and 'APP_NAME=myapp'. The pod also has an env entry with name 'APP_DEBUG' set to 'false'. What is the value of APP_DEBUG in the container?

A.false

B.undefined

C.Both values are concatenated

D.true

AnswerA

Explicit env entries take precedence over envFrom.

Why this answer

When a pod has both an `envFrom` referencing a ConfigMap and an explicit `env` entry with the same key, the explicit `env` entry takes precedence. This is because Kubernetes merges environment variables from multiple sources, and individual `env` entries override any values from `envFrom` for the same key. Therefore, `APP_DEBUG` will be set to 'false' as defined in the explicit `env` entry.

Exam trap

The trap here is that candidates often assume `envFrom` merges all keys and that explicit `env` entries are additive, but they fail to remember that explicit `env` entries override `envFrom` for duplicate keys, leading them to pick the ConfigMap's value (true) or think both values are concatenated.

How to eliminate wrong answers

Option B is wrong because the environment variable `APP_DEBUG` is defined both via the ConfigMap and the explicit `env` entry, so it is not undefined. Option C is wrong because Kubernetes does not concatenate values for the same key; it applies a precedence rule where the explicit `env` entry overrides the value from `envFrom`. Option D is wrong because the explicit `env` entry with value 'false' overrides the ConfigMap's value of 'true', not the other way around.

Practice this question →

117

MCQmedium

You apply a ResourceQuota to a namespace that limits memory requests to 2Gi. You then try to create a pod that requests 3Gi memory. What happens?

A.The pod is created with a warning, but the request is ignored.

B.The pod is created, but the memory request is capped at 2Gi.

C.The pod creation fails with an error message indicating the quota would be exceeded.

D.The pod is created, but it will be OOMKilled if it exceeds 2Gi.

AnswerC

The API server validates admission and rejects the request.

Why this answer

When a ResourceQuota is applied to a namespace with a memory request limit of 2Gi, any pod creation that would cause the total memory requests in the namespace to exceed that quota is rejected by the Kubernetes API server. The pod creation fails immediately with an error message indicating the quota would be exceeded, because the admission controller validates the request against the quota before allowing the pod to be scheduled.

Exam trap

The trap here is that candidates may confuse ResourceQuota (which enforces at admission time and rejects the pod) with LimitRange (which sets default requests/limits but does not cap existing requests), or mistakenly think Kubernetes silently adjusts resource requests to fit within quotas.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not create pods with warnings and ignore requests; quota enforcement is strict and fails the creation. Option B is wrong because the memory request is not capped at 2Gi; the pod creation is rejected entirely, not modified. Option D is wrong because the pod is never created, so it cannot be OOMKilled; OOMKilling occurs at runtime if a container exceeds its memory limit, not due to quota enforcement.

Practice this question →

118

MCQhard

A Pod specification includes: securityContext: { seccompProfile: { type: RuntimeDefault } }. What does this configuration do?

A.It disables seccomp for the pod

B.It applies the container runtime's default seccomp profile

C.It allows all syscalls

D.It uses a custom seccomp profile from a file

AnswerB

RuntimeDefault uses the runtime's default, which is usually a restricted profile.

Why this answer

Setting `seccompProfile.type: RuntimeDefault` in the Pod's securityContext instructs the container runtime (e.g., containerd or CRI-O) to apply its own default seccomp profile to the container. This default profile restricts system calls to a safe subset, blocking dangerous or unnecessary syscalls while allowing common ones required for typical application execution. It is the recommended way to enable seccomp without managing a custom profile.

Exam trap

The trap here is that candidates confuse `RuntimeDefault` with disabling seccomp or allowing all syscalls, when in fact it applies a restrictive, runtime-specific default profile that is neither fully permissive nor custom.

How to eliminate wrong answers

Option A is wrong because `RuntimeDefault` does not disable seccomp; disabling seccomp would require setting the type to `Unconfined` or omitting the seccomp configuration entirely. Option C is wrong because `RuntimeDefault` does not allow all syscalls; it applies a restrictive profile that blocks many syscalls, and allowing all syscalls would be achieved by `Unconfined`. Option D is wrong because using a custom seccomp profile from a file requires setting the type to `Localhost` and specifying a `localhostProfile` path, not `RuntimeDefault`.

Practice this question →

119

MCQmedium

A pod is in Pending state. 'kubectl describe pod' shows '0/1 nodes are available: 1 Insufficient cpu'. Which action would resolve this?

A.Reduce the CPU request in the container's resource spec

B.Increase the CPU limit of the container

C.Delete and recreate the pod

D.Add more environment variables

AnswerA

Reducing the request makes the pod schedulable on nodes with less available CPU.

Why this answer

The pod cannot be scheduled because the requested CPU is not available on any node. Reducing the CPU request may allow scheduling.

Practice this question →

120

MCQmedium

A namespace 'team-a' has a ResourceQuota that sets 'requests.cpu: 4' and 'limits.cpu: 8'. A developer tries to create a pod with 'resources.requests.cpu: 2' and 'resources.limits.cpu: 10'. What happens?

A.The pod is rejected because the limit (10) exceeds the quota's allowed limit

B.The pod is created because the request (2) is within the quota

C.The pod is created but its limit is automatically reduced to 8

D.The pod is created, but it will be evicted immediately

AnswerA

A ResourceQuota enforces that the sum of limits across all pods in the namespace does not exceed 8.

Why this answer

The pod is rejected because the ResourceQuota in namespace 'team-a' sets a hard limit of 8 CPUs for limits.cpu across all pods. The developer's pod specifies a limit of 10 CPUs, which exceeds this quota. Kubernetes enforces ResourceQuota at admission time, so any resource request or limit that violates the quota's constraints will cause the pod creation to be denied.

Exam trap

The trap here is that candidates often assume only the request is checked against the quota, but Kubernetes enforces both requests and limits independently, and a pod with a limit exceeding the quota's limit will be rejected even if the request is within bounds.

How to eliminate wrong answers

Option B is wrong because even though the request (2) is within the quota, the limit (10) exceeds the quota's allowed limit of 8, and Kubernetes checks both requests and limits against the quota. Option C is wrong because Kubernetes does not automatically reduce resource limits to fit within a quota; it rejects the pod instead, as per the admission controller behavior. Option D is wrong because the pod is not created at all due to admission denial, so it cannot be evicted; eviction occurs only after a pod is running and violates a limit range or is under resource pressure.

Practice this question →

121

MCQeasy

You have a ConfigMap named 'app-config' with key 'database.url'. Which environment variable definition correctly injects this value into a pod using a configMapKeyRef?

A.- name: DATABASE_URL valueFrom: configMapKeyRef: name: app-config key: database.url

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

C.- name: DATABASE_URL valueFrom: secretKeyRef: name: app-config key: database.url

D.- valueFrom: configMapKeyRef: name: app-config key: database.url

AnswerD

This is the correct YAML structure to reference a specific key from a ConfigMap.

Why this answer

Option D is correct because it uses a `valueFrom` field with a `configMapKeyRef` to inject the value of the key `database.url` from the ConfigMap named `app-config` into the environment variable. The `configMapKeyRef` requires both `name` and `key` fields to specify the ConfigMap and the exact key to extract, and the environment variable name is defined separately (e.g., `- name: DATABASE_URL`). The structure in D correctly places the `valueFrom` block under the container's `env` entry, though the variable name is missing in the snippet; in practice, you must also include `name: DATABASE_URL` above the `valueFrom`.

Exam trap

The trap here is that candidates often confuse `envFrom` with `valueFrom` and `configMapKeyRef`, thinking that `envFrom` can inject a single key, or they mistakenly use `secretKeyRef` for ConfigMaps, failing to recognize that the resource type must match the reference field.

How to eliminate wrong answers

Option A is wrong because it uses `valueFrom` with a `configMapKeyRef` but the syntax is incomplete — it lacks the `- name: DATABASE_URL` line above the `valueFrom` block, which is required to define the environment variable name; however, the core structure is actually correct if the name were present, so this option is not the best answer because the question expects the exact correct snippet. Option B is wrong because `envFrom` with a `configMapRef` injects all keys from the ConfigMap as environment variables, not a single specific key, and it does not allow renaming the variable to `DATABASE_URL`; it would create an environment variable named `database.url`, which is invalid in most shells due to the dot. Option C is wrong because it uses `secretKeyRef` instead of `configMapKeyRef`, which is designed for Secrets, not ConfigMaps; referencing a ConfigMap with `secretKeyRef` will fail because the API expects a Secret resource.

Practice this question →

122

MCQhard

A pod in a namespace with a ResourceQuota that sets 'requests.cpu: 2' is failing to schedule. The pod manifest specifies 'resources: { requests: { cpu: "500m" } }'. What is the likely cause?

A.The ResourceQuota applies to limits, not requests.

B.The namespace has already used all its CPU request quota.

C.The pod does not specify a CPU limit.

D.The pod's CPU request exceeds the ResourceQuota limit.

AnswerB

Even though the pod's request is small, the total sum of requests in the namespace may have already reached the quota limit, preventing this pod from being scheduled.

Why this answer

The ResourceQuota sets a hard limit of 2 CPU cores for total requests across all pods in the namespace. If the sum of CPU requests from all pods already reaches or exceeds 2, a new pod with a 500m CPU request cannot be scheduled because it would exceed the quota. The pod's request (500m) is well within the quota limit, so the issue is that the namespace has exhausted its CPU request budget.

Exam trap

The trap here is that candidates assume the pod's individual request must be less than the quota, but they overlook that the quota is a cumulative limit across all pods in the namespace, so even a small request can fail if the namespace is already at capacity.

How to eliminate wrong answers

Option A is wrong because ResourceQuota can apply to both requests and limits; by default, it applies to requests unless specified otherwise, and the question states 'requests.cpu: 2' which explicitly targets requests. Option C is wrong because a CPU limit is not required for scheduling; the ResourceQuota only enforces the requests.cpu limit, and the pod can run without a limit. Option D is wrong because the pod's CPU request (500m) is less than the ResourceQuota limit (2), so it does not exceed the quota; the failure is due to cumulative usage, not an individual overage.

Practice this question →

123

MCQhard

You have a Secret of type kubernetes.io/tls. The pod mounting it as a volume expects the files 'tls.crt' and 'tls.key'. What keys must the Secret data contain?

A.ca.crt and tls.key

B.tls.crt and tls.key

C.cert and key

D.certificate and key

AnswerB

These are the required data keys for tls secrets.

Why this answer

For a Secret of type `kubernetes.io/tls`, the Kubernetes API server expects the data to contain exactly the keys `tls.crt` and `tls.key`. When such a Secret is mounted as a volume into a pod, the files created in the mount path are named `tls.crt` and `tls.key`, matching these keys. This is enforced by the Kubernetes TLS secret controller and is documented in the official Kubernetes reference for TLS secrets.

Exam trap

The trap here is that candidates confuse the generic concept of a certificate and key with the exact key names required by the `kubernetes.io/tls` secret type, leading them to choose options like `cert` and `key` or `certificate` and `key` instead of the mandatory `tls.crt` and `tls.key`.

How to eliminate wrong answers

Option A is wrong because `ca.crt` is an optional key for a TLS secret (used to provide a CA bundle), but the required keys for the secret type `kubernetes.io/tls` are `tls.crt` and `tls.key`; the pod expects `tls.crt` and `tls.key` files, not `ca.crt`. Option C is wrong because `cert` and `key` are not the standard key names for a TLS secret; Kubernetes specifically requires the keys to be named `tls.crt` and `tls.key` to match the expected file names on mount. Option D is wrong because `certificate` and `key` are generic terms, not the exact key names mandated by the `kubernetes.io/tls` secret type; the API server will reject a secret that does not contain the exact keys `tls.crt` and `tls.key`.

Practice this question →

124

MCQhard

A Pod Security Admission policy is set to 'restricted' for a namespace. Which of the following pod specs is ALLOWED?

A.A pod with securityContext.runAsNonRoot: true and readOnlyRootFilesystem: true

B.A pod with securityContext.capabilities.add: ["NET_ADMIN"]

C.A pod with no securityContext specified

D.A pod with securityContext.privileged: true

AnswerA

Complies with restricted policy: runAsNonRoot and readOnlyRootFilesystem are required.

Why this answer

The 'restricted' Pod Security Admission (PSA) policy enforces the most stringent security controls, requiring pods to meet specific baseline security constraints. Option A satisfies these requirements by setting `runAsNonRoot: true` (preventing root execution) and `readOnlyRootFilesystem: true` (preventing writes to the root filesystem), both of which are mandatory for the restricted profile. The other options violate the restricted policy by either enabling privileged access, adding dangerous capabilities, or omitting required security contexts.

Exam trap

CNCF often tests the misconception that omitting securityContext is acceptable or that adding a single capability like `NET_ADMIN` is harmless, but the restricted profile mandates explicit non-root execution and read-only root filesystem, and prohibits any capability additions beyond the default set.

How to eliminate wrong answers

Option B is wrong because the restricted policy explicitly forbids adding any capabilities beyond the default set (e.g., `NET_ADMIN` is a privileged capability that grants network administration rights, which is not allowed). Option C is wrong because the restricted policy requires explicit security context settings, including `runAsNonRoot: true` and `readOnlyRootFilesystem: true`; a pod with no securityContext specified defaults to root and writable root filesystem, violating the policy. Option D is wrong because the restricted policy prohibits privileged containers entirely; setting `privileged: true` grants unrestricted host access and bypasses all security constraints.

Practice this question →

125

Multi-Selectmedium

Which TWO approaches can be used to expose a Secret's value as an environment variable in a pod?

Select 2 answers

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

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

C.envFrom: - secretRef: name: my-secret

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

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

AnswersA, C

Correct use of secretKeyRef.

Why this answer

Option A is correct because the `valueFrom.secretKeyRef` field in a container's `env` definition directly references a specific key from a Kubernetes Secret and injects its value as an environment variable. This is the standard method for exposing a single secret key as an environment variable, as defined in the Kubernetes API.

Exam trap

CNCF often tests the distinction between `secretKeyRef` (for individual keys) and `secretRef` (for all keys via `envFrom`), and the trap here is that candidates may confuse `configMapKeyRef` with `secretKeyRef` or think that `volumeMounts` can expose secrets as environment variables.

Practice this question →

126

Multi-Selectmedium

A developer wants to mount a ConfigMap as a volume in a Pod so that updates to the ConfigMap are reflected in the Pod without restarting. Which two statements are correct? (Choose two.)

Select 2 answers

A.Using envFrom to inject ConfigMap data as environment variables will update automatically.

B.ConfigMap updates are reflected immediately in the volume mount.

C.Using subPath in the volume mount prevents automatic updates.

D.The Pod must be restarted for any ConfigMap change to take effect.

E.Mounting the ConfigMap as a volume (without subPath) ensures that file updates are reflected automatically through symlinks.

AnswersC, E

subPath mounts a single file; updates require pod restart.

Why this answer

Option C is correct because when a ConfigMap is mounted using `subPath`, Kubernetes treats the mount as a single file rather than a directory of symlinks. This means the atomic update mechanism (which uses symlinks to swap the directory contents) is bypassed, and updates to the ConfigMap are not reflected in the Pod without a restart or remount.

Exam trap

The trap here is that candidates often assume all ConfigMap mounts update automatically, but `subPath` mounts are a critical exception that breaks the automatic update mechanism.

Practice this question →

127

Multi-Selectmedium

Which TWO statements about Kubernetes Secrets are correct? (Select 2)

Select 2 answers

A.A Secret can be mounted as a volume or exposed as environment variables

B.Secrets are always encrypted in etcd

C.Secret data is base64 encoded in YAML manifests but stored in plaintext in etcd by default

D.The maximum size of a Secret is 1 MB

E.Secrets can only be used by pods in the same namespace as the Secret

AnswersA, C

Both methods are supported.

Why this answer

A is correct because Kubernetes Secrets are designed to be consumed by Pods either as files mounted into a volume (via `volumes` and `volumeMounts`) or as environment variables (via `env` or `envFrom`). This flexibility allows applications to access sensitive data like passwords or tokens without hardcoding them into the container image or pod spec.

Exam trap

CNCF often tests the misconception that base64 encoding is encryption, leading candidates to think Secrets are secure by default, when in fact base64 is just encoding and Secrets are stored in plaintext in etcd unless encryption at rest is configured.

Practice this question →

128

MCQmedium

A pod fails to start with a 'CreateContainerConfigError'. Running 'kubectl describe pod my-pod' reveals: 'Error: container has runAsNonRoot and image will run as root'. The pod definition includes 'securityContext.runAsNonRoot: true'. What is the most likely cause?

A.The container does not have the CAP_SYS_ADMIN capability

B.The container image's default user is root (UID 0), conflicting with runAsNonRoot

C.The container's filesystem is read-only

D.The runAsUser field is missing, so the pod uses a random UID

AnswerB

runAsNonRoot: true requires the container to run as a non-root user. If the image defaults to root, the pod will fail with this error.

Why this answer

The error 'container has runAsNonRoot and image will run as root' occurs because the pod's securityContext sets `runAsNonRoot: true`, but the container image's default user is root (UID 0). Kubernetes checks the image's user at container startup; if the image runs as root and the pod enforces non-root, the container fails to start with a CreateContainerConfigError.

Exam trap

The trap here is that candidates often assume the error is about missing runAsUser or capabilities, but the error message directly points to the image's default user being root, which is a mismatch with the runAsNonRoot constraint.

How to eliminate wrong answers

Option A is wrong because CAP_SYS_ADMIN is a Linux capability unrelated to the runAsNonRoot check; the error is about the container's user identity, not capabilities. Option C is wrong because a read-only filesystem does not cause a runAsNonRoot conflict; it would produce a different error (e.g., 'read-only filesystem'). Option D is wrong because runAsUser is not required when runAsNonRoot is true; Kubernetes will still enforce non-root even without an explicit UID, and the error explicitly states the image runs as root, not that a random UID is used.

Practice this question →

129

Drag & Dropmedium

Sequence the steps to scale a Deployment to 5 replicas and verify.

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

Steps

Order

Why this order

Check current state, scale, watch Pods, confirm count, and inspect events.

Practice this question →

130

MCQhard

A container image requires a seccomp profile that is not the default. The cluster supports the RuntimeDefault seccomp profile. Which Pod securityContext field should be configured to use the RuntimeDefault seccomp profile?

A.seccompProfile: type: RuntimeDefault

B.seccomp: type: RuntimeDefault

C.capabilities: add: [SECCOMP]

D.securityContext: seccomp: type: Unconfined

AnswerA

Correct. This sets the seccomp profile to the runtime default.

Why this answer

Option A is correct because the `seccompProfile` field under the Pod's `securityContext` is the proper way to specify a seccomp profile in Kubernetes. Setting `type: RuntimeDefault` tells the container runtime (e.g., containerd or CRI-O) to use the default seccomp profile provided by the runtime, which is a secure baseline that blocks around 44 system calls while allowing common ones like `read`, `write`, and `exit`. This field was introduced in Kubernetes 1.19 (GA in 1.22) and is the standard approach for configuring seccomp at the Pod or container level.

Exam trap

The trap here is that candidates confuse the old alpha annotation `seccomp.security.alpha.kubernetes.io/pod` (deprecated in 1.19) with the current `seccompProfile` field, or they mistakenly think `capabilities` can set the seccomp profile, when in fact capabilities only grant permission to use seccomp syscalls, not apply a profile.

How to eliminate wrong answers

Option B is wrong because `seccomp` is not a valid field in the Pod `securityContext`; the correct field is `seccompProfile`, and the `type` subfield specifies the profile type (e.g., RuntimeDefault, Localhost, Unconfined). Option C is wrong because `capabilities` with `SECCOMP` is a Linux capability that allows a process to install seccomp filters, but it does not configure the Pod to use the RuntimeDefault profile; it grants the ability to manipulate seccomp, which is a different concept. Option D is wrong because `securityContext` does not have a `seccomp` field; the correct structure is `seccompProfile.type`, and `Unconfined` disables seccomp entirely, which is the opposite of using the RuntimeDefault profile.

Practice this question →

131

MCQeasy

Which kubectl command creates a Secret named 'tls-secret' from a TLS certificate file 'cert.pem' and private key file 'key.pem'?

A.kubectl create secret tls tls-secret --certificate=cert.pem --private-key=key.pem

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

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

D.kubectl create secret docker-registry tls-secret --cert=cert.pem --key=key.pem

AnswerB

This creates a kubernetes.io/tls Secret with the certificate and key.

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 private key pair. The correct flags are `--cert` for the certificate file and `--key` for the private key file, matching the usage shown in option B.

Exam trap

The trap here is that candidates confuse the `--cert` and `--key` flags with similar flags from other tools (like OpenSSL) or assume `--certificate` is the correct flag, leading them to choose option A, or they mistakenly use `generic` instead of `tls` for TLS secrets, as in option C.

How to eliminate wrong answers

Option A is wrong because it uses `--certificate` and `--private-key` flags, which are not valid for `kubectl create secret tls`; the correct flags are `--cert` and `--key`. Option C is wrong because it uses `kubectl create secret generic`, which creates a generic Opaque secret, not a TLS secret; TLS secrets require the `tls` type to properly encode the certificate and key with the correct keys (`tls.crt` and `tls.key`). Option D is wrong because it uses `kubectl create secret docker-registry`, which is for creating a Docker registry authentication secret, not a TLS secret; it expects `--docker-username`, `--docker-password`, etc., not certificate files.

Practice this question →

132

MCQmedium

You deploy a pod with resource requests: cpu: 500m, memory: 256Mi and limits: cpu: 1, memory: 512Mi. The container tries to allocate 600Mi of memory. What happens?

A.The container is OOMKilled because it exceeds the memory limit

B.The container runs normally, but memory usage is throttled

C.The container runs normally because requests are the only constraints

D.The container is evicted from the node

AnswerA

Exceeding the memory limit triggers OOM kill.

Why this answer

The correct answer is A because the container's memory allocation of 600Mi exceeds its configured memory limit of 512Mi. Kubernetes enforces memory limits using the cgroup memory controller; when a container attempts to allocate more memory than its limit, the kernel's Out-Of-Memory (OOM) killer terminates the container process. This results in the container being OOMKilled, as recorded in the pod status.

Exam trap

CNCF often tests the misconception that memory, like CPU, can be throttled when limits are exceeded, but memory is a non-compressible resource and exceeding its limit always results in an OOM kill, not throttling.

How to eliminate wrong answers

Option B is wrong because memory is not a compressible resource like CPU; exceeding the memory limit triggers an OOM kill, not throttling. Option C is wrong because memory limits are hard constraints enforced by Kubernetes, not just requests; requests are used for scheduling, while limits are enforced at runtime. Option D is wrong because eviction occurs when a node is under memory pressure and the kubelet reclaims resources by terminating pods, not when a single container exceeds its own limit.

Practice this question →

133

MCQmedium

A pod is running with a SecurityContext that sets 'runAsUser: 1000' and 'runAsGroup: 3000'. The container process is running as user 1000. However, the container needs to access a file on a mounted volume that is owned by user 1000 and group 2000. Which SecurityContext setting should be added to ensure the container can read the file?

A.Set fsGroup: 2000 in the pod-level securityContext

B.Set readOnlyRootFilesystem: true

C.Set runAsGroup: 2000

D.Add capability: CAP_DAC_READ_SEARCH

AnswerA

Setting fsGroup to 2000 ensures that all files in mounted volumes are group-owned by GID 2000, and the container processes have that group as a supplementary group, enabling read access.

Why this answer

The 'fsGroup' field in the pod's SecurityContext changes the group ownership of any files in the mounted volumes to the specified GID, and all container processes are part of the supplementary group. This allows the container to read files with group 2000 if fsGroup is set to 2000. Option A (runAsGroup: 2000) would change the primary group of the process, but the file's group is 2000 and the container runs as user 1000, which might not own the file; fsGroup is the correct approach.

Option C adds capabilities, which are not related to file access groups. Option D sets readOnlyRootFilesystem, which doesn't help with volume access.

Practice this question →

134

MCQeasy

Which command creates a generic Secret with username=admin and password=secret123?

A.kubectl create secret tls mysecret --from-literal=username=admin --from-literal=password=secret123

B.kubectl create secret generic mysecret --from-env-file=username=admin,password=secret123

C.kubectl create secret generic mysecret --from-file=username=admin --from-file=password=secret123

D.kubectl create secret generic mysecret --from-literal=username=admin --from-literal=password=secret123

AnswerD

Correct syntax for creating a secret from literals.

Why this answer

Option D is correct because `kubectl create secret generic` with `--from-literal` allows you to specify key-value pairs directly on the command line, creating a generic (opaque) Secret with the literal values `username=admin` and `password=secret123`. This is the standard way to create a generic Secret from literal data.

Exam trap

CNCF often tests the distinction between `--from-literal`, `--from-file`, and `--from-env-file`, and candidates commonly confuse `--from-file` (which expects a file path) with `--from-literal` (which expects a key=value pair).

How to eliminate wrong answers

Option A is wrong because `kubectl create secret tls` creates a TLS Secret, which expects a `--cert` and `--key` file, not literal key-value pairs, and is used for TLS certificates, not generic credentials. Option B is wrong because `--from-env-file` expects a file path (e.g., a `.env` file), not inline key-value pairs; the syntax `--from-env-file=username=admin,password=secret123` is invalid and would cause an error. Option C is wrong because `--from-file` expects a file path (e.g., `--from-file=username=./username.txt`), not literal key-value pairs; using `--from-file=username=admin` would try to read a file named `admin` in the current directory, not set the value to `admin`.

Practice this question →

135

MCQeasy

Which kubectl command creates a ConfigMap named 'app-config' from a file 'app.properties'?

A.kubectl create configmap app-config --from-file=app.properties

B.kubectl create configmap app-config --from-literal=app.properties

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

D.kubectl create configmap app-config --file=app.properties

AnswerA

Correct. The --from-file flag creates a ConfigMap from a file.

Why this answer

Option A is correct because `kubectl create configmap app-config --from-file=app.properties` reads the file `app.properties` and creates a ConfigMap with a single key-value pair where the key is the filename (without extension) and the value is the entire file content. This is the standard way to create a ConfigMap from a file in Kubernetes.

Exam trap

The trap here is confusing `--from-file` (which stores the entire file content as a single value) with `--from-env-file` (which parses the file as key-value pairs for environment variables), leading candidates to pick option C when they need to import a properties file as a single blob.

How to eliminate wrong answers

Option B is wrong because `--from-literal` expects a key=value pair directly on the command line, not a filename; using `--from-literal=app.properties` would create a ConfigMap with the literal string 'app.properties' as both the key and value, not the file's content. Option C is wrong because `--from-env-file` is used to import a file containing multiple key=value lines (one per line) as environment variables, not to store the entire file content as a single value. Option D is wrong because `--file` is not a valid flag for the `kubectl create configmap` command; the correct flag is `--from-file`.

Practice this question →

136

Multi-Selectmedium

Which TWO of the following are valid types of Secrets in Kubernetes?

Select 2 answers

A.Opaque

B.kubernetes.io/ssh-auth

C.configmap

D.dockerconfigjson

E.kubernetes.io/tls

AnswersA, E

Opaque secrets store arbitrary key-value pairs.

Why this answer

Option A is correct because Opaque is the default Secret type in Kubernetes, used for storing arbitrary key-value pairs such as passwords or tokens. It is defined as `Opaque` in the Secret's `type` field and is the most commonly used Secret type for general-purpose sensitive data.

Exam trap

CNCF often tests the exact naming of built-in Secret types, and the trap here is that candidates may confuse `dockerconfigjson` (missing the `kubernetes.io/` prefix) with the valid `kubernetes.io/dockerconfigjson`, or assume `configmap` is a Secret type when it is a separate resource.

Practice this question →

137

MCQmedium

A Pod specification includes: securityContext: { runAsNonRoot: true }. The container image runs as root by default. What will happen when the Pod is created?

A.The Pod will start and immediately be OOMKilled

B.The Pod will run but with a warning

C.The Pod will not start; the kubelet will reject it because the container tries to run as root

D.The Pod will run successfully because K8s overrides the user to non-root

AnswerC

The Pod will be rejected during admission or at runtime, and remain in a pending/error state.

Why this answer

When a Pod specifies `runAsNonRoot: true` in its `securityContext`, the kubelet verifies that the container's user ID is non-zero (non-root) before starting the container. If the container image runs as root by default (UID 0), the kubelet will reject the Pod, and it will remain in a `ContainerCreating` or `CrashLoopBackOff` state with an error like 'container has runAsNonRoot and image will run as root'. This is a security enforcement mechanism that prevents privileged execution.

Exam trap

The trap here is that candidates assume Kubernetes will automatically adjust the container user to non-root when `runAsNonRoot` is set, but in reality, Kubernetes only validates the existing user and rejects the Pod if it's root—you must explicitly set `runAsUser` to a non-zero value if the image runs as root.

How to eliminate wrong answers

Option A is wrong because OOMKilled (Out Of Memory Killed) occurs when a container exceeds its memory limit, not due to security context violations; the Pod is rejected before any execution. Option B is wrong because Kubernetes does not issue warnings for security context violations—it enforces them strictly by failing the Pod creation, and the event logs will show an error, not a warning. Option D is wrong because Kubernetes does not automatically override the container's user to non-root; the `runAsNonRoot` flag only validates the user, and if the image runs as root, the Pod is rejected unless you explicitly set `runAsUser` to a non-zero value.

Practice this question →

138

Multi-Selecthard

Which THREE are valid ways to create a ConfigMap?

Select 3 answers

A.kubectl create configmap my-config --from-literal=key=value

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

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

D.kubectl create configmap my-config --from-file=key=file

E.kubectl apply configmap my-config --from-literal=key=value

AnswersA, B, C

Valid.

Why this answer

Option A is correct because `kubectl create configmap` with `--from-literal` directly creates a ConfigMap with a key-value pair from the command line, which is a standard and valid method. This approach is ideal for simple, single-key configurations without needing external files.

Exam trap

The trap here is that candidates may confuse `kubectl create configmap` with `kubectl apply` or misremember the syntax for `--from-file` with a custom key, leading them to select invalid options like D or E.

Practice this question →

139

MCQeasy

Which command creates a TLS secret from an existing certificate and key file?

A.kubectl create secret tls my-tls --cert=cert.pem --key=key.pem

B.kubectl create secret tls my-tls --from-file=cert.pem --from-file=key.pem

C.kubectl create secret generic my-tls --from-file=cert.pem --from-file=key.pem

D.kubectl create secret docker-registry my-tls --docker-server=... --docker-username=... --docker-password=...

AnswerA

Correct.

Why this answer

Option A is correct because the `kubectl create secret tls` command is specifically designed to create a TLS secret from an existing certificate and key file. The `--cert` and `--key` flags directly specify the paths to the PEM-encoded certificate and private key, which Kubernetes then stores as a `kubernetes.io/tls` secret type, automatically base64-encoding the data for secure storage in etcd.

Exam trap

The trap here is that candidates confuse the `--from-file` flag (used for generic secrets) with the `--cert` and `--key` flags (required for TLS secrets), leading them to choose option B or C, which would create a secret of the wrong type or with incorrect key mappings.

How to eliminate wrong answers

Option B is wrong because `kubectl create secret tls` does not support `--from-file` flags; those flags are used with `kubectl create secret generic` or `kubectl create secret docker-registry`, and using them with `tls` would result in a syntax error or create a generic secret instead of a TLS secret. Option C is wrong because `kubectl create secret generic` creates a generic secret (type `Opaque`), not a TLS secret (type `kubernetes.io/tls`), and the `--from-file` flags would store the files as arbitrary keys rather than the required `tls.crt` and `tls.key` entries. Option D is wrong because `kubectl create secret docker-registry` creates a Docker registry authentication secret (type `kubernetes.io/dockercfg`), which is used for pulling images from private registries, not for storing TLS certificates and keys.

Practice this question →

140

Multi-Selecthard

Which THREE of the following are valid fields in a PodSecurityContext (pod-level securityContext)? (Select 3)

Select 3 answers

A.runAsUser

B.fsGroup

C.readOnlyRootFilesystem

D.capabilities

E.seccompProfile

AnswersA, B, E

Valid at pod level; sets the user for all containers.

Why this answer

Option A is correct because `runAsUser` is a valid field in a PodSecurityContext that sets the user ID (UID) for all containers in the pod, overriding any container-level `securityContext.runAsUser`. This is defined in the Kubernetes API under `PodSecurityContext` and is commonly used to enforce non-root execution.

Exam trap

CNCF often tests the distinction between pod-level and container-level securityContext fields, and the trap here is that candidates confuse `readOnlyRootFilesystem` and `capabilities` as pod-level fields when they are actually only valid at the container level.

Practice this question →

141

MCQmedium

A LimitRange in namespace 'limits' sets default memory request to 256Mi and default memory limit to 512Mi. A pod is created without specifying any resources. What are the pod's effective memory request and limit?

A.request: 512Mi, limit: 256Mi

B.request: 256Mi, limit: 512Mi

C.No request or limit; the pod will be scheduled with best-effort QoS

D.request: 0, limit: unlimited

AnswerB

The LimitRange default values are applied to the pod because no resources were specified.

Why this answer

When a LimitRange exists in a namespace, it automatically applies default resource requests and limits to any pod that does not specify them. In this case, the LimitRange sets the default memory request to 256Mi and the default memory limit to 512Mi, so the pod inherits those values. This ensures the pod has a guaranteed QoS class (Guaranteed) because request equals limit, but only if both are set; here they differ, so the pod will be Burstable.

Exam trap

The trap here is that candidates often forget that a LimitRange applies defaults to pods that omit resource specifications, leading them to incorrectly assume the pod will have no limits or be Best-Effort, when in fact the LimitRange enforces both request and limit.

How to eliminate wrong answers

Option A is wrong because it reverses the values: the default request is 256Mi, not 512Mi, and the default limit is 512Mi, not 256Mi. Option C is wrong because a LimitRange in the namespace overrides the absence of resource specifications; the pod will have both request and limit set, resulting in Burstable QoS, not Best-Effort. Option D is wrong because a LimitRange does not leave resources unlimited; it enforces defaults, so the pod will have a request of 256Mi and a limit of 512Mi, not 0 or unlimited.

Practice this question →

142

Multi-Selecthard

Which THREE of the following are true about ServiceAccount token automounting? (Choose three.)

Select 3 answers

A.The token is mounted at /var/run/secrets/kubernetes.io/serviceaccount/token

B.Automounting can be disabled at the ServiceAccount level by setting automountServiceAccountToken: false.

C.Setting automountServiceAccountToken: false in a Pod spec prevents only that Pod from automounting.

D.The token is automatically refreshed by the kubelet.

E.By default, Kubernetes automounts the default ServiceAccount token into every Pod.

AnswersB, C, E

Correct.

Why this answer

Option B is correct because the `automountServiceAccountToken` field can be set to `false` in the ServiceAccount manifest to prevent the automatic mounting of the token into any Pod that uses that ServiceAccount. This is a declarative way to disable token automounting at the account level, overriding the default behavior where the token is mounted into every Pod.

Exam trap

CNCF often tests the misconception that the token is automatically refreshed by the kubelet, when in fact token rotation is managed by the TokenRequest API and the kube-controller-manager, not the kubelet, and static tokens are not refreshed at all.

Practice this question →

143

Multi-Selecthard

Which THREE of the following are valid fields in a SecurityContext at the container level? (Select three.)

Select 3 answers

A.fsGroup

B.runAsUser

C.readOnlyRootFilesystem

D.capabilities

E.allowPrivilegeEscalation

AnswersC, D, E

readOnlyRootFilesystem is valid at container level.

Why this answer

Option C is correct because `readOnlyRootFilesystem` is a valid field in a container-level SecurityContext that, when set to `true`, mounts the container's root filesystem as read-only, preventing writes to the container's filesystem and enhancing security by limiting the impact of potential exploits.

Exam trap

CNCF often tests the distinction between Pod-level and container-level SecurityContext fields, and the trap here is that `fsGroup` is a Pod-level field, not a container-level one, while `runAsUser` is valid at both levels but is not among the three correct answers, leading candidates to incorrectly select it.

Practice this question →

144

MCQhard

You create a Secret with 'kubectl create secret generic db-secret --from-literal=password=myPass'. Later, you mount it as a volume in a pod. When you exec into the container and cat the file, what will you see?

A.password=myPass

B.bXlQYXNz

C.myPass

D.An error because secrets cannot be mounted as volumes

AnswerC

Kubernetes decodes the Secret data when mounting as volume.

Why this answer

Option C is correct because when you mount a Secret as a volume, Kubernetes automatically decodes the base64-encoded data and presents the file contents as the original plaintext value. In this case, the Secret stores the literal key-value pair `password=myPass`, and when mounted, the file named `password` contains the decoded value `myPass`.

Exam trap

The trap here is that candidates often confuse the base64-encoded representation stored in the Secret manifest with the decoded content presented when mounted as a volume, leading them to pick Option B.

How to eliminate wrong answers

Option A is wrong because the file content is not the raw `--from-literal` string `password=myPass`; Kubernetes separates the key from the value, so the file name is the key (`password`) and the file content is the value (`myPass`). Option B is wrong because `bXlQYXNz` is the base64 encoding of `myPass`, but when mounted as a volume, Kubernetes automatically decodes the data, so the file contains the plaintext `myPass`, not the encoded string. Option D is wrong because Secrets can absolutely be mounted as volumes; this is a standard and common method for exposing secret data to pods.

Practice this question →

145

MCQhard

Given the following partial pod spec: ```yaml securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 ``` Which combination correctly describes the resulting permissions on a mounted volume?

A.Volume owned by user 2000, group 1000; container runs with user 2000 and group 1000

B.Volume owned by user 3000, group 2000; container runs with user 1000 and group 3000

C.Volume owned by user 1000, group 2000; container runs with user 1000 and group 3000

D.Volume owned by user 1000, group 3000; container runs with user 1000 and group 2000

AnswerC

runAsUser sets the container user to 1000; runAsGroup sets the primary group to 3000; fsGroup sets the volume's group ownership to 2000.

Why this answer

Option C is correct because `runAsUser: 1000` sets the container's primary user ID to 1000, `runAsGroup: 3000` sets the primary group ID to 3000, and `fsGroup: 2000` changes the group ownership of any mounted volume to group 2000, while also granting the container's processes supplemental group access to group 2000. The volume's user ownership remains the default (often root or the image's user) unless explicitly changed, but the key point is that the volume is group-owned by 2000 and the container runs with UID 1000 and GID 3000.

Exam trap

The trap here is confusing `runAsGroup` (which sets the container's primary GID) with `fsGroup` (which sets the volume's group ownership and adds a supplemental group), leading candidates to incorrectly assign the volume's group to the container's primary group or vice versa.

How to eliminate wrong answers

Option A is wrong because it incorrectly states the volume is owned by user 2000 and group 1000, but `fsGroup` only affects group ownership, not user ownership, and `runAsUser` sets the container's UID to 1000, not 2000. Option B is wrong because it claims the volume is owned by user 3000 and group 2000, but `runAsUser: 1000` sets the container's UID to 1000, not 3000, and `fsGroup: 2000` sets the volume's group to 2000, not the user. Option D is wrong because it states the volume is owned by user 1000 and group 3000, but `fsGroup: 2000` sets the volume's group to 2000, not 3000, and the container's primary group is 3000, not 2000.

Practice this question →

146

MCQeasy

You have a ConfigMap created from an env file. Which command creates the ConfigMap from the file 'app.env' containing key=value pairs?

A.kubectl create configmap app-config --from-file=app.env

B.kubectl create configmap app-config --env-file=app.env

C.kubectl create configmap app-config --from-literal=app.env

D.kubectl create configmap app-config --from-env-file=app.env

AnswerD

--from-env-file correctly reads env file and creates a ConfigMap with each line as key=value.

Why this answer

Option D is correct because `--from-env-file` is the exact flag used to create a ConfigMap from a file containing key=value pairs in env-file format (e.g., `app.env`). This flag parses each line as a key-value pair and stores them as individual data entries in the ConfigMap, unlike `--from-file` which stores the entire file content under a single key.

Exam trap

CNCF often tests the subtle difference between `--from-file` and `--from-env-file`, where candidates mistakenly choose `--from-file` because they think it handles env files generically, but it does not parse key-value pairs.

How to eliminate wrong answers

Option A is wrong because `--from-file=app.env` creates a ConfigMap where the entire file content is stored as a single entry under the key `app.env`, not as separate key-value pairs. Option B is wrong because `--env-file` is not a valid flag for `kubectl create configmap`; it is used with `kubectl run` to inject environment variables from a file into a pod. Option C is wrong because `--from-literal` is used to specify key-value pairs directly on the command line (e.g., `key=value`), not to reference a file, and passing `app.env` as a literal would treat it as a literal string, not a file path.

Practice this question →

147

MCQmedium

A pod runs as user ID 1000. The container image includes a binary that expects to run as root. Which SecurityContext setting can allow the binary to run with root-like privileges while still running the container as non-root?

A.Add the SYS_ADMIN capability under securityContext.capabilities.add

B.Set securityContext.privileged: true

C.Set securityContext.runAsUser: 0

D.Set securityContext.allowPrivilegeEscalation: true

AnswerC

Setting runAsUser to 0 makes the container run as root, fulfilling the binary's requirement.

Why this answer

Option C is correct because setting `securityContext.runAsUser: 0` overrides the pod's user ID (1000) for this specific container, making it run as root (UID 0). This allows the binary that expects root privileges to execute without changing the pod-level security context or granting unnecessary capabilities.

Exam trap

The trap here is that candidates confuse `runAsUser: 0` with a security risk, when in fact it is a precise way to run a specific container as root without elevating the entire pod or using privileged mode.

How to eliminate wrong answers

Option A is wrong because adding the SYS_ADMIN capability grants broad administrative privileges but does not change the user ID; the binary would still run as UID 1000 and fail if it requires root. Option B is wrong because setting `privileged: true` gives the container almost all host capabilities and disables most security restrictions, which is excessive and violates the requirement to run as non-root. Option D is wrong because `allowPrivilegeEscalation: true` only permits processes to gain more privileges than their parent (e.g., via setuid binaries), but it does not change the initial user ID; the binary still runs as UID 1000 unless a setuid root binary is present.

Practice this question →

148

Multi-Selecthard

Which THREE of the following are capabilities that can be added to a container's securityContext?

Select 3 answers

A.RuntimeDefault

B.CAP_SYS_ADMIN

C.NET_ADMIN

D.CHOWN

E.SYS_TIME

AnswersC, D, E

Allows various network-related operations (e.g., interface configuration).

Why this answer

Option C (NET_ADMIN) is correct because it is a Linux capability that can be added to a container's securityContext under the `capabilities.add` field. This capability allows the container to perform network administration tasks such as interface configuration, firewall management, and routing table manipulation, which are common in network-focused pods.

Exam trap

The trap here is that candidates often confuse seccomp profiles (like RuntimeDefault) with Linux capabilities, or they assume that all capability names must be prefixed with 'CAP_' in the YAML (e.g., writing 'CAP_NET_ADMIN' instead of 'NET_ADMIN'), leading them to select incorrect options.

Practice this question →

149

MCQhard

You need to create a Role and RoleBinding to allow a ServiceAccount 'monitor' in namespace 'app' to list pods in that namespace. Which YAML snippet correctly achieves this?

A.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader namespace: app rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: monitor-binding namespace: app roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: pod-reader subjects: - kind: ServiceAccount name: monitor namespace: app

B.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader namespace: app rules: - apiGroups: [""] resources: ["pods"] verbs: ["read"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: monitor-binding namespace: app roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: pod-reader subjects: - kind: ServiceAccount name: monitor

C.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: monitor-binding roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: pod-reader subjects: - kind: ServiceAccount name: monitor namespace: app

D.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader namespace: app rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: monitor-binding namespace: app roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: pod-reader subjects: - kind: ServiceAccount name: monitor namespace: app

AnswerA, D

A Role in namespace 'app' grants permissions only in that namespace. The RoleBinding binds the Role to the ServiceAccount 'monitor' in the same namespace.

Why this answer

Option A is correct because it defines a Role in the 'app' namespace with rules allowing 'get' and 'list' verbs on 'pods', and binds that Role to the 'monitor' ServiceAccount using a RoleBinding in the same namespace. This grants the ServiceAccount the exact permissions needed to list pods within the namespace, following the principle of least privilege.

Exam trap

The trap here is that candidates may confuse 'read' with the valid verbs 'get' and 'list', or mistakenly use a ClusterRole/ClusterRoleBinding when a namespace-scoped Role/RoleBinding is required, leading to overly broad permissions.

How to eliminate wrong answers

Option B is wrong because it uses the verb 'read' instead of the valid Kubernetes verbs 'get' and 'list'; Kubernetes RBAC does not recognize 'read' as a verb, so the Role would grant no permissions. Option C is wrong because it uses a ClusterRole and ClusterRoleBinding, which would grant pod list permissions across all namespaces, violating the requirement to restrict access to only the 'app' namespace; the question explicitly requires namespace-scoped access.

Practice this question →

150

MCQhard

You want to restrict a Pod to only run with a seccomp profile of 'RuntimeDefault'. Which SecurityContext field should you set?

A.appArmorProfile

B.capabilities

C.seLinuxOptions

D.seccompProfile

AnswerD

Correct field to set the seccomp profile. Set type: RuntimeDefault.

Why this answer

The `seccompProfile` field in a Pod's SecurityContext allows you to specify a seccomp profile to restrict system calls. Setting it to `RuntimeDefault` applies the container runtime's default seccomp profile, which blocks a set of dangerous syscalls while allowing normal operation. This is the correct field to enforce a seccomp profile of 'RuntimeDefault'.

Exam trap

The trap here is that candidates confuse seccomp with other security mechanisms like AppArmor or SELinux, or think that `capabilities` can restrict syscalls, when in fact seccomp is the only field that directly controls syscall filtering.

How to eliminate wrong answers

Option A is wrong because `appArmorProfile` is used to set AppArmor profiles, not seccomp profiles; AppArmor is a separate Linux Security Module (LSM) that controls file access and capabilities. Option B is wrong because `capabilities` adds or drops Linux capabilities (e.g., CAP_NET_ADMIN), which are privileges, not syscall filters. Option C is wrong because `seLinuxOptions` configures SELinux labels for process and file security contexts, which is another LSM unrelated to seccomp.

Practice this question →