CKAD Practice Exam 55 — 20 Questions

Question 1

A NetworkPolicy named 'deny-all' is applied in a namespace. Which YAML snippet correctly implements a default-deny-all ingress policy?

Accepted Answer

spec:
  podSelector: {}
  policyTypes:
  - Ingress. A NetworkPolicy with an empty `podSelector: {}` selects all pods in the namespace, and specifying `policyTypes: [Ingress]` without any `ingress` rules creates a default-deny-all ingress policy, blocking all incoming traffic. Options B and C include `ingress` rules (with empty `from`), which is not the standard approach for a strict deny-all; the canonical method is to omit the `ingress` field entirely when using `policyTypes: [Ingress]`.

Answer

spec:
  podSelector: {}
  ingress:
  - from: []

Answer

spec:
  podSelector:
    matchLabels: {}
  ingress:
  - from: []

Answer

spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Ingress

Question 2

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

Accepted Answer

Run 'kubectl rollout undo deployment '.. 'kubectl rollout undo deployment ' reverts a Deployment to its previous ReplicaSet revision by rolling back the Deployment's pod template, which is the built-in mechanism Kubernetes provides for undoing a rollout. It uses the revision history stored in the Deployment's ReplicaSets, so it restores the prior configuration cleanly without manual editing.

Answer

Run 'kubectl edit deployment <name>' and manually revert changes.

Answer

Run 'kubectl delete -f deployment.yaml' and reapply the old YAML.

Answer

Run 'kubectl replace -f deployment.yaml' with the old YAML.

Question 3

You have a Deployment 'web-app' with 4 replicas. You want to perform a rolling update such that during the update, at most 2 pods can be unavailable and at most 5 pods can be above the desired replica count. Which TWO of the following strategy configurations achieve this?

Accepted Answer

maxSurge: 5, maxUnavailable: 2. MaxSurge: 5 and maxUnavailable: 2 means during the rolling update, up to 2 pods can be unavailable (below the desired 4) and up to 5 extra pods can be created above the desired count, allowing a total of 9 pods at peak. This satisfies the requirement that at most 2 pods are unavailable and at most 5 pods are above the desired replica count. Option D is correct because 125% of 4 equals 5, and 50% of 4 equals 2, so the effective limits are the same as option C. Option B is incorrect because maxUnavailable: 0 prevents any pod from becoming unavailable during the update, making it impossible to delete old pods without violating the constraint. A rolling update requires some pods to become temporarily unavailable when they are terminated; with maxUnavailable=0, the update cannot proceed because no pod can be terminated. Thus, the configuration does not achieve a successful rolling update. Options A and E are incorrect because they allow more than 2 pods unavailable (A: maxUnavailable=3) or allow only 1 extra pod (E: maxSurge=1), not the required 5.

Answer

maxSurge: 3, maxUnavailable: 3

Answer

maxSurge: 5, maxUnavailable: 0

Answer

maxSurge: 1, maxUnavailable: 2

Question 4

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

Accepted Answer

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

Answer

Add a 'securityContext' field to the Pod template with 'runAsUser: 1000'

Answer

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

Answer

Set the label 'pod-security.kubernetes.io/warn=restricted' on the namespace

Question 5

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

Accepted Answer

runAsNonRoot: true. Option A (runAsNonRoot: true) is correct because the restricted profile requires containers to run as a non-root user, enforcing runAsNonRoot=true in the security context. Option B (seccompProfile.type: RuntimeDefault) is correct because restricted mandates a seccomp profile, and RuntimeDefault is the minimum accepted value. Option C (capabilities must drop ALL) is correct because restricted requires dropping all Linux capabilities, allowing only NET_BIND_SERVICE to be added back. Option D is incorrect because allowPrivilegeEscalation must be false under restricted, not true. Option E is incorrect because privileged containers are explicitly disallowed by the restricted profile.

Answer

allowPrivilegeEscalation: true

Answer

Privileged containers allowed

Question 6

Which TWO statements about Init Containers are correct? (Select exactly 2.)

Accepted Answer

Init containers run to completion sequentially before any app containers start. Option B is correct because Kubernetes executes init containers one at a time, in the order defined in the pod spec, and each must run to completion successfully before the next init container or any app container starts. Option C is correct because each init container is defined with its own image field in the pod spec, so it can use a completely different container image (and different tooling) than the app containers. Option A is wrong because init containers run sequentially, not in parallel, which is the opposite of what the statement claims. Option D is wrong because if an init container fails, Kubernetes restarts it according to the pod's restartPolicy (Always, OnFailure, or Never), not unconditionally regardless of restartPolicy. Option E is wrong because init containers do not support liveness, readiness, or startup probes; they are only expected to run to completion.

Answer

Init containers run in parallel to reduce startup time

Answer

If an init container fails, Kubernetes restarts it until it succeeds regardless of restartPolicy

Answer

Init containers can have liveness and readiness probes

Question 7

Which of the following are valid kubectl commands for managing rollouts? (Select all that apply)

Accepted Answer

kubectl rollout status deployment/myapp. Option A, `kubectl rollout status deployment/myapp`, is correct because it is a valid subcommand that watches the progress of a Deployment rollout until it completes or fails, reporting the current status. Option C, `kubectl rollout history deployment/myapp`, is correct because it lists the revision history of the Deployment, showing each revision number and change-cause annotation. Option D, `kubectl rollout restart deployment/myapp`, is correct because it performs a rolling restart of the Deployment by adding a restartedAt annotation to the pod template, triggering a new rollout. Option E, `kubectl rollout pause deployment/myapp`, is correct because it pauses an in-progress rollout, allowing multiple changes to be applied before resuming with `kubectl rollout resume`. Option B, `kubectl rollout diff deployment/myapp`, is not a valid kubectl subcommand; `kubectl rollout` supports status, history, undo, restart, pause, and resume, but not diff.

Answer

kubectl rollout diff deployment/myapp

Question 8

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

Accepted Answer

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

Answer

/etc/kubernetes/admin.conf

Answer

/var/run/secrets/kubernetes.io/serviceaccount/namespace

Answer

/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

Question 9

You want to run a command inside an existing container 'app-container' in pod 'my-pod'. The pod has only one container. Which command enters an interactive shell?

Accepted Answer

kubectl exec -it my-pod -- /bin/sh. The correct command is `kubectl exec -it my-pod -- /bin/sh` because it provides an interactive shell session within the only container of the pod. The `-it` flags are essential for interactive mode, allocating a pseudo-TTY and connecting stdin, while `--` delimits the command from kubectl arguments.

Answer

kubectl exec my-pod -c app-container /bin/sh

Answer

kubectl run -it my-pod --image=busybox

Answer

kubectl attach my-pod

Question 10

A pod named 'app' has a container that logs to stdout. You want to add a sidecar container that streams these logs to a centralized logging service. Which pattern does this represent?

Accepted Answer

Sidecar pattern. The sidecar pattern involves adding a secondary container (the sidecar) to the same pod as the primary container to extend or enhance its functionality without altering the primary container itself. In this scenario, the sidecar container reads the logs from the primary container's stdout (typically via a shared volume or by tailing the container's log file) and forwards them to a centralized logging service, such as Elasticsearch, Fluentd, or a cloud logging endpoint. This pattern is a core Kubernetes design pattern for modular, non-invasive extensions.

Answer

Ambassador pattern

Answer

Adapter pattern

Answer

Init container pattern

Question 11

You are tasked with building a container image for a Node.js application. The Dockerfile must first install system dependencies, then copy application code, and finally run the app. Which of the following Dockerfiles is correct?

Accepted Answer

FROM node:14
RUN apt-get update && apt-get install -y build-essential
COPY . /app
CMD ["node","app.js"]. It follows the required order: first installs system dependencies using RUN (which executes at build time), then copies application code with COPY, and finally uses CMD to define the default command that runs the Node.js app at container runtime. CMD is the appropriate instruction for specifying the executable when the container starts, as opposed to RUN which would execute during image build and fail to run the app.

Answer

FROM node:14
CMD apt-get update && apt-get install -y build-essential
COPY . /app
CMD ["node","app.js"]

Answer

FROM node:14
RUN apt-get update && apt-get install -y build-essential
COPY . /app
RUN ["node","app.js"]

Answer

FROM node:14
RUN apt-get update && apt-get install -y build-essential
COPY . /app
ENTRYPOINT ["node","app.js"]

Question 12

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

Accepted Answer

The container's root filesystem is mounted as read-only.. 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.

Answer

The container can only read from the root filesystem, but can still write to /tmp.

Answer

The container cannot write to any mounted volumes.

Answer

The container will be killed if it attempts to write to the root filesystem.

Question 13

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

Accepted Answer

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

Answer

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

Answer

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

Answer

The pod is created, but it will be evicted immediately

Question 14

Which THREE of the following are correct statements about Helm?

Accepted Answer

Values defined in a 'values.yaml' file can be referenced in templates using '{{ .Values.key }}'.. Option A is correct because Helm's templating engine exposes the merged values from values.yaml (and overrides) under the .Values object, so a key defined there is referenced in a template as {{ .Values.key }}. Option B is correct because 'helm rollback RELEASE REVISION' reverts a named release to the specified revision number, restoring the Kubernetes resources to that prior state. Option E is correct because charts are packaged artifacts that can be pushed to and pulled from a Helm repository (an HTTP server hosting an index.yaml plus .tgz chart files), enabling sharing and versioned distribution. Option C is not correct because Helm manages applications deployed into a Kubernetes cluster, not the cluster's own lifecycle (that is the role of tools like kubeadm, kops, or Cluster API). Option D is not correct because Helm 3 uses a three-way strategic merge patch during upgrades (comparing the old manifest, the new manifest, and the live state), not a two-way merge.

Answer

Helm can be used to manage the lifecycle of a Kubernetes cluster itself.

Answer

Helm uses a two-way strategic merge patch during upgrades.

Question 15

Which TWO of the following are correct methods to implement a canary deployment using Kubernetes resources?

Accepted Answer

Create two Deployments (stable and canary) with a shared Service that selects both based on a common label. Initially, canary has 1 replica while stable has many. Gradually increase canary replicas.. Option C is correct because a native Kubernetes approach to canary deployment is to run two Deployments (stable and canary) that share a common label selected by a single Service; by starting the canary with 1 replica versus many stable replicas, the Service load-balances across all matching pods, so the canary receives a small fraction of traffic that grows as you scale its replicas up. Option E is correct because an Ingress controller such as NGINX Ingress supports canary traffic splitting via annotations (e.g., nginx.ingress.kubernetes.io/canary: "true" with canary-weight or canary-by-header), letting you route a defined percentage of requests to a separate canary Deployment/Service without touching the stable path. Option A is wrong because Kubernetes Deployment strategy.type only supports Recreate and RollingUpdate; there is no built-in 'Canary' strategy type. Option B is wrong because plain Kubernetes Services do not perform header-based routing; that requires an Ingress controller or service mesh, and the option as stated misattributes the capability to Services. Option D is wrong because DNS-based percentage routing is not a Kubernetes resource mechanism and DNS cannot reliably split traffic by percentage at the request level.

Answer

Use a Deployment with 'strategy.type: Canary' in the spec.

Answer

Create two Services and use a header-based routing to send specific users to canary.

Answer

Create two separate Services, one for stable and one for canary, and use DNS to route a percentage of traffic.

Question 16

Which THREE components are required for a basic Ingress to route HTTP traffic to a Service? (Choose three.)

Accepted Answer

A Service of type ClusterIP or NodePort. Option B is correct because an Ingress routes external HTTP traffic to a backing Service, which must exist as a ClusterIP or NodePort Service that selects the application's pods and exposes the target port. Option D is correct because the Ingress resource YAML defines the routing rules (host, path, and backend Service name/port) that the controller reads to configure HTTP routing. Option E is correct because an Ingress resource has no effect on its own; an Ingress controller such as nginx-ingress watches Ingress objects and programs the actual HTTP load balancer/proxy. Option A is not required because the Ingress only needs a Service with endpoints, and those endpoints can come from any workload controller or even manually managed pods, not specifically a Deployment. Option C is not required because NetworkPolicy is an optional security control; basic Ingress routing works without any NetworkPolicy as long as the controller can reach the Service endpoints.

Answer

A Deployment of the application

Answer

A NetworkPolicy allowing traffic from the Ingress controller

Question 17

Which of the following are valid methods to perform a blue-green deployment? (Choose TWO)

Accepted Answer

Create two Deployments for blue and green, and update the Service selector to point to the new version. Option A is correct because a classic Kubernetes blue-green deployment runs two separate Deployments (blue and green) simultaneously, each with its own pod labels, and the cutover is performed by editing the Service's spec.selector to match the new version's labels, instantly redirecting traffic without downtime. Option D is correct because an Ingress resource can define rules that route requests to different backend Services, each fronting a different version of the app; switching the Ingress rule (or using weighted/canary annotations) shifts traffic from the blue Service to the green Service, achieving the same atomic cutover at layer 7. Option B is invalid because mutating pod labels on a single Deployment to match the Service selector does not create a parallel green environment and would cause the Service to lose its endpoints during the change, not a controlled blue-green switch. Option C describes a standard rolling update of one Deployment, which gradually replaces pods rather than maintaining two distinct environments. Option E is not blue-green because deleting the old Deployment before creating the new one causes downtime and provides no instant rollback path.

Answer

Create a single Deployment and update the pod labels to match the Service selector

Answer

Use a single Deployment and change the container image, then perform a rolling update

Answer

Delete the old Deployment and create a new one

Question 18

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

Accepted Answer

kubectl create secret docker-registry regcred --docker-server=my-registry.example.com --docker-username=myuser --docker-password=mypassword --docker-email=myemail@example.com. `kubectl create secret docker-registry` is the dedicated command to create a Secret of type `kubernetes.io/dockerconfigjson`. It automatically generates the required `.dockerconfigjson` field with the base64-encoded Docker credentials in the correct JSON format, which the kubelet uses to authenticate to a private registry when pulling images.

Answer

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

Answer

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

Answer

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

Question 19

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

Accepted Answer

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

Answer

LoadBalancer

Answer

ClusterIP

Answer

ExternalName

Question 20

Which TWO are valid Service types? (Choose two.)

Accepted Answer

NodePort. A is correct because NodePort is a standard Kubernetes Service type that exposes a Service on a static port (30000-32767) on each Node's IP address, allowing external traffic to reach the Service. It works by opening that port on every node and routing traffic to the ClusterIP Service, which then forwards to the Pods.

Answer

Headless

Answer

Ingress

Answer

Pod