CKA Practice Test 3 — 10 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'