How to Ace the CKA: Certified Kubernetes Administrator

Question 1 · Cluster Architecture, Installation & Configuration

You need to verify that an RBAC ClusterRole has the correct permissions without applying it to the cluster. Which command allows dry-run inspection?

• kubectl apply -f clusterrole.yaml --dry-run=client to validate syntax
• kubectl auth can-i create deployments as user to test permissions
• kubectl describe clusterrole rolename to see permissions
• RBAC roles must be applied to test them; dry-run is not available

Correct answer: kubectl apply -f clusterrole.yaml --dry-run=client to validate syntax

The --dry-run=client flag validates the manifest without applying it. kubectl auth can-i tests actual permissions but requires the role to exist. kubectl describe shows existing roles. Dry-run is available for validation.

Question 2 · Workloads & Scheduling

You need to deploy a web application with 3 replicas that automatically scales when CPU usage exceeds 80%. Which Kubernetes resources are required?

• A Deployment with 3 replicas and a manual scale procedure
• A Deployment with 3 initial replicas and a HorizontalPodAutoscaler targeting 80% CPU threshold
• A StatefulSet with 3 replicas and built-in auto-scaling via replicas field
• A Service with 3 endpoints and Ingress controller for scaling

Correct answer: A Deployment with 3 initial replicas and a HorizontalPodAutoscaler targeting 80% CPU threshold

HPA (HorizontalPodAutoscaler) automatically adjusts Deployment replicas based on metrics like CPU. The Deployment provides the base template. StatefulSets are for stateful workloads. Services and Ingress manage traffic, not scaling.

Question 3 · Services & Networking

You need to route traffic to a Service based on the hostname in the HTTP request. Which Kubernetes resource should you use?

• A Service with multiple ports
• An Ingress resource with host-based routing rules
• A NetworkPolicy to filter traffic by hostname
• A LoadBalancer service with hostname configuration

Correct answer: An Ingress resource with host-based routing rules

Ingress provides Layer 7 (HTTP) routing based on hostnames, paths, and other HTTP attributes. Services operate at Layer 4 and don't understand HTTP. NetworkPolicy filters network traffic but doesn't understand hostnames. LoadBalancer is Layer 4.

Question 4 · Storage

A StorageClass is created with provisioner: kubernetes.io/aws-ebs and reclaimPolicy: Delete. What happens to the EBS volume when a PVC using this StorageClass is deleted?

• The volume is retained and can be reused by manually creating a new PV
• The volume is automatically deleted from AWS
• The volume is moved to a read-only state but retained
• The volume creation request is denied until manual cleanup occurs

Correct answer: The volume is automatically deleted from AWS

reclaimPolicy: Delete instructs the storage provisioner to automatically delete the underlying storage resource when the PVC is deleted. This is the default behavior for dynamically provisioned volumes. Retain would keep the volume, read-only state isn't a valid reclaim policy, and denial of PVC deletion isn't how reclaimPolicy works.

Question 5 · Troubleshooting

A Node reports a status of NotReady. You need to investigate the cause. Which command should you run first?

• kubectl get nodes to see the node's age
• kubectl describe node <node-name> to check conditions and events
• kubectl logs kubelet to view kubelet logs directly
• kubectl top node <node-name> to check resource usage

Correct answer: kubectl describe node <node-name> to check conditions and events

kubectl describe node provides the Status, Conditions (Ready, MemoryPressure, DiskPressure, PIDPressure), and recent Events that explain why the node is NotReady. kubectl get nodes only shows the status without details, kubectl logs requires node access, and kubectl top only shows resource usage, not status conditions.

Question 6 · Cluster Architecture, Installation & Configuration

A kubeadm node is in NotReady state. What is the first diagnostic step?

• Run 'kubectl drain node' to force it to Ready state
• Check 'kubectl describe node nodename' for conditions and their reasons
• Immediately delete and re-join the node
• Restart the entire cluster

Correct answer: Check 'kubectl describe node nodename' for conditions and their reasons

kubectl describe shows node conditions (MemoryPressure, DiskPressure, NotReady reason). This diagnostic reveals the root cause. Draining is for graceful shutdown, not fixing NotReady. Deletion/cluster restart are extreme actions.

Question 7 · Cluster Architecture, Installation & Configuration

When using kubeadm to configure an external etcd cluster, which flag specifies the etcd endpoints?

• --etcd-servers=https://etcd1:2379,https://etcd2:2379,https://etcd3:2379 in kubeadm init config
• --etcd-cluster-endpoints in kubeadm join
• The etcd endpoints are auto-discovered from DNS
• External etcd is not supported with kubeadm

Correct answer: --etcd-servers=https://etcd1:2379,https://etcd2:2379,https://etcd3:2379 in kubeadm init config

External etcd requires specifying endpoints via kubeadm config (ClusterConfiguration.etcd.external.endpoints). kubeadm doesn't auto-discover etcd. External etcd is fully supported for HA.

Question 8 · Cluster Architecture, Installation & Configuration

An RBAC audit reveals a user has excessive permissions. What is the safest approach to remediate?

• Immediately revoke all permissions and re-grant only necessary ones
• Delete the user's account and recreate it with correct permissions
• Create a more restrictive Role/ClusterRole and gradually migrate bindings to it
• Change the user's password to prevent access while investigating

Correct answer: Create a more restrictive Role/ClusterRole and gradually migrate bindings to it

Gradual migration prevents service disruption. Immediate revocation risks breaking applications. Deleting/recreating accounts is destructive. Password changes don't address RBAC. A staged approach allows testing.

Question 9 · Cluster Architecture, Installation & Configuration

You need to allow a Pod to read events cluster-wide for monitoring purposes. Which RBAC resource is needed?

• A Role with 'events' resource in kube-system namespace
• A ClusterRole with apiGroups: [''], resources: ['events'], verbs: ['get', 'list', 'watch']
• A ServiceAccount with 'monitoring' label
• A NetworkPolicy allowing Pod-to-APIserver traffic

Correct answer: A ClusterRole with apiGroups: [''], resources: ['events'], verbs: ['get', 'list', 'watch']

Cluster-wide access to events requires ClusterRole (not namespace-scoped Role). Events are in the core API group (''). The verbs allow reading and watching events. ServiceAccounts and NetworkPolicy don't grant API access.

Question 10 · Cluster Architecture, Installation & Configuration

A Helm release fails to upgrade because the ConfigMap already exists but wasn't created by Helm. What should you do?

• Delete the existing ConfigMap manually, then retry the Helm upgrade
• Use 'helm upgrade --install' flag to skip validation
• Modify the Helm chart to reference an existing ConfigMap
• Add --force flag to Helm upgrade to overwrite the ConfigMap

Correct answer: Delete the existing ConfigMap manually, then retry the Helm upgrade

Helm tracks resources it creates. An existing resource it didn't create conflicts. Deleting it resolves the conflict. --install and --force don't address the core issue (resource ownership conflict). Modifying the chart is a workaround.