CKAD Practice Test 42 — 15 Questions

Question 1

You have a Deployment 'app' with the following strategy configuration: 'type: RollingUpdate', 'rollingUpdate: {maxSurge: 0, maxUnavailable: 1}'. You update the container image. What is the behavior during the update?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

One old pod is terminated, then a new pod is created, repeating until all pods are updated.. With `maxSurge: 0` and `maxUnavailable: 1`, the RollingUpdate strategy ensures that during the update, no extra pods beyond the desired replica count are created (surge is zero), and at most one pod can be unavailable at any time. The Deployment controller first terminates an old pod (making one unavailable), then creates a new pod to replace it, repeating this process until all pods are updated. This guarantees a controlled, sequential rollout with minimal disruption.

Answer

A new pod is created first, then the oldest pod is terminated.

Answer

Two old pods are terminated at a time, while new pods are created.

Answer

All old pods are terminated simultaneously, then new pods are created.

Question 2

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

Accepted Answer

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

Answer

The container is killed because it violated the seccomp policy.

Answer

The pod is evicted by the kubelet because of a security violation.

Answer

The container runs successfully because RuntimeDefault allows all syscalls.

Question 3

Which THREE statements correctly describe Kustomize? (Select THREE.)

Accepted Answer

Kustomize uses a kustomization.yaml file to define customization rules.. Option A is correct because Kustomize is driven by a kustomization.yaml file that declares the resources, bases, overlays, patches, and other customization rules for a given directory. Option D is correct because Kustomize natively supports both strategic merge patches (which merge by Kubernetes object schema and merge keys) and JSON patches (RFC 6902-style operations) to modify resources. Option E is correct because kubectl has built-in Kustomize support, so kubectl apply -k <directory> builds and applies the kustomization found in that directory. Option B is incorrect because Kustomize works with plain Kubernetes YAML manifests and is not limited to Helm charts; it can even be combined with Helm output via helm template. Option C is incorrect because Kustomize is a client-side, standalone binary (and is embedded in kubectl) with no separate server component required.

Answer

Kustomize can only be used with Helm charts.

Answer

Kustomize requires a separate server component to run.

Question 4

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

Accepted Answer

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

Answer

serviceAccountName: my-sa

Answer

serviceAccountName: my-sa
  automountServiceAccountToken: false

Answer

containers:
  - automountServiceAccountToken: false

Question 5

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

Accepted Answer

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

Answer

kubectl create configmap app-config --from-file=app.properties --from-env-file=app.properties

Answer

kubectl create configmap app-config --from-literal=app.properties

Answer

kubectl create configmap app-config --from-env-file=app.properties

Question 6

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

Accepted Answer

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

Answer

spec.serviceAccount

Answer

spec.accountName

Answer

spec.automountServiceAccountToken

Question 7

You are performing a blue-green deployment. You have two Deployments: 'app-blue' and 'app-green', each with 5 replicas. Both are labeled with 'app: myapp'. The Service 'myapp-svc' selects pods with 'app: myapp' and 'version: blue'. After deploying the new version to 'app-green' and verifying it, what change is required to switch traffic to the green deployment?

Accepted Answer

Update the Service selector to 'version: green'. In a blue-green deployment, traffic is switched by updating the Service's selector to match the labels of the new version's pods. Here, the Service 'myapp-svc' selects pods with 'version: blue'. To route traffic to the green deployment, you must change the selector to 'version: green'. This causes the Service to immediately forward traffic to the green pods without modifying the pods themselves.

Answer

Update the label on app-green pods to 'version: blue'

Answer

Scale down app-blue to 0 replicas

Answer

Delete app-blue deployment

Question 8

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?

Accepted Answer

Use an Ingress controller that supports canary deployments or a service mesh. Kubernetes Services alone cannot perform weighted traffic splitting based on replica counts; they use round-robin load balancing at the pod level. To achieve a precise 10% traffic split, you need an Ingress controller (e.g., NGINX Ingress with canary annotations) or a service mesh (e.g., Istio with VirtualService) that supports weighted routing between two different Services or subsets. This allows you to direct a specific percentage of traffic to the canary version independently of replica counts.

Answer

Use a Service with multiple ports

Answer

Set the Service's sessionAffinity to distribute load

Answer

Scale app-canary to 1 replica and app-stable to 9 replicas, and use a single Service that selects both

Question 9

You want to use Kustomize to apply a patch to a Deployment in the 'overlays/production' directory. Which command should you run from the kustomization directory?

Accepted Answer

kubectl apply -k overlays/production/. `kubectl apply -k` is the standard command to apply a Kustomize overlay directly from a directory. It instructs kubectl to process the kustomization.yaml file in the specified path, build the final Kubernetes resources with all patches and transformations applied, and then apply them to the cluster. This is the idiomatic way to use Kustomize with kubectl in a production overlay scenario.

Answer

kubectl create -k overlays/production/

Answer

kustomize build overlays/production/ | kubectl apply -f -

Answer

kubectl apply -f overlays/production/

Question 10

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

Accepted Answer

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

Answer

username and password

Answer

tls.crt, tls.key, and ca.crt

Answer

.dockerconfigjson

Question 11

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

Accepted Answer

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

Answer

securityContext:
  allowPrivilegeEscalation: false

Answer

securityContext:
  runAsNonRoot: true

Answer

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: true

Question 12

Given the following NetworkPolicy YAML:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

What is the effect of this policy?

Accepted Answer

Denies all ingress and egress traffic to and from all pods in the namespace. This NetworkPolicy uses an empty `podSelector: {}` which selects all pods in the namespace. By specifying both `Ingress` and `Egress` in `policyTypes` without any `ingress` or `egress` rules, the policy defaults to denying all ingress and egress traffic. In Kubernetes, NetworkPolicy rules are additive (allow-listed), so an empty rules list means no traffic is permitted, effectively creating a default-deny for both directions.

Answer

Denies all ingress traffic but allows all egress traffic

Answer

Allows all traffic to and from pods in the namespace

Answer

Denies all traffic except traffic that is explicitly allowed by other policies

Question 13

You have a Helm chart for an application. You want to upgrade the release but only if the upgrade does not introduce breaking changes. Which command should you use?

Accepted Answer

helm upgrade --dry-run my-release ./mychart. `helm upgrade --dry-run` simulates the upgrade process and validates the chart against the cluster without actually applying changes. The `--dry-run` flag allows you to detect breaking changes (e.g., missing required values, API deprecations, or incompatible resource definitions) before committing to the upgrade, ensuring the release remains stable.

Answer

helm install --dry-run my-release ./mychart

Answer

helm rollback my-release 0

Answer

helm diff upgrade my-release ./mychart

Question 14

You have a Deployment that uses an httpGet liveness probe on port 8080 with path /healthz. The probe fails after the container starts, but you can successfully curl http://localhost:8080/healthz from within the container. What is the most likely cause?

Accepted Answer

The container is listening on localhost (127.0.0.1) instead of 0.0.0.0. The liveness probe is executed by the kubelet from the node's network namespace, not from within the container. If the application binds only to 127.0.0.1 (localhost), it will only accept connections from within the container itself. The kubelet's HTTP GET request to the pod's IP on port 8080 will be refused because the socket is not listening on 0.0.0.0, causing the probe to fail even though a local curl succeeds.

Answer

The liveness probe port is incorrect

Answer

The container is not running

Answer

The liveness probe path is incorrect

Question 15

What annotation is required on an Ingress resource to use a specific IngressClass (e.g., 'nginx')?

Accepted Answer

kubernetes.io/ingress.class: nginx. The `kubernetes.io/ingress.class` annotation is the legacy method to specify the IngressClass for an Ingress resource. This annotation tells the Ingress controller (e.g., nginx) which controller should process the Ingress rules. In Kubernetes 1.18+, the preferred method is the `spec.ingressClassName` field, but the annotation is still widely supported for backward compatibility.

Answer

kubernetes.io/ingress-type: nginx

Answer

ingress.kubernetes.io/class: nginx

Answer

kubernetes.io/class: nginx