Courseiva

CCNA Application Environment, Configuration and Security Questions

75 of 201 questions · Page 1/3 · 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

The `kubectl create configmap` command with `--from-file` reads the contents of the specified file and stores it as a single key (defaulting to the filename, `config.properties`) in the ConfigMap. This is the idiomatic way to import a configuration file's raw data without parsing or transforming it, making it perfect for arbitrary property files, YAML, or JSON. The resulting ConfigMap can then be mounted as a volume or consumed as environment variables by pods.

Why this answer

`kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named `app-config` with a single key `config.properties` (the filename) and the file's entire content as its value. The `--from-file` flag does not parse the file into separate key-value pairs. To parse lines like KEY=VALUE, you would use `--from-env-file`.

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

This is correct because drop: [ALL] first removes every capability from the container's effective and bounding sets, and add: ["NET_BIND_SERVICE"] then explicitly grants only the one capability required for binding to privileged ports such as 80 and 443. The resulting container runs with the minimal capability set possible, adhering to the principle of least privilege and satisfying the security requirement.

Why this answer

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 developer deploys a Pod that reads configuration from a ConfigMap named 'app-config' using a volume mount at /etc/config. Later, the ConfigMap is updated with new values. The application running in the Pod is designed to re-read the file periodically but continues to see the old values. What is the most likely reason the application is not seeing the updated configuration?

A.The ConfigMap volume is mounted as read-only, preventing updates from being propagated.
B.The Pod was created with the ConfigMap volume mounted using subPath, which prevents automatic updates.
C.The ConfigMap was updated using kubectl edit, which does not trigger a volume refresh.
D.The application is using an environment variable instead of reading the file from the volume mount.
AnswerB

When a ConfigMap volume is mounted with subPath, the kubelet does not receive update events for that specific file, so the content remains static. Without subPath, the kubelet periodically syncs the volume and updates the files. This is a common pitfall when developers use subPath for convenience. The application will continue to see the original values until the Pod is restarted or the volume is remounted without subPath.

Why this answer

ConfigMap volumes mounted without subPath are periodically updated by the kubelet, but when subPath is used, the kubelet does not sync changes to that file. The application re-reads the file but sees stale data because the file content is never refreshed. Removing subPath or restarting the Pod would resolve the issue.

Exam trap

The trap here is assuming that any ConfigMap volume automatically updates, overlooking that subPath mounts are excluded from the kubelet's sync mechanism.

Practice this question →
4
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 correctly grants the NET_ADMIN capability, which the kernel checks before allowing network administration operations inside the container's network namespace. The capabilities.add list augments the container's default capability set, permitting actions such as modifying iptables rules, adding or removing routes, and managing interface flags. It supplies the needed privilege with precision, following the least-privilege principle by adding only that specific capability.

Why this answer

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 →
5
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

In Kubernetes, the pod specification is the most authoritative source for pod-level settings. When a pod explicitly sets automountServiceAccountToken, that value overrides the automountServiceAccountToken field defined on the referenced ServiceAccount. This is by design: the ServiceAccount provides defaults, but the pod author retains final control over how the token is mounted. Therefore, even if the ServiceAccount has automountServiceAccountToken: false, a pod with automountServiceAccountToken: true will still have the token mounted.

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 →
6
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

The process runs as UID 1000 and GID 2000, satisfying the pod's runAsUser and runAsGroup constraints. fsGroup 3000 only affects volume ownership and supplementary group membership for mounted filesystems; it does not override the primary GID. The container's main process therefore keeps GID 2000 as its primary group.

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 →
7
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

Liveness probes check if a container is running (if they fail, the container is restarted). Readiness probes check if a container is ready to serve traffic (if they fail, traffic is not routed to it). Startup probes check if an application has started, used mainly for slow-starting containers.

Practice this question →
8
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

This is the correct RBAC combination: the Role defines the allowed actions within a specific namespace, and the RoleBinding, also namespaced, names the ServiceAccount as its subject, thereby granting those permissions only to that account and only within that namespace. Any pod that uses this ServiceAccount inherits the bound permissions, and the access is scoped exactly as needed, following least privilege.

Why this answer

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 →
9
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
AnswerA

This is the correct placement because the pod-level `securityContext` can legally include `runAsUser: 1000` and `runAsNonRoot: true`, which enforces that the container runs with UID 1000 and validates it is not running as root. The container-level `securityContext` is the only place where `readOnlyRootFilesystem` is accepted, so putting it there makes the pod valid and the root filesystem read-only. This demonstrates the proper scope: pod-wide user and group settings at the pod level, container-specific settings like read-only filesystem at the container level.

Why this answer

Ly sets runAsUser and runAsNonRoot at the pod level to enforce non-root execution with UID 1000, and readOnlyRootFilesystem at the container level, which is the correct placement for that field. The other options either use invalid fields (runAsRoot), omit runAsNonRoot, or incorrectly place readOnlyRootFilesystem at the pod level.

Exam trap

The trap is that readOnlyRootFilesystem must be set at the container level, not the pod level. Option D appears to have all three settings but places readOnlyRootFilesystem at the pod level, which is invalid. Candidates often overlook the level at which securityContext fields are applied.

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 →
10
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 uses the dedicated docker-registry subcommand, which generates a kubernetes.io/dockerconfigjson Secret. Under the hood it constructs a .dockerconfigjson key containing a JSON object with an auths map, where the registry server is mapped to base64-encoded credentials (username:password). The resulting value is exactly what kubelet expects when a pod references this secret via imagePullSecrets, so the private registry becomes accessible for pulling images.

Why this answer

`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 →
11
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

This is the correct command because `generic` creates the default `Opaque` Secret type, and `--from-literal=password=p@ssw0rd` explicitly defines a data entry with key `password` and value `p@ssw0rd`. Kubectl will automatically base64-encode the literal value when the Secret object is stored in etcd. The syntax follows the required `key=value` format, making it the only valid option.

Why this answer

`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 →
12
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

The `pod-security.kubernetes.io/enforce: restricted` annotation is the correct mechanism to actively enforce the strictest Pod Security Standard. When a namespace carries this label, the Pod Security Admission controller rejects any pod that fails the restricted policy, preventing its creation. This is the only option that both blocks violating resources and mandates the most hardened security posture, covering privileged containers, host namespaces, and other high-risk settings.

Why this answer

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 →
13
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 use base64 encoding on their data fields, which is simply an encoding scheme, not encryption—anyone with access to the Secret object can decode it trivially. ConfigMaps store their data as literal plaintext strings in the API object, making them readable directly. This distinction is a primary reason why Secrets are intended for sensitive data, even though base64 does not provide real confidentiality by itself.

Why this answer

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 →
14
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 logs for the container show an error such as 'listen tcp :8080: bind: address already in use' (or EADDRINUSE), which means the application process could not bind to its configured port because another process on the same network namespace already holds that port. Each pod shares one network namespace among its containers, so either another container in the pod, a host process at the node layer, or a previous instance still in the namespace is occupying the socket. This prevents the application from starting and causes the container to exit, leading Kubernetes to restart it with an exponential backoff, producing CrashLoopBackOff.

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 →
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

--from-file reads the file and stores its entire content under the key equal to the file's basename (config.properties). This preserves the raw file data as a single entry in the ConfigMap, which is exactly what an application expecting a properties file would read.

Why this answer

`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: true instructs Kubernetes to verify that the container's user ID is non-zero before starting, and it rejects the pod if the image would run as root or if no non-root user is specified. readOnlyRootFilesystem: true forces the container's root filesystem to be mounted read-only, so even a compromised non-root process cannot write to system directories. Together these two settings directly address both requirements: a non-root process with a read-only root filesystem.

Why this answer

`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

This option is correct: with readOnlyRootFilesystem: true, the container's root filesystem is mounted read-only by the container runtime. Any attempt to write to /tmp — a directory on the root filesystem — triggers an EROFS (read-only file system) error on the write syscall. The application, expecting to write temporary files, receives this I/O error and crashes (or exits with an error). This is the direct consequence of a read-only root filesystem without a writable volume mounted at /tmp.

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

Setting `enforce=baseline` configures the Pod Security Admission controller to actively reject any pod in the `dev` namespace that violates the baseline Pod Security Standard. The baseline standard is the minimal set of restrictions designed to prevent privilege escalation and covers key security contexts like `allowPrivilegeEscalation` and `privileged`. This label is the correct way to enforce the baseline standard, as it makes the admission controller deny non-compliant pods at creation time.

Why this answer

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

This is the correct behavior: setting readonlyRootFilesystem to true in the pod's securityContext causes the container's root filesystem to be mounted with the read-only flag. As a result, all write operations to any file or directory within the container's image filesystem (including the upper layer) will fail with a read-only file system error. This is a common security hardening measure to prevent runtime tampering of the container's 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 fail with an error, not 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

Setting runAsUser: 1000 in the pod's securityContext instructs the container runtime to launch the main process with UID 1000, which satisfies the requirement of running as a non-root user with that exact user ID. This overrides the default user defined in the image, ensuring all processes inside the container operate as UID 1000 rather than root, which is precisely what the statement demands.

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

The --from-file flag reads config.properties and stores its contents as a single key named after the file, producing the ConfigMap app-config. This matches the required name and file source exactly, unlike literal or directory-based alternatives.

Why this answer

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

automountServiceAccountToken: false is the correct way to prevent automatic mounting of the service account token into a pod. This boolean field, defined in the PodSpec, tells the kubelet not to project the service account token at /var/run/secrets/kubernetes.io/serviceaccount. It can also be set on a ServiceAccount to apply the same behavior to all pods that use that account. This is a security best practice for workloads that do not need to interact with the Kubernetes API.

Why this answer

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
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

The `kubectl create secret tls` subcommand builds a Kubernetes TLS secret directly from a certificate and private key pair, storing them under the required `tls.crt` and `tls.key` data keys that an Ingress controller expects. Supplying `--cert` and `--key` satisfies the stem's requirement to create the secret from both files.

Why this answer

`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 →
24
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

`defaultAddCapabilities` specifies a list of Linux capabilities that are appended to the `default` set of capabilities for every container created under the policy. It is a valid capability field because it directly controls which capabilities are added by default, complementing the container runtime defaults.

Why this answer

`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 →
25
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

Adding the NET_BIND_SERVICE capability to the container's securityContext grants the precise Linux capability that allows a non-root process to bind to Internet domain sockets with port numbers below 1024. This directly solves the port-binding problem while preserving the principle of least privilege, because the process continues to run as the unprivileged user 1000 and retains no other unnecessary capabilities. It is the correct, secure approach to exposing a service on a standard HTTP/HTTPS port.

Why this answer

The container process runs as a non-root user (UID 1000) and needs to bind to a privileged port (below 1024). Linux requires either root privileges or the CAP_NET_BIND_SERVICE capability to bind to ports below 1024. Adding this capability to the container's securityContext grants the process the necessary privilege without running as root, which is the correct and secure approach.

Exam trap

The trap here is that candidates often confuse allowPrivilegeEscalation with granting specific capabilities, or they incorrectly assume that dropping all capabilities is a safe default that still allows low-port binding, when in fact it removes the very capability needed.

How to eliminate wrong answers

Option A is wrong because allowPrivilegeEscalation controls whether a process can gain more privileges than its parent (e.g., via setuid binaries), but it does not grant the specific capability needed to bind to a privileged port. Option B is wrong because dropping all capabilities (capabilities.drop: [ALL]) removes all Linux capabilities, including any that might allow binding to low ports, making the problem worse. Option D is wrong because setting runAsUser: 0 runs the container as root, which would work but violates the principle of least privilege and is not the minimal change required; the question asks what to modify to allow binding, and adding the specific capability is the correct targeted fix.

Practice this question →
26
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

A ResourceQuota is a namespaced API object that, via the admission controller, enforces hard limits on aggregate resource use — such as requests.cpu, requests.memory, limits.cpu, limits.memory, and extended or storage resources — across every workload in the namespace. When a new object's resource totals would push the namespace past those limits, the creation request is rejected. In effect, it caps the combined consumption of all pods rather than applying constraints to any single container.

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 →
27
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

This correctly defines a namespaced Role in the test namespace with read-only pod verbs (get, list, watch) and binds it to the specified service account using a RoleBinding in the same test namespace. Because both the Role and RoleBinding are namespaced, the access is scoped precisely to the test namespace. The verb set is limited to read operations, satisfying the read-only requirement exactly.

Why this answer

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 →
28
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 resources: they bind a Role to a service account only within the namespace where the RoleBinding is created. If the RoleBinding resides in, say, 'kube-system' instead of 'test', the SA 'my-sa' in 'test' has no permissions, and the pod cannot list pods. The RoleBinding must be in the same namespace as the pod and its service account to take effect.

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 →
29
MCQeasy

A developer needs to create a Secret named 'db-credentials' in the 'staging' namespace using the literal values username=admin and password=S3cr3t!. Which kubectl command will accomplish this?

A.kubectl create secret tls db-credentials --from-literal=username=admin --from-literal=password=S3cr3t! -n staging
B.kubectl create secret generic db-credentials --from-literal=username:admin --from-literal=password:S3cr3t! -n staging
C.kubectl create secret generic db-credentials --from-literal=username=admin --from-literal=password=S3cr3t! -n staging
D.kubectl create secret generic db-credentials --from-file=username=admin --from-file=password=S3cr3t! -n staging
AnswerC

This command uses kubectl create secret generic with the --from-literal flag to specify key-value pairs directly. The -n staging flag targets the correct namespace. This is the standard way to create a Secret from literal values. The resulting Secret will have base64-encoded data for each key, which is the expected format for Kubernetes Secrets.

Why this answer

The kubectl create secret generic command with --from-literal is designed to create a Secret from literal key-value pairs. The -n flag specifies the namespace. The other options either use incorrect flags or syntax that does not match the intended use, such as --from-file requiring files or the tls type requiring certificates.

Exam trap

The trap here is confusing --from-literal with --from-file, or using a colon instead of an equals sign in the key-value pair.

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

This is the correct syntax because the PodSecurity admission controller reads the pod-security.kubernetes.io/enforce label to determine the enforced level for the namespace. Setting it to 'restricted' makes the controller reject every pod that does not conform to the Restricted Pod Security Standard, including privileged containers, host namespaces, or missing seccomp profiles. The label must be placed on the namespace, and the controller evaluates it at pod admission time, failing API requests that violate the policy.

Why this answer

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

A ResourceQuota is an admission controller resource that sets a hard ceiling on aggregate resource usage in a namespace. By configuring spec.hard.requests.memory to 10Gi, the Kubernetes API server sums the memory requests of all existing and newly created Pods in that namespace and rejects any new Pod that would push the total over 10Gi. This directly satisfies the requirement to restrict total memory usage across all Pods in the 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
MCQhard

A developer wants to run a container as a non-root user and prevent it from gaining additional privileges. The container image runs as root by default. Which securityContext configuration should be applied to the container to achieve this?

A.securityContext: { runAsUser: 1000, privileged: true }
B.securityContext: { runAsGroup: 1000, allowPrivilegeEscalation: true }
C.securityContext: { runAsNonRoot: true, privileged: false }
D.securityContext: { runAsUser: 1000, allowPrivilegeEscalation: false }
AnswerD

Setting runAsUser: 1000 ensures the container process runs as a non-root user. allowPrivilegeEscalation: false prevents the process from gaining more privileges than its parent (e.g., via setuid or setgid binaries). Together, these satisfy the requirements. This is a common best practice for hardening container security.

Why this answer

To run as a non-root user, runAsUser must be set to a non-zero UID. To prevent privilege escalation, allowPrivilegeEscalation must be false. The combination of runAsUser: 1000 and allowPrivilegeEscalation: false achieves both goals.

Other options either fail to set a non-root user, enable privilege escalation, or rely on runAsNonRoot without specifying a UID.

Exam trap

The trap here is thinking that runAsNonRoot alone is sufficient, or that privileged: false prevents privilege escalation, when actually allowPrivilegeEscalation is the specific control.

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 is a namespace-scoped resource that defines minimum, maximum, and default values for CPU and memory requests and limits per container or pod. Setting a max limit in a LimitRange ensures that any pod that declares a memory limit exceeding that maximum is rejected during admission control. It also can set default requests/limits for pods that do not specify them, giving the administrator direct control over per-pod resource bounds.

Why this answer

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

resources.limits.ephemeral-storage is a valid field in a container's resources block because ephemeral-storage is one of Kubernetes' three built-in basic resource types, alongside cpu and memory. It caps the amount of local scratch space (e.g., emptyDir volumes, container logs, and image layers) a container may consume, protecting node stability from runaway disk usage. Unlike persistent storage, this quota applies to the pod/container's usage of the node's local ephemeral storage, making it a legitimate resource field under resources.limits.

Why this answer

`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

By declaring `limits.cpu` and `limits.memory` in the quota's `hard` map, the namespace is forced to have every Pod set these fields explicitly. The quota admission controller rejects any Pod whose PodSpec does not include a CPU and memory limit, regardless of the actual values. This guarantees that no Pod can run unbounded, although it does not enforce a particular limit size; a LimitRange or individual Pod spec sets the actual numbers.

Why this answer

Option B is correct because a ResourceQuota can include the key limits.cpu and limits.memory (or requests.cpu/requests.memory), which forces every Pod in the namespace to declare matching resource limits or requests—otherwise the Pod is rejected at admission time. Option D is correct because by capping aggregate CPU, memory, storage, and object counts per namespace, ResourceQuota stops one namespace from consuming the entire cluster's capacity and starving other tenants. Option E is correct because ResourceQuota tracks the sum of requests/limits across all Pods in the namespace and denies any new Pod that would push the total past the configured CPU or memory ceiling.

Option A is not correct because setting default requests and limits is the job of a LimitRange, not a ResourceQuota. Option C is not correct because restricting which users can create Pods is handled by RBAC (Roles/RoleBindings) or admission policies, not by 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

Under the restricted Pod Security Standard, runAsNonRoot must be true, which enforces that the container's primary process runs as a non-root user (UID != 0). There is no securityContext setting that can override this; any attempt to set runAsUser: 0 would be invalidated by admission control. The only solution is to modify the container image to use a non-root user or to run under a different Pod Security Standard. Thus no SecurityContext field permits UID 0.

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

The `envFrom` block with `secretRef` is the recommended way to inject all key-value pairs from a Secret as environment variables in one go. Each key in the Secret becomes an environment variable name, and the corresponding value is the decoded Secret data. This automatically provides both `username` and `password` (or any other keys) to the pod without listing them individually.

Why this answer

`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

This is the correct form: the env entry declares the environment variable DB_PASSWORD, and valueFrom.secretKeyRef tells Kubernetes to retrieve the value of the key 'password' from the Secret named 'db-secret'. Because the secretKeyRef object is nested under valueFrom, the API server knows to fetch the key and inject it as an environment variable. This syntax provides an explicit one-to-one mapping between a specific secret key and a custom container environment variable name.

Why this answer

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
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

This is the correct and idiomatic way to inject a single value from a ConfigMap into an environment variable. The configMapKeyRef field explicitly names the ConfigMap (db-config) and the specific key (DB_URL), and Kubernetes resolves this reference when the pod is created. Unlike envFrom, it gives precise control over which entry gets injected, and unlike a literal value, it keeps the configuration externalized so the same manifest can be reused with different ConfigMaps.

Why this answer

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 →
40
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

This rule is correct because the apiGroups field uses an empty string "", which is the proper way to reference the Kubernetes core API group where pods live. The resource "pods" and verb "list" are valid, and because this is a Role (not a ClusterRole), it grants the ability to list pods only within the namespace where the Role is bound. This minimal, precise scope aligns with RBAC best practices.

Why this answer

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 →
41
MCQmedium

A Pod is running in a namespace with a default LimitRange that sets a default CPU request of 100m and a default CPU limit of 200m. The Pod's container spec does not specify any CPU requests or limits. What will be the effective CPU request and limit for the container?

A.CPU request: 200m, CPU limit: 200m
B.CPU request: 0, CPU limit: 0
C.CPU request: 100m, CPU limit: 200m
D.CPU request: 100m, CPU limit: 100m
AnswerC

The LimitRange's default values are applied to containers that do not specify their own CPU requests and limits. Since the container omits both, the default request of 100m and default limit of 200m are automatically set. This ensures that resources are allocated according to namespace policies. The Pod will be scheduled based on the 100m request and constrained by the 200m limit.

Why this answer

A LimitRange with default CPU request and limit values automatically applies those to containers that do not specify their own. The defaultRequest becomes the request, and the default becomes the limit. Thus, the container gets a CPU request of 100m and a limit of 200m, as defined in the LimitRange.

Exam trap

The trap here is assuming that without explicit requests and limits, the container gets none, or that the request and limit are always equal when defaults are applied.

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

This is correct when the security context also drops all Linux capabilities (e.g., `capabilities: drop: [ALL]`) alongside `allowPrivilegeEscalation: false`. The container's process starts with an empty effective and permitted capability set, and the `no_new_privs` flag stops it from acquiring any new capabilities through setuid, `execve`, or other escalation paths. The result is a container that has no extra capabilities and no mechanism to gain privileges at runtime.

Why this answer

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

The only way to inject a specific Secret key as an environment variable is to define an env entry with a name for the variable and a valueFrom block that contains secretKeyRef. Inside secretKeyRef, you provide the Secret object's name and the exact key you want; the referenced key's value is then resolved by the kubelet when the container starts. Using per-key entries gives you explicit control and avoids accidentally exposing unrelated Secret data.

Why this answer

`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, E

The generic subcommand with --from-file=key=file.txt explicitly assigns the file's contents to a chosen key inside the Secret's data map. This is the canonical way to create a Secret that holds a single arbitrary file, and kubectl automatically base64-encodes the value when the Secret is created, though the command line uses the raw file content. It is the recommended approach when you need to mount the file as a volume in a Pod.

Why this answer

Both options A and E are valid commands to create a Secret from a file. Option A uses `--from-file` to read file contents and store them under a specified key. Option E uses `--from-env-file` to parse a file with key=value pairs and create a Secret for environment variables.

Option C is incorrect for this question because `kubectl apply -f secret.yaml` applies a YAML manifest that defines a Secret, but it does not create a Secret directly from a file's contents in the same way as the `kubectl create secret` commands. The question asks for two commands that create a Secret from a file, and both A and E meet that criterion.

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

Pod Security Admission (PSA) is a built-in admission controller that enforces the Pod Security Standards, which define privileged, baseline, and restricted security profiles. The restricted profile explicitly requires readOnlyRootFilesystem: true, along with preventing privileged containers, host namespaces, and other high-risk capabilities. By labeling a namespace with the enforce level and restricted version, an administrator guarantees that every pod meets these mandatory security context requirements.

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

The `kubectl create secret generic` command instantiates a Secret of type Opaque (generic) in the current namespace. `--from-literal` takes a key=value pair directly and base64-encodes the value when storing it in the Secret's `data` map. Multiple `--from-literal` flags are allowed, so this command creates a Secret named `db-secret` with two data entries: `username` and `password` with the provided literal strings.

Why this answer

`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

Setting `automountServiceAccountToken: false` in the pod spec stops the kubelet projecting the ServiceAccount token into the container's filesystem, satisfying the requirement to prevent automatic mounting. This field overrides the ServiceAccount's own setting, giving per-pod control without altering the `my-sa` object itself.

Why this answer

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

The apps/v1 version is the stable, general-availability API for Deployment and other workload resources. It has been the standard since Kubernetes 1.9 and is fully supported by all modern clusters, containing the complete set of stable fields and behaviors. kubectl and other tooling default to this version, making it the correct and safest apiVersion for Deployment manifests.

Why this answer

(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

This correctly maps the password key from the db-secret Secret into the DB_PASSWORD environment variable via valueFrom.secretKeyRef. Kubernetes fetches the value from the Secret at container creation and exposes it to the process exactly as named. This is the standard, recommended pattern for injecting a single secret key into a pod.

Why this answer

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

PodSecurityPolicy (PSP) was formally deprecated in Kubernetes v1.21 and entirely removed in v1.25, making it unavailable in current clusters. Its successor, Pod Security Admission (PSA), is a built-in admission controller that enforces the Pod Security Standards (baseline, restricted, privileged) at namespace granularity, addressing PSP's complexity and management overhead by providing a simpler, declarative approach without needing custom webhooks or separate RBAC.

Why this answer

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

When a syscall is blocked by a seccomp profile, the kernel returns an error (commonly EPERM) to the process that made the call. The process's behavior after that depends entirely on how the application handles the error: it may log the failure, retry, or abort, but the container itself is not automatically stopped. Many applications do not check for seccomp-related errors and continue running with degraded functionality, so the container often remains alive and running.

Why this answer

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

The --from-file flag reads the entire content of config.properties and stores it as the Value of a single data entry whose Key is the file basename, config.properties. This is the correct way to create a ConfigMap when you want the file's raw content exposed intact, for example when mounting it to a volume or consuming via envFrom. By default, kubectl also ensures the ConfigMap is named app-config as specified.

Why this answer

`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
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

This is the correct way to create a ConfigMap from literal values: each --from-literal flag declares one key-value pair, and repeating the flag adds multiple entries to the ConfigMap's data field. The resulting resource will have data containing color: blue and size: large. This syntax is unambiguous, follows the kubectl CLI contract, and works in scripts without external files.

Why this answer

`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 →
54
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

The correct flag, --from-file, imports the specified file as a single ConfigMap entry, with the key defaulting to the file's basename (app.properties) and the value being the complete file content. This is the standard way to store a raw configuration file so it can later be mounted as a volume or exposed as a single environment variable. It works for any file format, including properties, YAML, JSON, or text, without requiring the content to look like KEY=VALUE pairs.

Why this answer

`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 →
55
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

The serviceAccountName field is the correct way to assign the ServiceAccount my-sa to the pod. It is a top-level field in the pod spec, and when set, all containers in the pod share the identity and permissions of that ServiceAccount. Omitting it defaults to the 'default' ServiceAccount in the namespace.

Why this answer

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 →
56
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

spec.serviceAccountName is the exact field used to specify which ServiceAccount should be attached to a Pod. This string field must reference a ServiceAccount that exists in the same namespace as the Pod, and if omitted, it defaults to 'default'. It is the basis for the Pod's identity for RBAC authorization and for authentication when contacting the Kubernetes API.

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 →
57
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

Role and RoleBinding are namespaced resources, so the permissions they grant apply only within ns1. Listing pods in ns2 requires a separate Role and RoleBinding in that namespace, or a ClusterRole paired with a ClusterRoleBinding for cluster-wide access. The stem's cross-namespace failure confirms this scoping constraint.

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 →
58
MCQhard

A Pod in namespace 'team-a' runs with a serviceAccountName of 'reporter'. The Pod must read a Secret named 'metrics-token' that lives in namespace 'team-b'. Cluster-wide RBAC and the ServiceAccount token are already configured correctly. Which Pod specification change allows the container to obtain the Secret's data?

A.Use the ServiceAccount token to call the API server for the Secret in 'team-b', then write the returned data into a file the application reads.
B.Create a Secret in 'team-a' that has the same name, and rely on the kubelet to mirror the data from 'team-b' automatically.
C.Mount a volume of type secret with secretName 'metrics-token' and add a volumeMount at /var/run/metrics.
D.Add an env entry with valueFrom.secretKeyRef naming 'metrics-token' and set the Pod's namespace field to 'team-b'.
AnswerA

Secrets are namespaced objects, and the supported way to reach one in another namespace is through the Kubernetes API with credentials that RBAC authorizes. Since the ServiceAccount token and cluster-wide RBAC are already correct, the container can project the token and use an init container or sidecar to fetch the Secret and write it to a shared file for the application.

Why this answer

Secret references such as secretKeyRef and secret volume sources resolve only inside the Pod's own namespace, so a Pod in 'team-a' cannot directly project a Secret stored in 'team-b'. The API server is the cross-namespace path, and the Pod's ServiceAccount token, combined with the already-correct RBAC, lets the container retrieve the Secret and stage its data into a file the application consumes.

Exam trap

The trap here is expecting a namespace field on a Secret reference or on the Pod spec to permit cross-namespace Secret access.

Practice this question →
59
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

In a kubernetes.io/tls Secret, the data field must contain exactly tls.crt (the PEM-encoded certificate chain) and tls.key (the PEM-encoded private key). These two keys are mandatory: the API server validates their presence at creation time, and Ingress controllers or application pods rely on them for TLS termination. Without either key, the Secret cannot be used for its intended cryptographic purpose.

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 →
60
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

Combining runAsNonRoot: true with allowPrivilegeEscalation: false provides defense in depth: the former ensures the container does not start as root, while the latter prevents the process from gaining any additional privileges beyond its current non-root identity, such as via setuid execution or other escalators. This layered approach both satisfies the non-root mandate and blocks a common privilege escalation vector, making it the correct configuration for secure pod deployment.

Why this answer

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 →
61
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

The command correctly uses the --from-literal flag, which accepts a key=value pair directly on the command line and stores the provided value as the data entry in the ConfigMap. This creates a ConfigMap named app-config with a key color whose value is the string blue. This is the standard and intended way to define a simple literal value as a ConfigMap data source.

Why this answer

`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 →
62
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

Setting the label 'pod-security.kubernetes.io/enforce=restricted' on the namespace activates the Pod Security Admission controller's restricted policy for all Pods created in that namespace. This label causes the admission controller to reject any Pod that does not meet the restricted profile's requirements, such as running as non-root and using a seccomp profile. It is the standard mechanism for enforcing PSA policies at the namespace level.

Why this answer

Option A is correct because PSA enforcement is enabled per-namespace by applying the label 'pod-security.kubernetes.io/enforce=restricted' to the 'dev' namespace, which tells the Pod Security Admission controller to reject Pods that violate the restricted profile. Option E is correct because the restricted profile imposes strict requirements — such as runAsNonRoot: true, allowPrivilegeEscalation: false, dropping ALL capabilities, and setting seccompProfile.type to RuntimeDefault or Localhost — so workloads must be configured to satisfy these controls to be admitted. Option B is incorrect because merely setting runAsUser: 1000 does not satisfy the restricted profile, which specifically requires runAsNonRoot rather than a fixed UID.

Option C is incorrect because 'baseline' is a less restrictive profile than 'restricted' and would not enforce the required policy. Option D is incorrect because the 'warn' label only produces warnings and does not enforce the restricted profile; enforcement requires the 'enforce' label.

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 →
63
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

This is correct because a RoleBinding always scopes the permissions it grants to the namespace where the RoleBinding itself is created. The ClusterRole named 'secret reader' defines the verbs get, list, and watch on secrets, but the RoleBinding in namespace 'app' limits those permissions to secrets in 'app'. Since secrets are namespaced resources, the effective access is exactly get/list/watch for secrets only in the 'app' 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 →
64
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

The kube-scheduler places a pod only if every node has enough unused allocatable resources to meet the pod's requests. If the combined memory and CPU requests exceed what is available on any node, the pod is stuck in Pending. Lowering both request values to fit within the allocatable capacity remaining on an existing node allows the scheduler to find a feasible host and bind the pod.

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 →
65
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

This is a direct method to expose a single key from a Secret as a named environment variable. In the container spec, you define an env entry with a name and valueFrom.secretKeyRef referencing the Secret and key. Kubernetes decodes the base64 value and injects it into the container's environment. This approach gives precise control over which secret values become env vars and what their variable names are.

Why this answer

`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 →
66
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

This is the correct command because --from-literal directly accepts an inline key=value pair and stores it as a single data entry in the ConfigMap. The syntax --from-literal=APP_COLOR=blue precisely defines the key as APP_COLOR and the value as blue, with no filesystem involvement. kubectl then creates the ConfigMap with the specified name 'app-config' containing this literal.

Why this answer

`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 →
67
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

This is correct because the container image sets a non-root default user (UID 1001) in its metadata. With runAsNonRoot: true and no explicit runAsUser in the securityContext, the kubelet verifies that the image's effective UID is not 0; since 1001 is non-root, the container is permitted to run. The flag acts as a guard that confirms the actual user the container will run as is safe.

Why this answer

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 →
68
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

Setting runAsUser to a non-zero UID (e.g., 1000) explicitly overrides the user ID with which the container's main process runs. When runAsNonRoot: true is set, Kubernetes admission (and the container runtime) verifies that the resulting effective UID is non-zero, so a UID of 1000 satisfies the check. This is the correct fix because it keeps the security safeguard while ensuring the container actually runs as a non-root user, avoiding the immediate error and complying with best practices for container security.

Why this answer

The error 'container has runAsNonRoot and image will run as root' indicates that the pod's securityContext has runAsNonRoot: true, but the container image runs as root (UID 0). To satisfy the runAsNonRoot constraint, you must override the container's user to a non-zero UID by setting runAsUser to a non-zero value (e.g., 1000). This forces the container to run as a non-root user, resolving the conflict.

Exam trap

The trap here is that candidates mistakenly think removing runAsNonRoot (Option A) is the fix, but the exam tests that you must satisfy the security constraint by changing the user, not disabling the check.

How to eliminate wrong answers

Option A is wrong because removing runAsNonRoot: true would bypass the security requirement but does not address the root cause; the image still runs as root, which may violate security policies. Option B is wrong because fsGroup sets the group ID for volume ownership, not the user ID the container runs as, and does not change the effective UID from root. Option C is wrong because allowPrivilegeEscalation: false controls whether a process can gain more privileges than its parent, but it does not change the user the container runs as; the container would still start as root, triggering the same error.

Practice this question →
69
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

A RoleBinding is the mandatory link that assigns the Role's permissions to a subject, such as a User, Group, or ServiceAccount, within a namespace. Without it, the Role exists in isolation and grants nothing. It also allows binding a ClusterRole, but here it binds the Role you created, completing the RBAC grant.

Why this answer

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 →
70
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

Kubernetes projects the service account token into every pod at a fixed projected volume path. Reading /var/run/secrets/kubernetes.io/serviceaccount/token supplies the bearer token the pod presents to the API server, resolving the 403 caused by missing authentication.

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 →
71
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

When runAsUser overrides the image's declared USER to 2000 while the application's files and configuration expect uid 1000, the process can't read or write its own runtime files, often encountering 'permission denied' at startup. This manifests as the container exiting immediately with a non-zero code, which Kubernetes reports as CrashLoopBackOff. The fix is to set runAsUser to 1000 or adjust file ownership to match 2000.

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 →
72
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

runAsUser is a valid field in PodSecurityContext, specifying the numeric UID that all containers in the pod must run with. It overrides any user defined in the container image, enforcing a non-root user consistently across the pod. This field is also available at the container level, but when set at the pod level it applies to every container unless an individual container overrides it.

Why this answer

(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 →
73
MCQeasy

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

A.runAsGroup: 3000
B.runAsUser: 1000
C.readOnlyRootFilesystem: true
D.runAsNonRoot: true
AnswerD

runAsNonRoot: true is a securityContext validation that ensures the container will not start if it is configured to run as root. Kubernetes checks the user defined in the image metadata (or the runtime user) and refuses to launch the pod if the UID is 0 or unspecified. This directly enforces the non-root requirement, providing a hard guarantee that the container runs with an unprivileged user ID. It is the only option that actively prevents root execution, making it the correct choice for this question.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
74
MCQmedium

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

A.envFrom: - configMapRef: name: db-config
B.env: - name: DB_URL valueFrom: configMapKeyRef: name: db-config key: url
C.env: - name: DB_URL valueFrom: secretKeyRef: name: db-config key: url
D.env: - name: DB_URL valueFrom: configMap: name: db-config key: url
AnswerB

This is the correct syntax for referencing a single key from a ConfigMap. The valueFrom.configMapKeyRef field tells Kubernetes to look up the ConfigMap named db-config, read the value stored under the key url, and assign it to the environment variable DB_URL. This enables precise, selective injection of configuration data without importing the entire ConfigMap.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
75
MCQeasy

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

A.Privileged, Default
B.Default
C.Restricted
D.Secure
AnswerC

Restricted is a valid Pod Security Admission standard, representing the most stringent level. It enforces namespaces and pods to follow best practices such as disallowing privileged containers, dropping all capabilities, and setting a non-root user. This standard is often chosen for sensitive production workloads to minimize container escape risks.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
Page 1 of 3 · 201 questions totalNext →

Ready to test yourself?

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

Start 20-question session