Courseiva

CCNA Application Environment, Configuration and Security Questions

75 of 233 questions · Page 1/4 · Application Environment, Configuration and Security · Answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

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

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

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

Why this answer

Option A is correct because `kubectl create configmap app-config --from-file=config.properties` directly reads the file `config.properties` and creates a ConfigMap named `app-config` with each key-value pair from the file. The `--from-file` flag is the standard way to import a single file's contents as a ConfigMap, where the filename becomes the key and the file content becomes the value.

Exam trap

The trap here is confusing `--from-file` with `--from-env-file`, as candidates often assume any file with key-value pairs will be parsed automatically, but `--from-file` treats the entire file as a single value, while `--from-env-file` parses each line as a separate key-value pair.

How to eliminate wrong answers

Option B is wrong because `--from-env-file` is used to import a file in the format of environment variables (e.g., `KEY=VALUE` lines) and creates a ConfigMap with each line as a separate key-value pair, not a single key from the filename. 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. Option D is wrong because `kubectl apply` is used to apply a configuration from a file or stdin, not to create a ConfigMap from a properties file; the correct command for creation is `kubectl create configmap`.

Practice this question →
2
MCQhard

A security requirement states: 'The container must drop all capabilities and add only NET_BIND_SERVICE'. Which YAML snippet correctly implements this in the securityContext?

A.securityContext: capabilities: drop: ["NET_BIND_SERVICE"] add: [ALL]
B.securityContext: capabilities: drop: [ALL] add: ["NET_BIND_SERVICE"]
C.securityContext: capabilities: add: [ALL] drop: ["NET_BIND_SERVICE"]
D.securityContext: capabilities: "drop ALL; add NET_BIND_SERVICE"
AnswerB

drop: [ALL] removes all capabilities; add: ["NET_BIND_SERVICE"] adds the required one.

Why this answer

Option B is correct because it first drops all capabilities with `drop: [ALL]` and then explicitly adds only `NET_BIND_SERVICE` via `add: ["NET_BIND_SERVICE"]`. This matches the security requirement exactly: the container starts with no capabilities and gains only the one needed to bind to privileged ports (<1024). In Kubernetes, the order of `drop` and `add` matters — dropping ALL first ensures a clean slate, then adding the specific capability.

Exam trap

The trap here is that candidates often confuse the order of `add` and `drop`, or mistakenly think that dropping `ALL` includes the capability they want to add, leading them to pick options that either drop the needed capability or add too many.

How to eliminate wrong answers

Option A is wrong because it drops `NET_BIND_SERVICE` (the capability that should be added) and adds `ALL` (all capabilities), which violates the requirement to drop all capabilities. Option C is wrong because it adds `ALL` first and then drops `NET_BIND_SERVICE`, resulting in the container having all capabilities except `NET_BIND_SERVICE` — the opposite of what is required. Option D is wrong because it uses an invalid string syntax; Kubernetes `capabilities` must be a structured object with `add` and `drop` lists, not a semicolon-delimited string.

Practice this question →
3
MCQmedium

A container needs to run with the NET_ADMIN capability. Which securityContext field should be used?

A.capabilities: drop: ["ALL"]
B.capabilities: add: ["NET_ADMIN"]
C.runAsUser: 0
D.readOnlyRootFilesystem: true
AnswerB

This adds the NET_ADMIN capability to the container.

Why this answer

Option B is correct because the `capabilities.add` field in a container's `securityContext` is specifically designed to grant Linux capabilities like `NET_ADMIN` to a container. This allows the container to perform network administration operations (e.g., configuring iptables, changing interface settings) without running as root or giving full privileged access.

Exam trap

The trap here is that candidates often confuse `capabilities.add` with `capabilities.drop` or assume that running as root (`runAsUser: 0`) is the only way to gain network admin privileges, missing the precise capability-based approach that CKAD expects.

How to eliminate wrong answers

Option A is wrong because `capabilities.drop: ["ALL"]` removes all capabilities, which would prevent the container from using `NET_ADMIN`; it's the opposite of what is needed. Option C is wrong because `runAsUser: 0` runs the container as root, which is an overly broad and insecure approach that grants all capabilities, not just `NET_ADMIN`, and is not the recommended way to add a specific capability. Option D is wrong because `readOnlyRootFilesystem: true` only makes the container's root filesystem read-only for security hardening and has no effect on Linux capabilities or network administration permissions.

Practice this question →
4
MCQhard

You create a ServiceAccount 'my-sa' with automountServiceAccountToken: false. A pod that references this ServiceAccount also sets automountServiceAccountToken: true in its spec. Will the service account token be mounted?

A.Yes, because the pod spec setting takes precedence.
B.No, because the ServiceAccount has automountServiceAccountToken: false, which is a hard block.
C.It depends on the namespace default settings.
D.No, because the ServiceAccount setting overrides the pod setting.
AnswerA

Pod-level automountServiceAccountToken overrides the ServiceAccount's setting.

Why this answer

The pod spec's `automountServiceAccountToken: true` takes precedence over the ServiceAccount's `automountServiceAccountToken: false`. Kubernetes merges the ServiceAccount and pod-level settings, with the pod-level setting overriding the ServiceAccount's setting. Therefore, the token will be mounted into the pod.

Exam trap

CNCF often tests the precedence rule between ServiceAccount and pod-level settings, expecting candidates to incorrectly assume the ServiceAccount setting is authoritative or that the most restrictive setting wins.

How to eliminate wrong answers

Option B is wrong because `automountServiceAccountToken: false` on the ServiceAccount is not a hard block; it is a default that can be overridden by the pod spec. Option C is wrong because namespace default settings (e.g., via an admission controller or defaulting webhook) do not override explicit pod-level settings; the pod spec's explicit value takes precedence. Option D is wrong because the pod-level setting overrides the ServiceAccount setting, not the other way around.

Practice this question →
5
MCQmedium

A pod is running with the following SecurityContext: securityContext: runAsUser: 1000 runAsGroup: 2000 fsGroup: 3000 What UID and GID does the process inside the container use?

A.UID 1000, GID 3000
B.UID 1000, GID 2000
C.UID 0, GID 2000
D.UID 3000, GID 2000
AnswerB

runAsUser sets UID, runAsGroup sets GID. Both apply to the container process.

Why this answer

The `runAsUser` and `runAsGroup` fields in the Pod's SecurityContext directly set the UID and GID for the container's main process. Here, `runAsUser: 1000` sets the process UID to 1000, and `runAsGroup: 2000` sets the process GID to 2000. The `fsGroup: 3000` field only applies to the group ownership of mounted volumes, not to the process's primary GID.

Exam trap

The trap here is that candidates confuse `fsGroup` with the process's primary GID, thinking it overrides `runAsGroup`, when in fact `fsGroup` only affects volume group ownership and does not change the process's GID.

How to eliminate wrong answers

Option A is wrong because it incorrectly assumes `fsGroup` replaces the process GID; `fsGroup` only affects volume ownership, not the process's primary GID. Option C is wrong because it assumes the process runs as root (UID 0), but `runAsUser: 1000` explicitly overrides that. Option D is wrong because it swaps the UID and `fsGroup` values, misunderstanding that `runAsUser` sets the UID, not `fsGroup`.

Practice this question →
6
Matchingmedium

Match each Kubernetes probe to its check behavior.

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

Concepts
Matches

Runs a command inside the container; success if exit 0

Performs an HTTP GET request; success if 2xx-3xx

Attempts to open a TCP socket; success if connection established

Performs a gRPC health check (alpha)

Indicates whether the application has started successfully

Why these pairings

Probes are used for health checking and readiness.

Practice this question →
7
MCQmedium

A pod uses a ServiceAccount 'my-sa' with a RoleBinding that grants get and list on pods. The pod makes an API call to list pods in its own namespace. Which RBAC resource is necessary?

A.A Role with the appropriate rules
B.A ClusterRoleBinding that binds the ClusterRole to the ServiceAccount
C.A RoleBinding that binds the Role to the ServiceAccount
D.A ClusterRole with the same rules
AnswerC

A RoleBinding is required to grant the Role's permissions to the ServiceAccount.

Why this answer

Option C is correct because the pod uses a ServiceAccount 'my-sa' and the API call is to list pods in its own namespace. A RoleBinding binds a Role (which contains the rules) to a ServiceAccount within a specific namespace, granting the permissions only in that namespace. Since the operation is namespace-scoped and the Role already has the necessary get and list rules, a RoleBinding is the minimal and correct RBAC resource to associate the Role with the ServiceAccount.

Exam trap

CNCF often tests the distinction between RoleBinding and ClusterRoleBinding, trapping candidates who think a ClusterRoleBinding is required when the operation is namespace-scoped, or who forget that a Role alone is not a binding.

How to eliminate wrong answers

Option A is wrong because a Role alone defines the rules but does not bind them to any subject; without a RoleBinding, the ServiceAccount has no permissions. Option B is wrong because a ClusterRoleBinding grants permissions cluster-wide, which is excessive for a namespace-scoped operation and would bind a ClusterRole (not a Role) to the ServiceAccount, violating the principle of least privilege. Option D is wrong because a ClusterRole is a cluster-scoped resource that can be used across namespaces, but it is unnecessary here since the operation is confined to a single namespace; a Role is sufficient and more appropriate.

Practice this question →
8
MCQmedium

A pod's container needs to run as non-root user with UID 1000 and ensure its filesystem is read-only. Which SecurityContext settings achieve this?

A.spec: securityContext: runAsUser: 1000 runAsNonRoot: true containers: - name: app securityContext: readOnlyRootFilesystem: true
B.securityContext: runAsNonRoot: true runAsRoot: false readOnlyRootFilesystem: true
C.securityContext: runAsGroup: 1000 readOnlyRootFilesystem: true
D.securityContext: runAsNonRoot: true runAsUser: 1000 readOnlyRootFilesystem: true
AnswerD

This correctly sets non-root enforcement, UID, and read-only root filesystem.

Why this answer

Option D is correct because it sets both `runAsNonRoot: true` (to enforce non-root execution) and `runAsUser: 1000` (to specify the exact UID) at the pod-level `securityContext`, while `readOnlyRootFilesystem: true` is set at the container-level `securityContext` to make the container's filesystem read-only. This combination satisfies the requirement of running as a non-root user with UID 1000 and ensuring a read-only root filesystem.

Exam trap

The trap here is that candidates often confuse `runAsGroup` with `runAsUser` or forget that `runAsNonRoot` must be explicitly set to enforce non-root execution, assuming that setting a UID alone is sufficient.

How to eliminate wrong answers

Option A is wrong because it places `readOnlyRootFilesystem: true` in the container-level `securityContext`, which is valid, but the pod-level `securityContext` is missing `runAsNonRoot: true` (only `runAsUser: 1000` is set), so it does not explicitly enforce non-root execution. Option B is wrong because `runAsRoot: false` is not a valid field in Kubernetes SecurityContext; the correct field is `runAsNonRoot: true`, and the option also omits `runAsUser: 1000`. Option C is wrong because it sets `runAsGroup: 1000` instead of `runAsUser: 1000`, which specifies the group ID, not the user ID, and it lacks `runAsNonRoot: true` to enforce non-root execution.

Practice this question →
9
MCQeasy

A developer needs to create a Kubernetes Secret for Docker registry authentication. The registry URL is 'myregistry.io', username 'user', password 'pass', email 'user@example.com'. Which command creates this Secret?

A.kubectl create secret tls regcred --cert=cert --key=key
B.kubectl create secret generic regcred --from-literal=username=user --from-literal=password=pass
C.kubectl create secret registry regcred --server=myregistry.io --username=user --password=pass
D.kubectl create secret docker-registry regcred --docker-server=myregistry.io --docker-username=user --docker-password=pass --docker-email=user@example.com
AnswerD

This creates a kubernetes.io/dockerconfigjson Secret with the correct credentials.

Why this answer

Option D is correct because `kubectl create secret docker-registry` is the dedicated command for creating a Docker registry authentication secret, which automatically encodes the provided credentials into a `.dockerconfigjson` format. This secret type is specifically designed for pulling images from private registries, and the flags `--docker-server`, `--docker-username`, `--docker-password`, and `--docker-email` match the required fields for registry authentication.

Exam trap

The trap here is that candidates may confuse the generic `kubectl create secret generic` command with the specialized `docker-registry` subcommand, or they may misremember the exact subcommand name as `registry` instead of `docker-registry`, leading them to pick option B or C.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret tls` creates a TLS secret for storing certificates and keys, not Docker registry credentials. Option B is wrong because `kubectl create secret generic` creates a generic Opaque secret with arbitrary key-value pairs, but it does not produce the `.dockerconfigjson` format required by Kubernetes for image pull secrets, and it lacks the registry server and email fields. Option C is wrong because `kubectl create secret registry` is not a valid kubectl command; the correct subcommand is `docker-registry`, not `registry`.

Practice this question →
10
MCQeasy

Which command creates an Opaque Secret named 'my-secret' with key 'password' and value 'p@ssw0rd'?

A.kubectl create secret tls my-secret --cert=cert.pem --key=key.pem
B.kubectl create secret generic my-secret --from-literal=password
C.kubectl create secret generic my-secret --from-literal=p@ssw0rd=password
D.kubectl create secret generic my-secret --from-literal=password=p@ssw0rd
AnswerD

Correct syntax: generic secret with literal key=value.

Why this answer

Option D is correct because `kubectl create secret generic` creates an Opaque secret, and the `--from-literal=key=value` syntax correctly assigns the literal value 'p@ssw0rd' to the key 'password'. This produces a secret with the specified key-value pair.

Exam trap

The trap here is that candidates may confuse the order of key and value in the `--from-literal` syntax, or mistakenly use a different secret type like TLS or docker-registry, which have specific purposes and required flags.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret tls` creates a TLS secret (type kubernetes.io/tls), not an Opaque secret, and requires certificate and key files. Option B is wrong because `--from-literal=password` lacks the `=value` part, so it would fail with an error about invalid literal format. Option C is wrong because it reverses the key and value, setting key 'p@ssw0rd' with value 'password', which does not match the requirement.

Practice this question →
11
MCQmedium

Which annotation is used to enforce Pod Security Admission at the 'restricted' level on a namespace?

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

Correct. This annotation enforces the restricted Pod Security Standard.

Why this answer

Option A is correct because the `pod-security.kubernetes.io/enforce` annotation enforces Pod Security Standards (PSS) at the namespace level, and setting it to `restricted` blocks any pod that violates the most stringent set of security controls (e.g., running as root, privileged containers). This is the only annotation that actively prevents non-compliant pods from being created, rather than just warning or logging violations.

Exam trap

The trap here is that candidates confuse the `enforce` mode (which blocks non-compliant pods) with the `warn` or `audit` modes (which only notify or log), and may also mistakenly choose `baseline` thinking it is the highest security level, when in fact `restricted` is the most stringent.

How to eliminate wrong answers

Option B is wrong because `pod-security.kubernetes.io/warn: restricted` only generates a warning message when a pod violates the restricted profile, but does not block the pod from being created. Option C is wrong because `pod-security.kubernetes.io/enforce: baseline` enforces the baseline level, which is less restrictive than restricted (e.g., it allows some privileged capabilities that restricted forbids). Option D is wrong because `pod-security.kubernetes.io/audit: restricted` only logs violations to the audit log without preventing pod creation or issuing warnings.

Practice this question →
12
Multi-Selectmedium

Which two statements about ConfigMaps and Secrets are correct? (Select TWO.)

Select 2 answers
A.Secrets store data in base64-encoded form, while ConfigMaps store plaintext
B.Both ConfigMaps and Secrets can be consumed as environment variables or mounted as volumes
C.ConfigMaps are immutable and cannot be updated after creation
D.ConfigMaps are suitable for storing sensitive data like passwords
E.Secrets are encrypted at rest by default in Kubernetes
AnswersA, B

Secrets store data as base64-encoded strings, ConfigMaps store plaintext.

Why this answer

Option A is correct because Secrets store data as base64-encoded strings, which is not encryption but a simple encoding that obscures the data. ConfigMaps store data in plaintext (UTF-8) without any encoding. This distinction is fundamental: base64 encoding is reversible and provides no security, while plaintext is human-readable.

Exam trap

CNCF often tests the misconception that base64 encoding is a form of encryption, leading candidates to think Secrets are secure by default, or that ConfigMaps are immutable — the trap is assuming default immutability or confusing encoding with encryption.

Practice this question →
13
MCQmedium

A Pod is in 'CrashLoopBackOff' state. 'kubectl logs mypod' shows: 'Error: listen tcp :8080: bind: address already in use'. What is the most likely cause?

A.The pod's resource limits are too low
B.The container's application is attempting to use a port that is already occupied
C.The pod's ServiceAccount token is not mounted
D.The pod is using a readOnlyRootFilesystem
AnswerB

The error indicates port conflict.

Why this answer

The error 'listen tcp :8080: bind: address already in use' indicates that the container's application is trying to bind to port 8080, but that port is already occupied by another process within the same network namespace (typically the same Pod or container). This is a classic port conflict, not a resource or permission issue, making option B correct.

Exam trap

The trap here is that candidates may confuse 'CrashLoopBackOff' with resource exhaustion (option A) or filesystem issues (option D), but the specific error message 'bind: address already in use' directly points to a port conflict, not resource limits or permissions.

How to eliminate wrong answers

Option A is wrong because resource limits (CPU/memory) cause OOMKilled or CPU throttling, not a 'bind: address already in use' error. Option C is wrong because a missing ServiceAccount token would cause authentication failures (e.g., 403 Forbidden) when accessing the Kubernetes API, not a port binding error. Option D is wrong because readOnlyRootFilesystem prevents writing to the container's filesystem, leading to errors like 'read-only file system', not port binding conflicts.

Practice this question →
14
MCQmedium

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

A.The pod cannot use any service account.
B.The pod will use a different service account.
C.The pod will be unable to start.
D.The pod will not have the service account token mounted.
AnswerD

Correct. The automatic mounting of the token is disabled.

Why this answer

Setting `automountServiceAccountToken: false` in a Pod spec prevents the automatic injection and mounting of the service account token into the Pod's containers. By default, Kubernetes mounts a token at `/var/run/secrets/kubernetes.io/serviceaccount/token` for API authentication; disabling this option means the token is not mounted, but the Pod can still use a service account if the token is explicitly mounted via a volume or if the Pod does not need API access.

Exam trap

The trap here is that candidates confuse 'not mounting the token' with 'not using a service account,' leading them to think the Pod cannot use any service account (Option A), when in fact the service account is still assigned and can be used for non-token-based purposes like RBAC or PodSecurityPolicy.

How to eliminate wrong answers

Option A is wrong because the Pod can still use a service account; it simply does not have the token automatically mounted, but the service account itself is still assigned and can be used for authorization decisions (e.g., RBAC). Option B is wrong because this setting does not change which service account is used; the Pod still uses the default service account (or one specified via `serviceAccountName`), only the automatic token mount is suppressed. Option C is wrong because the Pod will start normally; the absence of an automatically mounted token does not prevent container runtime from launching the Pod, as the token is not required for Pod startup.

Practice this question →
15
MCQmedium

An administrator needs to create a ConfigMap named 'app-config' from a file called 'config.properties'. Which kubectl command accomplishes this?

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

This creates a ConfigMap with a data item named 'config.properties' containing the file contents.

Why this answer

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

Exam trap

The trap here is confusing `--from-file` (which stores the file content as a single value) with `--from-env-file` (which parses key-value pairs) or `--from-literal` (which expects inline key=value syntax), leading candidates to choose options that either misinterpret the file format or incorrectly specify the key.

How to eliminate wrong answers

Option A is wrong because `--from-literal` expects a key=value pair directly in the command, not a filename; it would treat 'config.properties' as a literal string, not a file. Option C is wrong because `--from-env-file` is used to import a file containing key=value pairs (one per line) to create multiple entries, not to store the entire file content as a single value. Option D is wrong because `--from-file=key1=config.properties` would create a ConfigMap with the key 'key1' and the content of the file, but the requirement is to use the filename as the key, not a custom key.

Practice this question →
16
MCQmedium

A developer wants to ensure that a container runs as a non-root user and the filesystem is read-only except for a tmpfs volume. Which fields should be set in the container's securityContext?

A.runAsUser: 1000 and readOnlyRootFilesystem: true
B.runAsNonRoot: true and privileged: false
C.runAsNonRoot: true and readOnlyRootFilesystem: true
D.allowPrivilegeEscalation: false and readOnlyRootFilesystem: true
AnswerC

runAsNonRoot prevents running as root, and readOnlyRootFilesystem makes the root filesystem read-only.

Why this answer

Option C is correct because `runAsNonRoot: true` enforces that the container cannot run as the root user (UID 0), and `readOnlyRootFilesystem: true` makes the container's filesystem read-only except for volumes explicitly mounted as writable, such as a tmpfs volume. Together, these fields satisfy the requirement of a non-root container with a read-only filesystem except for a tmpfs mount.

Exam trap

CNCF often tests the distinction between `runAsUser` (which sets a UID but does not enforce non-root) and `runAsNonRoot` (which enforces non-root but does not set a UID), leading candidates to pick Option A when they only need to ensure non-root, not a specific UID.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 1000` sets a specific UID but does not enforce that the container runs as a non-root user (the image could still run as root if the UID is not respected), and it lacks `runAsNonRoot: true` which is required to guarantee non-root execution. Option B is wrong because `privileged: false` is the default and does not enforce non-root execution, and `runAsNonRoot: true` alone does not make the filesystem read-only. Option D is wrong because `allowPrivilegeEscalation: false` only prevents privilege escalation (e.g., via setuid binaries) but does not ensure the container runs as a non-root user, and while `readOnlyRootFilesystem: true` is correct, the missing `runAsNonRoot: true` fails the non-root requirement.

Practice this question →
17
MCQmedium

A pod has a container with 'readOnlyRootFilesystem: true' in its securityContext. The container writes to /tmp. What is the expected outcome?

A.The pod runs normally; Kubernetes automatically makes /tmp writable.
B.The container crashes because it tries to write to /tmp but the filesystem is read-only.
C.The pod is rejected by the admission controller because readOnlyRootFilesystem conflicts with writing to /tmp.
D.The container writes successfully because readOnlyRootFilesystem only applies to the container image layers.
AnswerB

The application will fail when trying to write to /tmp because the root filesystem is read-only.

Why this answer

When `readOnlyRootFilesystem: true` is set in the container's securityContext, the root filesystem is mounted as read-only. The container writes to `/tmp`, which is part of the root filesystem by default, so the write fails and the container crashes (e.g., with an error like 'Read-only file system'). Kubernetes does not automatically make `/tmp` writable unless an explicit emptyDir volume is mounted at that path.

Exam trap

The trap here is that candidates assume `/tmp` is always writable or that `readOnlyRootFilesystem` only affects the image layers, but in reality it makes the entire root filesystem read-only, causing runtime failures unless a writable volume is explicitly mounted at the write location.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not automatically make `/tmp` writable; the root filesystem remains read-only as configured. Option C is wrong because the pod is not rejected by an admission controller; the securityContext is valid, and the failure occurs at runtime when the container attempts the write. Option D is wrong because `readOnlyRootFilesystem` applies to the entire root filesystem, including `/tmp`, not just the container image layers; the writable layer is also made read-only.

Practice this question →
18
MCQmedium

A PodSecurityPolicy (PSP) has been replaced by Pod Security Admission. Which of the following commands applies a baseline pod security standard to the namespace 'dev'?

A.kubectl label ns dev pod-security.kubernetes.io/warn=baseline
B.kubectl label ns dev pod-security.kubernetes.io/enforce=privileged
C.kubectl label ns dev pod-security.kubernetes.io/audit=baseline
D.kubectl label ns dev pod-security.kubernetes.io/enforce=baseline
AnswerD

Enforces the baseline pod security standard.

Why this answer

Option D is correct because Pod Security Admission uses labels on namespaces to enforce pod security standards. The label `pod-security.kubernetes.io/enforce=baseline` applies the baseline standard, which prevents known privilege escalations while allowing the default minimal pod configuration. This replaces the deprecated PodSecurityPolicy (PSP) with a built-in admission controller.

Exam trap

The trap here is that candidates confuse the three modes (enforce, warn, audit) and pick a mode that does not actually apply the standard, or they mistakenly select `privileged` thinking it is the baseline standard.

How to eliminate wrong answers

Option A is wrong because the `warn` mode only generates a warning for non-compliant pods but does not enforce the standard; it is not the correct mode for applying a standard. Option B is wrong because it sets the enforce mode to `privileged`, which allows all capabilities and is the least restrictive standard, not the baseline standard. Option C is wrong because the `audit` mode logs violations but does not block or enforce the standard; it is used for auditing purposes only.

Practice this question →
19
MCQeasy

What is the effect of setting 'readOnlyRootFilesystem: true' in a container's securityContext?

A.The container can only read from the root filesystem, but can still write to /tmp.
B.The container's root filesystem is mounted as read-only.
C.The container cannot write to any mounted volumes.
D.The container will be killed if it attempts to write to the root filesystem.
AnswerB

Correct. The container will be unable to write to its own filesystem.

Why this answer

Setting `readOnlyRootFilesystem: true` in a container's securityContext mounts the container's root filesystem as read-only. This prevents any process inside the container from writing to the root filesystem, enhancing security by reducing the attack surface and ensuring immutability of the container image layers. It does not affect writable volumes mounted at other paths, such as emptyDir or hostPath volumes.

Exam trap

The trap here is that candidates often confuse 'readOnlyRootFilesystem' with making all volumes read-only, or assume the container is terminated on write attempts, when in reality only the root filesystem is affected and writes simply fail silently.

How to eliminate wrong answers

Option A is wrong because while the root filesystem is read-only, the container cannot write to /tmp unless /tmp is a separate writable volume mount; the root filesystem includes /tmp by default, so writing there would also be blocked. Option C is wrong because mounted volumes (e.g., emptyDir, hostPath, PVC) are not part of the root filesystem and can still be written to unless they are explicitly mounted read-only. Option D is wrong because the container is not killed on a write attempt; instead, the write operation fails with an error (e.g., 'Read-only file system'), and the container continues running.

Practice this question →
20
MCQeasy

A pod needs to run as a non-root user with UID 1000. Which SecurityContext field should be set?

A.runAsUser: 1000
B.runAsGroup: 1000
C.runAsNonRoot: true
D.fsGroup: 1000
AnswerA

This sets the user ID to 1000 for all processes in the container.

Why this answer

The `runAsUser` field in the PodSecurityContext or container SecurityContext sets the user ID (UID) under which the container's main process runs. Setting `runAsUser: 1000` ensures the container runs as a non-root user with UID 1000, meeting the requirement. This field directly controls the effective UID of the process, overriding the default root (UID 0).

Exam trap

The trap here is that candidates often confuse `runAsUser` with `runAsGroup` or `fsGroup`, thinking group or filesystem settings control the process user identity, when only `runAsUser` directly sets the UID of the running process.

How to eliminate wrong answers

Option B is wrong because `runAsGroup: 1000` sets the primary group ID (GID) for the container process, not the user ID; it does not change the user from root. Option C is wrong because `runAsNonRoot: true` only enforces that the container cannot run as root (UID 0), but it does not specify which non-root UID to use; the container would fail if no explicit UID is set or if the image's default user is root. Option D is wrong because `fsGroup: 1000` applies to the group ownership of mounted volumes, not the user identity of the running process; it is used for volume access control, not for running as a non-root user.

Practice this question →
21
MCQeasy

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

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

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

Why this answer

Option C is correct because the `kubectl create configmap` command with the `--from-file` flag directly creates a ConfigMap from the contents of a specified file, using the filename as the key and the file content as the value. This is the standard method for creating a ConfigMap from a single file like 'config.properties'.

Exam trap

The trap here is that candidates often confuse `--from-file` (which imports a file as a single data entry) with `--from-env-file` (which parses a file as multiple key-value pairs), leading them to choose Option A incorrectly.

How to eliminate wrong answers

Option A is wrong because `--from-env-file` is used to create a ConfigMap from a file that contains key=value pairs (one per line), treating each line as a separate environment variable, not as a single file with arbitrary content. Option B 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. Option D is wrong because `kubectl apply -f` is used to apply a YAML or JSON manifest to create or update resources, and 'config.properties' is not a valid Kubernetes manifest file.

Practice this question →
22
MCQeasy

A pod is running with the default service account. An administrator wants to prevent the pod from automatically mounting the service account token. Which field in the pod spec accomplishes this?

A.serviceAccountName: ""
B.automountServiceAccountToken: false
C.serviceAccountToken: none
D.securityContext.readOnlyRootFilesystem: true
AnswerB

This field in the pod spec prevents automatic mounting of the service account token.

Why this answer

Option B is correct because setting `automountServiceAccountToken: false` in the pod spec explicitly prevents the automatic mounting of the service account token into the pod. By default, Kubernetes mounts a projected service account token into every pod at `/var/run/secrets/kubernetes.io/serviceaccount`; this field overrides that default behavior at the pod level.

Exam trap

The trap here is that candidates often confuse `automountServiceAccountToken` with `serviceAccountName` or assume that setting an empty service account name removes the token, but only the explicit boolean field controls the mounting behavior.

How to eliminate wrong answers

Option A is wrong because setting `serviceAccountName: ""` does not prevent token mounting; it simply assigns the pod to the default service account in the namespace, which still results in automatic token mounting. Option C is wrong because `serviceAccountToken: none` is not a valid field in the pod spec; Kubernetes does not recognize this field. Option D is wrong because `securityContext.readOnlyRootFilesystem: true` only makes the container's root filesystem read-only, which does not prevent the service account token from being mounted (the token is still mounted and accessible, just on a read-only filesystem).

Practice this question →
23
MCQmedium

A developer wants to use a ConfigMap named 'app-config' to set environment variables for a pod. The ConfigMap has keys 'DEBUG' and 'DATABASE_URL'. Which annotation should be added to the pod spec to inject all keys from the ConfigMap as environment variables?

A.env: - name: DEBUG valueFrom: configMapKeyRef: name: app-config key: DEBUG
B.envFrom: - configMapRef: name: app-config
C.envFrom: - secretRef: name: app-config
D.env: - configMapRef: name: app-config
AnswerB

This injects all keys from the ConfigMap as environment variables.

Why this answer

Option B is correct because the `envFrom` field in a Pod spec allows injecting all key-value pairs from a ConfigMap as environment variables into the container. By specifying `configMapRef` with the ConfigMap name, every key in the ConfigMap becomes an environment variable, which matches the requirement to inject all keys without listing them individually.

Exam trap

CNCF often tests the distinction between `env` (for individual key injection) and `envFrom` (for bulk injection), and the trap here is that candidates confuse `envFrom` with `env` syntax or mistakenly use `secretRef` for ConfigMaps, overlooking the specific resource type required.

How to eliminate wrong answers

Option A is wrong because it uses `env` with individual `configMapKeyRef` entries, which requires manually listing each key (DEBUG and DATABASE_URL) rather than injecting all keys automatically. Option C is wrong because it uses `secretRef` instead of `configMapRef`, which is designed for Secrets, not ConfigMaps, and would fail to reference the ConfigMap 'app-config'. Option D is wrong because `env` does not support a `configMapRef` field; `configMapRef` is only valid under `envFrom`, and using it under `env` is syntactically invalid in Kubernetes.

Practice this question →
24
MCQhard

You need to create a TLS secret for an ingress with certificate and key. Which command correctly creates the secret?

A.kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key
B.kubectl create secret docker-registry tls-secret --docker-cert=tls.crt --docker-key=tls.key
C.kubectl create secret generic tls-secret --from-file=tls.crt --from-file=tls.key
D.kubectl create secret certificate tls-secret --cert= --key=
AnswerA

This creates a TLS secret of type kubernetes.io/tls.

Why this answer

Option A is correct because `kubectl create secret tls` is the dedicated subcommand for creating a TLS secret, which automatically encodes the certificate and key files and stores them under the expected keys (`tls.crt` and `tls.key`). This is the only command that produces a secret of type `kubernetes.io/tls`, which is required by Ingress controllers to serve HTTPS traffic.

Exam trap

The trap here is that candidates may think `kubectl create secret generic` with `--from-file` can create a TLS secret, but they overlook that the secret type must be `kubernetes.io/tls` for the Ingress controller to use it, and the generic command does not set that type.

How to eliminate wrong answers

Option B is wrong because `kubectl create secret docker-registry` creates a secret of type `kubernetes.io/dockerconfigjson` for container registry authentication, not TLS; it expects `--docker-username`, `--docker-password`, etc., not certificate flags. Option C is wrong because `kubectl create secret generic` creates a secret of type `Opaque`, not `kubernetes.io/tls`, and while it can store the files, the Ingress controller will not recognize the keys unless they are named exactly `tls.crt` and `tls.key` and the secret type is correct; this command does not set the type automatically. Option D is wrong because `kubectl create secret certificate` is not a valid kubectl subcommand; the correct subcommand is `tls`, and the flags `--cert=` and `--key=` are incomplete (they require file paths).

Practice this question →
25
Multi-Selectmedium

Which THREE of the following are valid fields in a PodSecurityPolicy (PSP) that control Linux capabilities? (Select exactly 3)

Select 3 answers
A.privileged
B.defaultAddCapabilities
C.readOnlyRootFilesystem
D.requiredDropCapabilities
E.allowedCapabilities
AnswersB, D, E

Capabilities added by default to containers.

Why this answer

Option B is correct because `defaultAddCapabilities` is a valid field in a PodSecurityPolicy (PSP) that specifies a list of Linux capabilities to be added to containers by default, even if not explicitly requested in the container's security context. This field is part of the PSP's capabilities control mechanism, as defined in the Kubernetes PodSecurityPolicy spec.

Exam trap

CNCF often tests the distinction between fields that directly control capabilities (like `allowedCapabilities`, `defaultAddCapabilities`, `requiredDropCapabilities`) and other security-related fields (like `privileged` or `readOnlyRootFilesystem`) that serve different purposes, causing candidates to select options that are not capability-specific.

Practice this question →
26
MCQhard

A Pod is configured with securityContext: { runAsUser: 1000, runAsGroup: 2000, fsGroup: 3000 }. The container's image runs a process that must listen on a TCP port below 1024 (e.g., port 80). The process is currently failing to start. What should you modify to allow the process to bind to a privileged port?

A.Set 'allowPrivilegeEscalation: true'
B.Add 'capabilities.drop: [ALL]' to the container's securityContext
C.Add 'capabilities.add: [NET_BIND_SERVICE]' to the container's securityContext
D.Set runAsUser: 0 to run as root
AnswerC

Correct. The NET_BIND_SERVICE capability allows a non-root process to bind to ports below 1024.

Why this answer

Option C is correct. When a container runs as a non-root user (runAsUser: 1000), it cannot bind to ports below 1024. Adding the NET_BIND_SERVICE capability to the container's capabilities allows it to bind to privileged ports without being root.

Dropping all capabilities is not necessary.

Practice this question →
27
MCQeasy

What is the purpose of a ResourceQuota in Kubernetes?

A.To set default resource limits for containers that do not specify them.
B.To limit the total amount of resources (CPU, memory, etc.) that can be consumed by all pods in a namespace.
C.To limit the number of nodes in a cluster.
D.To limit the number of replicas in a Deployment.
AnswerB

ResourceQuota enforces aggregate limits on resource usage within a namespace.

Why this answer

A ResourceQuota is a Kubernetes object that enforces aggregate resource consumption limits on a per-namespace basis. It constrains the total CPU, memory, and other resource requests and limits across all pods in that namespace, preventing any single namespace from exhausting cluster resources. Option B correctly identifies this namespace-level resource cap.

Exam trap

The trap here is confusing ResourceQuota (namespace-wide resource cap) with LimitRange (per-container default limits), as both deal with resource constraints but at different scopes and with different enforcement mechanisms.

How to eliminate wrong answers

Option A is wrong because setting default resource limits for containers is the purpose of a LimitRange, not a ResourceQuota; a LimitRange applies default requests/limits per container, while a ResourceQuota caps total namespace usage. Option C is wrong because the number of nodes in a cluster is managed by cluster autoscalers or cloud provider configurations, not by a ResourceQuota, which operates only within a namespace. Option D is wrong because limiting replicas in a Deployment is done via the Deployment's spec.replicas field or a HorizontalPodAutoscaler, not by a ResourceQuota, which does not control replica counts directly.

Practice this question →
28
MCQmedium

You need to grant a ServiceAccount 'my-sa' read-only access to pods in the 'test' namespace. Which RBAC YAML should you create?

A.kind: ClusterRole\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n name: pod-reader\nrules:\n- apiGroups: [""]\n resources: ["pods"]\n verbs: ["get", "list", "watch"]\n---\nkind: ClusterRoleBinding\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n name: read-pods\nsubjects:\n- kind: ServiceAccount\n name: my-sa\n namespace: test\nroleRef:\n kind: ClusterRole\n name: pod-reader\n apiGroup: rbac.authorization.k8s.io
B.kind: Role\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n namespace: test\n name: pod-reader\nrules:\n- apiGroups: [""]\n resources: ["pods"]\n verbs: ["get", "list", "watch"]\n---\nkind: RoleBinding\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n namespace: test\n name: read-pods\nsubjects:\n- kind: ServiceAccount\n name: my-sa\n namespace: test\nroleRef:\n kind: Role\n name: pod-reader\n apiGroup: rbac.authorization.k8s.io
C.kind: Role\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n namespace: test\n name: pod-reader\nrules:\n- apiGroups: [""]\n resources: ["pods"]\n verbs: ["create", "delete"]
D.kind: Role\napiVersion: rbac.authorization.k8s.io/v1\nmetadata:\n name: pod-reader\n namespace: default\nrules: ...\n---\nkind: RoleBinding ...
AnswerB

Correct Role and RoleBinding in the same namespace.

Why this answer

Option B is correct because it creates a Role in the 'test' namespace with read-only verbs ('get', 'list', 'watch') on pods, and binds that Role to the ServiceAccount 'my-sa' in the same namespace via a RoleBinding. This grants the ServiceAccount scoped, namespace-level read-only access to pods, which matches the requirement precisely.

Exam trap

CNCF often tests the distinction between Role and ClusterRole, and between RoleBinding and ClusterRoleBinding, to see if candidates understand that namespace-scoped access requires a Role and RoleBinding, not a ClusterRole and ClusterRoleBinding, even when the permissions are identical.

How to eliminate wrong answers

Option A is wrong because it uses a ClusterRole and ClusterRoleBinding, which grant cluster-wide access; the requirement is for read-only access only in the 'test' namespace, so a namespace-scoped Role and RoleBinding are appropriate. Option C is wrong because it defines a Role with 'create' and 'delete' verbs, which are write operations, not read-only; it also lacks a RoleBinding to actually bind the Role to the ServiceAccount. Option D is wrong because the Role is created in the 'default' namespace, not the 'test' namespace, so it would not grant access to pods in the 'test' namespace.

Practice this question →
29
MCQmedium

A pod named 'test-pod' in namespace 'test' has a service account 'my-sa' attached. The service account has a RoleBinding to a Role that allows get/list pods. However, the pod cannot list pods. What is the most likely issue?

A.The pod is using the default service account instead of 'my-sa'
B.The RoleBinding is in a different namespace than the pod
C.RoleBindings cannot grant access to list pods
D.The pod has automountServiceAccountToken set to false
AnswerB

RoleBindings are namespace-scoped. The RoleBinding must be in the same namespace as the pod and service account.

Why this answer

RoleBindings in Kubernetes are namespace-scoped and can only grant permissions within the namespace where they are created. If the RoleBinding is in a different namespace than the pod, the service account 'my-sa' will not have the get/list pods permissions in the pod's namespace, causing the pod to fail when trying to list pods.

Exam trap

CNCF often tests the namespace-scoping of RoleBindings versus ClusterRoleBindings, tricking candidates into thinking a RoleBinding in any namespace can grant permissions to a pod in another namespace.

How to eliminate wrong answers

Option A is wrong because the question explicitly states the pod has service account 'my-sa' attached, so it is not using the default service account. Option C is wrong because RoleBindings can grant access to list pods via a Role that includes the 'list' verb on 'pods' resources; this is a standard RBAC capability. Option D is wrong because automountServiceAccountToken set to false would prevent the pod from mounting the service account token, but the pod would then have no credentials at all, not just fail to list pods; the question states the pod cannot list pods specifically, implying it has some token but lacks the correct permissions.

Practice this question →
30
MCQhard

You want to enforce a Pod Security Standard of 'restricted' in a namespace. Which command applies the correct label?

A.kubectl label namespace my-ns psp=restricted
B.kubectl label namespace my-ns pod-security.kubernetes.io/enforce=restricted
C.kubectl annotate namespace my-ns pod-security.kubernetes.io/enforce=restricted
D.kubectl label namespace my-ns pod-security.kubernetes.io/audit=restricted
AnswerB

Correct.

Why this answer

Option B is correct because Pod Security Standards are enforced by applying a label with the key `pod-security.kubernetes.io/enforce` to a namespace. The value `restricted` sets the most restrictive Pod Security Standard, which prevents pods from running with privileged access or insecure capabilities. This label is part of the built-in Pod Security Admission (PSA) controller, which replaced PodSecurityPolicy in Kubernetes v1.23+.

Exam trap

The trap here is that candidates confuse the deprecated PodSecurityPolicy (PSP) label key `psp` with the correct Pod Security Admission label key `pod-security.kubernetes.io/enforce`, or they mistakenly use `annotate` instead of `label` because both commands can attach metadata to resources.

How to eliminate wrong answers

Option A is wrong because the label key `psp` is not a valid Pod Security Standard label; it references the deprecated PodSecurityPolicy (PSP) feature, which is removed in Kubernetes v1.25. Option C is wrong because `kubectl annotate` adds an annotation, not a label, and Pod Security Standards are enforced via labels, not annotations. Option D is wrong because the label key `pod-security.kubernetes.io/audit` sets the audit level, which only logs violations without blocking them; the enforce level requires the key `pod-security.kubernetes.io/enforce`.

Practice this question →
31
MCQmedium

You want to restrict total memory usage in a namespace to 10 Gi. Which resource should you create?

A.ResourceQuota
B.PodDisruptionBudget
C.LimitRange
D.NetworkPolicy
AnswerA

ResourceQuota can limit total memory across all pods in a namespace.

Why this answer

A ResourceQuota is the correct Kubernetes object to enforce aggregate resource consumption limits at the namespace level. By defining a ResourceQuota with `spec.hard.memory: 10Gi`, you restrict the total memory requested and used by all pods in that namespace to 10 GiB. This directly meets the requirement to limit total memory usage.

Exam trap

CNCF often tests the distinction between per-container limits (LimitRange) and aggregate namespace limits (ResourceQuota), leading candidates to mistakenly choose LimitRange when the question explicitly asks for total namespace-wide restrictions.

How to eliminate wrong answers

Option B is wrong because a PodDisruptionBudget (PDB) controls the minimum number of available pods during voluntary disruptions (e.g., node drains), not resource usage limits. Option C is wrong because a LimitRange sets per-container default and minimum/maximum resource constraints, not an aggregate namespace-wide limit. Option D is wrong because a NetworkPolicy governs ingress/egress traffic rules using labels and CIDR blocks, not memory or CPU restrictions.

Practice this question →
32
Multi-Selectmedium

Which two fields can be used in a SecurityContext to control a container's access to the host filesystem? (Choose two.)

Select 2 answers
A.runAsUser
B.capabilities
C.readOnlyRootFilesystem
D.allowPrivilegeEscalation
E.runAsGroup
AnswersC, D

When set to true, the container's root filesystem is read-only, preventing writes.

Why this answer

Option C is correct because setting `readOnlyRootFilesystem: true` in a container's SecurityContext mounts the container's root filesystem as read-only, preventing any writes to the host filesystem through the container's root. This directly controls access to the host filesystem by blocking modifications. Option D is correct because `allowPrivilegeEscalation: false` prevents a process from gaining more privileges than its parent, which restricts the ability to perform privileged operations that could access the host filesystem, such as mounting or modifying host paths.

Exam trap

CNCF often tests the distinction between fields that control user identity (runAsUser, runAsGroup) versus fields that directly restrict filesystem access or privilege escalation, leading candidates to mistakenly select identity fields as filesystem access controls.

Practice this question →
33
MCQhard

A cluster administrator wants to enforce that no pod in namespace 'prod' uses more than 4Gi of memory. Which Kubernetes resource should be created?

A.PodDisruptionBudget
B.NetworkPolicy
C.LimitRange
D.ResourceQuota
AnswerC

A LimitRange with a max limit can enforce a maximum memory limit per container or pod.

Why this answer

Option C is correct because a LimitRange resource in the 'prod' namespace can set a default memory limit and a maximum memory limit per container or pod, enforcing that no pod exceeds 4Gi of memory. This is the appropriate Kubernetes primitive for per-pod resource constraints within a namespace, as it applies to all pods that do not specify their own limits.

Exam trap

The trap here is confusing ResourceQuota (namespace-level aggregate limits) with LimitRange (per-pod/per-container limits), leading candidates to select D when the question explicitly asks for per-pod enforcement.

How to eliminate wrong answers

Option A is wrong because a PodDisruptionBudget is used to define the minimum number of replicas that must be available during voluntary disruptions (e.g., node drains), not to enforce memory limits. Option B is wrong because a NetworkPolicy controls ingress and egress traffic between pods based on labels and ports, not resource usage. Option D is wrong because a ResourceQuota sets aggregate resource consumption limits for the entire namespace (e.g., total memory across all pods), not per-pod maximums, and cannot prevent a single pod from using more than 4Gi.

Practice this question →
34
Multi-Selectmedium

Which THREE of the following are valid fields in a Pod's container spec for resource management? (Choose three.)

Select 3 answers
A.resources.limits.ephemeral-storage
B.resources.requests.cpu
C.resources.limits.memory
D.resources.requests.gpu
E.resources.requests.storage
AnswersA, B, C

Correct: ephemeral-storage is a resource type.

Why this answer

Option A is correct because `ephemeral-storage` is a valid resource type in Kubernetes that can be specified under `resources.limits` to control the maximum temporary storage a container can use, preventing pods from exhausting node storage. This is defined in the Kubernetes resource model and is commonly used for scratch space or logs.

Exam trap

The trap here is that candidates often confuse `resources.requests.storage` with `PersistentVolumeClaim` storage requests, or assume `gpu` is a built-in resource like CPU or memory, when in fact Kubernetes only natively supports CPU and memory as core resources, with extended resources requiring explicit configuration.

Practice this question →
35
Multi-Selectmedium

Which THREE of the following are benefits of using a ResourceQuota in a namespace? (Select THREE)

Select 3 answers
A.It sets default resource requests and limits for Pods that don't specify them
B.It can enforce that every Pod has resource limits set
C.It restricts which users can create Pods in the namespace
D.It prevents a single namespace from exhausting cluster resources
E.It limits the total amount of CPU and memory that can be consumed by all Pods in the namespace
AnswersB, D, E

ResourceQuota can require that all Pods have limits set by specifying 'limits.cpu' and 'limits.memory' in the quota.

Why this answer

Option B is correct because a ResourceQuota can enforce that every Pod in the namespace has resource limits set by specifying the `limits.cpu` and `limits.memory` fields in the quota's `hard` spec. If a Pod is created without those limits, the API server will reject it, ensuring no Pod runs unbounded. This is distinct from setting default values, which is done by a LimitRange, not a ResourceQuota.

Exam trap

The trap here is that candidates often confuse the purpose of a ResourceQuota with a LimitRange, mistakenly thinking a ResourceQuota sets default resource requests/limits, when in fact that is exclusively a LimitRange feature.

Practice this question →
36
MCQhard

A container image requires running as UID 0 but you need to comply with a 'restricted' Pod Security Admission policy. Which SecurityContext setting allows this while still passing the policy?

A.Set securityContext: { allowPrivilegeEscalation: true }
B.No SecurityContext setting allows running as UID 0 under the restricted policy.
C.Set securityContext: { runAsNonRoot: true, capabilities: { add: ['SYS_ADMIN'] } }
D.Set runAsUser: 0 and runAsNonRoot: false
AnswerB

The restricted policy requires runAsNonRoot: true, which prohibits running as UID 0. The container must be modified to run as a non-root user.

Why this answer

The 'restricted' Pod Security Admission policy requires that containers run as non-root (runAsNonRoot: true) and prohibits setting runAsUser to 0. Since the image requires UID 0, no SecurityContext setting can override this policy constraint; the only way to comply is to modify the image to run as a non-root user. Therefore, option B is correct.

Exam trap

The trap here is that candidates assume they can override the restricted policy with a SecurityContext setting like runAsUser: 0, not realizing that the restricted policy explicitly forbids UID 0 and enforces runAsNonRoot: true, making any such override invalid.

How to eliminate wrong answers

Option A is wrong because allowPrivilegeEscalation: true is actually prohibited by the restricted policy (it must be false), and it does not address the UID 0 requirement. Option C is wrong because runAsNonRoot: true conflicts with running as UID 0, and adding SYS_ADMIN capability is forbidden by the restricted policy (only NET_BIND_SERVICE is allowed). Option D is wrong because runAsUser: 0 with runAsNonRoot: false explicitly violates the restricted policy's requirement that runAsNonRoot must be true and runAsUser must not be 0.

Practice this question →
37
MCQeasy

A developer wants to inject database credentials into a pod as environment variables. The credentials are stored in a Kubernetes Secret named 'db-creds' with keys 'username' and 'password'. Which pod spec snippet correctly injects both values as environment variables?

A.env: - name: username valueFrom: secretKeyRef: name: db-creds key: username
B.envFrom: - configMapRef: name: db-creds
C.envFrom: - secretRef: name: db-creds
D.envFrom: - secretKeyRef: name: db-creds
AnswerC

envFrom with secretRef loads all keys from the Secret as environment variables.

Why this answer

Option C is correct because `envFrom` with `secretRef` injects all key-value pairs from a Secret as environment variables into the pod. This directly satisfies the requirement to inject both 'username' and 'password' from the 'db-creds' Secret without needing to specify each key individually.

Exam trap

The trap here is that candidates often confuse `envFrom` with `env` and use `secretKeyRef` under `envFrom` (Option D) or mistakenly use `configMapRef` for secrets (Option B), failing to recognize that `envFrom` requires `secretRef` to inject all keys from a Secret.

How to eliminate wrong answers

Option A is wrong because it only injects a single key ('username') as an environment variable, missing the 'password' key; it uses `env` with `secretKeyRef` for one value, not `envFrom` for all values. Option B is wrong because `configMapRef` references a ConfigMap, not a Secret; ConfigMaps are for non-sensitive data, while database credentials require a Secret. Option D is wrong because `secretKeyRef` is not a valid field under `envFrom`; `envFrom` uses `secretRef` to reference the entire Secret, while `secretKeyRef` is used under `env` for individual key references.

Practice this question →
38
MCQeasy

A developer creates a Secret named 'db-secret' with key 'password'. They want to expose the password as an environment variable DB_PASSWORD in a Pod. Which of the following is the correct way to achieve this?

A.Set env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password
B.Set env: - name: DB_PASSWORD valueFrom: configMapKeyRef: name: db-secret key: password
C.Use envFrom: - secretRef: name: db-secret
D.Set env: - name: DB_PASSWORD secretRef: name: db-secret key: password
AnswerA

Correctly maps the secret key to the desired environment variable name.

Why this answer

Option A is correct because it uses the `valueFrom.secretKeyRef` field to reference a specific key (`password`) from the Secret named `db-secret` and expose it as the environment variable `DB_PASSWORD`. This is the standard Kubernetes syntax for injecting a single Secret key into a Pod's environment variable.

Exam trap

The trap here is that candidates often confuse `secretKeyRef` with `configMapKeyRef` or incorrectly use `secretRef` directly under `env`, forgetting that `secretKeyRef` must be nested under `valueFrom`.

How to eliminate wrong answers

Option B is wrong because `configMapKeyRef` is used to reference keys from a ConfigMap, not a Secret; using it with a Secret name would fail to resolve the value. Option C is wrong because `envFrom` with `secretRef` injects all keys from the Secret as environment variables, but the developer specifically wants only the `password` key exposed as `DB_PASSWORD`, not all keys. Option D is wrong because `secretRef` is not a valid field under `env`; the correct field is `valueFrom.secretKeyRef`, and the syntax shown is incomplete and invalid.

Practice this question →
39
Multi-Selecteasy

Which TWO of the following are valid sources for creating a ConfigMap?

Select 2 answers
A.A file
B.An environment variable file
C.Literal key-value pairs
D.A directory
E.A Secret
AnswersA, C

Using --from-file.

Why this answer

A file is a valid source for creating a ConfigMap because the `kubectl create configmap` command supports the `--from-file` flag, which reads the entire contents of a file and creates a key-value pair where the key defaults to the filename. This is commonly used to inject configuration data like application properties or scripts into a Pod.

Exam trap

CNCF often tests the distinction between valid sources (`--from-file`, `--from-literal`) and invalid ones like a directory or Secret, tricking candidates into thinking a directory or Secret can be directly used as a source for `kubectl create configmap`.

Practice this question →
40
MCQeasy

A pod named 'web-app' is running but has no environment variables. The developer wants to inject a variable 'DB_URL=postgres://db:5432' from a ConfigMap named 'db-config'. Which pod spec snippet correctly achieves this?

A.env: - name: DB_URL value: "postgres://db:5432"
B.envFrom: - configMapRef: name: db-config key: DB_URL
C.env: - name: DB_URL valueFrom: secretKeyRef: name: db-config key: DB_URL
D.env: - name: DB_URL valueFrom: configMapKeyRef: name: db-config key: DB_URL
AnswerD

Correctly references ConfigMap key.

Why this answer

Option D is correct because it uses the `configMapKeyRef` field under `valueFrom` to inject a specific key from a ConfigMap as an environment variable. This allows the pod to consume the `DB_URL` value from the `db-config` ConfigMap without exposing it as a file or using `envFrom`.

Exam trap

CNCF often tests the distinction between `envFrom` (which imports all keys) and `valueFrom.configMapKeyRef` (which imports a single key), and candidates confuse the syntax by placing `key` directly under `configMapRef` instead of using the correct nested structure.

How to eliminate wrong answers

Option A is wrong because it hardcodes the value directly in the pod spec, ignoring the requirement to inject from a ConfigMap. Option B is wrong because `envFrom` with `configMapRef` imports all keys from the ConfigMap as environment variables, but the syntax is incorrect: `key` is not a valid field under `configMapRef` (it belongs under `configMapKeyRef` inside `valueFrom`). Option C is wrong because `secretKeyRef` is used to reference a Secret, not a ConfigMap, and the resource is named `db-config`, which implies a ConfigMap.

Practice this question →
41
MCQmedium

A developer creates a Role and RoleBinding in the namespace 'development' to grant list pods permission to a service account. Which manifest snippet correctly defines the Role?

A.rules: - apiGroups: ["pods"] resources: ["pods"] verbs: ["get", "list"]
B.rules: - apiGroups: ["apps"] resources: ["pods"] verbs: ["list"]
C.rules: - apiGroups: [""] resources: ["pods"] verbs: ["list"]
D.rules: - apiGroups: ["*"] resources: ["pods"] verbs: ["list"]
AnswerC

Correct apiGroups for core resources is empty string.

Why this answer

Option C is correct because pods belong to the core API group, which is represented by an empty string `""` in the `apiGroups` field. The `list` verb is sufficient to list pods, and the `resources` field correctly specifies `pods`. This Role grants the service account permission to list pods in the `development` namespace.

Exam trap

The trap here is that candidates often confuse the core API group with a named group like `"apps"` or use a wildcard `"*"` instead of the correct empty string `""`, leading to rules that either don't apply or are overly permissive.

How to eliminate wrong answers

Option A is wrong because `apiGroups: ["pods"]` is invalid; `pods` is a resource, not an API group, and the correct API group for pods is the core group (`""`). Option B is wrong because `apiGroups: ["apps"]` is incorrect; pods are not part of the `apps` API group (which includes Deployments, StatefulSets, etc.), so the rule would not apply to pods. Option D is wrong because `apiGroups: ["*"]` is a wildcard that matches all API groups, which is overly broad and not the precise way to specify the core group; the correct value for the core group is an empty string.

Practice this question →
42
MCQmedium

A pod's securityContext has 'allowPrivilegeEscalation: false' and 'capabilities: { drop: ["ALL"] }'. Which statement is true?

A.The container can still gain capabilities via setuid binaries.
B.The container runs with no extra capabilities and cannot gain privileges.
C.The container runs as root with full privileges.
D.The container runs with all Linux capabilities.
AnswerB

Correct interpretation.

Why this answer

Option B is correct because setting 'allowPrivilegeEscalation: false' prevents processes from gaining more privileges than their parent (e.g., via setuid binaries or kernel exploits), and dropping all capabilities with 'capabilities: { drop: ["ALL"] }' removes every Linux capability from the container's bounding set. Together, these ensure the container runs with no extra capabilities and cannot escalate privileges, even if running as root.

Exam trap

The trap here is that candidates assume dropping all capabilities still allows privilege escalation via setuid binaries, but 'allowPrivilegeEscalation: false' specifically blocks that path, making the combination a hard security boundary.

How to eliminate wrong answers

Option A is wrong because 'allowPrivilegeEscalation: false' explicitly blocks setuid binaries from granting elevated privileges, so the container cannot gain capabilities via that mechanism. Option C is wrong because dropping all capabilities means the container does not run with full privileges, even if the user is root; root without capabilities is restricted. Option D is wrong because 'drop: ["ALL"]' removes all Linux capabilities, so the container does not run with any capabilities, let alone all of them.

Practice this question →
43
Multi-Selectmedium

A developer needs to expose database credentials to a Pod as environment variables. The credentials are stored in a Kubernetes Secret named 'db-secret' with keys 'username' and 'password'. Which two methods correctly inject these values? (Choose two.)

Select 2 answers
A.Set 'env.name' to 'db-secret' and 'env.value' from 'secretKeyRef'.
B.Use 'valueFrom' with 'configMapKeyRef'.
C.Define an env entry with 'valueFrom' and 'secretKeyRef' for each key.
D.Mount the Secret as a volume and source environment variables from the mounted files.
E.Use 'envFrom' with 'secretRef' to expose all keys as environment variables.
AnswersC, E

Correct way to inject specific keys from a Secret.

Why this answer

Option C is correct because `valueFrom` with `secretKeyRef` allows you to reference a specific key from a Kubernetes Secret and inject its value as an environment variable. This is the standard method for exposing individual secret keys to a Pod. Option E is correct because `envFrom` with `secretRef` injects all keys from the referenced Secret as environment variables into the container, which is efficient when you need to expose multiple keys without defining each one individually.

Exam trap

CNCF often tests the distinction between `valueFrom` with `secretKeyRef` for individual keys versus `envFrom` with `secretRef` for bulk injection, and the trap here is that candidates confuse `configMapKeyRef` with `secretKeyRef` or think that mounting a Secret as a volume automatically creates environment variables from the file contents.

Practice this question →
44
Multi-Selecteasy

Which TWO commands can be used to create a Secret from a file? (Select 2)

Select 2 answers
A.kubectl create secret generic mysecret --from-file=key=file.txt
B.kubectl create configmap mysecret --from-file=file.txt
C.kubectl apply -f secret.yaml where secret.yaml contains data fields
D.kubectl create secret tls mysecret --cert=file.txt
E.kubectl create secret generic mysecret --from-env-file=file.txt
AnswersA, C

--from-file with key=filename syntax.

Why this answer

Option A is correct because `kubectl create secret generic mysecret --from-file=key=file.txt` creates a generic Secret by reading the contents of `file.txt` and storing it under the key `key`. This is the standard method to import file data into a Secret, where the file content is base64-encoded automatically by Kubernetes.

Exam trap

The trap here is that candidates often confuse `--from-file` with `--from-env-file` or think `kubectl create configmap` can create Secrets, but the CKAD exam tests precise command syntax and the distinction between Secret types (generic vs. TLS) and resource types (ConfigMap vs. Secret).

Practice this question →
45
MCQmedium

An administrator wants to enforce that all Pods in a namespace run with a read-only root filesystem. Which admission controller should be configured?

A.LimitRange
B.ResourceQuota
C.MutatingAdmissionWebhook
D.Pod Security Admission (PSA)
AnswerD

PSA enforces predefined security profiles including restricted which mandates readOnlyRootFilesystem.

Why this answer

Pod Security Admission (PSA) is the correct choice because it enforces Pod Security Standards (PSS) at the namespace level, including the `Restricted` profile which mandates a read-only root filesystem (`readOnlyRootFilesystem: true`). PSA is a built-in admission controller that evaluates pod specifications against predefined security policies and rejects pods that violate them, making it the appropriate tool for this requirement.

Exam trap

The trap here is that candidates confuse admission controllers that manage resource quotas (LimitRange, ResourceQuota) with those that enforce security policies, or mistakenly think a webhook is required when a built-in controller like PSA already provides the needed enforcement.

How to eliminate wrong answers

Option A is wrong because LimitRange is used to set default resource requests/limits and enforce min/max constraints on CPU and memory per pod or container, not to enforce filesystem security policies like read-only root filesystem. Option B is wrong because ResourceQuota limits aggregate resource consumption (e.g., total CPU, memory, or count of objects) in a namespace, but does not inspect or enforce pod-level security attributes such as filesystem access. Option C is wrong because MutatingAdmissionWebhook can modify pod specs (e.g., inject a read-only root filesystem), but it is not a built-in admission controller for enforcing security policies; it requires custom development and does not natively enforce the read-only root filesystem constraint without additional logic.

Practice this question →
46
MCQeasy

Which command creates a Secret named 'db-secret' with two keys, 'username' and 'password', from literal values?

A.kubectl create secret generic db-secret --from-literal=username=admin --from-literal=password=secret123
B.kubectl create secret db-secret --from-literal=username=admin --from-literal=password=secret123
C.kubectl create secret generic db-secret --from-file=username=admin --from-file=password=secret123
D.kubectl create secret generic db-secret --literal=username=admin --literal=password=secret123
AnswerA

This command correctly creates a generic secret with literal key-value pairs.

Why this answer

Option A is correct because `kubectl create secret generic` is the correct command syntax for creating a generic (opaque) Secret from literal key-value pairs. The `--from-literal` flag allows you to specify each key and its value directly on the command line, making it the appropriate choice for this task.

Exam trap

The trap here is that candidates often forget the `generic` subcommand or confuse `--from-literal` with `--from-file` or a non-existent `--literal` flag, leading to syntax errors or unintended behavior.

How to eliminate wrong answers

Option B is wrong because it omits the required subcommand `generic`; the correct syntax is `kubectl create secret generic`. Option C is wrong because `--from-file` expects a file path, not a literal key=value pair; using `--from-file=username=admin` would attempt to read a file named 'admin' and assign its content to key 'username', which is not the intended behavior. Option D is wrong because the flag `--literal` does not exist; the correct flag is `--from-literal`.

Practice this question →
47
MCQmedium

A developer creates a ServiceAccount 'my-sa' in namespace 'default'. They want to prevent pods from automatically mounting the ServiceAccount token. Which field should be set to false in the pod spec?

A.serviceAccountName: my-sa
B.automountServiceAccountToken: false
C.serviceAccountName: my-sa automountServiceAccountToken: false
D.containers: - automountServiceAccountToken: false
AnswerB

This disables automatic mounting of the service account token.

Why this answer

Option B is correct because setting `automountServiceAccountToken: false` in the pod spec explicitly prevents the automatic mounting of the ServiceAccount token into the pod. This is the standard Kubernetes field for controlling token mounting at the pod level, overriding the default behavior where the token is mounted automatically.

Exam trap

CNCF often tests the distinction between pod-level and container-level fields, and the trap here is that candidates may incorrectly assume `automountServiceAccountToken` can be set under `containers` (option D) or that specifying `serviceAccountName` alone (option A) is sufficient to control token mounting.

How to eliminate wrong answers

Option A is wrong because `serviceAccountName: my-sa` only specifies which ServiceAccount to use, but does not control token mounting; the token would still be mounted automatically unless explicitly disabled. Option C is wrong because it redundantly specifies both `serviceAccountName` and `automountServiceAccountToken`, but the correct field name is `automountServiceAccountToken` (not `automountServiceAccountToken` with a typo) and the placement is at the pod spec level, not as a separate line; however, the core issue is that the question asks for the field to set to false, and option C includes an unnecessary `serviceAccountName` specification, making it less precise than B. Option D is wrong because `automountServiceAccountToken` is a pod-level field, not a container-level field; placing it under `containers` is invalid and would be ignored by the Kubernetes API.

Practice this question →
48
MCQeasy

Which API version is correct for a Deployment in Kubernetes v1.29?

A.extensions/v1beta1
B.v1
C.apps/v1beta2
D.apps/v1
AnswerD

This is the current stable version.

Why this answer

Option D (apps/v1) is correct because the Deployment API version apps/v1 has been the stable version since Kubernetes v1.9, and it is the only correct version for creating Deployments in Kubernetes v1.29. The apps/v1 API group is the current, stable, and recommended version for managing Deployments, ReplicaSets, and other workload resources.

Exam trap

The trap here is that candidates may confuse the core v1 API group (used for Pods) with the apps/v1 group (used for Deployments), or mistakenly think that beta versions like apps/v1beta2 are still valid in recent Kubernetes releases.

How to eliminate wrong answers

Option A is wrong because extensions/v1beta1 was deprecated in Kubernetes v1.9 and removed entirely in v1.16; it is no longer available in v1.29. Option B is wrong because v1 is the core API group used for resources like Pods, Services, and ConfigMaps, but Deployments belong to the apps API group, not the core group. Option C is wrong because apps/v1beta2 was deprecated in Kubernetes v1.9 and removed in v1.16; it is not a valid API version in v1.29.

Practice this question →
49
MCQmedium

A pod uses a Secret 'db-secret' with keys 'username' and 'password'. Which environment variable definition correctly exposes the 'password' as an env var named 'DB_PASSWORD'?

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

Correctly references the secret and key using secretKeyRef.

Why this answer

Option B is correct because it uses `valueFrom.secretKeyRef` to reference the specific key `password` from the Secret `db-secret`, mapping it to the environment variable `DB_PASSWORD`. This is the standard Kubernetes method to expose a single key from a Secret as an environment variable with a custom name.

Exam trap

The trap here is that candidates often confuse `envFrom` with `env` and `secretRef` with `configMapKeyRef`, or assume that `envFrom` allows renaming keys, when in fact it only imports keys as-is, making Option C a distractor for those who want to import all keys but forget the naming requirement.

How to eliminate wrong answers

Option A is wrong because it hardcodes the password as a literal string in the Pod spec, which defeats the purpose of using a Secret and exposes sensitive data in plaintext. Option C is wrong because `envFrom` with `secretRef` imports all keys from the Secret as environment variables, but it does not allow renaming the variable to `DB_PASSWORD`; the key name `password` would become the env var name, not `DB_PASSWORD`. Option D is wrong because `configMapKeyRef` is used to reference ConfigMaps, not Secrets; Secrets require `secretKeyRef`.

Practice this question →
50
MCQeasy

Which of the following correctly describes the purpose of a PodSecurityPolicy (PSP) in Kubernetes? (Note: PSP is deprecated in v1.21+ and removed in v1.25; Pod Security Admission is the replacement.)

A.PSP is deprecated; its replacement is Pod Security Admission (PSA)
B.PSP is applied automatically to all pods in a cluster without configuration
C.PSP is a namespace-scoped resource that defines default security for pods
D.PSP cannot be used to control container security contexts
AnswerA

PSP is deprecated since Kubernetes v1.21 and removed in v1.25. Pod Security Admission is the successor.

Why this answer

Option A is correct because PodSecurityPolicy (PSP) was indeed deprecated in Kubernetes v1.21 and removed in v1.25, with Pod Security Admission (PSA) as its official replacement. PSA uses built-in Pod Security Standards (baseline, restricted, privileged) enforced via admission controllers and labels, eliminating the need for a separate admission webhook or CRD-based policy object.

Exam trap

The trap here is that candidates may remember PSP as a namespace-scoped resource (Option C) because it is often associated with namespaces in documentation, but it is actually cluster-scoped, and the deprecation timeline (Option A) is a frequent distractor for those who haven't kept up with Kubernetes version changes.

How to eliminate wrong answers

Option B is wrong because PSP is not applied automatically; it requires explicit RBAC authorization (use of the `use` verb on the PSP resource for the pod's service account) and an admission controller (`PodSecurityPolicy`) to be enabled in the API server. Option C is wrong because PSP is a cluster-scoped resource, not namespace-scoped; it applies across all namespaces unless restricted by RBAC. Option D is wrong because PSP can control container security contexts (e.g., `privileged`, `runAsUser`, `seLinuxOptions`, `capabilities`) via its spec fields, which is its primary function.

Practice this question →
51
MCQhard

A pod is configured with 'securityContext.seccompProfile.type: RuntimeDefault' but the container still attempts to use a syscall that is blocked by the default seccomp profile. What happens?

A.The container is killed because it violated the seccomp policy.
B.The pod is evicted by the kubelet because of a security violation.
C.The container runs successfully because RuntimeDefault allows all syscalls.
D.The syscall fails with an error, but the container may continue running.
AnswerD

The blocked syscall returns an error, and the application may or may not handle it gracefully.

Why this answer

Option D is correct because when a container uses a syscall blocked by the seccomp profile, the syscall itself fails (returns an error like EPERM or is killed by SIGSYS), but the container process can handle that error and continue running. The `RuntimeDefault` profile applies Docker's default seccomp profile, which blocks around 44 syscalls (e.g., `mount`, `ptrace`, `perf_event_open`), but does not terminate the container unless the process exits due to the failed syscall. The container is not killed by Kubernetes; only the specific syscall is denied by the kernel's seccomp mechanism.

Exam trap

The trap here is that candidates assume any security violation immediately kills the container or evicts the pod, but seccomp violations only fail the specific syscall, and the container may continue if the process handles the error.

How to eliminate wrong answers

Option A is wrong because the container is not killed by Kubernetes; the seccomp policy causes the syscall to fail, but the container process may continue if it handles the error gracefully. Option B is wrong because pod eviction by the kubelet occurs for resource constraints or node-level issues (e.g., memory pressure, disk pressure), not for seccomp violations. Option C is wrong because `RuntimeDefault` does not allow all syscalls; it applies a restrictive default profile that blocks dangerous syscalls, so a blocked syscall will fail.

Practice this question →
52
MCQeasy

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

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

This creates a ConfigMap named app-config with a data entry where the key is 'config.properties' and value is the file content.

Why this answer

Option A is correct because `kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' by reading the entire contents of the file 'config.properties' and storing it as a single key-value pair, where the key defaults to the filename (config.properties) and the value is the file's content. This is the standard syntax for creating a ConfigMap from a file in Kubernetes.

Exam trap

The trap here is that candidates confuse `--from-file` (which imports a file as a single key-value pair) with `--from-env-file` (which imports a file of environment variables as multiple key-value pairs), or mistakenly think `--from-literal` can accept a file path.

How to eliminate wrong answers

Option B 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; using `--from-literal=config.properties` would treat 'config.properties' as a literal string key with no value, which is invalid. Option C is wrong because `--file` is not a valid flag for `kubectl create configmap`; the correct flag is `--from-file`. Option D is wrong because `--from-env-file` is used to create a ConfigMap from a file containing environment variable definitions in KEY=VALUE format (one per line), not from a generic properties file; it would parse the file differently and may not produce the expected single-key ConfigMap.

Practice this question →
53
Multi-Selectmedium

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

Select 2 answers
A.Mounting the ConfigMap as a volume
B.Using configMapKeyRef in env.valueFrom
C.Using configMapRef in env.valueFrom
D.Using secretKeyRef in env.valueFrom
E.Using envFrom with configMapRef
AnswersA, B

ConfigMaps can be mounted as volumes using volumes.configMap.

Why this answer

Option A is correct because a ConfigMap can be mounted as a volume in a Pod, allowing files or directories to be created from the ConfigMap's data. This is done by specifying a volume of type `configMap` in the Pod spec and mounting it into the container's filesystem, which makes the key-value pairs available as files.

Exam trap

The trap here is that candidates often confuse `configMapRef` (used in `envFrom`) with `configMapKeyRef` (used in `env.valueFrom`), and may incorrectly think `envFrom` is not a valid consumption method, or they may select `secretKeyRef` because they forget it is specific to Secrets, not ConfigMaps.

Practice this question →
54
MCQmedium

A developer wants to create a ConfigMap named 'app-config' with two key-value pairs: 'color=blue' and 'size=large'. Which kubectl command should they use?

A.kubectl create configmap app-config --from-literal=color,size --value=blue,large
B.kubectl create configmap app-config --from-literal=color=blue --from-literal=size=large
C.kubectl create configmap app-config --from-env-file=color=blue,size=large
D.kubectl create configmap app-config --from-file=color=blue --from-file=size=large
AnswerB

Correct syntax for creating a ConfigMap from literals.

Why this answer

Option B is correct because `kubectl create configmap` with `--from-literal` allows specifying key-value pairs directly in the command line. Each literal must be provided as a separate `--from-literal=key=value` flag, and this command correctly creates the ConfigMap with the two entries 'color=blue' and 'size=large'.

Exam trap

The trap here is that candidates often confuse `--from-literal` with `--from-file` or try to use comma-separated syntax, not realizing that each literal must be specified with its own `--from-literal` flag in the exact `key=value` format.

How to eliminate wrong answers

Option A is wrong because `--from-literal` does not accept comma-separated keys and values; it requires the format `--from-literal=key=value` for each pair. Option C is wrong because `--from-env-file` expects a file path containing environment variables in `key=value` format, not inline comma-separated values. Option D is wrong because `--from-file` creates a ConfigMap entry from the content of a file, using the filename as the key, not from literal key-value pairs.

Practice this question →
55
MCQeasy

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

A.kubectl create configmap app-config --from-file=app.properties --from-env-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 --from-file=app.properties
AnswerD

Correctly creates a ConfigMap with the file contents as a key-value pair.

Why this answer

Option D is correct because `kubectl create configmap app-config --from-file=app.properties` creates a ConfigMap by reading the entire contents of the file 'app.properties' and storing it under a key that defaults to the filename (app.properties). This is the standard way to import a file's data as a single key-value pair in a ConfigMap.

Exam trap

The trap here is that candidates confuse `--from-env-file` (which parses key=value lines) with `--from-file` (which imports the entire file as a single key), leading them to choose option C incorrectly.

How to eliminate wrong answers

Option A is wrong because it combines `--from-file` and `--from-env-file` for the same file, which is redundant and not the correct single command to create a ConfigMap from a file; `--from-env-file` is used for files with key=value format, not for importing a file as a single key. Option B is wrong because `--from-literal` is used to specify key-value pairs directly on the command line, not to reference a file; it would attempt to treat 'app.properties' as a literal key without a value. Option C is wrong because `--from-env-file` is intended for files containing environment-variable-style key=value lines (e.g., a .env file), not for importing a file's entire content as a single key; it would parse 'app.properties' line by line and fail if the file does not follow that format.

Practice this question →
56
Multi-Selectmedium

Which TWO are true about LimitRange objects?

Select 2 answers
A.A LimitRange is enforced at container creation time.
B.A LimitRange can be applied to the entire cluster.
C.A LimitRange can set a minimum memory request for containers in a namespace.
D.A LimitRange can set a default CPU limit for pods.
E.A LimitRange can limit the total number of pods in a namespace.
AnswersA, C

LimitRange is validated at pod creation.

Why this answer

Option A is correct because LimitRange objects enforce resource constraints at the time a container is created within a namespace. When a Pod is created, the LimitRange admission controller validates that the container's resource requests and limits fall within the defined minimum, maximum, and default values. If the container violates the LimitRange (e.g., requests less than the minimum memory), the Pod creation is rejected immediately.

Exam trap

The trap here is confusing LimitRange with ResourceQuota: candidates often think LimitRange can set namespace-wide limits like total Pod count or cluster-wide scope, but LimitRange is strictly per-container resource constraints within a single namespace.

Practice this question →
57
MCQmedium

An administrator wants to grant a ServiceAccount 'app-sa' in namespace 'dev' read-only access to pods in the same namespace. Which YAML snippet correctly defines the required RBAC resources?

A.--- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: dev name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: dev subjects: - kind: ServiceAccount name: app-sa namespace: dev roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
B.Same as A but subjects: - kind: Group name: app-sa
C.Same as A but subjects: - kind: User name: app-sa
D.Same as A but RoleBinding uses kind: ClusterRole
AnswerA

Correctly defines a Role and RoleBinding in the same namespace.

Why this answer

Option A correctly defines a Role with read-only verbs (get, list, watch) on pods in the 'dev' namespace, and binds it to the ServiceAccount 'app-sa' using a RoleBinding. Since both the Role and RoleBinding are scoped to the same namespace, this grants the ServiceAccount the required read-only access to pods within that namespace.

Exam trap

The trap here is that candidates often confuse the subject kind (ServiceAccount vs. User vs. Group) or incorrectly use a ClusterRole when a namespace-scoped Role is sufficient, leading to overly permissive or misconfigured bindings.

How to eliminate wrong answers

Option B is wrong because it uses 'kind: Group' instead of 'kind: ServiceAccount'; a Group subject is used for LDAP or OIDC groups, not for a Kubernetes ServiceAccount. Option C is wrong because it uses 'kind: User' instead of 'kind: ServiceAccount'; a User subject is for human users or external identities, not for a ServiceAccount. Option D is wrong because it uses 'kind: ClusterRole' in the RoleBinding; while a ClusterRole can be bound to a namespace-scoped RoleBinding, the question specifically requires a Role (not a ClusterRole) to limit access to the 'dev' namespace only, and using a ClusterRole would introduce unnecessary cluster-wide scope.

Practice this question →
58
MCQmedium

You have created a ServiceAccount named 'my-sa' in namespace 'default'. You want a Pod to use this ServiceAccount. Which Pod spec field is correct?

A.spec.securityContext.serviceAccount: my-sa
B.serviceAccountName: my-sa
C.serviceAccount: my-sa
D.automountServiceAccountToken: false
AnswerB

Correct. This sets the ServiceAccount for the pod.

Why this answer

Option B is correct because the `serviceAccountName` field in a Pod spec is the standard way to assign a specific ServiceAccount to a Pod. When this field is set to `my-sa`, the Pod will use the token and permissions associated with that ServiceAccount for API authentication and authorization.

Exam trap

The trap here is that candidates confuse the deprecated `serviceAccount` field with the current `serviceAccountName` field, or incorrectly assume that `securityContext` can set the ServiceAccount.

How to eliminate wrong answers

Option A is wrong because `spec.securityContext.serviceAccount` is not a valid field; `securityContext` applies to Pod or container security settings (e.g., user ID, SELinux options), not ServiceAccount assignment. Option C is wrong because `serviceAccount` is a deprecated field in Pod spec; it has been replaced by `serviceAccountName` in Kubernetes v1.1+ and may be removed in future versions. Option D is wrong because `automountServiceAccountToken: false` controls whether the ServiceAccount token is automatically mounted into the Pod, but it does not specify which ServiceAccount to use; it is a boolean flag, not a name reference.

Practice this question →
59
Multi-Selectmedium

Which TWO of the following are valid ways to create a ConfigMap from a file named 'app.properties'? (Select two.)

Select 2 answers
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=app.properties
D.kubectl create configmap app-config --from-file=app.properties=app.properties
E.kubectl create configmap app-config --from-env-file=app.properties
AnswersA, E

--from-file uses the filename as the key and the file content as the value.

Why this answer

Option A is correct because `--from-file=app.properties` creates a ConfigMap with a single key-value pair, where the key defaults to the filename (app.properties) and the value is the entire file content. Option E is correct because `--from-env-file=app.properties` imports each line of the file as a separate key-value pair, treating the file as an environment variable definition file (key=value format).

Exam trap

CNCF often tests the confusion between `--from-file` (which creates a single key with the file content) and `--from-env-file` (which creates multiple keys from key=value lines), and candidates mistakenly think `--from-env` is a valid flag.

Practice this question →
60
MCQeasy

Which field in a Pod spec specifies which ServiceAccount the pod should use?

A.spec.serviceAccount
B.spec.accountName
C.spec.automountServiceAccountToken
D.spec.serviceAccountName
AnswerD

This is the correct field.

Why this answer

The correct field is `spec.serviceAccountName` in the Pod spec. This field explicitly specifies the name of the ServiceAccount that the Pod should use. If omitted, the Pod automatically uses the `default` ServiceAccount in its namespace.

This is defined in the Kubernetes API for PodSpec.

Exam trap

The trap here is that candidates may confuse the deprecated `spec.serviceAccount` field with the correct `spec.serviceAccountName`, or mistakenly think `spec.automountServiceAccountToken` selects the ServiceAccount, when it only controls token mounting.

How to eliminate wrong answers

Option A is wrong because `spec.serviceAccount` is a deprecated field that was replaced by `spec.serviceAccountName` in Kubernetes v1.9+; it is no longer supported in current API versions. Option B is wrong because `spec.accountName` is not a valid field in the PodSpec; Kubernetes does not recognize this field for ServiceAccount assignment. Option C is wrong because `spec.automountServiceAccountToken` is a boolean field that controls whether the ServiceAccount token is automatically mounted into the Pod, not which ServiceAccount to use.

Practice this question →
61
MCQmedium

A developer created a Role named 'pod-reader' in namespace 'ns1' that allows 'get', 'list', and 'watch' on pods. They created a RoleBinding binding this Role to a ServiceAccount 'sa1' in the same namespace. However, a pod using 'sa1' cannot list pods in namespace 'ns2'. What is the most likely cause?

A.The Role is missing the apiGroup field
B.The Role does not include the 'list' verb for pods
C.Role and RoleBinding are namespace-scoped; they only grant permissions within their namespace
D.The RoleBinding is not bound to the correct ServiceAccount
AnswerC

Correct. Role and RoleBinding are scoped to a single namespace. To grant access across namespaces, you need ClusterRole and ClusterRoleBinding.

Why this answer

Role and RoleBinding are namespace-scoped resources in Kubernetes. A Role defined in 'ns1' grants permissions only within 'ns1', and a RoleBinding in 'ns1' binds that Role to a ServiceAccount only for operations inside 'ns1'. To list pods in 'ns2', the ServiceAccount needs a separate Role and RoleBinding (or a ClusterRole and ClusterRoleBinding) that explicitly grant permissions in 'ns2'.

Therefore, the pod using 'sa1' cannot list pods in 'ns2' because the Role and RoleBinding are confined to 'ns1'.

Exam trap

The trap here is that candidates often overlook the namespace-scoped nature of Role and RoleBinding, assuming that a RoleBinding can grant permissions across namespaces, when in fact it is strictly confined to the namespace of the RoleBinding itself.

How to eliminate wrong answers

Option A is wrong because the 'get', 'list', and 'watch' verbs on pods do not require an apiGroup field; pods are in the core API group (v1), which is the default and does not need explicit specification. Option B is wrong because the Role explicitly includes the 'list' verb for pods, as stated in the question. Option D is wrong because the RoleBinding is correctly bound to ServiceAccount 'sa1' in 'ns1', and the issue is not about binding to the wrong ServiceAccount but about namespace scope.

Practice this question →
62
MCQmedium

You have a Secret of type 'kubernetes.io/tls' named 'tls-secret'. What keys are required in the Secret data?

A.tls.crt and tls.key
B.username and password
C.tls.crt, tls.key, and ca.crt
D..dockerconfigjson
AnswerA

Required keys for a TLS secret: the certificate and private key.

Why this answer

A is correct because a Kubernetes TLS secret of type 'kubernetes.io/tls' requires exactly two data keys: 'tls.crt' (the TLS certificate) and 'tls.key' (the private key). These are mandatory for the TLS handshake to function, as defined by the Kubernetes API for TLS secrets.

Exam trap

The trap here is that candidates often assume 'ca.crt' is required because they think of full certificate chains, but the CKAD exam tests the exact mandatory keys per the Kubernetes API documentation for 'kubernetes.io/tls'.

How to eliminate wrong answers

Option B is wrong because 'username and password' are used for basic authentication secrets (type 'kubernetes.io/basic-auth'), not for TLS secrets. Option C is wrong because while 'ca.crt' (the CA certificate) is optional and can be included for chain validation, it is not required; only 'tls.crt' and 'tls.key' are mandatory. Option D is wrong because '.dockerconfigjson' is the key for a Docker registry secret (type 'kubernetes.io/dockerconfigjson'), not for a TLS secret.

Practice this question →
63
MCQmedium

A developer wants to ensure that a pod runs with a non-root user and cannot gain root privileges. Which SecurityContext settings should be used?

A.securityContext: allowPrivilegeEscalation: false
B.securityContext: runAsNonRoot: true
C.securityContext: runAsNonRoot: true allowPrivilegeEscalation: false
D.securityContext: runAsNonRoot: true allowPrivilegeEscalation: true
AnswerC

Correct. runAsNonRoot ensures non-root; allowPrivilegeEscalation: false prevents privilege escalation.

Why this answer

Option C is correct because setting `runAsNonRoot: true` enforces that the container's user ID is non-zero (non-root), and `allowPrivilegeEscalation: false` prevents the container from gaining additional privileges beyond its initial set, such as through setuid binaries or kernel capabilities. Together, they ensure the pod runs as a non-root user and cannot escalate to root, satisfying the developer's requirement.

Exam trap

The trap here is that candidates often think `runAsNonRoot: true` alone is sufficient to prevent privilege escalation, but it only restricts the initial user ID, not the ability to escalate later, which requires `allowPrivilegeEscalation: false`.

How to eliminate wrong answers

Option A is wrong because `allowPrivilegeEscalation: false` alone does not enforce that the container runs as a non-root user; it only prevents privilege escalation, so a root user could still be used initially. Option B is wrong because `runAsNonRoot: true` alone ensures the container runs as a non-root user but does not prevent privilege escalation, meaning the container could still gain root privileges via setuid binaries or other mechanisms. Option D is wrong because `allowPrivilegeEscalation: true` explicitly permits privilege escalation, which directly contradicts the requirement to 'cannot gain root privileges'.

Practice this question →
64
MCQeasy

Which kubectl command creates a ConfigMap named 'app-config' with key 'color' and value 'blue'?

A.kubectl create configmap app-config --from-literal=color=blue
B.kubectl create configmap app-config --from-file=color=blue
C.kubectl create configmap app-config --from-env-file=color=blue
D.kubectl run configmap app-config --data color=blue
AnswerA

Correct syntax using --from-literal.

Why this answer

Option A is correct because `kubectl create configmap app-config --from-literal=color=blue` directly creates a ConfigMap with a key-value pair. The `--from-literal` flag specifies a literal key=value string, which is the standard way to inject a single key-value pair into a ConfigMap without referencing an external file.

Exam trap

The trap here is confusing `--from-literal` with `--from-file` or `--from-env-file`, as candidates often misremember which flag accepts a literal key=value string versus a file path.

How to eliminate wrong answers

Option B is wrong because `--from-file` expects a file path (e.g., `--from-file=color.txt`), not a literal key=value pair; using `--from-file=color=blue` would attempt to read a file named 'color=blue', which does not exist. Option C is wrong because `--from-env-file` expects a file containing environment variable definitions in KEY=VALUE format (e.g., `--from-env-file=env.txt`), not a literal key=value pair. Option D is wrong because `kubectl run` is used to create a Pod, not a ConfigMap; the `--data` flag is invalid for `kubectl run` and does not create ConfigMaps.

Practice this question →
65
Multi-Selecthard

You want to apply a Pod Security Admission (PSA) policy that enforces the 'restricted' profile in the 'dev' namespace, but only for Pods that are not exempt. Which TWO steps are required? (Select TWO)

Select 2 answers
A.Set the label 'pod-security.kubernetes.io/enforce=restricted' on the namespace
B.Add a 'securityContext' field to the Pod template with 'runAsUser: 1000'
C.Set the label 'pod-security.kubernetes.io/enforce=baseline' on the namespace
D.Set the label 'pod-security.kubernetes.io/warn=restricted' on the namespace
E.Configure Pods to meet the restricted profile requirements, such as setting runAsNonRoot and seccompProfile
AnswersA, E

This label enforces the restricted profile for all pods in the namespace.

Why this answer

Option A is correct because setting the label 'pod-security.kubernetes.io/enforce=restricted' on the namespace instructs the Pod Security Admission controller to reject any Pod that does not meet the restricted profile, unless the Pod is exempt (e.g., system-critical Pods or those with specific exemptions). This label directly enforces the policy at admission time, ensuring only compliant Pods are created in the 'dev' namespace.

Exam trap

The trap here is confusing the 'warn' mode with 'enforce' mode, as candidates often think a warning label is sufficient to block non-compliant Pods, but only the 'enforce' label actually rejects them at admission time.

Practice this question →
66
MCQhard

A ClusterRole named 'secret-reader' grants get, list, watch on secrets in all namespaces. A RoleBinding in namespace 'app' binds this ClusterRole to a ServiceAccount 'app-sa'. Which of the following is true about the effective permissions of 'app-sa'?

A.The ServiceAccount can read secrets in all namespaces
B.The RoleBinding is invalid because ClusterRole cannot be used with RoleBinding
C.The ServiceAccount can read secrets only in namespace 'app'
D.The ServiceAccount can read secrets only in the default namespace
AnswerC

Correct. A RoleBinding scopes the ClusterRole's permissions to the RoleBinding's namespace.

Why this answer

A RoleBinding can only grant permissions within its own namespace, even when it references a ClusterRole. Since the RoleBinding is in namespace 'app', the ServiceAccount 'app-sa' receives the permissions defined in the 'secret-reader' ClusterRole, but scoped only to namespace 'app'. Therefore, it can read secrets only in namespace 'app', not in all namespaces.

Exam trap

The trap here is that candidates often assume a ClusterRole always grants cluster-wide permissions when bound via any binding, forgetting that a RoleBinding restricts the scope to its own namespace.

How to eliminate wrong answers

Option A is wrong because a RoleBinding scopes the ClusterRole's permissions to the RoleBinding's namespace ('app'), not to all namespaces; to grant cluster-wide access, a ClusterRoleBinding must be used. Option B is wrong because a RoleBinding can legally reference a ClusterRole; this is a standard Kubernetes pattern to reuse cluster-scoped roles within a specific namespace. Option D is wrong because the RoleBinding is in namespace 'app', not 'default', so the permissions apply to namespace 'app' only.

Practice this question →
67
MCQhard

A pod is stuck in Pending state. You run 'kubectl describe pod mypod' and see the event: '0/3 nodes are available: 1 Insufficient memory, 2 Insufficient cpu'. The pod has resource requests defined. Which action would allow the pod to be scheduled?

A.Increase the resource requests for the container
B.Delete the pod and recreate it with the same spec
C.Decrease the memory and CPU requests to fit within available node resources
D.Decrease the CPU request but keep the memory request the same
AnswerC

This would make the pod schedulable on the existing nodes.

Why this answer

The pod is unschedulable because the cluster's three nodes collectively lack sufficient CPU and memory to satisfy the pod's resource requests. Decreasing the memory and CPU requests to fit within the available node resources (option C) directly resolves the scheduling failure by making the pod's resource demands compatible with the remaining capacity on at least one node.

Exam trap

CNCF often tests the misconception that simply recreating the pod or adjusting only one resource dimension will fix scheduling issues, when in fact the scheduler evaluates all resource requests simultaneously against each node's allocatable capacity.

How to eliminate wrong answers

Option A is wrong because increasing resource requests would make the pod even more demanding, worsening the scheduling failure. Option B is wrong because deleting and recreating the pod with the same spec does not change the resource requests or node availability, so it will remain stuck in Pending. Option D is wrong because decreasing only the CPU request while keeping the memory request unchanged would still leave the memory request unmet (the event shows 1 node has insufficient memory), so the pod would still be unschedulable.

Practice this question →
68
Multi-Selectmedium

Which TWO methods can be used to expose a Secret's data as environment variables inside a container? (Select 2)

Select 2 answers
A.Using 'args' in container spec
B.Using 'env.valueFrom.secretKeyRef'
C.Using 'env.valueFrom.configMapKeyRef'
D.Using 'volumeMounts' with a secret volume
E.Using 'envFrom.secretRef'
AnswersB, E

Exposes a single key as a named env var.

Why this answer

Option B is correct because `env.valueFrom.secretKeyRef` allows you to inject a specific key from a Kubernetes Secret as an environment variable into a container. This is a standard method for exposing sensitive data like passwords or tokens directly into the container's environment without hardcoding them in the Pod spec.

Exam trap

CNCF often tests the distinction between `env.valueFrom.secretKeyRef` (for a single key) and `envFrom.secretRef` (for all keys), and the trap is that candidates confuse `secretKeyRef` with `configMapKeyRef` or think `args` can be used for environment injection.

Practice this question →
69
MCQeasy

You need to create a ConfigMap named 'app-config' with key 'APP_COLOR' and value 'blue'. Which command creates this ConfigMap?

A.kubectl create configmap app-config --from-env-file=APP_COLOR=blue
B.kubectl create configmap app-config --from-literal=APP_COLOR=blue
C.kubectl create configmap app-config --from-literal=APP_COLOR:blue
D.kubectl create configmap app-config --from-file=APP_COLOR=blue
AnswerB

Correct. --from-literal is used for inline key-value pairs.

Why this answer

Option B is correct because `kubectl create configmap app-config --from-literal=APP_COLOR=blue` uses the `--from-literal` flag, which directly creates a ConfigMap entry from a key-value pair specified in the command line. The syntax `key=value` is required for literal data, and this command correctly maps the key 'APP_COLOR' to the value 'blue'.

Exam trap

The trap here is confusing the `--from-literal` syntax (which requires `=`) with the colon-based syntax used in YAML or environment files, leading candidates to incorrectly choose Option C.

How to eliminate wrong answers

Option A is wrong because `--from-env-file` expects a path to a file containing environment variables in `key=value` format, not a literal key-value pair; using `--from-env-file=APP_COLOR=blue` would attempt to read a file named 'APP_COLOR=blue', which does not exist. Option C is wrong because `--from-literal` requires the `=` sign to separate key and value, not a colon (`:`); using a colon would be interpreted as part of the key name, resulting in a key like 'APP_COLOR:blue' with an empty value. Option D is wrong because `--from-file` expects a file path or a file with a key specified as `key=filepath`, not a literal value; `--from-file=APP_COLOR=blue` would try to read a file named 'blue' and assign its contents to the key 'APP_COLOR', which is not the intended behavior.

Practice this question →
70
MCQhard

A pod's container has securityContext with runAsNonRoot: true but no runAsUser set. The container image has a user 'appuser' with UID 1001. Will the pod run successfully?

A.No, because runAsNonRoot requires an explicit runAsUser
B.No, because the container image user is unknown
C.Yes, because runAsNonRoot is ignored if runAsUser is not set
D.Yes, because the container image user is non-root
AnswerD

runAsNonRoot: true requires that the container does not run as root. The image's default user is non-root (1001), so it's allowed.

Why this answer

Option D is correct because when `runAsNonRoot: true` is set in the pod's security context without an explicit `runAsUser`, Kubernetes checks the container image's user (as defined in the Dockerfile `USER` directive). If that user is non-root (UID 1001 in this case), the container runs as that user, satisfying the non-root requirement. The pod will start successfully because the image user is non-root, and no explicit `runAsUser` is required.

Exam trap

CNCF often tests the misconception that `runAsNonRoot` requires an explicit `runAsUser` field, but the correct behavior is that Kubernetes falls back to the container image's user if no `runAsUser` is set.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot` does not require an explicit `runAsUser`; it can rely on the container image's user if it is non-root. Option B is wrong because the container image user is known (UID 1001) and is non-root, so the pod will run successfully. Option C is wrong because `runAsNonRoot` is not ignored when `runAsUser` is not set; it validates the container image's user instead.

Practice this question →
71
MCQhard

A pod is failing to start with error 'container has runAsNonRoot and image will run as root'. The container image runs as root. Which change allows the pod to run?

A.Remove runAsNonRoot: true from securityContext
B.Add fsGroup: 1000
C.Set allowPrivilegeEscalation: false
D.Set runAsUser to a non-zero UID, e.g., 1000
AnswerD

This overrides the image's user to a non-root user, satisfying runAsNonRoot.

Why this answer

Option B is correct: set runAsUser to a non-zero ID to run as non-root, satisfying runAsNonRoot. Option A removes the check but may be insecure. Option C does not change user.

Option D is not valid.

Practice this question →
72
Multi-Selecteasy

Which TWO of the following are required to create a Role and RoleBinding that grants read access to Pods in the 'development' namespace? (Choose two.)

Select 2 answers
A.A NetworkPolicy that allows traffic to Pods
B.A ClusterRole with the same rules
C.A RoleBinding that binds the Role to a subject (User or ServiceAccount)
D.A ClusterRoleBinding that binds the Role to a subject
E.A Role with apiGroups: [""], resources: ["pods"], verbs: ["get", "list", "watch"]
AnswersC, E

Correct.

Why this answer

Option C is correct because a RoleBinding is the Kubernetes resource that binds a Role (which defines permissions) to a specific subject (User, Group, or ServiceAccount) within a namespace. Without a RoleBinding, the permissions defined in the Role are not granted to any identity, making it a required component for granting access.

Exam trap

The trap here is that candidates often confuse RoleBindings with ClusterRoleBindings, thinking a ClusterRoleBinding is needed for a Role, or they mistakenly believe a NetworkPolicy is part of RBAC, when it is a separate network security mechanism.

Practice this question →
73
MCQhard

A pod is running with a service account that has been granted a Role to get pods. The pod's code uses the Kubernetes API from within the container. However, the API call fails with a 403 Forbidden error. Which file should the pod read to obtain the authentication token?

A./var/run/secrets/kubernetes.io/serviceaccount/token
B./etc/kubernetes/admin.conf
C./var/run/secrets/kubernetes.io/serviceaccount/namespace
D./var/run/secrets/kubernetes.io/serviceaccount/ca.crt
AnswerA

Correct. The token file is mounted at that path.

Why this answer

The pod's service account token is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. This token is a signed JWT that the pod uses to authenticate to the Kubernetes API server. Without reading this file, the pod cannot present valid credentials, resulting in a 403 Forbidden error.

Exam trap

CNCF often tests the distinction between the token file, the CA certificate, and the namespace file — candidates confuse the token with the CA cert or think the admin kubeconfig is accessible inside the pod.

How to eliminate wrong answers

Option B is wrong because /etc/kubernetes/admin.conf is the kubeconfig file for the cluster administrator, not for a pod's service account; it contains admin-level credentials and is not mounted inside pods. Option C is wrong because /var/run/secrets/kubernetes.io/serviceaccount/namespace contains only the namespace name, not an authentication token. Option D is wrong because /var/run/secrets/kubernetes.io/serviceaccount/ca.crt is the CA certificate used to verify the API server's TLS certificate, not an authentication token.

Practice this question →
74
MCQmedium

A pod with the following security context is in CrashLoopBackOff. The container image runs as user 1000. securityContext: runAsUser: 2000 runAsGroup: 3000 fsGroup: 4000 What is the most likely cause?

A.runAsUser is set to 2000, but the container expects to run as user 1000
B.runAsGroup is set to 3000, but the container expects group 1000
C.The pod does not have enough CPU resources
D.fsGroup is set to 4000, causing volume mount permission issues
AnswerA

This mismatch causes permission errors because the container's file permissions or processes require user 1000.

Why this answer

The container image is built to run as user 1000, but the Pod's securityContext overrides this with runAsUser: 2000. When the container starts, it attempts to access files or resources that require user 1000 permissions, causing it to fail and enter CrashLoopBackOff. The mismatch between the image's default user and the securityContext's runAsUser is the most direct cause of the crash.

Exam trap

CNCF often tests the nuance that runAsUser overrides the container image's default user, and candidates may incorrectly attribute the crash to group or volume issues without checking the actual user mismatch.

How to eliminate wrong answers

Option B is wrong because runAsGroup: 3000 does not conflict with the container expecting group 1000; the container image specifies a user (UID 1000), not a group, and group mismatches typically cause permission errors on files, not immediate crashes. Option C is wrong because insufficient CPU resources would manifest as a different error (e.g., OOMKilled or container pending), not a CrashLoopBackOff with a security context mismatch. Option D is wrong because fsGroup: 4000 affects volume mount permissions, but the question does not mention any volumes; without volumes, fsGroup has no effect, and even with volumes, it would cause permission errors on mounted files, not a crash on startup.

Practice this question →
75
Multi-Selecthard

Which THREE of the following are valid fields in a PodSecurityContext that affect container security? (Select 3)

Select 3 answers
A.capabilities
B.runAsUser
C.runAsGroup
D.privileged
E.fsGroup
AnswersB, C, E

Valid field in PodSecurityContext.

Why this answer

Option B (runAsUser) is correct because it is a valid field in a PodSecurityContext that specifies the user ID (UID) under which all containers in the pod run. This field directly affects container security by controlling privilege levels and access to host resources, overriding the container's default user.

Exam trap

The trap here is that candidates often confuse PodSecurityContext fields (which affect all containers in the pod) with container-level SecurityContext fields (which affect only a single container), leading them to incorrectly select 'capabilities' or 'privileged' as pod-level options.

Practice this question →
Page 1 of 4 · 233 questions totalNext →

Ready to test yourself?

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

Start 20-question session