CKA Practice Test 2 — 25 Questions

Question 1

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 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

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 15

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

Question 16

Which TWO of the following are valid methods to diagnose why a node is in 'NotReady' state?

Accepted Answer

Check the kubelet service logs using 'journalctl -u kubelet'. Checking kubelet logs (journalctl) and verifying the network plugin are both standard troubleshooting steps. Option C (checking API server) is not node-level. Option D (checking kube-proxy) is for service connectivity, not node readiness. Option A (restarting all containers) is not relevant.

Answer

Restart all containers on the node

Answer

Check the kube-apiserver logs on the control plane

Answer

Check kube-proxy configuration

Question 17

A pod with a resource request of 500m CPU and a limit of 1 CPU is scheduled. The node has a CPU capacity of 2 cores. What does the '500m' represent?

Accepted Answer

500 millicores (0.5 CPU core). In Kubernetes, CPU resources are measured in millicores, where 1000m equals 1 full CPU core (vCPU or hyperthread). The '500m' in a resource request means the pod is guaranteed at least 500 millicores, or 0.5 CPU core, from the node's 2-core capacity. This is a standard unit used by the kubelet for CPU scheduling and the Completely Fair Scheduler (CFS) quota enforcement.

Answer

500 megabytes of memory

Answer

50% of the node's CPU capacity

Answer

A limit of 500,000 CPU seconds per day

Question 18

A cluster has a PersistentVolumeClaim (PVC) named 'data-claim' bound to a PersistentVolume (PV) with reclaim policy 'Retain'. The PVC is deleted. The PV now shows status 'Released'. What must be done so that the PV can be reused by a new PVC?

Accepted Answer

Delete and recreate the PersistentVolume.. When a PVC is deleted and the PV has a reclaim policy of 'Retain', the PV enters a 'Released' state, meaning it still contains the data but is no longer bound to the original PVC. The PV cannot be directly reused by a new PVC because its claim reference is still set to the deleted PVC's UID. To make the PV available again, you must manually delete and recreate the PV (or at least delete it and re-create it with a clean claimRef), which resets its status to 'Available'.

Answer

Nothing; the PV will automatically become Available after some time.

Answer

Create a new PVC with the same name.

Answer

Change the reclaim policy to Delete.

Question 19

You are troubleshooting a node that is 'NotReady'. Which THREE of the following are possible causes? (Choose three.)

Accepted Answer

The kubelet cannot contact the API server. The kubelet is the primary node agent that communicates with the API server to report node status, heartbeats, and pod lifecycle events. If the kubelet cannot reach the API server (e.g., due to network partition, TLS certificate issues, or API server downtime), it cannot send the periodic NodeStatus updates, and the control plane marks the node as 'NotReady' after the `node-monitor-grace-period` (default 40 seconds) expires.

Answer

The node has disk pressure

Answer

A pod on the node is consuming excessive memory

Question 20

A NetworkPolicy with podSelector: {} and policyTypes: [Ingress] is applied to a namespace. What is the effect on pods in that namespace?

Accepted Answer

All ingress traffic is denied unless explicitly allowed by another policy.. A NetworkPolicy with `podSelector: {}` selects all pods in the namespace. When `policyTypes: [Ingress]` is set without any ingress rules, it defaults to denying all ingress traffic that is not explicitly allowed by another policy. This is because Kubernetes NetworkPolicy implements an implicit deny for the specified traffic direction when no rules are provided, effectively isolating the pods from inbound connections.

Answer

The policy has no effect because no rules are defined.

Answer

All ingress traffic is allowed.

Answer

All egress traffic is denied.