Courseiva

Certified Kubernetes Application Developer CKAD (CKAD) — Questions 1–75

991 questions total · 14pages · All types, answers revealed

Take a mock examExam hub

Page 1 of 14

Page 2
1
MCQeasy

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
2
MCQmedium

A developer creates a Deployment with 3 replicas that uses a ConfigMap mounted as a volume. After updating the ConfigMap, the developer expects the pods to pick up the new configuration immediately, but the old configuration is still in use. What is the most likely reason?

A.ConfigMap updates are not propagated to mounted volumes.
B.The kubelet sync interval delays the propagation of ConfigMap changes to pods.
C.The pods must be recreated after a ConfigMap update to see the changes.
D.ConfigMaps are immutable and cannot be updated.
AnswerB

The kubelet periodically syncs ConfigMap data; changes may take up to the sync period to appear.

Why this answer

When a ConfigMap is mounted as a volume, updates to the ConfigMap are eventually propagated to the pods, but not instantly. The kubelet periodically syncs mounted ConfigMaps (default interval is 60 seconds), so there is a delay before pods see the new configuration. This is the most likely reason the old configuration is still in use.

Exam trap

The trap here is that candidates often assume ConfigMap updates are either instant or require pod recreation, but the CKAD exam tests the nuance that mounted volumes are updated with a kubelet sync delay, while environment variables are not updated at all.

How to eliminate wrong answers

Option A is wrong because ConfigMap updates are propagated to mounted volumes — the kubelet does update the files in the volume, but with a sync delay. Option C is wrong because pods do not need to be recreated; the mounted volume is updated in-place by the kubelet, though some applications may require a restart to reload the configuration. Option D is wrong because ConfigMaps are not immutable by default; they can be updated unless explicitly created with the `immutable: true` field.

Full explanation →
3
Multi-Selectmedium

Which TWO of the following are valid fields in a Job spec? (Select TWO.)

Select 2 answers
A.replicas
B.backoffLimit
C.schedule
D.restartPolicy
E.parallelism
AnswersB, E

Specifies the number of retries before marking the Job as failed.

Why this answer

Options B and D are correct. 'parallelism' controls concurrency, 'backoffLimit' controls retries. Option A (restartPolicy) is a pod-level field, not a Job spec field; Jobs have a default restartPolicy of OnFailure. Option C (replicas) is for Deployments.

Option E (schedule) is for CronJobs.

Full explanation →
4
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
5
Multi-Selectmedium

Which TWO commands can be used to create resources in Kubernetes? (Select TWO.)

Select 2 answers
A.kubectl describe
B.kubectl get
C.kubectl create
D.kubectl run
E.kubectl apply
AnswersC, E

Creates resources from file or stdin.

Why this answer

kubectl create and kubectl apply can both create resources. kubectl run creates a pod, but it's more specific. kubectl get reads resources, kubectl describe reads.

Full explanation →
6
MCQeasy

Refer to the exhibit. A pod named 'app-backend-6b4c9d8f7-2x4z5' is in CrashLoopBackOff state. What is the MOST likely cause of this issue?

A.The container is crashing due to a misconfiguration or application error.
B.The container has exceeded its memory limit and is being OOMKilled.
C.The node running the pod is down, preventing the container from starting.
D.A network policy is blocking the container from accessing required services.
AnswerA

CrashLoopBackOff indicates repeated crashes, often from configuration or code issues.

Why this answer

A CrashLoopBackOff state indicates that the container in the pod is repeatedly crashing and being restarted by the kubelet. The most common cause is a misconfiguration (e.g., incorrect environment variables, missing dependencies, or a faulty entrypoint script) or an application error (e.g., a runtime exception or panic). The kubelet detects the crash via the container runtime (e.g., containerd) and applies an exponential backoff delay before restarting, leading to the CrashLoopBackOff status.

Exam trap

CNCF often tests the distinction between CrashLoopBackOff and other pod failure states like OOMKilled or ImagePullBackOff, and the trap here is that candidates may assume any crash is due to resource limits or network issues without checking the specific exit code or pod events.

How to eliminate wrong answers

Option B is wrong because an OOMKilled container would show a status of 'OOMKilled' in the pod's last state, not CrashLoopBackOff; CrashLoopBackOff is a generic restart loop, not a specific resource limit violation. Option C is wrong because if the node were down, the pod would be in 'NodeLost' or 'Unknown' state, and the kubelet would not be able to restart the container; CrashLoopBackOff requires the kubelet to be actively managing the pod. Option D is wrong because a network policy blocking access would cause the application to fail to connect to services, but the container itself would still start and run (possibly with errors), not crash immediately; CrashLoopBackOff implies the container process exits with a non-zero code at startup.

Full explanation →
7
MCQmedium

You have a Deployment with 'replicas: 3' and the HPA is configured with 'targetCPUUtilizationPercentage: 80'. The current CPU usage is at 60% across all pods, but the HPA has scaled up to 5 replicas. What is the most likely reason?

A.The 'targetCPUUtilizationPercentage' might be set differently on the Deployment's resource spec
B.The HPA has a behavior policy that scales up aggressively
C.The HPA is using the 'averageUtilization' target type on a custom metric, not CPU
D.The HPA is reading the total CPU usage instead of average
AnswerA

If the container's resource requests are set lower than actual usage, the utilization percentage can be higher. For example, if request is 100m but usage is 200m, utilization is 200% even if absolute CPU is low. This could trigger scaling.

Why this answer

The HPA may be using average utilization across all pods. With 3 pods at 60% each, average is 60%, below 80%, so it should not scale up. However, if one pod is at high CPU and others low, the average might be skewed.

But the most common reason for unexpected scaling is custom metrics or behavior policies. Option B is plausible: the HPA's behavior configuration might include a scale-up stabilization window that causes aggressive scaling. Or maybe the target is average value, not percentage? Actually, the question says 'most likely reason'.

Option D (different target) is also possible but less likely. Let's go with D.

Full explanation →
8
MCQmedium

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

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

This adds the NET_ADMIN capability to the container.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
9
Multi-Selecteasy

Which TWO of the following are valid fields in a Kustomize kustomization.yaml file? (Select two)

Select 2 answers
A.containers
B.patches
C.apiVersion
D.resources
E.replicas
AnswersB, D

Valid field for strategic merge patches.

Why this answer

Option A ('resources') and Option C ('patches') are valid Kustomize fields. Option B ('containers') is not a top-level field. Option D ('apiVersion') is not a Kustomize field; it's part of the YAML but not a content field.

Option E ('replicas') is not a direct field in kustomization.yaml; it's used in patches.

Full explanation →
10
MCQmedium

A developer runs `kubectl expose deployment web-deploy --port=80 --target-port=8080 --type=NodePort` and later wants to access the Service from outside the cluster. What is the correct way to find the external port?

A.Run `kubectl get nodes -o wide` and use the node's external IP and port 80.
B.Run `kubectl get pod -l app=web-deploy` and use the pod IP with port 8080.
C.Run `kubectl describe svc web-deploy` and look for the NodePort field.
D.Run `kubectl get svc web-deploy -o yaml` and look for `spec.ports[0].port`.
AnswerC

`kubectl describe svc` shows NodePort in the Port section.

Why this answer

The `kubectl get svc web-deploy` command shows the NodePort assigned in the PORT(S) column, e.g., 80:31234/TCP.

Full explanation →
11
MCQeasy

Which command scales a Deployment named 'web' to 5 replicas?

A.kubectl set replicas deployment web 5
B.kubectl scale deployment web --replicas=5
C.kubectl resize deployment web --replicas=5
D.kubectl autoscale deployment web --replicas=5
AnswerB

This is the correct syntax.

Why this answer

The correct command is 'kubectl scale deployment web --replicas=5'.

Full explanation →
12
Multi-Selectmedium

A developer is creating a CronJob that should not start a new job if the previous one is still running. Which TWO configurations achieve this? (Select exactly 2.)

Select 2 answers
A.Set concurrencyPolicy: Allow
B.Set startingDeadlineSeconds to a low value
C.Set concurrencyPolicy: Replace
D.Set concurrencyPolicy: Forbid
E.Use a schedule that ensures jobs finish before the next scheduled time
AnswersD, E

Forbid prevents new job creation while a previous job is still running.

Why this answer

concurrencyPolicy: Forbid prevents overlapping jobs. Also, setting a schedule that never overlaps (though less flexible) or using 'Allow' would not prevent overlap.

Full explanation →
13
MCQhard

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

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

Pod-level automountServiceAccountToken overrides the ServiceAccount's setting.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
14
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
15
Matchingmedium

Match each Kubernetes probe to its check behavior.

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

Concepts
Matches

Runs a command inside the container; success if exit 0

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

Attempts to open a TCP socket; success if connection established

Performs a gRPC health check (alpha)

Indicates whether the application has started successfully

Why these pairings

Probes are used for health checking and readiness.

Full explanation →
16
MCQeasy

Which of the following commands creates a Service named 'my-svc' of type ClusterIP that exposes TCP port 80 on a set of pods selected by the label 'app: web'?

A.kubectl port-forward my-pod 8080:80
B.kubectl expose deployment my-deploy --port=80 --type=LoadBalancer --name=my-svc
C.kubectl expose pod my-pod --port=80 --target-port=80 --type=NodePort --name=my-svc
D.kubectl expose pod my-pod --port=80 --target-port=80 --type=ClusterIP --name=my-svc --selector=app=web
AnswerD

Correct. The expose command creates a ClusterIP Service with the given name and port mapping.

Why this answer

The 'kubectl expose' command with '--type=ClusterIP' creates a ClusterIP Service. The '--port' flag specifies the service port, and '--target-port' maps to the container port. The selector is derived from the pod's labels (here 'app: web').

Option A is correct. Option B uses NodePort, which is incorrect. Option C uses LoadBalancer.

Option D is a port-forward command, not a Service creation.

Full explanation →
17
MCQmedium

A pod is stuck in 'Pending' state. You run 'kubectl describe pod my-pod' and see the event: '0/3 nodes are available: 3 Insufficient cpu.' Which action should you take?

A.Increase the CPU limits on the pod to give it more resources.
B.Reduce the CPU request of the pod and reapply the manifest.
C.Add another node to the cluster to increase overall CPU capacity.
D.Add a nodeSelector to the pod to target a specific node.
AnswerB

Lowering CPU request may allow the pod to fit on a node with available CPU.

Why this answer

The pod is stuck in 'Pending' because the scheduler cannot find a node with enough allocatable CPU to satisfy the pod's CPU request. Reducing the CPU request (the amount guaranteed to the container) makes the pod schedulable on existing nodes. Increasing limits would only worsen the problem, as limits are a cap on usage, not a scheduling constraint.

Exam trap

The trap here is that candidates confuse CPU requests with CPU limits, assuming that increasing limits gives the pod more resources, when in fact the scheduler only checks requests for admission, and limits are a runtime constraint.

How to eliminate wrong answers

Option A is wrong because increasing CPU limits does not affect scheduling; the scheduler only considers requests, not limits. Option C is wrong because adding a node is an operational overhead and not the immediate fix; the issue is that the pod's request is too high for the current cluster capacity. Option D is wrong because a nodeSelector targets a specific node but does not resolve the underlying resource insufficiency; if no node has enough CPU, the pod will still remain Pending.

Full explanation →
18
MCQmedium

Which field in a HorizontalPodAutoscaler spec defines the target CPU utilization percentage?

A.spec.behavior
B.spec.metrics[0].resource.target.averageUtilization
C.spec.maxReplicas
D.spec.targetCPUUtilizationPercentage
AnswerD

Correct. In autoscaling/v1 HPA, this field sets the CPU target.

Why this answer

The targetCPUUtilizationPercentage field in the HPA spec (for autoscaling/v1) or in the metric spec (for autoscaling/v2) defines the CPU target.

Full explanation →
19
MCQeasy

A developer is designing a Job that should run exactly once and then stop. The Job runs a batch process that is expected to complete within one hour. Which restartPolicy and backoffLimit are appropriate?

A.restartPolicy: Always, backoffLimit: 6
B.restartPolicy: OnFailure, backoffLimit: 4
C.restartPolicy: Never, backoffLimit: 0
D.restartPolicy: Always, backoffLimit: 0
AnswerB

OnFailure retries within the backoff limit; Job completes when pod succeeds.

Why this answer

Option B is correct because a Job designed to run exactly once and stop should use `restartPolicy: OnFailure` or `Never`, and `backoffLimit: 4` provides a reasonable number of retries (up to 4) before the Job is marked as Failed, ensuring the batch process can recover from transient errors within the expected one-hour completion window. The `restartPolicy: Always` is invalid for Jobs (only `OnFailure` or `Never` are allowed), and `backoffLimit: 0` would prevent any retries, which is too restrictive for a batch process that may encounter temporary failures.

Exam trap

The trap here is that candidates often confuse the `restartPolicy` for Pods in a Job with the `restartPolicy` for Deployments, forgetting that Jobs only accept `OnFailure` or `Never`, and that `backoffLimit` controls retries at the Job level, not the container level.

How to eliminate wrong answers

Option A is wrong because `restartPolicy: Always` is not permitted for a Kubernetes Job; Jobs only support `OnFailure` or `Never`, and using `Always` would cause an API validation error. Option C is wrong because `backoffLimit: 0` means the Job will not retry at all after a failure, which is inappropriate for a batch process that may need a few retries to complete successfully within the one-hour window. Option D is wrong because `restartPolicy: Always` is invalid for Jobs, and `backoffLimit: 0` would also prevent any retries, combining two incorrect settings.

Full explanation →
20
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
21
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
22
MCQeasy

A pod is running but not responding to traffic. You suspect the application inside the container is unhealthy but the pod is still marked as 'Running'. Which probe should be configured to remove the pod from the service's endpoints automatically?

A.Readiness probe
B.Resource limits
C.Startup probe
D.Liveness probe
AnswerA

Correct. Readiness probe indicates whether the container is ready to serve traffic; failure removes the pod from service backends.

Why this answer

A readiness probe determines if a container is ready to serve traffic. If it fails, the pod is removed from service endpoints.

Full explanation →
23
MCQhard

A team uses a Service named 'backend' in namespace 'prod' to reach Pods in namespace 'staging'. The Service in 'prod' has no endpoints. What is the most likely cause?

A.The Service port name does not match the container port
B.The Service selector does not match any Pods in the same namespace
C.The Service type is ClusterIP but should be NodePort
D.DNS resolution is broken in the staging namespace
AnswerB

Service selects Pods only within its own namespace; no matching Pods in prod means no endpoints.

Why this answer

The Service in the 'prod' namespace has no endpoints because its selector does not match any Pods in the same namespace. Kubernetes Services only discover Pods within the same namespace via label selectors; cross-namespace access requires a different approach (e.g., ExternalName Service or manual endpoint configuration). Since the Pods are in 'staging', the selector in 'prod' finds no matching Pods, resulting in zero endpoints.

Exam trap

The trap here is that candidates assume Services can automatically discover Pods across namespaces, but Kubernetes restricts Service selectors to the same namespace, so a Service in 'prod' cannot select Pods in 'staging' without manual endpoint configuration.

How to eliminate wrong answers

Option A is wrong because a port name mismatch would cause connectivity issues but would not prevent the Service from having endpoints—endpoints are generated based on selector matches, not port names. Option C is wrong because Service type (ClusterIP vs. NodePort) affects external accessibility, not endpoint population; a ClusterIP Service can still have endpoints if the selector matches Pods.

Option D is wrong because DNS resolution is irrelevant to endpoint creation; endpoints are populated by the kube-controller-manager based on selector matching, not DNS.

Full explanation →
24
Matchingmedium

Match each Kubernetes object field to its description.

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

Concepts
Matches

Maximum resources a container can use

Determines when to restart containers in a pod

Checks if container is running; restarts if fails

Checks if container is ready to serve traffic

Inject a secret value as an environment variable

Why these pairings

These fields are essential for pod configuration and health checks.

Full explanation →
25
MCQeasy

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
26
Multi-Selecteasy

Which TWO of the following commands can be used to create a Pod in Kubernetes? (Select 2)

Select 3 answers
A.kubectl create service my-svc --image=nginx
B.kubectl create deployment mydeploy --image=nginx
C.kubectl run mypod --image=nginx
D.kubectl apply -f pod.yaml
E.kubectl create cronjob myjob --image=nginx
AnswersB, C, D

Correct: creates a Deployment that manages pods.

Why this answer

kubectl run and kubectl create deployment (which creates a Deployment that in turn creates pods) can be used. kubectl apply can apply a YAML file that defines a pod. However, kubectl create cronjob creates a CronJob, not a pod. kubectl create service creates a Service.

Full explanation →
27
MCQeasy

A DevOps engineer needs to set up resource monitoring for pods in a namespace. Which built-in Kubernetes resource provides CPU and memory metrics out-of-the-box?

A.Metrics Server
B.Prometheus
C.CoreDNS
D.Kubernetes Dashboard
AnswerA

Built-in cluster addon for resource metrics.

Why this answer

The Metrics Server is the built-in Kubernetes resource that collects resource metrics (CPU and memory) from the kubelet on each node via the Summary API and exposes them through the metrics.k8s.io API. It provides these metrics out-of-the-box without requiring any additional configuration or external storage, making it the standard solution for horizontal pod autoscaling and kubectl top commands.

Exam trap

CNCF often tests the distinction between built-in Kubernetes components and third-party add-ons, so candidates may mistakenly choose Prometheus because it is a popular monitoring tool, but the question specifically asks for a built-in resource that provides metrics out-of-the-box.

How to eliminate wrong answers

Option B is wrong because Prometheus is a third-party monitoring system that is not built into Kubernetes; it requires separate installation and configuration, and while it can scrape metrics, it is not the built-in resource for CPU and memory metrics. Option C is wrong because CoreDNS is a DNS server for service discovery within the cluster, not a metrics provider; it has no capability to expose CPU or memory metrics. Option D is wrong because Kubernetes Dashboard is a web UI for managing the cluster, not a metrics source; it relies on the Metrics Server or another backend to display resource usage data.

Full explanation →
28
MCQeasy

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

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

Correct syntax: generic secret with literal key=value.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
29
MCQhard

Given the following NetworkPolicy YAML: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress - Egress What is the effect of this policy?

A.Denies all ingress and egress traffic to and from all pods in the namespace
B.Denies all ingress traffic but allows all egress traffic
C.Allows all traffic to and from pods in the namespace
D.Denies all traffic except traffic that is explicitly allowed by other policies
AnswerA

Correct. The policy denies all traffic because it has no allow rules.

Why this answer

The NetworkPolicy selects all pods in the namespace (empty podSelector). It specifies both Ingress and Egress policyTypes, but no rules under ingress or egress. This means all inbound and outbound traffic is denied for those pods.

Option D is correct. Option A is wrong because it mentions 'allow all'. Option B is wrong because it allows traffic that is not explicitly denied (default deny).

Option C is wrong because it suggests only ingress is affected.

Full explanation →
30
MCQmedium

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

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

Correct. This annotation enforces the restricted Pod Security Standard.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
31
MCQmedium

You are performing a rolling update of a Deployment. You set maxSurge=2 and maxUnavailable=1. The Deployment has 5 replicas. During the update, how many pods can be running simultaneously?

A.7
B.6
C.10
D.5
AnswerA

5 desired + 2 surge = 7 maximum running pods.

Why this answer

With maxSurge=2, up to 2 extra pods can be created above the desired 5. With maxUnavailable=1, at most 1 pod can be unavailable. So the total running can be up to 5 + 2 = 7.

Full explanation →
32
Multi-Selectmedium

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

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

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

Why this answer

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

Exam trap

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

Full explanation →
33
MCQmedium

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

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

The error indicates port conflict.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
34
MCQmedium

You have an Ingress with the following spec: spec: rules: - host: app.example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 How does the Ingress controller route a request to http://app.example.com/api/v1/users?

A.The request is rejected because pathType Prefix requires trailing /
B.It matches but the host is app.example.com, so it goes to api-service
C.It does not match because the path is exactly /api
D.It matches because /api/v1/users begins with /api
AnswerD

Prefix matching allows any subpaths.

Why this answer

Option B is correct. With pathType: Prefix, the path /api matches any path that starts with /api. So /api/v1/users matches.

Option A would be for Exact pathType. Option C is incorrect because the host matches. Option D is irrelevant.

Full explanation →
35
MCQmedium

When using 'kubectl expose', which flag creates a NodePort service?

A.--node-port
B.--type=NodePort
C.--type=ClusterIP
D.--port
AnswerB

Creates NodePort service.

Why this answer

Option B is correct. '--type=NodePort' creates a NodePort service. Option A is default. Option C is not a valid flag.

Option D is not a flag.

Full explanation →
36
Multi-Selecthard

Which TWO of the following are true about the 'kubectl describe pod' output? (Select 2)

Select 3 answers
A.It shows the exact resource requests and limits of each container
B.It shows the last few lines of the container logs
C.It shows recent events related to the pod
D.It shows the current CPU and memory usage of the pod
E.It shows the node name where the pod is scheduled
AnswersA, C, E

kubectl describe pod shows both requests and limits.

Why this answer

kubectl describe shows events related to the pod and the container state. Option A is wrong because it shows resource limits, not just requests. Option D is incorrect because it does not show logs.

Full explanation →
37
Multi-Selecteasy

Which TWO of the following are valid Ingress path types? (Select 2)

Select 2 answers
A.Glob
B.Exact
C.Wildcard
D.Regex
E.Prefix
AnswersB, E

Exact matches the path exactly.

Why this answer

Exact and Prefix are the valid path types in networking.k8s.io/v1.

Full explanation →
38
MCQmedium

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

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

Correct. The automatic mounting of the token is disabled.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
39
MCQeasy

You have a Deployment with the following strategy: type: Recreate. What happens when you update the pod template?

A.Old pods are terminated first, then new pods are created
B.New pods are created first, then old pods are terminated
C.Pods are updated in-place without termination
D.The update is rejected because Recreate is not a valid strategy
AnswerA

Correct for Recreate strategy.

Why this answer

The Recreate strategy in a Kubernetes Deployment first terminates all existing Pods before creating new ones. When the pod template is updated, the Deployment controller scales down the ReplicaSet to 0 replicas, waits for all Pods to terminate, then scales up the new ReplicaSet to the desired number of replicas. This ensures zero overlap between old and new Pods, which is useful for workloads that cannot run concurrently.

Exam trap

The trap here is that candidates confuse Recreate with RollingUpdate, assuming new Pods are always created first to minimize downtime, but Recreate deliberately sacrifices availability for safety by terminating all old Pods before starting new ones.

How to eliminate wrong answers

Option B is wrong because it describes the RollingUpdate strategy, where new Pods are created first and old Pods are terminated gradually to maintain availability. Option C is wrong because Kubernetes Pods are immutable; updates to the pod template always require Pod recreation, not in-place updates. Option D is wrong because Recreate is a valid and documented Deployment strategy type in Kubernetes, explicitly supported in the apps/v1 API.

Full explanation →
40
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
41
MCQeasy

Which command exposes a deployment named 'web' as a ClusterIP service on port 80?

A.kubectl create service clusterip web --port=80
B.kubectl expose deployment web --port=80
C.kubectl run web --expose --port=80
D.kubectl expose deployment web --port=80 --type=NodePort
AnswerB

Correct. kubectl expose creates a ClusterIP service by default on the specified port.

Why this answer

The correct command is 'kubectl expose deployment web --port=80' which creates a ClusterIP service by default. Option B uses '--type=NodePort', option C uses 'service' incorrectly, and option D uses incorrect syntax.

Full explanation →
42
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
43
MCQeasy

What is the purpose of a readiness probe?

A.To restart the container if it becomes unresponsive
B.To indicate whether the container is ready to serve traffic
C.To indicate that the container has started successfully
D.To measure the resource usage of the container
AnswerB

Readiness probe determines if traffic should be sent to the pod.

Why this answer

A readiness probe determines whether a container is ready to accept traffic. If the probe fails, the Pod's IP address is removed from the Endpoints of the associated Service, preventing traffic from being routed to an unready container. This is distinct from liveness probes, which restart containers, and startup probes, which indicate successful initialization.

Exam trap

The trap here is confusing readiness probes with liveness probes, as both are health checks, but readiness probes control traffic routing while liveness probes trigger container restarts.

How to eliminate wrong answers

Option A is wrong because restarting an unresponsive container is the purpose of a liveness probe, not a readiness probe. Option C is wrong because indicating that the container has started successfully is the purpose of a startup probe, which is used for slow-starting containers to delay liveness checks. Option D is wrong because measuring resource usage is done by metrics servers or resource monitoring tools (e.g., cAdvisor, Prometheus), not by probes.

Full explanation →
44
MCQeasy

A developer wants to expose a set of Pods on a specific port on each node's IP. Which Service type should be used?

A.LoadBalancer
B.ClusterIP
C.NodePort
D.ExternalName
AnswerC

NodePort exposes on each node's IP at a static port.

Why this answer

NodePort is the correct Service type because it exposes each Pod's port on a static port (the NodePort) on every node's IP address. This allows external traffic to reach the Pods by accessing any node's IP on that specific port, fulfilling the requirement to expose the Pods on a per-node IP basis.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking LoadBalancer is needed for external access, but the question specifically asks for exposure on each node's IP, which is exactly what NodePort provides without requiring a cloud load balancer.

How to eliminate wrong answers

Option A is wrong because LoadBalancer exposes the Service via an external load balancer (typically a cloud provider's LB), not directly on each node's IP; it builds on top of NodePort but adds an external IP that distributes traffic, not per-node exposure. Option B is wrong because ClusterIP exposes the Service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like a proxy or ingress. Option D is wrong because ExternalName maps a Service to a DNS name (via CNAME records) and does not expose any ports or Pods at all; it is used for external service aliasing, not for exposing Pods on node IPs.

Full explanation →
45
MCQhard

You are using Kustomize with a base and an overlay. The base sets a Deployment's replicas to 3. The overlay sets replicas to 5 using a patch. What is the final replica count after running 'kubectl apply -k overlay/'?

A.5
B.The result depends on the merge order
C.8
D.3
AnswerA

Overlay patch overrides base.

Why this answer

In Kustomize, overlays override base values. The patch sets replicas to 5, so the final count is 5. Option C is correct.

Option A is the base value. Option B sums them? Not correct. Option D random.

Full explanation →
46
Matchingmedium

Match each Kubernetes resource to its API group.

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

Concepts
Matches

apps/v1

v1 (core)

networking.k8s.io/v1

autoscaling/v2

networking.k8s.io/v1

Why these pairings

Knowing API groups is important for writing correct manifests.

Full explanation →
47
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
48
MCQeasy

Which Kubernetes API version is used for creating a CronJob?

A.batch/v1beta1
B.batch/v1
C.cron/v1
D.apps/v1
AnswerB

batch/v1 is the stable version for CronJob.

Why this answer

CronJob is in the batch/v1 API group.

Full explanation →
49
Matchingmedium

Match each Kubernetes resource to its primary purpose.

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

Concepts
Matches

Smallest deployable unit running containers

Stable network endpoint for a set of pods

Store non-sensitive configuration data

Request for storage resources

HTTP and HTTPS routing to services

Why these pairings

These are core Kubernetes resources with distinct roles.

Full explanation →
50
Multi-Selectmedium

Which TWO of the following are valid concurrencyPolicy values for a CronJob? (Select TWO.)

Select 3 answers
A.Replace
B.Allow
C.Parallel
D.Forbid
E.Serial
AnswersA, B, D

Replaces the currently running job with a new one.

Why this answer

Options A and C are correct. Allow and Forbid are valid. Option B (Replace) is also valid but the question asks for TWO, and we need to select two.

Since there are three valid ones (Allow, Forbid, Replace), the correct ones are A and C (or any two). However, to be precise, the question expects two: Allow and Forbid are the most common. Option D (Parallel) is not valid.

Option E (Serial) is not valid.

Full explanation →
51
MCQeasy

Which Helm command installs a chart from a repository?

A.helm deploy <release-name> <chart>
B.helm install <release-name> <chart>
C.helm create <release-name> <chart>
D.helm run <release-name> <chart>
AnswerB

This is the correct syntax to install a chart.

Why this answer

The correct command is 'helm install <release-name> <chart-name> --repo <repo-url>' or simply 'helm install <release-name> <repo>/<chart>'. The simplest form is 'helm install <release-name> <chart-name>' if the chart is in a local repo or added repo.

Full explanation →
52
MCQmedium

You want to block all ingress traffic to pods labeled 'app=api' except from pods labeled 'app=frontend'. Which NetworkPolicy rule is correct?

A.ingress: - from: - podSelector: matchLabels: app: frontend
B.ingress: - from: - namespaceSelector: matchLabels: app: frontend
C.ingress: - ports: - port: 80
D.ingress: - from: - ipBlock: cidr: 10.0.0.0/8
AnswerA

This allows ingress only from pods with label app=frontend.

Why this answer

The ingress rule should allow from pods with matching labels.

Full explanation →
53
MCQhard

You want to debug a pod that is failing to start. The pod does not have a shell installed. Which command can you use to attach an ephemeral debug container to the running (or failed) pod?

A.kubectl attach <pod>
B.kubectl exec -it <pod> -- /bin/sh
C.kubectl run debug --image=busybox -it --restart=Never
D.kubectl debug -it <pod> --image=busybox --target=<container>
AnswerD

This attaches a debug container (ephemeral container) to the pod, allowing debugging without modifying the original container.

Why this answer

Option D is correct because `kubectl debug` allows you to attach an ephemeral debug container to a running or failed pod, even if the pod lacks a shell. The `--target` parameter specifies the container in the pod to which the debug container attaches, enabling network namespace sharing and process inspection without modifying the original container.

Exam trap

The trap here is that candidates often choose `kubectl exec` or `kubectl attach` out of habit, not realizing those commands require a running container with a shell, whereas `kubectl debug` is the only option that can inject a new container into a pod that lacks debugging tools or is in a failed state.

How to eliminate wrong answers

Option A is wrong because `kubectl attach` attaches to a running container's stdin/stdout/stderr, but it requires the container to have a shell or process running; it cannot add a new container or work if the pod is in a CrashLoopBackOff state. Option B is wrong because `kubectl exec` requires the target container to have a shell (e.g., /bin/sh) and a running process; if the pod has no shell or is failing to start, exec will fail. Option C is wrong because `kubectl run` creates a new standalone pod, not an ephemeral container attached to an existing pod; it cannot debug the original pod's namespace or processes.

Full explanation →
54
MCQmedium

You run 'kubectl run debug-pod --image=busybox -it --restart=Never -- sh' but the pod starts and immediately exits. You want to keep the container running to execute commands later. What flag should you add?

A.--stdin=true
B.--command
C.-- sleep infinity
D.--attach
AnswerC

This overrides the command to run 'sleep infinity', keeping the container alive.

Why this answer

The '--' and 'sh' run a shell that exits when stdin is closed. To keep it running, use 'sleep infinity' or a 'while' loop. The simplest is to change the command to 'sleep infinity'.

Full explanation →
55
Multi-Selecteasy

Which TWO are valid ways to debug a pod using ephemeral containers?

Select 2 answers
A.kubectl debug -it <pod> --image=busybox -- sh
B.kubectl run debug --image=busybox -- sh
C.Adding an ephemeral container to the pod's spec under ephemeralContainers
D.kubectl exec -it <pod> -- sh
E.kubectl attach to the pod
AnswersA, C

Creates an ephemeral container with busybox for debugging.

Why this answer

Option A is correct because `kubectl debug -it <pod> --image=busybox -- sh` creates an ephemeral container in the target pod and attaches an interactive terminal to it. This is the standard Kubernetes mechanism for debugging a running pod without modifying its original container spec, using the ephemeral container feature (alpha in v1.16, stable in v1.23).

Exam trap

The trap here is that candidates confuse `kubectl exec` (which runs a command in an existing container) with `kubectl debug` (which creates a new ephemeral container), and also mistakenly think `kubectl run` or `kubectl attach` can inject a debug container into a running pod.

Full explanation →
56
Multi-Selectmedium

Which THREE of the following are correct statements about the terminationGracePeriodSeconds field? (Select 3)

Select 3 answers
A.The default value is 30 seconds
B.It gives the container time to shut down gracefully after receiving SIGTERM
C.After the grace period expires, the container is forcefully killed with SIGKILL
D.The default value is 0 seconds
E.It is used to configure the readiness probe timeout
AnswersA, B, C

Correct: default is 30.

Why this answer

Option A is correct because the Kubernetes documentation specifies that the default value for terminationGracePeriodSeconds is 30 seconds. This field is part of the PodSpec and controls the duration between sending SIGTERM to the container and forcefully killing it with SIGKILL. If not set, Kubernetes applies this default to ensure a reasonable window for graceful shutdown.

Exam trap

CNCF often tests the exact default value (30 seconds) and the distinction between SIGTERM (graceful) and SIGKILL (forceful), so candidates must not confuse terminationGracePeriodSeconds with probe settings like readiness or liveness probe timeouts.

Full explanation →
57
MCQmedium

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

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

Enforces the baseline pod security standard.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
58
Multi-Selectmedium

Which TWO of the following are valid concurrencyPolicy values for a CronJob?

Select 2 answers
A.Parallel
B.Forbid
C.Serial
D.Allow
E.Replace
AnswersB, D

Forbids concurrent runs; skips if previous is still running.

Why this answer

Allow, Forbid, and Replace are the three valid values.

Full explanation →
59
MCQeasy

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
60
MCQhard

You deploy a pod with the following specification: apiVersion: v1 kind: Pod metadata: name: probe-pod spec: containers: - name: app image: nginx livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 failureThreshold: 3 The application listens on port 80, not 8080. What will happen to the pod?

A.The pod will be terminated and not restarted
B.The pod will start and run normally
C.The container will be restarted repeatedly due to liveness probe failure
D.The pod will be stuck in 'Pending' state
AnswerC

Correct. The liveness probe will fail, causing restarts.

Why this answer

The liveness probe will fail because it checks port 8080 but the app listens on 80. After failureThreshold failures (3 * periodSeconds = 30 seconds after initial delay), the container will be restarted.

Full explanation →
61
MCQmedium

You have installed a Helm chart for 'wordpress' using 'helm install my-wordpress bitnami/wordpress'. Later, you want to check the status of the release. Which command lists the status of all releases?

A.helm list
B.helm status my-wordpress
C.helm history my-wordpress
D.helm show status
AnswerA

This lists all Helm releases in the current namespace, including their status.

Why this answer

Option B is correct: 'helm list' lists all releases in the current namespace. Option A only shows the status of a specific release. Option C shows revision history of a release.

Option D is not a valid Helm command.

Full explanation →
62
MCQmedium

You have a pod with two containers: 'web' and 'sidecar'. You want to view the logs of only the 'sidecar' container. Which command should you use?

A.kubectl logs pod-name -c sidecar
B.kubectl attach pod-name -c sidecar
C.kubectl logs pod-name
D.kubectl logs pod-name --container sidecar
AnswerA

The -c flag specifies which container's logs to show.

Why this answer

Option A is correct because `kubectl logs pod-name -c sidecar` explicitly specifies the container name within the pod using the `-c` flag, allowing you to view logs from only the 'sidecar' container. In Kubernetes, when a pod contains multiple containers, you must specify the container name to isolate logs from a particular container.

Exam trap

The trap here is that candidates may confuse the `-c` flag with `--container` and use an incorrect syntax, or they may forget that multi-container pods require explicit container specification, leading them to choose the ambiguous `kubectl logs pod-name` option.

How to eliminate wrong answers

Option B is wrong because `kubectl attach` attaches to a running container's standard input/output streams, not to its logs; it is used for interactive debugging, not for viewing historical log output. Option C is wrong because `kubectl logs pod-name` without the `-c` flag will fail if the pod has more than one container, as Kubernetes requires explicit container selection to avoid ambiguity. Option D is wrong because `--container sidecar` is not a valid flag; the correct flag is `-c sidecar` or `--container=sidecar` (with an equals sign), and the provided syntax `--container sidecar` is incorrect and will cause a parsing error.

Full explanation →
63
MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Delete and recreate the pod to clear the crash loop
B.Increase the CPU request for the container
C.Increase the memory limit in the pod's container resource specification
D.Delete the namespace and redeploy all workloads
AnswerC

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. Increasing the memory limit in the container's resource specification is the appropriate fix.

Full explanation →
64
MCQeasy

You have a pod 'app-pod' that keeps restarting. You want to see the logs from the previous (crashed) container instance. Which command should you use?

A.kubectl logs app-pod --previous
B.kubectl logs app-pod -p
C.kubectl logs app-pod -f
D.kubectl describe pod app-pod
AnswerA

Correct. --previous shows logs from the last terminated container.

Why this answer

The --previous flag shows logs from the previous instance of a container.

Full explanation →
65
MCQmedium

A pod named 'web-app' is experiencing high CPU usage. You want to investigate which process inside the container is consuming the most CPU. Which command should you run?

A.kubectl logs -f web-app
B.kubectl exec web-app -- top
C.kubectl describe node
D.kubectl top pod web-app
AnswerB

Executes 'top' inside the container, showing per-process CPU usage.

Why this answer

Option B is correct because `kubectl exec web-app -- top` runs the `top` command inside the container of the pod 'web-app', which displays real-time process-level CPU usage. This allows you to identify the specific process consuming the most CPU, directly addressing the question's requirement to investigate inside the container.

Exam trap

The trap here is that candidates confuse `kubectl top pod` (which shows pod-level resource usage) with the ability to inspect processes inside the container, leading them to choose Option D instead of using `kubectl exec` to run a process inspection command like `top`.

How to eliminate wrong answers

Option A is wrong because `kubectl logs -f web-app` streams the container's stdout/stderr logs, which do not show process-level CPU usage or running processes. Option C is wrong because `kubectl describe node` provides node-level resource allocation and conditions, not process-level details inside a specific pod's container. Option D is wrong because `kubectl top pod web-app` shows aggregate CPU and memory usage of the pod's containers, but does not reveal individual processes inside the container.

Full explanation →
66
MCQmedium

A user runs 'kubectl run nginx --image=nginx --restart=Never' and the pod goes into 'Pending' state. What is a likely reason?

A.The image name is incorrect
B.The pod is missing a readiness probe
C.The pod's restart policy is set to Never
D.The node has insufficient resources to schedule the pod
AnswerD

Pending means the pod is unschedulable due to resource shortages.

Why this answer

Pending often indicates resource constraints like insufficient CPU or memory.

Full explanation →
67
Multi-Selectmedium

Which TWO of the following are valid liveness probe types in Kubernetes?

Select 2 answers
A.command
B.tcpSocket
C.portCheck
D.httpGet
E.grpc
AnswersB, D

Valid liveness probe type.

Why this answer

The valid liveness probe types are httpGet, tcpSocket, exec, and grpc. gRPC is also valid since v1.24.

Full explanation →
68
Multi-Selectmedium

Which TWO of the following are valid Service types in Kubernetes? (Select 2)

Select 2 answers
A.ExternalName
B.ClusterIP
C.NodePort
D.Headless
E.Ingress
AnswersB, C

Default service type.

Why this answer

ClusterIP, NodePort, LoadBalancer, and ExternalName are the four standard types.

Full explanation →
69
Multi-Selectmedium

Which TWO practices optimize Docker image size? (Select 2)

Select 2 answers
A.Running 'apt-get upgrade' in the Dockerfile
B.Using a full OS base image like ubuntu:latest
C.Including a .dockerignore file to exclude unnecessary files
D.Using multi-stage builds to copy only necessary artifacts
E.Installing all packages in one layer without cleanup
AnswersC, D

.dockerignore prevents sending large files to the Docker daemon, reducing context size and build time.

Why this answer

Options A and D are correct. Multi-stage builds (A) allow using a large build image and a small runtime image. .dockerignore (D) excludes unnecessary files. Option B (running apt-get upgrade) increases size.

Option C (using a larger base image) increases size.

Full explanation →
70
MCQhard

You have a CronJob that runs every 5 minutes. The previous job is still running when the next scheduled time arrives. You want the new job to be skipped if the previous one is still running. Which concurrencyPolicy should you set?

A.Skip
B.Allow
C.Replace
D.Forbid
AnswerD

Forbid skips the new job if the previous one is still running, meeting the requirement.

Why this answer

Option B is correct. concurrencyPolicy: Forbid prevents a new job from starting if the previous one hasn't finished. Allow would start another instance concurrently; Replace would terminate the running job and start a new one.

Full explanation →
71
MCQmedium

Which kubectl command can you use to pause a rolling update of a Deployment?

A.kubectl rollout pause deployment/my-deployment
B.kubectl rollout suspend deployment/my-deployment
C.kubectl rollout stop deployment/my-deployment
D.kubectl rollout halt deployment/my-deployment
AnswerA

This command pauses the rolling update.

Why this answer

'kubectl rollout pause deployment/<name>' pauses the rollout, preventing further changes until resumed.

Full explanation →
72
MCQhard

A developer wants to perform a canary deployment where 10% of traffic goes to a new version (v2) of an application. They create two Deployments (app-v1 and app-v2) and a Service. The Service selector is configured to match labels: 'app: myapp, version: v1'. How can they route 10% of traffic to v2 with minimal changes?

A.Use kubectl rollout pause on the v2 Deployment.
B.Set the v2 Deployment's spec.replicas to 10% of the total replicas and keep the Service selector unchanged.
C.Change the Service selector to 'app: myapp' (remove version label) and set v1 replicas to 9 and v2 replicas to 1.
D.Add a NetworkPolicy to limit traffic to v2 pods to 10%.
AnswerC

Correct. This makes the Service select both versions, and the replica ratio achieves 10% traffic to v2.

Why this answer

By adding the label 'version: v1' to only a subset of v2 pods, the Service will include them. But the correct approach is to modify the Service selector to match both versions and then scale the Deployments accordingly. However, the simplest method is to adjust the replica counts: if v1 has 9 replicas and v2 has 1 replica, and the Service selects both, traffic will be distributed roughly 90/10.

Full explanation →
73
Multi-Selecthard

Which TWO of the following are valid approaches to debug a pod that is in a CrashLoopBackOff state? (Select 2)

Select 2 answers
A.Exec into the pod with 'kubectl exec -it' to inspect the environment
B.Check resource usage with 'kubectl top pod'
C.Use 'kubectl debug' to start an ephemeral container for troubleshooting
D.View logs from the previous container instance with 'kubectl logs --previous'
E.Create a new pod with 'kubectl run' using the same image
AnswersC, D

kubectl debug can add an ephemeral container to the pod even if the main container is crashing.

Why this answer

Option C is correct because 'kubectl debug' can start an ephemeral container in the same pod as the crashing container, allowing you to inspect the environment (e.g., filesystem, network, processes) without the main container running. This is especially useful when the main container crashes immediately and you cannot exec into it. Ephemeral containers share the pod's namespaces (e.g., network, PID) and can mount the same volumes, giving you a live debugging environment.

Exam trap

CNCF often tests the distinction between 'kubectl exec' (requires a running container) and 'kubectl debug' (works even when the container is crashing), and candidates mistakenly think exec can be used on a CrashLoopBackOff pod.

Full explanation →
74
MCQeasy

You create a Service with `kubectl expose deployment web --port=80 --target-port=8080`. What type of Service is created by default?

A.ClusterIP
B.LoadBalancer
C.NodePort
D.ExternalName
AnswerA

ClusterIP is the default Service type when no type is specified.

Why this answer

By default, `kubectl expose` creates a ClusterIP Service if no type is specified.

Full explanation →
75
MCQeasy

A deployment 'web-app' is running with 3 replicas. Users report that the application is slow. The team suspects a memory leak. Which command provides the most immediate insight into the memory usage of the pods?

A.kubectl describe deployment web-app
B.kubectl get events
C.kubectl logs <pod>
D.kubectl top pod
AnswerD

Shows real-time CPU and memory usage per pod.

Why this answer

Option D is correct because `kubectl top pod` directly queries the metrics server to display real-time CPU and memory usage for each pod, providing the most immediate insight into whether a pod is consuming excessive memory due to a suspected leak. Unlike logs or events, it gives quantitative resource utilization data without requiring additional configuration or parsing.

Exam trap

The trap here is that candidates may choose `kubectl logs` thinking application logs will reveal memory leak details, but logs only show application output, not raw memory metrics, and `kubectl top pod` is the standard tool for immediate resource usage insight.

How to eliminate wrong answers

Option A is wrong because `kubectl describe deployment web-app` shows the deployment's configuration and status, not the actual runtime memory usage of individual pods. Option B is wrong because `kubectl get events` lists cluster events (e.g., scheduling failures, restarts) but does not provide memory usage metrics. Option C is wrong because `kubectl logs <pod>` outputs application logs, which may contain memory-related error messages but do not give direct, real-time memory consumption numbers.

Full explanation →

Page 1 of 14

Page 2

All pages

1234567891011121314

Practice CKAD by domain

Target a specific domain to shore up weak areas.

Application Design and BuildApplication DeploymentApplication Environment, Configuration and SecurityApplication Observability and MaintenanceServices and Networking
See all domains with question counts →