CKA Practice Exam 2 — 20 Questions

Question 1

A node named 'worker-1' is unhealthy. You want to mark it as unschedulable and move workloads to other nodes. Which command sequence is correct?

Accepted Answer

kubectl cordon worker-1; kubectl drain worker-1. `kubectl cordon worker-1` marks the node as unschedulable, preventing new pods from being scheduled onto it, and `kubectl drain worker-1` safely evicts all existing pods from the node, respecting PodDisruptionBudgets and terminating pods gracefully. This sequence ensures workloads are moved to other nodes without disrupting running services.

Answer

kubectl uncordon worker-1; kubectl drain worker-1

Answer

kubectl delete node worker-1; kubectl cordon worker-1

Answer

kubectl drain worker-1; kubectl cordon worker-1

Question 2

A pod is stuck in Pending state. 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) didn't match pod anti-affinity rules'. What is the most likely cause?

Accepted Answer

The pod has a requiredDuringSchedulingIgnoredDuringExecution anti-affinity rule that is too restrictive. The event '0/3 nodes are available: 3 node(s) didn't match pod anti-affinity rules' directly indicates that the pod's scheduling is being blocked by anti-affinity constraints. Option B is correct because a `requiredDuringSchedulingIgnoredDuringExecution` anti-affinity rule is a hard constraint that must be satisfied at scheduling time; if no node meets the rule (e.g., the rule prevents co-location with other pods that are present on all nodes), the pod remains Pending.

Answer

The nodes have insufficient resources

Answer

The pod has a taint tolerance issue

Answer

The nodes are all cordoned

Question 3

You run `kubectl port-forward service/my-svc 8080:80`. What does this command do?

Accepted Answer

It forwards local port 8080 to port 80 on a Pod selected by the Service, bypassing the Service's ClusterIP.. The `kubectl port-forward` command forwards connections from a local port to a port on a Pod. When you specify a Service (e.g., `service/my-svc`), kubectl automatically selects an active Pod matching the Service's selector and forwards the traffic directly to that Pod. It completely bypasses the Service's ClusterIP and kube-proxy routing.

Answer

It forwards traffic from port 80 to port 8080 within the cluster.

Answer

It creates a LoadBalancer Service on port 8080 forwarding to port 80.

Answer

It exposes the Service on each node's port 8080.

Question 4

You have a Kubernetes cluster with a single control-plane node and multiple worker nodes. You need to upgrade the cluster from v1.28.0 to v1.29.0. Which sequence of steps is correct?

Accepted Answer

Upgrade the control plane first, then drain each worker node, upgrade the kubelet and kube-proxy, then uncordon. Kubernetes requires the control plane to be upgraded first, as it is the source of truth for the cluster state and API version compatibility. After the control plane is upgraded, each worker node must be drained (to evict pods gracefully), upgraded (kubelet and kube-proxy), and then uncordoned to resume scheduling. This sequential process ensures that the cluster remains functional and that kubelet versions never exceed the kube-apiserver version, which is a strict compatibility requirement.

Answer

Upgrade all worker nodes first, then upgrade the control plane

Answer

Drain all nodes simultaneously, upgrade the control plane, then upgrade worker nodes

Answer

Upgrade the control plane and worker nodes at the same time

Question 5

You have a Deployment named 'web-app' in the 'default' namespace. You run the following command: kubectl rollout history deployment web-app. The output shows: revision 1, revision 2, revision 3. You want to roll back to revision 1. Which command achieves this?

Accepted Answer

kubectl rollout undo deployment web-app --to-revision=1. `kubectl rollout undo` with the `--to-revision` flag is the proper syntax to roll back a Deployment to a specific revision. The command `kubectl rollout undo deployment web-app --to-revision=1` reverts the Deployment to revision 1, as shown in the rollout history output.

Answer

kubectl rollout undo deployment web-app --revision=1

Answer

kubectl rollback deployment web-app --to-revision=1

Answer

kubectl rollout undo deployment web-app

Question 6

You apply the following NetworkPolicy to namespace 'ns1':
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []
What effect does this policy have?

Accepted Answer

Denies all ingress traffic to all pods in namespace ns1.. This NetworkPolicy selects all pods in namespace 'ns1' (via empty `podSelector: {}`), specifies `policyTypes: [Ingress]`, and defines an empty `ingress: []` rule list. In Kubernetes, an empty `ingress: []` explicitly denies all ingress traffic because no allow rules are present, overriding the default allow-all behavior. Therefore, all ingress traffic to any pod in ns1 is denied.

Answer

Denies all egress traffic as well.

Answer

Allows ingress traffic only from pods in the same namespace.

Answer

Allows all ingress traffic because no explicit deny rules are defined.

Question 7

You apply the following NetworkPolicy:

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

What effect does this policy have?

Accepted Answer

All ingress traffic to any pod in the namespace is denied.. This NetworkPolicy uses a `podSelector: {}` which selects all pods in the namespace, and specifies `policyTypes: [Ingress]` with no ingress rules. According to Kubernetes NetworkPolicy semantics, when no ingress rules are defined, all ingress traffic is denied. This effectively creates a default-deny ingress policy for all pods in the namespace, making option D correct.

Answer

Ingress traffic from pods with label 'app: allowed' is allowed.

Answer

All ingress and egress traffic to/from pods in the namespace is denied.

Answer

The policy has no effect because no rules are specified.

Question 8

Which THREE of the following are CNI plugins?

Accepted Answer

Flannel. Flannel is a CNI plugin that provides a simple overlay network for Kubernetes clusters, typically using VXLAN or host-gw to encapsulate and route pod traffic across nodes. It implements the Container Network Interface (CNI) specification by installing a binary and configuration file on each node, enabling pod-to-pod communication without requiring a separate network daemon.

Answer

kube-proxy

Answer

CoreDNS

Question 9

After deploying a new Deployment, you notice that the pods are stuck in ImagePullBackOff. What is the most common cause?

Accepted Answer

The container image name or tag is incorrect. The ImagePullBackOff status indicates that the kubelet is unable to pull the container image from the registry. The most common cause is an incorrect image name or tag, which results in a manifest not found error. This triggers an exponential backoff retry loop, leading to the ImagePullBackOff state.

Answer

The liveness probe is misconfigured

Answer

The node has insufficient resources

Answer

The container command fails on startup

Question 10

Which command shows all events in the cluster, sorted by timestamp?

Answer

kubectl logs --all-namespaces [wrong]

Answer

kubectl top events [wrong]

Answer

kubectl describe events [wrong]

Answer

kubectl get events -A --sort-by='.metadata.creationTimestamp'

Question 11

You run 'kubectl get events --sort-by=.lastTimestamp' and see the following events for a pod: 'Warning FailedScheduling 0/3 nodes are available: 3 Insufficient cpu'. What is the most likely solution?

Accepted Answer

Reduce the CPU request for the pod or remove other workloads to free CPU. The event '0/3 nodes are available: 3 Insufficient cpu' indicates that all three nodes in the cluster lack sufficient allocatable CPU to satisfy the pod's CPU request. The most direct solution is to either reduce the pod's CPU request (so it fits on an existing node) or remove other workloads to free up CPU capacity. This aligns with Kubernetes resource scheduling, where the scheduler only considers requests (not limits) when placing pods.

Answer

Change the scheduler to a different one

Answer

Increase the CPU limit for the pod

Answer

Add more nodes to the cluster

Question 12

Which access mode allows a PersistentVolume to be mounted as read-write by multiple pods across different nodes?

Accepted Answer

ReadWriteMany (RWX). ReadWriteMany (RWX) is the correct access mode because it allows a PersistentVolume to be mounted as read-write by multiple pods simultaneously, even when those pods are scheduled on different nodes. This is the only access mode that supports concurrent read-write access across nodes, which is essential for shared storage solutions like NFS, GlusterFS, or CephFS.

Answer

ReadWriteOnce (RWO)

Answer

ReadWriteOncePod (RWOP)

Answer

ReadOnlyMany (ROX)

Question 13

A Deployment's pod is stuck in Pending state. 'kubectl describe pod' shows Events: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient memory'. What is the likely fix?

Accepted Answer

Increase the memory limit of the pod or add more worker nodes. The error '3 Insufficient memory' indicates that three worker nodes lack the required memory to schedule the pod. Increasing the pod's memory limit (if it's set too high) or adding more worker nodes directly addresses the resource shortage. The control-plane node's taint is irrelevant because the pod is not trying to schedule there; the issue is insufficient memory on the available worker nodes.

Answer

Remove the taint from the control-plane node

Answer

Add a toleration for the control-plane taint to the pod spec

Answer

Set nodeSelector to schedule on control-plane nodes

Question 14

An Ingress resource is created with the following spec:

spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

The backend service 'api-service' is in the same namespace as the Ingress. What must be true for the Ingress to route traffic to the service?

Accepted Answer

The service 'api-service' must have a valid ClusterIP and at least one endpoint.. For an Ingress to route traffic to a backend service, the service must have a valid ClusterIP (so the Ingress controller can reach it via the cluster network) and at least one healthy endpoint (i.e., pods matching the service’s selector must be running and ready). The Ingress controller forwards traffic to the service’s ClusterIP on the specified port, not directly to pods, so a ClusterIP and endpoints are essential.

Answer

The Ingress controller must be configured to use the NodePort of the service.

Answer

The service 'api-service' must be of type NodePort.

Answer

The Ingress must have an IngressClass annotation.

Question 15

A pod is stuck in 'Pending' state. Which TWO of the following are common causes?

Accepted Answer

A taint on the node that the pod does not tolerate. A pod enters 'Pending' state when it cannot be scheduled onto a node. Taints on a node with `NoSchedule` or `NoExecute` effects prevent pods that do not have matching tolerations from being scheduled there. This is a common cause because the scheduler skips tainted nodes unless the pod explicitly tolerates the taint, leaving the pod unscheduled and stuck in Pending.

Answer

The service account does not exist

Answer

The pod's liveness probe is failing

Answer

The pod's container image does not exist

Question 16

You run 'kubectl get pods' and see a pod with status 'Init:CrashLoopBackOff'. What does this indicate?

Accepted Answer

An init container in the pod is failing and restarting. The status 'Init:CrashLoopBackOff' indicates that an init container within the pod is failing and being repeatedly restarted by Kubernetes. Init containers run sequentially before any main containers start, and if one exits with a non-zero exit code, Kubernetes retries it with an exponential backoff delay, leading to the CrashLoopBackOff state. This is distinct from a main container crash, which would show 'CrashLoopBackOff' without the 'Init:' prefix.

Answer

The pod's init container ran successfully but the main container has not started yet

Answer

The pod is still initializing but will eventually run

Answer

The main container is crashing and the pod is restarting

Question 17

A pod has been restarted multiple times. You want to see the logs from the previous (terminated) container instance. Which command should you use?

Accepted Answer

kubectl logs my-pod -p. The `kubectl logs` command retrieves logs for a container in a pod. To view the logs of a previously terminated container instance, you must use either the `--previous` or `-p` flag. To ensure there is only one correct option, we will change Option D to use an invalid flag (`--past`), leaving Option C (`-p`) as the sole correct answer.

Answer

kubectl logs my-pod -c --previous

Answer

kubectl logs my-pod --tail=100

Answer

kubectl logs my-pod --past

Question 18

You are applying the following RBAC manifest:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Which TWO statements are true about this Role? (Choose TWO.)

Accepted Answer

It allows reading pod details in the 'development' namespace. The Role explicitly defines rules for the 'pods' resource with verbs 'get', 'watch', and 'list' in the 'development' namespace. These verbs allow reading pod details such as their specifications, status, and metadata. The Role is scoped to the 'development' namespace, so it only grants these read permissions within that namespace.

Answer

It also grants access to secrets in the 'development' namespace

Answer

It grants permissions across all namespaces

Answer

It allows creating pods in the 'development' namespace

Question 19

Which THREE of the following are valid methods to authenticate to the Kubernetes API server? (Select 3)

Accepted Answer

Service account bearer tokens. Service account bearer tokens are a valid authentication method to the Kubernetes API server. When a pod is associated with a service account, Kubernetes automatically mounts a token into the pod at /var/run/secrets/kubernetes.io/serviceaccount/token. This token is a signed JWT that the API server validates against the TokenReview API, allowing the pod to authenticate as that service account.

Answer

Anonymous requests

Answer

Password file with usernames and passwords

Question 20

A DaemonSet named 'fluentd' is configured to run on all nodes. After adding a new node to the cluster, you notice that the DaemonSet pod is not running on the new node. What could be the cause?

Accepted Answer

The new node has a taint that the DaemonSet pod does not tolerate. A DaemonSet ensures that a copy of a pod runs on all (or a subset of) nodes. When a new node is added, the DaemonSet controller automatically schedules a pod on it unless the node has a taint that the pod does not tolerate. By default, the new node may have a taint (e.g., `node.kubernetes.io/unschedulable` or a custom taint) that prevents the DaemonSet pod from being scheduled unless the pod's spec includes a matching toleration.

Answer

The new node does not have enough resources to run the DaemonSet pod

Answer

The DaemonSet has a nodeSelector that does not match the new node's labels

Answer

The DaemonSet's update strategy is set to OnDelete