CKA Practice Test 19 — 15 Questions

Question 1

A NetworkPolicy named 'default-deny-ingress' is applied to all pods in a namespace. The policy has no rules. An administrator then creates a new NetworkPolicy that allows ingress traffic to pods with label 'app: web' from any source using a podSelector with '{}'. Will traffic be allowed to pods labeled 'app: web'?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Yes, because the new policy allows traffic to pods with label 'app: web'. A NetworkPolicy with a podSelector of '{}' selects all pods in the namespace, and the 'from' section with an empty podSelector (or no 'from' selector at all) allows traffic from any source. When multiple NetworkPolicies are applied, they are additive: if any policy allows the traffic, it is allowed, overriding a default-deny policy that has no rules. Thus, the new policy explicitly permits ingress to pods with label 'app: web', so traffic to those pods is allowed.

Answer

No, because the new policy's empty podSelector selects all pods but does not specify a source

Answer

Yes, because the default-deny policy is ignored when a new policy exists

Answer

No, because the default-deny policy takes precedence

Question 2

A Kubernetes cluster is running with a single control plane node. The administrator wants to add a second control plane node for high availability. What is the first step after the new node has been provisioned with the required software?

Accepted Answer

Run kubeadm join with the --control-plane flag on the new node.. The first step to add a second control plane node to an existing cluster is to run `kubeadm join` with the `--control-plane` flag on the new node. This command uses the existing control plane's API server to join the new node as a control plane member, automatically distributing certificates and configuring the etcd cluster. The `--control-plane` flag signals kubeadm to set up the additional control plane components (e.g., kube-apiserver, kube-controller-manager, kube-scheduler) and join the etcd cluster as a learner or voting member, depending on the etcd configuration.

Answer

Create a bootstrap token on the existing control plane node.

Answer

Run kubeadm init on the new node.

Answer

Take a snapshot of etcd using etcdctl.

Question 3

You have a Pod that is stuck in Pending state. Running 'kubectl describe pod' shows events: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, 3 node(s) had taint {key: value}, that the pod didn't tolerate.' How can you resolve this issue?

Accepted Answer

Add appropriate tolerations to the Pod's spec. The Pod is stuck in Pending because none of the nodes can schedule it due to taints that the Pod does not tolerate. Option D is correct because adding the appropriate tolerations to the Pod's spec tells the scheduler that the Pod can tolerate those taints, allowing it to be scheduled on the tainted nodes. This directly addresses the mismatch between node taints and Pod tolerations. A common misconception in the CKA exam is that removing taints from nodes is the only fix, but the correct Kubernetes approach is to add tolerations to the Pod spec, preserving node isolation for other workloads.

Answer

Increase the Pod's resource requests

Answer

Remove the taints from all nodes using 'kubectl taint nodes --all key:value-'

Answer

Delete the Pod and recreate it with a different name

Question 4

A Kubernetes cluster has a node pool with GPU nodes labeled 'accelerator=nvidia-tesla'. A Pod requires a GPU. Which configuration is necessary?

Accepted Answer

Set nodeSelector to 'accelerator=nvidia-tesla' and request 'nvidia.com/gpu' in resources.. A Pod that requires a GPU must both be scheduled onto a node with the appropriate GPU label and explicitly request the GPU resource. The `nodeSelector` ensures the Pod lands on a node labeled `accelerator=nvidia-tesla`, and requesting `nvidia.com/gpu` in `resources.requests` or `resources.limits` (typically limits) tells the kubelet to allocate a GPU device to the container. Without the resource request, the scheduler has no way to account for GPU capacity, and without the nodeSelector, the Pod might be scheduled on a non-GPU node.

Answer

Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution for the GPU label.

Answer

Set resources.limits for 'nvidia.com/gpu' only.

Answer

Add a toleration for GPU node taints.

Question 5

A ServiceAccount 'monitor-sa' needs to be able to list Pods in namespace 'monitoring'. Which RBAC configuration is appropriate?

Accepted Answer

Create a Role in namespace 'monitoring' with 'get' and 'list' verbs on pods, then a RoleBinding in 'monitoring' to monitor-sa. A Role in the 'monitoring' namespace with 'get' and 'list' verbs on pods, combined with a RoleBinding in the same namespace to the 'monitor-sa' ServiceAccount, grants the exact permissions required within the scope of that namespace. This follows the principle of least privilege by scoping permissions to the specific namespace where the pods reside.

Answer

Create a ClusterRole with 'get' and 'list' verbs on pods, then a ClusterRoleBinding to monitor-sa

Answer

Add the ServiceAccount to the cluster-admin group

Answer

Create a Role in default namespace with 'get' and 'list' verbs on pods, then a RoleBinding in 'monitoring' to monitor-sa

Question 6

Which component runs on every node in a Kubernetes cluster and ensures containers are running in a pod?

Accepted Answer

kubelet. The kubelet is the primary node agent that runs on every node in a Kubernetes cluster. It is responsible for ensuring that containers described in PodSpecs are running and healthy by communicating with the container runtime via the CRI (Container Runtime Interface). Without the kubelet, no pod or container lifecycle management can occur on that node.

Answer

kube-scheduler

Answer

container runtime

Answer

kube-proxy

Question 7

Which THREE of the following are true about HorizontalPodAutoscaler (HPA)?

Accepted Answer

HPA can use custom metrics from the Kubernetes Metrics Server.. The HorizontalPodAutoscaler (HPA) can use custom metrics provided by the Kubernetes Metrics Server, such as requests per second or queue length, in addition to standard CPU and memory metrics. The HPA retrieves these metrics via the `metrics.k8s.io` API (for resource metrics) or custom metrics APIs, enabling scaling based on application-specific behavior.

Answer

HPA supports in-place pod resizing.

Answer

HPA cannot scale based on memory utilization.

Question 8

Which component is responsible for implementing the NetworkPolicy rules?

Accepted Answer

CNI plugin. NetworkPolicy rules are enforced by the Container Network Interface (CNI) plugin, not by kube-proxy or any other Kubernetes control plane component. The CNI plugin (e.g., Calico, Cilium, Weave Net) implements the actual network policy by programming iptables, eBPF, or other data-plane mechanisms to allow or deny traffic between pods based on the policy selectors and rules defined in the NetworkPolicy resource.

Answer

CoreDNS

Answer

kube-controller-manager

Answer

kube-proxy

Question 9

A Deployment named 'app' has 3 replicas. The rolling update strategy is set with maxSurge=1 and maxUnavailable=1. During an update, a new ReplicaSet is created. How many pods will be in terminating state at the moment when the new ReplicaSet has 2 pods ready?

Accepted Answer

1. With maxSurge=1 and maxUnavailable=1, the Deployment controller ensures that during a rolling update, the total number of pods across old and new ReplicaSets does not exceed desiredReplicas + maxSurge (3+1=4). When the new ReplicaSet has 2 pods ready, the controller will begin terminating old pods to bring the total down. At that exact moment, exactly 1 old pod will be in Terminating state, as the controller scales down the old ReplicaSet by 1 to maintain the surge limit.

Answer

3

Answer

0

Answer

2

Question 10

You need to create a Service that exposes port 80 on each node's IP at a static port (30080). Which Service type should you use?

Accepted Answer

NodePort. A NodePort Service exposes the application on a static port (30080) across every node's IP address in the cluster. This is the only Service type that allows you to specify a fixed port on the node's IP, making it the correct choice for this requirement.

Answer

LoadBalancer

Answer

ClusterIP

Answer

ExternalName

Question 11

A CronJob is configured to run every hour. You notice that the job did not run at the scheduled time. What is the most likely reason?

Accepted Answer

The concurrency policy is set to 'Forbid' and a previous job was still running. When a CronJob's concurrency policy is set to 'Forbid', it prevents a new job from starting if the previous job is still running. If the previous job took longer than the scheduled interval (e.g., more than one hour), the next scheduled run will be skipped, causing the job not to run at the expected time. This is a common scenario where a long-running job overlaps with the next scheduled time, and the 'Forbid' policy enforces that only one job instance runs at a time.

Answer

The concurrency policy is set to 'Allow'

Answer

The previous job run succeeded and the CronJob is configured to not rerun after success

Answer

The concurrency policy is set to 'Replace'

Question 12

Which of the following YAML snippets correctly defines a Kubernetes Deployment with 3 replicas and a rolling update strategy?

Accepted Answer

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1. It uses the stable `apps/v1` API version, specifies 3 replicas, and defines a `RollingUpdate` strategy with both `maxUnavailable` and `maxSurge` set to 1. This ensures that during an update, at most one Pod is unavailable and at most one extra Pod is created, maintaining application availability.

Answer

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-deploy
spec:
  replicas: 3
  strategy:
    type: RollingUpdate

Answer

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
  maxUnavailable: 1
  maxSurge: 1

Answer

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  replicas: 3
  strategy:
    type: OnDelete

Question 13

A cluster administrator wants to expand an existing PersistentVolumeClaim (PVC) that is bound to a PersistentVolume (PV) with reclaim policy Delete and storage class 'fast'. The PV was dynamically provisioned. Which condition is required for the PVC expansion to succeed?

Accepted Answer

The StorageClass 'fast' must have allowVolumeExpansion: true.. For PVC expansion to succeed with a dynamically provisioned PV, the StorageClass must have the `allowVolumeExpansion: true` field set. This field explicitly enables volume expansion for all PVCs using that StorageClass. Without it, the PVC expansion request will be rejected even if other conditions are met.

Answer

The PV must be in Released state.

Answer

The reclaim policy must be changed to Retain before expansion.

Answer

The PVC must be using access mode ReadWriteOnce.

Question 14

Which TWO components are part of the Kubernetes control plane? (Select two.)

Accepted Answer

etcd. etcd is a distributed key-value store that serves as the primary datastore for the Kubernetes cluster, storing all cluster state and configuration data. The kube-controller-manager runs controller processes that regulate the state of the cluster, such as the node controller, replication controller, and endpoints controller. Both are core control plane components that run on the master node(s).

Answer

kubelet

Answer

kube-proxy

Answer

container runtime

Question 15

A cluster administrator is configuring a Pod to use a PersistentVolumeClaim (PVC) that is dynamically provisioned using a StorageClass with volumeBindingMode: WaitForFirstConsumer. The PVC is created before the Pod. When the Pod is created, which node will the PV be provisioned on?

Accepted Answer

The node where the Pod is scheduled.. When a StorageClass uses volumeBindingMode: WaitForFirstConsumer, the PersistentVolume (PV) is not provisioned until a Pod that uses the PersistentVolumeClaim (PVC) is scheduled. The PV is then provisioned on the exact node where the Pod is scheduled, ensuring that the volume is created in the same zone or topology as the Pod. This avoids unnecessary cross-zone data transfer and ensures the PV is available locally to the Pod's node.

Answer

The PV is provisioned immediately on the node specified in the StorageClass's allowedTopologies.

Answer

Any node in the cluster that has sufficient resources for the PV.

Answer

The control plane node.