CKAD Practice Test 14 — 15 Questions

Question 1

Which 'kubectl' command creates a pod named 'test-pod' using the nginx image and outputs the YAML manifest without actually creating it?

Accepted Answer

kubectl run test-pod --image=nginx --dry-run=client -o yaml. `kubectl run test-pod --image=nginx --dry-run=client -o yaml` generates the YAML manifest for a pod named 'test-pod' using the nginx image without actually creating it. The `--dry-run=client` flag simulates the request locally and prevents API server submission, while `-o yaml` formats the output as YAML.

Answer

kubectl apply -f pod.yaml

Answer

kubectl run test-pod --image=nginx --dry-run=server

Answer

kubectl run test-pod --image=nginx --dry-run=client -o json

Question 2

Which kubectl command creates a Secret named 'tls-secret' from a TLS certificate file 'cert.pem' and private key file 'key.pem'?

Accepted Answer

kubectl create secret tls tls-secret --cert=cert.pem --key=key.pem. The `kubectl create secret tls` command is specifically designed to create a TLS secret from a certificate and private key pair. The correct flags are `--cert` for the certificate file and `--key` for the private key file, matching the usage shown in option B.

Answer

kubectl create secret tls tls-secret --certificate=cert.pem --private-key=key.pem

Answer

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

Answer

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

Question 3

You have a pod that is in a 'Pending' state. You run 'kubectl describe pod' and see the event: '0/3 nodes are available: 3 Insufficient cpu'. What is the most likely cause?

Accepted Answer

The pod's CPU request is larger than the available CPU on any node. The event '0/3 nodes are available: 3 Insufficient cpu' indicates that the Kubernetes scheduler attempted to place the pod on each of the three nodes but found that none had enough allocatable CPU capacity to satisfy the pod's CPU request. This means the sum of CPU requests across all pods on each node, plus the new pod's request, exceeds the node's CPU capacity. The pod remains in 'Pending' because the scheduler cannot find a suitable node until CPU resources are freed or the request is reduced.

Answer

The pod requires more memory than any node can provide

Answer

The pod's liveness probe is failing

Answer

All nodes are tainted and the pod does not tolerate the taints

Question 4

Which command outputs the pod's full YAML specification including status?

Accepted Answer

kubectl get pod -o yaml. `kubectl get pod -o yaml` outputs the full YAML specification of the pod, including its status (e.g., conditions, container statuses, phase). The `-o yaml` flag retrieves the complete Kubernetes resource object from the API server, which includes both the desired spec and the current status, as stored in etcd.

Answer

kubectl describe pod <pod-name>

Answer

kubectl get pod <pod-name> --export

Answer

kubectl get pod <pod-name> -o json

Question 5

A NetworkPolicy allows egress traffic to pods with label 'db: mysql' in the same namespace. Which egress rule is correct?

Accepted Answer

egress:
  - to:
    - podSelector:
        matchLabels:
          db: mysql. A NetworkPolicy egress rule uses the `to` field to specify destination pods, and a `podSelector` within the same namespace selects pods with the label `db: mysql`. This allows outbound traffic from any pod in the namespace to pods matching that label, which directly satisfies the requirement.

Answer

egress:
  - to:
    - namespaceSelector:
        matchLabels:
          db: mysql

Answer

egress:
  - from:
    - podSelector:
        matchLabels:
          db: mysql

Answer

egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/8

Question 6

A developer needs to run a one-time batch job to process data. After completion, the pod should be retained for logs inspection. Which Job configuration parameter should be set?

Accepted Answer

Leave ttlSecondsAfterFinished unset. To retain a Job's Pod after completion for log inspection, the `ttlSecondsAfterFinished` field must be left unset (or set to nil). When this field is unset, the Job controller does not automatically delete the Pod, allowing logs to be inspected. Setting it to any non-negative integer would schedule automatic deletion after that many seconds, which contradicts the requirement.

Answer

backoffLimit: 0

Answer

ttlSecondsAfterFinished: -1

Answer

activeDeadlineSeconds: 3600

Question 7

A NetworkPolicy named 'default-deny-ingress' is applied to a namespace but contains no rules. What is the effect on pods in that namespace?

Accepted Answer

All ingress traffic is denied.. A NetworkPolicy with no rules defaults to denying all ingress traffic because Kubernetes NetworkPolicies are additive: any pod selected by a NetworkPolicy is isolated, and only traffic explicitly allowed by rules is permitted. Since this policy has no rules, no ingress traffic is allowed, effectively creating a deny-all ingress policy for pods in the namespace.

Answer

Only traffic from pods with label 'allow: true' is allowed.

Answer

All ingress traffic is allowed.

Answer

Only traffic from pods in the same namespace is allowed.

Question 8

A ClusterRole named 'secret-reader' grants get, list, watch on secrets in all namespaces. A RoleBinding in namespace 'app' binds this ClusterRole to a ServiceAccount 'app-sa'. Which of the following is true about the effective permissions of 'app-sa'?

Accepted Answer

The ServiceAccount can read secrets only in namespace 'app'. A RoleBinding can only grant permissions within its own namespace, even when it references a ClusterRole. Since the RoleBinding is in namespace 'app', the ServiceAccount 'app-sa' receives the permissions defined in the 'secret-reader' ClusterRole, but scoped only to namespace 'app'. Therefore, it can read secrets only in namespace 'app', not in all namespaces.

Answer

The ServiceAccount can read secrets in all namespaces

Answer

The RoleBinding is invalid because ClusterRole cannot be used with RoleBinding

Answer

The ServiceAccount can read secrets only in the default namespace

Question 9

A Kubernetes Job with parallelism=3 and completions=6 is created. How many pods will run concurrently at most?

Accepted Answer

3. The `parallelism` field in a Kubernetes Job specifies the maximum number of pods that can run concurrently. With `parallelism=3`, at most 3 pods will run at the same time, regardless of the total number of completions required.

Answer

9

Answer

6

Answer

1

Question 10

You want to perform a canary deployment where 10% of traffic goes to the new version. You have a Deployment 'app-v1' with 10 replicas. You create a second Deployment 'app-v2' with 1 replica and a new Service. What Kubernetes resource is typically used to split traffic between the two Services?

Accepted Answer

Ingress resource with a canary annotation. An Ingress resource with a canary annotation (e.g., `nginx.ingress.kubernetes.io/canary-weight: "10"`) allows you to split traffic between two Services by weight. This is the standard Kubernetes approach for canary deployments, where the Ingress controller (like NGINX) routes a specified percentage of traffic to the canary Service (app-v2) and the rest to the primary Service (app-v1).

Answer

A single Service with multiple selectors

Answer

NetworkPolicy

Answer

HorizontalPodAutoscaler

Question 11

A pod named 'db-backup' is in CrashLoopBackOff. The team needs to understand why it keeps crashing. Which approach should be taken first to diagnose the issue?

Accepted Answer

View the logs of the pod using kubectl logs. C is correct because `kubectl logs` directly shows the stdout/stderr output from the container's main process, which typically contains the error message or stack trace explaining why the application crashed. Since the pod is in CrashLoopBackOff, the container is repeatedly starting and failing, so viewing the logs from the last (or previous) attempt is the fastest way to identify the root cause, such as a missing configuration file, a failed dependency, or an unhandled exception.

Answer

Increase the restart policy to Always

Answer

Run kubectl describe pod

Answer

Check the pod's events with kubectl get events

Question 12

Which TWO statements about init containers are true?

Accepted Answer

Init containers run to completion before any regular containers start.. Init containers are designed to run to completion before any regular containers in the Pod start. This ensures that prerequisites (e.g., database schema migrations, configuration file generation, or waiting for a service to become available) are satisfied before the main application containers begin execution.

Answer

Init containers run in parallel with regular containers.

Answer

Init containers must use the same image as the main container.

Answer

Init containers cannot access volumes shared with regular containers.

Question 13

Which TWO statements about Kubernetes DNS are correct?

Accepted Answer

A service named 'api' in namespace 'prod' has DNS name 'api.prod.svc.cluster.local'. Kubernetes DNS assigns a fully qualified domain name (FQDN) to services following the pattern `..svc.cluster.local`. For a service named 'api' in the 'prod' namespace, the DNS name is `api.prod.svc.cluster.local`, enabling cluster-internal service discovery via CoreDNS or kube-dns.

Answer

The kube-dns service is responsible for DNS resolution

Answer

Pods with hostNetwork: true automatically get DNS entries

Answer

A pod's DNS name is always 'pod-ip.namespace.pod.cluster.local'

Question 14

A company wants to deploy a stateless web application on Kubernetes. The application needs to be accessible externally via a stable IP address and should support SSL termination at the ingress level. Which resource should be used to route external traffic to the application?

Accepted Answer

Ingress. Ingress is the correct resource because it provides external HTTP/HTTPS access to services within a cluster, supports SSL/TLS termination at the ingress controller level, and can expose multiple services under a single stable IP address or hostname. Unlike other service types, Ingress is specifically designed for layer 7 routing and SSL termination, making it ideal for stateless web applications that require a stable external endpoint.

Answer

ClusterIP

Answer

NodePort

Answer

LoadBalancer

Question 15

A deployment is configured with a liveness probe that checks an HTTP endpoint. The probe fails intermittently, causing pod restarts. What is the best first step to diagnose the issue?

Accepted Answer

Examine the container logs via 'kubectl logs' for error messages around the time of the failures.. Container logs provide the application's perspective on why the HTTP endpoint is failing intermittently. The liveness probe failure is a symptom; the root cause (e.g., a transient error, resource exhaustion, or a bug) is most directly visible in the application's own log output around the failure timestamps. This aligns with the CKAD domain of Application Observability and Maintenance, where logs are the primary diagnostic tool for application-level issues.

Answer

Check the liveness probe events via 'kubectl describe pod' to see the exact probe responses.

Answer

Run 'kubectl exec' to curl the endpoint from another pod to test network connectivity.

Answer

Review the liveness probe parameters in the deployment YAML and increase the failureThreshold.