CKAD Practice Test 13 — 15 Questions

Question 1

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?

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

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 2

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 3

You need to create a TLS secret for an ingress with certificate and key. Which command correctly creates the secret?

Accepted Answer

kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key. `kubectl create secret tls` is the dedicated subcommand for creating a TLS secret, which automatically encodes the certificate and key files and stores them under the expected keys (`tls.crt` and `tls.key`). This is the only command that produces a secret of type `kubernetes.io/tls`, which is required by Ingress controllers to serve HTTPS traffic.

Answer

kubectl create secret docker-registry tls-secret --docker-cert=tls.crt --docker-key=tls.key

Answer

kubectl create secret generic tls-secret --from-file=tls.crt --from-file=tls.key

Answer

kubectl create secret certificate tls-secret --cert= --key=

Question 4

You need to configure a liveness probe for a container that starts a web server on port 8080. The probe should check the '/healthz' endpoint. Which YAML snippet correctly defines this probe?

Accepted Answer

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080. It defines an HTTP GET liveness probe that checks the '/healthz' endpoint on port 8080, which is the standard way to verify the health of a web server. The `httpGet` probe sends an HTTP GET request to the specified path and port, and the container is considered healthy if the response status code is between 200 and 399.

Answer

livenessProbe:
  exec:
    command: ["curl", "http://localhost:8080/healthz"]

Answer

livenessProbe:
  httpGet:
    port: 8080

Answer

livenessProbe:
  tcpSocket:
    port: 8080

Question 5

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

Accepted Answer

Increase the memory limit in the pod's container resource specification. The pod is in CrashLoopBackOff due to OOMKilled, which means the container's memory usage exceeded its configured memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container to allocate more memory without being terminated by the Out-of-Memory (OOM) killer.

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads

Answer

Increase the CPU request for the container

Question 6

You have a multi-container pod with two containers: container-A and container-B. container-B needs to access the network of container-A. Which configuration is required?

Accepted Answer

No additional configuration is needed; they share the same network namespace. In Kubernetes, containers within the same pod share the same network namespace by default, including the same IP address and port space. This means container-B can reach container-A via localhost and the port that container-A is listening on, without any additional configuration. The shared network namespace is a fundamental property of pod design, enabling direct inter-container communication.

Answer

Define a ServiceAccount for container-B to access container-A

Answer

Set hostNetwork: true in the pod spec

Answer

Expose the port in container-A and map it in container-B

Question 7

An init container in a pod runs a database migration script. The init container fails and exits with a non-zero exit code. What will happen to the pod?

Accepted Answer

The init container will be restarted until it succeeds. Init containers must run successfully (exit 0) before the main containers start. If an init container fails, Kubernetes restarts it (if restartPolicy is Always or OnFailure) until it succeeds. The pod will remain in Init:Error state until the init container succeeds.

Answer

The main containers will start anyway

Answer

The pod will enter CrashLoopBackOff

Answer

The pod will be deleted and recreated

Question 8

A Pod is configured with securityContext: { runAsUser: 1000, runAsGroup: 2000, fsGroup: 3000 }. The container's image runs a process that must listen on a TCP port below 1024 (e.g., port 80). The process is currently failing to start. What should you modify to allow the process to bind to a privileged port?

Accepted Answer

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

Answer

Set 'allowPrivilegeEscalation: true'

Answer

Add 'capabilities.drop: [ALL]' to the container's securityContext

Answer

Set runAsUser: 0 to run as root

Question 9

You need to allow ingress traffic to pods with label 'app: web' from pods with label 'role: frontend' in the same namespace, and also from any pod in namespace 'monitoring'. Which NetworkPolicy egress/ingress rule correctly implements this?

Accepted Answer

spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    - podSelector:
        matchLabels:
          role: frontend. It defines two separate ingress rules: one allowing traffic from pods with label 'role: frontend' in the same namespace, and another allowing traffic from any pod in namespace 'monitoring'. In Kubernetes NetworkPolicy, when multiple items are listed under 'from' in an ingress rule, they are ORed; however, here each rule is independent, so the first rule matches pods with 'role: frontend' (no namespaceSelector, so same namespace), and the second rule matches all pods in the 'monitoring' namespace (no podSelector, so all pods). This satisfies the requirement.

Answer

spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
      namespaceSelector:
        matchLabels:
          name: monitoring

Answer

spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
  - from:
    - namespaceSelector:
        matchLabels:
          name: monitoring

Question 10

You have a Deployment named 'frontend' with 4 replicas. You want to perform a rolling update with the following constraints: the number of pods above the desired count should never exceed 1, and the number of unavailable pods should never exceed 0. Which deployment strategy configuration achieves this?

Accepted Answer

strategy: rollingUpdate: {maxSurge: 1, maxUnavailable: 0}. Setting `maxSurge: 1` ensures that during a rolling update, at most one additional pod is created above the desired replica count of 4, and `maxUnavailable: 0` guarantees that no pods are taken down until the new ones are ready. This satisfies the constraints of never exceeding one extra pod and never having unavailable pods.

Answer

strategy: rollingUpdate: {maxSurge: 2, maxUnavailable: 0}

Answer

strategy: rollingUpdate: {maxSurge: 25%, maxUnavailable: 25%}

Answer

strategy: type: Recreate

Question 11

You need to create a Secret of type kubernetes.io/tls for use with an Ingress. Which kubectl command should you use?

Accepted Answer

kubectl create secret tls my-tls --cert=cert.pem --key=key.pem. `kubectl create secret tls` is the dedicated command for creating a TLS secret, which automatically stores the certificate and key under the expected keys `tls.crt` and `tls.key` respectively. This secret type (`kubernetes.io/tls`) is required by Ingress controllers to serve HTTPS traffic, and the command directly accepts `--cert` and `--key` flags for the PEM-encoded files.

Answer

kubectl create secret docker-registry my-tls --docker-username=user --docker-password=pass

Answer

kubectl create secret generic my-tls --from-file=cert.pem --from-file=key.pem

Answer

kubectl create secret tls my-tls --from-file=tls.crt --from-file=tls.key

Question 12

You need to allow ingress traffic to pods in namespace 'api' only from pods in namespace 'frontend' that have label 'role: proxy'. Which NetworkPolicy ingress rule correctly implements this?

Accepted Answer

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        name: frontend
    podSelector:
      matchLabels:
        role: proxy. It combines a namespaceSelector (to match the 'frontend' namespace) with a podSelector (to match pods with label 'role: proxy') in the same ingress rule. This ensures that only traffic from pods in the 'frontend' namespace that also have the label 'role: proxy' is allowed, fulfilling the requirement precisely.

Answer

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        name: frontend

Answer

ingress:
- from:
  - ipBlock:
      cidr: 0.0.0.0/0
  - podSelector:
      matchLabels:
        role: proxy

Answer

ingress:
- from:
  - podSelector:
      matchLabels:
        role: proxy

Question 13

Which TWO of the following are valid fields in a container's SecurityContext to restrict privilege escalation? (Select two.)

Accepted Answer

allowPrivilegeEscalation. A is correct because `allowPrivilegeEscalation` directly controls whether a process can gain more privileges than its parent, such as via setuid binaries or file capabilities. Setting it to `false` prevents privilege escalation, which is a core security requirement for restricting container breakout.

Answer

readOnlyRootFilesystem

Answer

runAsNonRoot

Answer

privileged

Question 14

A pod needs to mount a Secret named 'db-secret' as a volume at /etc/secret. Which volume mount definition is correct?

Accepted Answer

volumes:
- name: secret-volume
  secret:
    secretName: db-secret. It uses the proper `secret` key under the `volumes` field to reference a Secret object by its `secretName`. When this volume is mounted at `/etc/secret`, Kubernetes automatically creates a file for each key in the Secret, with the file content being the decoded value of the key. This is the standard syntax for mounting a Secret as a volume.

Answer

volumes:
- name: secret-volume
  secretVolumeSource:
    secretName: db-secret

Answer

volumes:
- name: db-secret
  secret:
    secretName: db-secret

Answer

volumes:
- name: secret-volume
  secret:
    name: db-secret

Question 15

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?

Accepted Answer

The secret name in the TLS section of the Ingress does not match the actual secret name. The most likely cause is that the secret name specified in the TLS section of the Ingress resource does not match the actual name of the Secret object. When TLS is configured, the Ingress controller reads the `secretName` field to fetch the certificate and key; a mismatch causes the controller to fail to load the TLS material, resulting in a certificate error. Since the secret exists in the same namespace, the only plausible issue is a naming mismatch.

Answer

The Ingress controller does not support TLS

Answer

The secret is in a different namespace than the Ingress

Answer

The certificate is not signed by a trusted CA