CKAD Practice Test 36 — 15 Questions

Question 1

Which command streams logs from a pod in real-time?

Accepted Answer

kubectl logs -f pod-name. `kubectl logs -f` (the `-f` flag stands for 'follow') streams log output from a pod in real-time, similar to `tail -f` on a file. This is the standard Kubernetes command for continuous log monitoring, allowing you to see new log lines as they are written by the container.

Answer

kubectl logs --stream pod-name

Answer

kubectl logs --previous pod-name

Answer

kubectl logs pod-name

Question 2

A Role named 'pod-reader' in namespace 'ns1' grants get, list, and watch on pods. Which RoleBinding correctly binds this role to a ServiceAccount 'sa1' in the same namespace?

Accepted Answer

roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: ns1. A RoleBinding in the same namespace as the Role and ServiceAccount must specify the Role's kind as 'Role' (not ClusterRole) and include the ServiceAccount's namespace in the subjects list. The roleRef references the 'pod-reader' Role with the correct apiGroup and kind, and the subject specifies the ServiceAccount 'sa1' in namespace 'ns1', which matches the Role's namespace, allowing the binding to grant the permissions.

Answer

roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: User name: sa1

Answer

roleRef: { apiGroup: rbac.authorization.k8s.io, kind: ClusterRole, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: ns1

Answer

roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: default

Question 3

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 run to completion before any app containers start, and Kubernetes treats a non-zero exit as a failure of that init container. The kubelet will restart the failed init container according to the pod's restartPolicy (default Always), retrying until it succeeds. Only after all init containers exit 0 will the main containers be started.

Answer

The main containers will start anyway

Answer

The pod will enter CrashLoopBackOff

Answer

The pod will be deleted and recreated

Question 4

Consider the following partial Dockerfile:
FROM alpine:3.18 AS builder
RUN apk add --no-cache curl
COPY src /app/src
RUN make /app/bin

FROM alpine:3.18
COPY --from=builder /app/bin /app/bin
CMD ["/app/bin"]
What is the primary benefit of this multi-stage build?

Accepted Answer

Reduced final image size by excluding build dependencies. The primary benefit of a multi-stage build is reduced final image size by excluding build dependencies. The builder stage installs build tools like curl and compiles the application, but only the compiled binary is copied to the final stage, leaving behind the build tools and intermediate files. This results in a smaller, more secure production image.

Answer

Faster builds because the builder stage runs in parallel

Answer

Automatic caching of the builder stage

Answer

Improved security by running the builder as a non-root user

Question 5

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

Accepted Answer

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

Answer

The pod runs normally; Kubernetes automatically makes /tmp writable.

Answer

The pod is rejected by the admission controller because readOnlyRootFilesystem conflicts with writing to /tmp.

Answer

The container writes successfully because readOnlyRootFilesystem only applies to the container image layers.

Question 6

Order the steps to perform a rolling rollback of a Deployment to a previous revision.

Accepted Answer

View the deployment revision history, then choose the revision to rollback to, then perform the rollback using kubectl rollout undo, then wait for the rollout to complete, then verify the deployment status. View history, choose revision, undo to that revision, wait for completion, then verify.

Answer

Choose the revision to rollback to, then view the deployment revision history, then perform the rollback, then wait for the rollout to complete, then verify

Answer

View the history, choose the revision, perform the rollback, then verify, then wait for completion

Answer

Perform the rollback, then view the history, then choose the revision, then wait, then verify

Question 7

Which Kubernetes API version is used for creating a CronJob?

Accepted Answer

batch/v1. CronJob is a Kubernetes resource that was promoted to a stable API version in Kubernetes 1.21. The correct API version for creating a CronJob is batch/v1, as it is the current stable version. The batch/v1beta1 version is deprecated and removed in Kubernetes 1.25, so batch/v1 is the correct choice for CKAD exam scenarios.

Answer

batch/v1beta1

Answer

cron/v1

Answer

apps/v1

Question 8

A Pod is configured with automountServiceAccountToken: false. The application inside the pod needs to access the Kubernetes API. What should be done?

Accepted Answer

Mount the service account token manually by adding a volume and volumeMount. Setting automountServiceAccountToken: false prevents automatic mounting of the service account token. To still access the Kubernetes API, you must manually mount the token by adding a volume of type projected (or secret) containing the service account token, and a corresponding volumeMount in the container. This allows the application to authenticate with the API server using the mounted token.

Answer

Create a new Secret of type kubernetes.io/dockerconfigjson

Answer

The application cannot access the API; the setting is final

Answer

Add a ConfigMap with the token

Question 9

Which THREE components are typically involved when using Ingress to expose a service?

Accepted Answer

Ingress resource. An Ingress resource defines the routing rules for external HTTP/HTTPS traffic to services within the cluster. It specifies hostnames, paths, and the backend service to forward requests to, but it is only a configuration object. The actual traffic handling requires an Ingress controller (e.g., NGINX, Traefik) to process the Ingress resource and implement the rules, and a Service of type ClusterIP or NodePort to expose the target pods internally.

Answer

External load balancer

Answer

NetworkPolicy

Question 10

A pod has two containers: a web server and a sidecar that scrapes logs. The sidecar container needs to read log files written by the web server. How should the logs be shared between the containers?

Accepted Answer

Use a shared emptyDir volume mounted into both containers at the same path. An emptyDir volume is a shared, ephemeral volume that is created when a Pod is assigned to a node and exists as long as that Pod is running. Both containers in the same Pod can mount the same emptyDir volume at the same or different paths, allowing the sidecar to read log files written by the web server without any external storage dependency. This is the standard Kubernetes pattern for inter-container log sharing within a Pod.

Answer

Use a ConfigMap to store logs

Answer

Use a hostPath volume mounted in both containers

Answer

Use a PersistentVolumeClaim

Question 11

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

Accepted Answer

helm list. The `helm list` command is the correct way to list all releases in the current namespace, showing their status (deployed, failed, pending, etc.). It provides a summary of each release, including the name, revision, update time, and status. This directly answers the question of listing the status of all releases.

Answer

helm status my-wordpress

Answer

helm history my-wordpress

Answer

helm show status

Question 12

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?

Accepted Answer

helm upgrade myapp ./mychart --values prod-values.yaml. `helm upgrade myapp ./mychart --values prod-values.yaml` explicitly specifies the release name (`myapp`), the chart path (`./mychart`), and the values file (`--values prod-values.yaml`). This is the standard syntax for upgrading a Helm release with custom values, where `--values` (or `-f`) merges the provided YAML file over the default chart values.

Answer

helm upgrade ./mychart prod-values.yaml --release myapp

Answer

helm upgrade --install myapp ./mychart -f prod-values.yaml

Answer

helm upgrade myapp -f prod-values.yaml

Question 13

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

Accepted Answer

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

Answer

A Role with the appropriate rules

Answer

A ClusterRoleBinding that binds the ClusterRole to the ServiceAccount

Answer

A ClusterRole with the same rules

Question 14

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

Accepted Answer

spec:
  securityContext:
    runAsUser: 1000
    runAsNonRoot: true
  containers:
  - name: app
    securityContext:
      readOnlyRootFilesystem: true. Ly sets runAsUser and runAsNonRoot at the pod level to enforce non-root execution with UID 1000, and readOnlyRootFilesystem at the container level, which is the correct placement for that field. The other options either use invalid fields (runAsRoot), omit runAsNonRoot, or incorrectly place readOnlyRootFilesystem at the pod level.

Answer

securityContext:
  runAsNonRoot: true
  runAsRoot: false
  readOnlyRootFilesystem: true

Answer

securityContext:
  runAsGroup: 1000
  readOnlyRootFilesystem: true

Answer

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true

Question 15

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

Accepted Answer

Readiness probe. A Readiness probe determines whether a container is ready to accept traffic. If the probe fails, Kubernetes removes the pod's IP address from the endpoints of all Services that match the pod's labels, effectively stopping traffic from reaching the pod while it remains in the Running state. This is the correct probe for removing an unhealthy pod from Service endpoints without terminating it.

Answer

Resource limits

Answer

Startup probe

Answer

Liveness probe