Courseiva

Certified Kubernetes Application Developer CKAD (CKAD) — Questions 676–750

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

Take a mock examExam hub
Page 9

Page 10 of 14

Page 11
676
MCQmedium

You create a Service with the following manifest. What is the effect? service.yaml: apiVersion: v1 kind: Service metadata: name: ext-svc spec: type: ExternalName externalName: db.example.com

A.The service is a CNAME alias for db.example.com
B.The service gets a ClusterIP and forwards to db.example.com
C.The service creates a load balancer pointing to db.example.com
D.The service selects pods with label app: ext
AnswerA

ExternalName maps the service DNS name to the external DNS name.

Why this answer

ExternalName services return a CNAME record for the external name, not a ClusterIP.

Full explanation →
677
MCQmedium

You need to run a database migration as a container before the main application container starts. Which Kubernetes concept should you use?

A.Job
B.Init container
C.Sidecar container
D.Ephemeral container
AnswerB

Init containers run to completion before the main containers start.

Why this answer

Option B is correct. Init containers run sequentially before the main containers start and are ideal for initialization tasks like migrations. Option A (sidecar) runs concurrently.

Option C (ephemeral) is for debugging. Option D (job) runs to completion but not as part of a pod's lifecycle.

Full explanation →
678
MCQmedium

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

A.The pod uses the default service account token from the namespace
B.The service account token is mounted but not updated
C.The pod cannot communicate with the Kubernetes API
D.The service account token is not mounted into the pod
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
679
MCQhard

You create a headless service with 'clusterIP: None' for a StatefulSet. How does a client discover the individual pod IPs?

A.DNS returns multiple A records for the service name, each pointing to a pod IP
B.The service returns the pod's hostname from the StatefulSet
C.An Ingress controller must be configured to expose each pod
D.The service provides a virtual IP that load balances among pods
AnswerA

Headless services allow DNS to return multiple A records for pod IPs.

Why this answer

Option A is correct. For a headless service, DNS returns A/AAAA records for all pods that match the selector. Clients can then connect directly to any pod IP.

Option B describes a regular ClusterIP service. Option C is about Ingress. Option D is about ExternalName.

Full explanation →
680
Multi-Selecthard

Which THREE of the following are true about NetworkPolicy? (Select 3)

Select 3 answers
A.Multiple NetworkPolicies are additive
B.NetworkPolicy can select pods in other namespaces using namespaceSelector
C.NetworkPolicy can control traffic to Services
D.If no NetworkPolicy selects a pod, then that pod is allowed all traffic
E.NetworkPolicy is a cluster-scoped resource
AnswersA, B, D

If multiple policies select a pod, the union of their rules applies.

Why this answer

NetworkPolicy applies to pods selected by podSelector; multiple policies are additive; it is namespace-scoped; it can select pods in other namespaces via namespaceSelector.

Full explanation →
681
Multi-Selectmedium

Which TWO of the following are valid patterns for sidecar containers in Kubernetes?

Select 3 answers
A.Ambassador
B.Singleton
C.Adapter
D.DaemonSet
E.Sidecar
AnswersA, C, E

Ambassador is a sidecar that proxies network connections.

Why this answer

Sidecar, adapter, and ambassador are the three common sidecar patterns. The sidecar pattern adds functionality to the main container, the adapter pattern transforms interfaces, and the ambassador pattern proxies connections.

Full explanation →
682
Multi-Selectmedium

Which TWO of the following are valid ways to expose a Deployment named 'web' as a Service?

Select 2 answers
A.kubectl expose deployment web --port=80
B.kubectl port-forward deployment/web 8080:80
C.Apply a Service YAML with selector matching the deployment's pod labels
D.kubectl run web --image=nginx --port=80
E.kubectl create service clusterip web --tcp=80:80
AnswersA, C

Correct. This creates a Service exposing the deployment.

Why this answer

Option A is valid: 'kubectl expose deployment web --port=80' creates a ClusterIP Service. Option D is valid: apply a Service YAML that selects the pods. Option B is invalid because 'kubectl run' creates a pod, not a service.

Option C is invalid because 'kubectl create service' requires --tcp flag for port, but the command is incomplete. Option E is invalid because 'kubectl port-forward' does not create a Service.

Full explanation →
683
MCQmedium

A developer wants to tag a local image 'myapp:latest' with the tag 'v1.0.0' for pushing to a registry. Which kubectl command does this?

A.docker push myapp:v1.0.0
B.docker tag myapp:latest myapp:v1.0.0
C.kubectl tag myapp:latest myapp:v1.0.0
D.kubectl set image myapp:v1.0.0
AnswerB

Correctly tags the image.

Why this answer

docker tag is the correct command for tagging images.

Full explanation →
684
MCQeasy

What is the difference between 'kubectl apply' and 'kubectl create'?

A.'kubectl apply' only works with Deployments, while 'kubectl create' works with all resources
B.'kubectl apply' is for creating resources, 'kubectl create' is for updating
C.There is no difference
D.'kubectl apply' can be used to create and update resources; 'kubectl create' only creates new resources
AnswerD

Correct, 'apply' is declarative and handles both create and update; 'create' only creates.

Why this answer

'kubectl apply' is declarative: it creates or updates a resource to match the provided configuration. 'kubectl create' is imperative: it creates a new resource and will fail if the resource already exists.

Full explanation →
685
Multi-Selectmedium

Which TWO of the following are valid ways to expose application metrics from a Pod in Kubernetes?

Select 2 answers
A.Write metrics to stdout and parse them with a log aggregator.
B.Use kubectl top to collect metrics and expose them via a Service.
C.Create a ServiceMonitor custom resource to push metrics to Prometheus.
D.Expose a /metrics HTTP endpoint and configure Prometheus to scrape it.
E.Use the Kubernetes custom metrics API to expose application-specific metrics.
AnswersD, E

Standard Prometheus metrics exposure.

Why this answer

Option D is correct because exposing a /metrics HTTP endpoint is the standard pattern for Prometheus-based monitoring. Prometheus uses a pull model, where it periodically scrapes metrics from the /metrics endpoint exposed by the application container. This approach is widely adopted in Kubernetes for application observability.

Exam trap

CNCF often tests the distinction between push-based and pull-based monitoring models, and the trap here is that candidates may think ServiceMonitor pushes metrics, when in fact it only configures Prometheus to pull from a target.

Full explanation →
686
MCQhard

A CronJob is configured with concurrencyPolicy: Forbid. The scheduled job takes longer than the interval between schedules to complete. What happens when the next scheduled time arrives while the previous job is still running?

A.The running job is killed to make room for the new one
B.The new job starts immediately, overriding the running one
C.The CronJob controller skips the new execution and logs a warning
D.The new job is queued and starts after the running job completes
AnswerC

Correct: Forbid prevents concurrent runs and skips the job if one is already running.

Why this answer

With concurrencyPolicy: Forbid, the CronJob controller does not start a new job if the previous job is still running. It skips the execution.

Full explanation →
687
MCQeasy

In a Dockerfile, what is the difference between CMD and ENTRYPOINT?

A.CMD always runs, ENTRYPOINT can be overridden
B.There is no difference; they are interchangeable
C.ENTRYPOINT defines the executable and CMD provides default arguments
D.CMD is used for shell form, ENTRYPOINT for exec form
AnswerC

Correct: ENTRYPOINT is the command, CMD is arguments that can be replaced.

Why this answer

ENTRYPOINT defines the executable, and CMD provides default arguments that can be overridden.

Full explanation →
688
MCQeasy

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

A.Hardcode the password in the Pod YAML
B.Store the password in a ConfigMap and use configMapKeyRef
C.Create a Secret and use secretKeyRef in the env definition
D.Use a ConfigMap with binaryData field
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
689
MCQhard

You have a Deployment 'db' that uses a ConfigMap for configuration. You want to update the ConfigMap and roll out the changes to pods without restarting them manually. Which approach should you use?

A.Delete the ConfigMap and recreate it with the same name
B.Update the ConfigMap and then update the Deployment's pod template (e.g., change an annotation) to trigger a rolling update
C.Edit the ConfigMap and run kubectl rollout restart deployment/db
D.Use kubectl replace on the ConfigMap and the pods will automatically get the new values
AnswerB

Pods will be recreated with the new ConfigMap.

Why this answer

Mounting ConfigMaps as volumes with subPath does not automatically update pods; however, using environment variables from ConfigMaps also does not update pods. The recommended approach is to use a Deployment update with a change that triggers a rollout (e.g., updating an annotation). Option B is correct.

Full explanation →
690
Drag & Dropmedium

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

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

Steps
Order

Why this order

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

Full explanation →
691
MCQmedium

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

A.Create a ConfigMap volume mount at /etc/config, mounting the entire ConfigMap, and ensure the application reads /etc/config/config.yaml.
B.Create a hostPath volume at /etc/config and copy the ConfigMap content to the node.
C.Use the ConfigMap to set an environment variable CONFIG and have the application read it from the environment.
D.Create a ConfigMap volume mount at /etc/config/app.conf using subPath: config.yaml.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
692
MCQhard

You have a Service named 'app-service' in namespace 'default'. You want a pod in namespace 'monitoring' to resolve the service DNS name. What is the correct fully qualified domain name (FQDN)?

A.app-service.default.cluster.local
B.app-service.svc.default.cluster.local
C.app-service.cluster.local.default.svc
D.app-service.default.svc.cluster.local
AnswerD

Correct format: <service>.<namespace>.svc.cluster.local.

Why this answer

Option A is correct. The standard DNS format for a Service is '<service>.<namespace>.svc.cluster.local'.

Full explanation →
693
MCQeasy

You want to see a list of all events in the 'default' namespace, sorted by timestamp. Which command should you use?

A.kubectl describe events
B.kubectl get pods
C.kubectl get events
D.kubectl logs --all-containers
AnswerC

This command lists events, which are automatically sorted by time.

Why this answer

Option C is correct because `kubectl get events` retrieves all events in the current namespace (default) and, by default, sorts them by the `lastTimestamp` field in ascending order, which is the timestamp of the event. This command directly answers the requirement to list events sorted by timestamp without additional flags.

Exam trap

The trap here is that candidates confuse `kubectl describe events` with `kubectl get events`, assuming the `describe` verb provides a sorted list, but `describe` does not sort by timestamp and may omit events due to pagination limits.

How to eliminate wrong answers

Option A is wrong because `kubectl describe events` shows detailed information about events but does not sort them by timestamp; it groups events by resource and may truncate the list. Option B is wrong because `kubectl get pods` lists pods, not events, and has no timestamp sorting relevant to events. Option D is wrong because `kubectl logs --all-containers` retrieves container logs, not events, and logs are not sorted by event timestamps.

Full explanation →
694
MCQmedium

You are debugging a pod that is running but not responding to network requests on port 8080. You suspect the application inside the container is faulty. You need to run an interactive shell inside the container to inspect the process. Which command should you use?

A.kubectl describe pod pod-name
B.kubectl logs pod-name -f
C.kubectl debug -it pod-name --image=busybox
D.kubectl exec -it pod-name -- /bin/sh
AnswerD

This command opens an interactive shell inside the container, allowing you to run commands and inspect processes.

Why this answer

The correct command is 'kubectl exec -it pod-name -- /bin/sh'. The -it flags enable interactive terminal. Option B is for reading logs.

Option C is for debugging with an ephemeral container. Option D is for describing the pod.

Full explanation →
695
Multi-Selecthard

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

Select 3 answers
A.ResourceQuota can specify both requests and limits for compute resources
B.ResourceQuota can limit the maximum CPU limit for a single pod
C.ResourceQuota can limit the total number of ConfigMaps in a namespace
D.ResourceQuota applies to all pods in a namespace
E.ResourceQuota applies across all namespaces
AnswersA, C, D

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

Why this answer

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

Exam trap

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

Full explanation →
696
Multi-Selecteasy

Which TWO Service types allow external access to pods from outside the Kubernetes cluster? (Select 2)

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

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

Why this answer

Options C and D are correct. NodePort and LoadBalancer Services expose the Service on node IPs or via a cloud load balancer, making them accessible externally.

Full explanation →
697
MCQmedium

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

A.kubernetes.io/tls
B.Opaque
C.kubernetes.io/dockerconfigjson
D.kubernetes.io/basic-auth
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
698
Multi-Selecteasy

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

Select 2 answers
A.kubernetes.io/password
B.kubernetes.io/ssh-auth
C.kubernetes.io/configmap
D.kubernetes.io/tls
E.Opaque
AnswersD, E

Used to store TLS certificates.

Why this answer

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

Exam trap

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

Full explanation →
699
Multi-Selectmedium

Which TWO of the following are valid methods to achieve a blue-green deployment in Kubernetes? (Select two.)

Select 2 answers
A.Use a single Deployment and change the image, then use kubectl rollout pause/resume to control traffic.
B.Set maxSurge=100% and maxUnavailable=0% in the Deployment strategy.
C.Create multiple Deployments with different images and use Ingress with weight-based routing.
D.Create two Deployments (blue and green) with different labels, and a Service that selects one of them. Update the Service's selector to switch traffic.
E.Create a Service that selects pods with label 'app: myapp' and manipulate the 'version' label on pods to shift traffic.
AnswersD, E

This is the classic blue-green deployment pattern.

Why this answer

Options A and C are correct. A: Create two separate Deployments and switch a Service's selector. C: Use Kubernetes Services with label selectors to route traffic to one set of pods, then update the selector.

Option B is not standard; Option D describes a canary deployment; Option E describes a rolling update.

Full explanation →
700
MCQeasy

Which command lists all Helm releases in the current namespace?

A.helm list
B.helm get all
C.helm ls
D.helm status
AnswerA

This is the correct command.

Why this answer

helm list lists all releases in the current namespace (default namespace if not set).

Full explanation →
701
MCQhard

An Ingress resource uses the annotation 'kubernetes.io/ingress.class: nginx'. However, traffic is not being routed. The cluster has multiple ingress controllers. What is the most likely cause?

A.The ingress controller is not installed.
B.The annotation is deprecated; use spec.ingressClassName instead.
C.The service backend doesn't exist.
D.TLS certificate is invalid.
AnswerB

Correct. In newer versions, the annotation is ignored and 'spec.ingressClassName' should be set.

Why this answer

The annotation is deprecated in v1.18+; the new method is to use 'spec.ingressClassName' field. Also, if multiple controllers exist, the ingress class must match one of them.

Full explanation →
702
MCQhard

During a canary deployment, you want to send 10% of traffic to the new version. You have two Deployments: 'app-stable' (version: stable) and 'app-canary' (version: canary). You use a Service with label selector 'app: myapp' and a second selector for version. How can you achieve the 10% traffic split?

A.Use an Ingress controller that supports canary deployments or a service mesh
B.Use a Service with multiple ports
C.Set the Service's sessionAffinity to distribute load
D.Scale app-canary to 1 replica and app-stable to 9 replicas, and use a single Service that selects both
AnswerA

Ingress controllers (e.g., NGINX Ingress) support canary annotations for traffic splitting.

Why this answer

Kubernetes Services do not support weighted load balancing natively. The common approach is to use an Ingress controller or service mesh. Option D is correct.

Full explanation →
703
MCQhard

You need to debug a pod that is running but not serving traffic. You want to add a temporary container with networking tools to the pod. Which command should you use?

A.kubectl run debug --image=busybox -it --restart=Never -- /bin/sh
B.kubectl attach mypod
C.kubectl exec -it mypod -- /bin/sh
D.kubectl debug mypod --image=busybox -it
AnswerD

Correct: kubectl debug adds an ephemeral container to the pod for debugging.

Why this answer

kubectl debug with the --image flag creates an ephemeral container in the pod for debugging. Ephemeral containers are temporary and do not restart if they exit.

Full explanation →
704
MCQhard

You need to create a Pod that runs with a specific non-root user (UID 1000), prevents privilege escalation, and mounts the container's filesystem as read-only. Which securityContext field is NOT required to achieve these requirements?

A.runAsUser: 1000
B.runAsGroup: 1000
C.readOnlyRootFilesystem: true
D.allowPrivilegeEscalation: false
AnswerB

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

Why this answer

Option B (runAsGroup: 1000) is not required because the requirement only specifies a non-root user (UID 1000) and does not mandate a specific group ID. The runAsGroup field sets the primary group for the container's processes, but it is optional; without it, the container will use the default group associated with the user or the container's default group. The other options are necessary: runAsUser: 1000 sets the user, readOnlyRootFilesystem: true makes the filesystem read-only, and allowPrivilegeEscalation: false prevents privilege escalation.

Exam trap

The trap here is that candidates often assume runAsGroup is mandatory alongside runAsUser for non-root execution, but the CKAD exam tests that only the user ID is required unless a specific group is explicitly needed.

How to eliminate wrong answers

Option A is wrong because runAsUser: 1000 is required to run the container as a non-root user with UID 1000, directly addressing the requirement. Option C is wrong because readOnlyRootFilesystem: true is required to mount the container's filesystem as read-only, fulfilling that specific requirement. Option D is wrong because allowPrivilegeEscalation: false is required to prevent privilege escalation, which is explicitly stated in the requirements.

Full explanation →
705
MCQmedium

A Helm chart is installed with the command 'helm install myapp ./mychart'. You need to upgrade the release with new values from a file 'prod-values.yaml'. Which command is correct?

A.helm upgrade myapp ./mychart --values prod-values.yaml
B.helm upgrade ./mychart prod-values.yaml --release myapp
C.helm upgrade --install myapp ./mychart -f prod-values.yaml
D.helm upgrade myapp -f prod-values.yaml
AnswerA

This is the correct syntax for upgrading with values file.

Why this answer

The correct command is 'helm upgrade myapp ./mychart -f prod-values.yaml'. The release name is 'myapp', chart path './mychart', and values file is specified with -f.

Full explanation →
706
Multi-Selecteasy

Which TWO of the following are valid methods to update a Deployment's image?

Select 2 answers
A.kubectl replace -f deployment.yaml
B.kubectl edit deployment/myapp and change the image field
C.kubectl rollout image deployment/myapp mycontainer=nginx:1.21
D.kubectl set image deployment/myapp mycontainer=nginx:1.21
E.kubectl create -f deployment.yaml
AnswersB, D

Editing the deployment allows you to change the image.

Why this answer

Both 'kubectl set image deployment/myapp mycontainer=nginx:1.21' and 'kubectl edit deployment/myapp' can be used to update the image. 'kubectl apply -f deployment.yaml' can also be used if the YAML has the new image. 'kubectl patch' can also be used. So there are multiple methods. The question asks for TWO valid methods.

The options include 'kubectl set image', 'kubectl edit', 'kubectl create -f' (which would fail if the resource exists), 'kubectl replace -f' (which can replace but requires the full manifest), and 'kubectl rollout image' (invalid).

Full explanation →
707
MCQeasy

Which probe type is used to determine if a container is ready to serve traffic?

A.Liveness probe
B.Readiness probe
C.Startup probe
D.Resource probe
AnswerB

A failing readiness probe removes the pod from Service endpoints.

Why this answer

A Readiness probe determines whether a container is ready to accept traffic. If the probe fails, the container is removed from the Service's endpoints, ensuring no requests are routed to an unready pod. This is defined in the PodSpec under `readinessProbe` and is essential for rolling updates and traffic management.

Exam trap

The trap here is that candidates confuse Liveness and Readiness probes, thinking both control traffic, but only the Readiness probe affects Service endpoints, while Liveness only triggers container restarts.

How to eliminate wrong answers

Option A is wrong because a Liveness probe checks if the container is still running (i.e., not deadlocked or crashed) and restarts it if it fails, but it does not control traffic routing. Option C is wrong because a Startup probe is used to delay Liveness and Readiness checks until the container has fully started, especially for slow-booting applications, but it does not directly determine traffic readiness. Option D is wrong because there is no standard 'Resource probe' in Kubernetes; resource management is handled via requests and limits, not probes.

Full explanation →
708
MCQmedium

You have created a HorizontalPodAutoscaler (HPA) named 'web-hpa' targeting a Deployment 'web'. The HPA uses targetCPUUtilizationPercentage: 80. The current CPU usage is 60%. How many replicas will the HPA set?

A.1
B.The HPA would not be created if current usage is below target
C.2
D.0
AnswerA

CPU usage is below target, so the HPA does not scale up.

Why this answer

The HPA scales based on the ratio: desiredReplicas = ceil[currentReplicas * (currentMetricValue / targetMetricValue)]. With current replicas at 1, desired = ceil[1 * (60/80)] = ceil[0.75] = 1. So it remains at 1.

Option A is correct.

Full explanation →
709
MCQmedium

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

A.readOnlyRootFilesystem: false
B.runAsUser: 0 (root)
C.capabilities.add: ["NET_BIND_SERVICE"]
D.seccompProfile: type: RuntimeDefault
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
710
MCQeasy

Which command is used to undo the most recent rollout of a Deployment named 'myapp'?

A.kubectl rollout undo deployment myapp
B.kubectl rollout undo deployment myapp --to-revision=2
C.kubectl rollout status deployment myapp
D.kubectl rollback deployment myapp
AnswerA

This command reverts the Deployment to the previous revision.

Why this answer

Option A is correct: 'kubectl rollout undo deployment myapp' rolls back to the previous revision. Option B rolls back to a specific revision. Option C shows the status, not undo.

Option D is not a valid command.

Full explanation →
711
MCQmedium

After upgrading a Helm release, you want to revert to the previous revision. Which command achieves this?

A.helm undo release-name
B.helm upgrade --rollback release-name
C.helm rollback release-name (previous-revision)
D.helm rollback release-name 0
AnswerC

Correct. You need to specify the revision number to rollback to.

Why this answer

helm rollback release-name revision-number reverts to a specific revision. To revert to the previous one, you use the revision number of the previous version.

Full explanation →
712
MCQeasy

Which file prevents certain files from being copied into a Docker image during a build?

A..kubeignore
B.Dockerfile.ignore
C..dockerignore
D..gitignore
AnswerC

.dockerignore excludes files from the Docker build context.

Why this answer

Option C is correct. A .dockerignore file in the build context tells Docker which files to ignore when sending the context to the Docker daemon.

Full explanation →
713
MCQmedium

You are using Kustomize. Your kustomization.yaml file specifies a base and an overlay. You run: kubectl apply -k overlays/production. What happens?

A.It errors because -k expects a directory with kustomization.yaml.
B.It applies the base resources only.
C.It applies the merged result of base and overlay.
D.It applies the overlay resources only.
AnswerC

Kustomize combines them and kubectl apply creates/updates the resources.

Why this answer

Option C is correct because when you run `kubectl apply -k overlays/production`, Kustomize reads the `kustomization.yaml` in the specified directory, which references a base and an overlay. It then performs a strategic merge patch of the overlay's customizations (e.g., patches, namePrefix, commonLabels) onto the base resources, producing a single set of manifests that are applied to the cluster. This is the core purpose of Kustomize: to compose and customize resources without templating.

Exam trap

The trap here is that candidates might think `-k` applies only the contents of the specified directory (like `-f` does), but Kustomize always resolves the full overlay chain, including the base, so the result is a merged output, not just the overlay's files.

How to eliminate wrong answers

Option A is wrong because `-k` does not require a directory with a file named exactly `kustomization.yaml`; it expects a directory containing a `kustomization.yaml` (or `kustomization.yml` or `Kustomization`) file, and `overlays/production` is a valid directory that contains such a file. Option B is wrong because Kustomize always merges the overlay onto the base; it does not apply only the base resources when an overlay is specified. Option D is wrong because Kustomize does not apply only the overlay resources; it merges the overlay's modifications onto the base, and the base resources are always included in the final output.

Full explanation →
714
MCQeasy

A developer is deploying a web application that requires 2 GiB of memory and 0.5 CPU cores. The cluster nodes have 4 GiB of memory and 2 CPU cores each. The developer wants to ensure the pod gets guaranteed QoS class. Which resource specification should be used?

A.requests: memory: 2Gi, cpu: 500m; no limits
B.requests: memory: 2Gi, cpu: 500m; limits: memory: 2Gi, cpu: 500m
C.requests: memory: 2Gi, cpu: 500m; limits: memory: 4Gi, cpu: 1
D.requests: memory: 1Gi, cpu: 250m; limits: memory: 2Gi, cpu: 500m
AnswerB

Equal requests and limits give Guaranteed QoS.

Why this answer

Option B is correct because for a pod to receive the Guaranteed QoS class, every container in the pod must have both resource requests and limits set, and the requests must equal the limits for each resource (memory and CPU). This configuration ensures the pod is not overcommitted and gets the highest priority under resource pressure.

Exam trap

The trap here is that candidates often think setting only requests (Option A) or setting limits higher than requests (Option C) still gives Guaranteed QoS, but Kubernetes strictly requires requests == limits for all resources to achieve Guaranteed class.

How to eliminate wrong answers

Option A is wrong because it sets only requests without limits, which places the pod in the Burstable QoS class (since limits are not set, the pod can burst above requests). Option C is wrong because the limits exceed the requests (memory 4Gi > 2Gi, CPU 1 > 500m), which also results in Burstable QoS, not Guaranteed. Option D is wrong because the requests are lower than the limits (memory 1Gi < 2Gi, CPU 250m < 500m), again yielding Burstable QoS; additionally, the requests do not match the developer's requirement of 2Gi memory and 500m CPU.

Full explanation →
715
MCQeasy

Which command lists all the secrets in the current namespace?

A.kubectl get configmaps
B.kubectl describe secrets
C.kubectl list secrets
D.kubectl get secrets
AnswerD

Correct. get secrets lists all secrets in the namespace.

Why this answer

The correct command to list all secrets in the current namespace is `kubectl get secrets`. This command retrieves and displays all Secret resources in the namespace specified by the current context (or the `--namespace` flag). Secrets are stored in etcd as base64-encoded data and are managed via the Kubernetes API, and `kubectl get` is the standard verb for listing resources.

Exam trap

CNCF often tests the distinction between `get` and `describe` verbs, and candidates may confuse `kubectl describe secrets` (which shows details) with listing secrets, or they may incorrectly assume `kubectl list secrets` is a valid command due to familiarity with Linux `ls` or `list` commands.

How to eliminate wrong answers

Option A is wrong because `kubectl get configmaps` lists ConfigMap resources, not Secrets; ConfigMaps store non-sensitive configuration data, while Secrets store sensitive data like credentials. Option B is wrong because `kubectl describe secrets` shows detailed information about a specific Secret (or all Secrets if no name is given), but it does not produce a simple list of Secret names; it outputs verbose details including metadata and data keys. Option C is wrong because `kubectl list secrets` is not a valid kubectl command; the correct verb for listing resources is `get`, not `list`.

Full explanation →
716
MCQhard

You need to debug a pod that has no shell installed. You want to add a temporary container with debugging tools to the pod. Which command should you use?

A.kubectl debug mypod -it --image=busybox -- /bin/sh
B.kubectl run debug --image=busybox -it -- /bin/sh
C.kubectl debug mypod --image=busybox --target=debug -n default
D.kubectl exec -it mypod -- /bin/sh
AnswerA

'kubectl debug' creates an ephemeral container in the target pod.

Why this answer

Option B is correct. 'kubectl debug' creates an ephemeral container in the pod for debugging. Option A uses 'kubectl run' which creates a new pod, not adding to existing. Option C exec requires the container to have a shell.

Option D creates a new pod in a different namespace.

Full explanation →
717
MCQmedium

You have just applied a new Deployment configuration using 'kubectl apply -f deployment.yaml'. You want to see the latest revision number of the rollout. Which command should you run?

A.kubectl rollout status deployment/myapp
B.kubectl get deployment myapp -o yaml
C.kubectl describe deployment myapp
D.kubectl rollout history deployment/myapp
AnswerD

Shows list of revisions with their numbers.

Why this answer

'kubectl rollout history deployment/<name>' shows revision history with revision numbers. The latest revision is shown as the most recent.

Full explanation →
718
MCQmedium

You have a Deployment 'web' with 'maxSurge: 25%' and 'maxUnavailable: 25%'. Current replicas is 4. You update the image. How many pods will be created at most during the rollout?

A.8
B.4
C.5
D.6
AnswerC

4 + 1 surge = 5.

Why this answer

maxSurge: 25% means at most 1 extra pod (25% of 4 = 1). So total pods during rollout can be up to 5 (4 desired + 1 surge).

Full explanation →
719
Multi-Selectmedium

Which TWO of the following are valid methods to perform a blue-green deployment in Kubernetes?

Select 2 answers
A.Use a Deployment with 'strategy.type: Recreate' and delete the old version before creating the new one.
B.Create a Deployment with two replicas and use a Service with session affinity to gradually shift traffic.
C.Use a Deployment with 'strategy.type: RollingUpdate' and set 'maxSurge: 100%' and 'maxUnavailable: 0%'.
D.Create two Services, one for blue and one for green. Initially point an ingress to the blue Service. Update the ingress to point to green after validation.
E.Create two Deployments with different labels (e.g., version: blue and version: green). Use a Service initially selecting blue. Update the Service selector to green after green is ready.
AnswersD, E

This is another valid blue-green implementation using separate Services and an ingress.

Why this answer

Blue-green deployment involves running two versions simultaneously and switching traffic. Option A uses label selectors to route traffic to either 'version: blue' or 'version: green' pods. Option D uses a Service with a selector that matches the active version, and traffic is switched by updating the selector.

Option B describes canary deployment. Option C is rolling update. Option E is not a standard method.

Full explanation →
720
MCQhard

A security requirement states that a container must run with a read-only root filesystem. Which field must be set in the container's securityContext?

A.runAsUser: 1000
B.capabilities: drop: ["ALL"]
C.allowPrivilegeEscalation: false
D.readOnlyRootFilesystem: true
AnswerD

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

Why this answer

Setting `readOnlyRootFilesystem: true` in the container's `securityContext` enforces that the container's root filesystem is mounted as read-only, preventing any writes to the filesystem at the root level. This satisfies the security requirement by ensuring that even if a process is compromised, it cannot modify system binaries, configuration files, or other critical files within the container's root filesystem.

Exam trap

The trap here is that candidates often confuse security context fields that control process privileges (like `runAsUser` or `capabilities`) with filesystem mount restrictions, mistakenly thinking dropping capabilities or disabling privilege escalation will make the filesystem read-only.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 1000` sets the user ID under which the container runs, but does not affect the writability of the root filesystem; it controls process privileges, not filesystem mount permissions. Option B is wrong because `capabilities: drop: ["ALL"]` removes all Linux capabilities from the container, which reduces kernel-level privileges but does not prevent writes to the root filesystem; the filesystem can still be written to unless explicitly mounted read-only. Option C is wrong because `allowPrivilegeEscalation: false` prevents a process from gaining more privileges than its parent (e.g., via setuid binaries), but it does not restrict filesystem write access; a non-privileged process can still modify files on a writable root filesystem.

Full explanation →
721
MCQhard

You have an Ingress with TLS configured. The Ingress controller returns a certificate error when accessing via HTTPS. The secret 'my-tls' exists in the same namespace. Which of the following is the most likely cause?

A.The secret name in the TLS section of the Ingress does not match the actual secret name
B.The Ingress controller does not support TLS
C.The secret is in a different namespace than the Ingress
D.The certificate is not signed by a trusted CA
AnswerA

If the secret name is misspelled or does not exist, the controller cannot fetch the certificate.

Why this answer

If the Ingress TLS secret is not referenced correctly in the Ingress YAML, the controller will not use it. Option C is correct. Option A is incorrect because the secret must be in the same namespace as the Ingress.

Option B is incorrect because the Ingress controller typically handles TLS termination. Option D is incorrect because the certificate CN/SAN must match the host.

Full explanation →
722
Drag & Dropmedium

Order the steps to expose a Kubernetes Deployment as a ClusterIP Service.

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

Steps
Order

Why this order

A Service requires a running Deployment. Define and apply the Service, then verify endpoints and test DNS resolution.

Full explanation →
723
Multi-Selecthard

Which TWO are valid ways to create a Service from a deployment named 'frontend'? (Choose two.)

Select 2 answers
A.kubectl create service clusterip frontend --tcp=80:80
B.kubectl autoscale deployment frontend --min=1 --max=5
C.Write a YAML manifest with apiVersion: v1, kind: Service, metadata.name, spec.selector matching deployment labels, and run kubectl apply -f manifest.yaml
D.kubectl expose deployment frontend --port=80
E.kubectl run frontend --image=nginx --port=80 --expose
AnswersC, D

Writing a YAML and applying is a valid method.

Why this answer

You can create a Service by using kubectl expose on the deployment, or by writing a YAML manifest and applying it. The other options are incorrect commands.

Full explanation →
724
MCQeasy

Which of the following Dockerfile instructions sets the working directory for any subsequent RUN, CMD, ENTRYPOINT, COPY, and ADD instructions?

A.EXPOSE
B.WORKDIR
C.COPY
D.USER
AnswerB

WORKDIR sets the working directory for any subsequent instructions in the Dockerfile.

Why this answer

Option C is correct. The WORKDIR instruction sets the working directory for all subsequent instructions in the Dockerfile. COPY and ADD are used to copy files, EXPOSE documents network ports, and USER sets the user name.

Full explanation →
725
Multi-Selectmedium

Which TWO of the following are valid ways to expose a canary deployment to a subset of users? (Select two)

Select 2 answers
A.Use a Service that includes a session affinity to pin users to a specific backend
B.Use a NetworkPolicy to restrict traffic to canary pods
C.Use an Ingress with annotation for weight-based routing to different Services
D.Use a single Service that randomly selects pods
E.Use the same Service with a label selector that matches both stable and canary pods
AnswersA, C

Session affinity can be used to route a subset of users to canary if combined with appropriate labels.

Why this answer

Option B (using a Service with session affinity) and Option C (using an Ingress with weight-based routing) are common techniques for canary deployments. Option A is not valid because changing labels would affect both. Option D is a basic Service, not canary.

Option E is a different concept.

Full explanation →
726
Multi-Selectmedium

Which TWO commands can be used to view the rollout history of a Deployment?

Select 2 answers
A.kubectl get deployment mydeployment
B.kubectl rollout status deployment/mydeployment
C.kubectl logs deployment/mydeployment
D.kubectl describe deployment mydeployment
E.kubectl rollout history deployment mydeployment
AnswersD, E

The describe output includes the rollout history annotations.

Why this answer

Both 'kubectl rollout history deployment' and 'kubectl describe deployment' can be used to view rollout history. 'kubectl rollout history' specifically shows revisions, while 'kubectl describe deployment' includes the rollout history in its output.

Full explanation →
727
MCQeasy

Refer to the exhibit. A user has created the Service shown. The application pods listen on port 8080. Which port should an external client use to access the application from outside the cluster?

A.8080
B.80
C.30007
D.30000
AnswerC

nodePort 30007 is the externally accessible port.

Why this answer

Option C is correct because the Service is of type NodePort, which exposes the application on a static port (30007) on each node's IP address. External clients can access the application by hitting any cluster node's IP on port 30007, which forwards traffic to the Service's ClusterIP on port 80, then to the pods on port 8080.

Exam trap

The trap here is that candidates confuse the Service port (80) or targetPort (8080) with the externally accessible port, failing to recognize that only the NodePort (30007) is reachable from outside the cluster.

How to eliminate wrong answers

Option A is wrong because port 8080 is the targetPort, which is the port the pods listen on inside the cluster; external clients cannot directly reach pod IPs or ports from outside. Option B is wrong because port 80 is the Service's port, which is only reachable from within the cluster via the ClusterIP; it is not exposed externally. Option D is wrong because port 30000 is not defined in the Service spec; the NodePort is explicitly set to 30007 in the YAML, and Kubernetes does not automatically assign a different NodePort unless omitted.

Full explanation →
728
MCQhard

You have a Deployment with 3 replicas. The pods have a readiness probe that checks an HTTP endpoint /ready. One pod's readiness probe is failing. What will happen?

A.The pod will be restarted by the kubelet
B.The Deployment will create a new pod to maintain 3 replicas
C.The pod will be removed from the Service endpoints
D.The pod will be terminated gracefully
AnswerC

The pod is not ready to serve traffic, so it is removed from the Service.

Why this answer

If a pod fails its readiness probe, it is removed from the Service endpoints. The pod remains running and is not restarted. Option B is correct.

Option A is wrong because liveness probes cause restarts. Option C is incorrect because readiness failure does not decrease replicas. Option D is wrong.

Full explanation →
729
MCQmedium

A developer creates a pod with the following YAML snippet: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 The pod mounts an emptyDir volume. What is the owner and group of the mounted directory inside the container?

A.Owner: 1000, Group: 3000
B.Owner: 1000, Group: 1000
C.Owner: 1000, Group: 2000
D.Owner: 0, Group: 2000
AnswerC

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

Why this answer

Option C is correct because when a pod specifies `fsGroup: 2000`, Kubernetes recursively changes the group ownership of any volume mounted into the pod (including emptyDir) to that GID (2000). The `runAsUser: 1000` sets the container process's UID, but the volume's group ownership is overridden by `fsGroup`. Thus, the mounted emptyDir directory is owned by UID 1000 (the process user) and GID 2000 (the fsGroup).

Exam trap

The trap here is that candidates confuse `runAsGroup` (which sets the primary GID of the container process) with `fsGroup` (which sets the group ownership of mounted volumes), leading them to pick Option A or B instead of recognizing that `fsGroup` overrides the volume's group.

How to eliminate wrong answers

Option A is wrong because it assumes the volume's group is set to `runAsGroup: 3000`, but `fsGroup` overrides the group ownership of mounted volumes, not `runAsGroup`. Option B is wrong because it incorrectly assumes the volume's group matches the user's primary GID (1000), but `fsGroup` explicitly sets a different GID (2000) for volume ownership. Option D is wrong because it claims the owner is root (UID 0), but `runAsUser: 1000` ensures the container process runs as UID 1000, and the volume's owner is the process's UID, not root.

Full explanation →
730
MCQmedium

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

A.configMap volume
B.emptyDir volume
C.projected volume with configMap source
D.downwardAPI volume
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
731
MCQmedium

You have a Dockerfile with 'CMD ["nginx", "-g", "daemon off;"]'. A developer wants to run the container with a different command: 'nginx -t'. How should they run the container?

A.docker run nginx ["nginx", "-t"]
B.docker run nginx CMD nginx -t
C.docker run nginx nginx -t
D.docker run --entrypoint nginx -t nginx
AnswerC

Appending command overrides CMD.

Why this answer

Option D is correct: To override CMD, append the command after the image name: docker run nginx nginx -t. Option A uses --entrypoint, which overrides ENTRYPOINT, not CMD. Option B uses exec form incorrectly.

Option C is wrong because CMD is overridable.

Full explanation →
732
Multi-Selecthard

Which THREE of the following are valid fields in a Helm chart's values.yaml file that can be used in templates?

Select 3 answers
A.replicaCount: 3
B.{{ .Chart.Name }}
C.{{- include "common.labels" . }}
D.service: type: ClusterIP port: 80
E.image: repository: nginx tag: latest
AnswersA, D, E

A common custom value accessed as {{ .Values.replicaCount }}.

Why this answer

In Helm, values.yaml can contain arbitrary fields that are accessed via .Values in templates. Options A, B, and D are valid: they are common patterns. Option C is a Go template function, not a values.yaml field.

Option E is a method, not a field.

Full explanation →
733
MCQhard

A namespace 'team-a' has a ResourceQuota with 'pods: 10' and a LimitRange with default memory request '256Mi'. A user creates a pod with no resource requests. What happens?

A.Pod is created with a default memory request of 256Mi.
B.Pod creation fails because the ResourceQuota is exceeded.
C.Pod creation fails because the LimitRange is not satisfied.
D.Pod is created with no memory request.
AnswerA

LimitRange applies default resource requests to pods that don't specify them.

Why this answer

When a pod is created in a namespace with a LimitRange that specifies a default memory request, Kubernetes automatically injects that default value into the pod's container spec if no explicit memory request is provided. The ResourceQuota of 'pods: 10' only limits the total number of pods, not the resource consumption of individual pods, so it does not affect this pod's creation. Therefore, the pod is created with a default memory request of 256Mi.

Exam trap

The trap here is that candidates often confuse ResourceQuota (which limits total resource consumption) with LimitRange (which sets per-pod defaults and constraints), leading them to incorrectly assume a quota or limit violation when defaults are applied.

How to eliminate wrong answers

Option B is wrong because a ResourceQuota with 'pods: 10' sets a limit on the total number of pods in the namespace, not on the resource requests of a single pod; creating one pod does not exceed that quota. Option C is wrong because a LimitRange does not cause pod creation to fail when its default values are applied; instead, it ensures the pod meets the namespace's resource constraints by injecting defaults. Option D is wrong because the LimitRange's default memory request of 256Mi is automatically applied to the pod, so it will have a memory request, not be created without one.

Full explanation →
734
MCQhard

A pod in namespace 'app' needs to resolve the DNS name 'db-service.data.svc.cluster.local'. What is the likely namespace of the 'db-service' Service?

A.app
B.data
C.svc
D.default
AnswerB

The second part of the DNS name after the service name is the namespace.

Why this answer

The DNS format is service.namespace.svc.cluster.local. Here, 'data' is the namespace.

Full explanation →
735
Multi-Selectmedium

Which TWO statements are true about Kubernetes Secrets?

Select 2 answers
A.Secret data is base64 encoded in YAML manifests.
B.Secrets cannot be used as environment variables.
C.Secrets are always encrypted at rest by default.
D.Secrets can be mounted as volumes in a Pod.
E.Secrets are limited to 1KB in size.
AnswersA, D

Secret values are base64 encoded, not plaintext.

Why this answer

Option A is correct because Kubernetes Secrets store data as base64-encoded strings in YAML manifests. This encoding is not encryption; it simply converts binary or non-printable data into an ASCII string format for safe inclusion in YAML. The base64 encoding is a standard practice for representing arbitrary data in Kubernetes resource definitions.

Exam trap

The trap here is that candidates often confuse base64 encoding with encryption, assuming it provides security, or they mistakenly believe Secrets are encrypted at rest by default, when in fact they are stored in plaintext in etcd unless explicitly configured otherwise.

Full explanation →
736
MCQmedium

You need to perform a canary deployment where 10% of traffic goes to the new version. You have a Deployment 'app-v1' with 9 replicas and 'app-v2' with 1 replica. What must be true for the Service to distribute traffic roughly 90/10?

A.The Service must have 'sessionAffinity: ClientIP' to ensure sticky sessions
B.The Service must not have any selectors, and endpoints must be manually managed
C.The Service selector must include only 'version: v2'
D.The Service selector must include a label that both Deployments share, e.g., 'app: myapp'
AnswerD

Both Deployments have the same app label, so the Service selects both sets of pods.

Why this answer

The Service must select both versions using a common label that both Deployments share, such as 'app: myapp'. The replicas count difference will naturally route about 90% to v1 and 10% to v2. Option B is correct.

Option A would only select v1. Option C is incorrect because the Service should select both. Option D would not help.

Full explanation →
737
MCQmedium

A pod uses a liveness probe with exec command 'cat /tmp/healthy'. The file /tmp/healthy exists initially but is deleted by the application after 60 seconds. Which behavior will occur?

A.The pod will continue running because the liveness probe only checks at startup
B.The pod will be deleted and recreated by the Deployment
C.The pod will be marked as NotReady and removed from the Service
D.The liveness probe will fail and the container will be restarted
AnswerD

Liveness probe failure triggers a container restart according to the restart policy.

Why this answer

When the file is deleted, the exec command fails, causing the liveness probe to fail. After failureThreshold attempts, the container is restarted. Option C is correct.

Full explanation →
738
MCQmedium

A Pod has the following environment variable definition: - name: DB_HOST valueFrom: configMapKeyRef: name: db-config key: host The ConfigMap 'db-config' exists in the same namespace but does not have a key 'host'. What will happen when the Pod starts?

A.The Pod will start and the environment variable will be set to the key name 'host'
B.The Pod will start and the environment variable will be empty
C.The Pod will start but the variable will be set to the ConfigMap's name
D.The Pod will fail to start because the key is not found
AnswerD

By default, configMapKeyRef is required. Missing key leads to error.

Why this answer

When a Pod references a ConfigMap key that does not exist, the Pod will fail to start. Kubernetes validates the ConfigMap key reference at Pod creation time; if the key is missing, the kubelet will not start the container, and the Pod will remain in a 'CreateContainerConfigError' or 'RunContainerError' state. This is because environment variables are resolved before the container starts, and a missing key is treated as a fatal configuration error.

Exam trap

The trap here is that candidates may assume Kubernetes will silently default to an empty string or ignore the missing key, but in reality, Kubernetes strictly validates ConfigMap key references and will fail the Pod start to prevent silent misconfiguration.

How to eliminate wrong answers

Option A is wrong because the environment variable will not be set to the key name 'host'; Kubernetes does not fall back to using the key name as a value. Option B is wrong because the environment variable will not be empty; the Pod will fail to start entirely rather than starting with an empty value. Option C is wrong because the variable will not be set to the ConfigMap's name; there is no such fallback behavior in Kubernetes.

Full explanation →
739
MCQhard

You have a CronJob that runs a backup every hour. Due to a network issue, some backups take longer than an hour, causing overlapping executions. You want to ensure that if a new job is scheduled while the previous one is still running, the new job is skipped. Which concurrencyPolicy should you set?

A.ConcurrencyPolicy: Skip
B.ConcurrencyPolicy: Allow
C.ConcurrencyPolicy: Forbid
D.ConcurrencyPolicy: Replace
AnswerC

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

Why this answer

Option B is correct. Forbid prevents new jobs from starting if the previous job is still running. Option A allows concurrent runs.

Option C replaces the running job with the new one. Option D is invalid.

Full explanation →
740
MCQeasy

You need to get a list of all events in the cluster sorted by timestamp. Which command should you use?

A.kubectl top events
B.kubectl describe events
C.kubectl get events --sort-by=.metadata.creationTimestamp
D.kubectl logs --events
AnswerC

This command lists all events sorted by creation time, showing the most recent events last.

Why this answer

The 'kubectl get events --sort-by=.metadata.creationTimestamp' command retrieves all events sorted by creation timestamp. Option A is the correct syntax.

Full explanation →
741
MCQhard

An administrator runs 'kubectl apply -f deployment.yaml' and later wants to revert to the previous configuration. Which approach is correct?

A.Run 'kubectl edit deployment <name>' and manually revert changes.
B.Run 'kubectl rollout undo deployment <name>'.
C.Run 'kubectl delete -f deployment.yaml' and reapply the old YAML.
D.Run 'kubectl replace -f deployment.yaml' with the old YAML.
AnswerB

Correct. This reverts the deployment to the previous revision.

Why this answer

kubectl rollout undo deployment <name> reverts to the previous revision.

Full explanation →
742
MCQhard

A Pod named `my-pod` in namespace `ns1` tries to resolve `svc-a.ns2.svc.cluster.local`. The DNS query fails. The Service `svc-a` exists in namespace `ns2`. What is the most likely cause?

A.The Service `svc-a` does not have any endpoints
B.The Pod cannot resolve names from other namespaces
C.The Service type is NodePort
D.The DNS add-on (e.g., CoreDNS) is not deployed or is misconfigured
AnswerD

If CoreDNS is not running or misconfigured, DNS resolution fails for all Services.

Why this answer

By default, a Pod can only resolve Services in its own namespace unless a fully qualified domain name (FQDN) is used. However, the FQDN `svc-a.ns2.svc.cluster.local` should work. The failure could be due to a missing cluster DNS add-on or a NetworkPolicy blocking DNS traffic.

Full explanation →
743
Multi-Selectmedium

Which TWO statements about Kubernetes Services are correct?

Select 2 answers
A.A ClusterIP service is accessible from outside the cluster.
B.A Service provides a stable IP address and DNS name for a set of pods.
C.A Service can load balance traffic across multiple clusters.
D.A NodePort service exposes the service on a static port on each node's IP.
E.A headless service assigns a ClusterIP to the service.
AnswersB, D

Correct.

Why this answer

A is correct: Services provide stable endpoints. C is correct: NodePort exposes on a static port on each node. B is false: ClusterIP is internal.

D is false: Services do not provide load balancing across clusters. E is false: Headless services do not have ClusterIP.

Full explanation →
744
MCQeasy

What is the correct command to forward a local port to a pod for debugging?

A.kubectl expose pod my-pod --port=8080
B.kubectl attach pod/my-pod
C.kubectl port-forward pod/my-pod 8080:80
D.kubectl proxy pod/my-pod 8080:80
AnswerC

Correct syntax.

Why this answer

`kubectl port-forward pod/my-pod 8080:80` forwards local port 8080 to pod port 80.

Full explanation →
745
MCQhard

You want to use Kustomize to apply a patch that adds a sidecar container to all pods in a Deployment. Which Kustomize feature should you use?

A.namePrefix
B.replicas
C.patchesStrategicMerge
D.images
AnswerC

Correct feature for adding sidecar containers.

Why this answer

PatchesStrategicMerge or patches (in modern Kustomize) allow you to merge a patch into an existing resource. For adding a sidecar, you would use a strategic merge patch.

Full explanation →
746
Multi-Selecteasy

Which TWO instructions are commonly used to add files to a Docker image during build? (Select 2)

Select 2 answers
A.COPY
B.ADD
C.ENTRYPOINT
D.RUN
E.CMD
AnswersA, B

Copies files from context into image.

Why this answer

Options A and D are correct: COPY and ADD are used to add files. RUN executes commands, CMD sets default command, ENTRYPOINT sets entry point.

Full explanation →
747
Multi-Selectmedium

Which TWO of the following are true about Kustomize overlays? (Select 2)

Select 2 answers
A.Overlays can only add labels, not modify existing ones.
B.Overlays are used to customize resources for different environments.
C.Overlays must be stored in the same directory as the base.
D.Overlays can patch resources defined in a base.
E.Overlays can only be used with Helm charts.
AnswersB, D

Overlays apply environment-specific patches.

Why this answer

Overlays are used to customize resources for different environments, and they can patch resources defined in bases.

Full explanation →
748
MCQmedium

You are using the Recreate strategy for a Deployment. What happens during an update?

A.New pods are created before old ones are terminated
B.Pods are updated in-place with a rolling update
C.All existing pods are terminated before new pods are created
D.Some old pods remain running until new ones become ready
AnswerC

Correct behavior.

Why this answer

Recreate kills all old pods before creating new ones. Option C is correct.

Full explanation →
749
MCQeasy

You need to create a ConfigMap named 'app-config' from a file 'config.properties'. Which kubectl command should you use?

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

Correct syntax to create a ConfigMap from a file.

Why this answer

Option C is correct because `kubectl create configmap app-config --from-file=config.properties` reads the file `config.properties` and creates a ConfigMap named `app-config` with a data key equal to the filename (`config.properties`) and the value set to the file's contents. This is the standard way to create a ConfigMap from a single file in Kubernetes.

Exam trap

The trap here is that candidates often confuse `--from-file` (which imports the entire file as a single key) with `--from-env-file` (which parses key-value pairs from a file), leading them to choose option D when they intend to import a properties file as a whole, or option B when they think `--from-literal` can accept a file path.

How to eliminate wrong answers

Option A is wrong because `kubectl create configmap` requires a flag (like `--from-file`, `--from-literal`, or `--from-env-file`) to specify the data source; simply listing the filename as a positional argument is invalid syntax and will result in an error. Option B is wrong because `--from-literal` expects a key=value pair (e.g., `--from-literal=key=value`), not a filename; using `--from-literal=config.properties` would treat the string 'config.properties' as a literal key with no value, not read the file. Option D is wrong because `--from-env-file` is used to import environment variables from a file in `key=value` format (one per line), but it does not create a ConfigMap with the file's raw content as a single key; it parses the file line-by-line, which is not the intended behavior for importing a properties file as a whole.

Full explanation →
750
MCQmedium

What is the primary purpose of a headless Service (clusterIP: None) in Kubernetes?

A.To prevent external access to the Service.
B.To provide a stable IP address for the Service.
C.To allow DNS resolution to return all pod IPs for a StatefulSet.
D.To enable load balancing across pods.
AnswerC

Headless Services enable DNS-based pod discovery for StatefulSets.

Why this answer

Headless Services are used with StatefulSets to provide stable network identities for pods, allowing direct pod-to-pod communication without a load-balanced IP.

Full explanation →
Page 9

Page 10 of 14

Page 11

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 →