Back to Blog

KCNA Practice Questions: Free Sample Test for 2026

25 realistic KCNA sample questions covering all domains with detailed answers and explanations to test your Kubernetes knowledge.

By Sailor Team , March 15, 2026

Ready to test your KCNA knowledge? These 25 realistic practice questions cover all five KCNA domains with the exact format and difficulty you’ll encounter on exam day. Work through them as if taking the real exam: 90 minutes, no external resources, honest scoring.

Each question includes a detailed explanation so you understand not just the answer, but the concepts behind it.

How to Use These Practice Questions

  1. Take the questions timed (roughly 3.5 minutes per question = 90 minutes total, or adjust pace)
  2. Don’t look at answers initially—force yourself to think
  3. Mark questions you’re unsure about
  4. Review ALL explanations—even for questions you got right
  5. Identify weak domains for focused study

Scoring Guide:

  • 19-25 correct: EXCELLENT (95-100%) — Ready to test
  • 16-18 correct: GOOD (85-94%) — One more week of prep
  • 13-15 correct: ADEQUATE (80-84%) — Two weeks more review needed
  • 10-12 correct: NEEDS WORK (70-79%) — Study weak domains thoroughly
  • Below 10: MORE PREP (Below 70%) — Return to fundamentals

Practice Questions with Answers

Domain 1: Kubernetes Fundamentals (Questions 1-14)

Question 1: Pod Basics (Single-Select)

Which of the following is the smallest deployable unit in Kubernetes?

A) Container B) Pod C) Deployment D) Node

Your Answer: ___

Click to reveal answer

Correct Answer: B) Pod

Explanation: A Pod is the smallest deployable unit in Kubernetes. It can contain one or more containers, but containers cannot be deployed directly to Kubernetes—they must be wrapped in a Pod. A Deployment is a higher-level abstraction that manages Pods. A Container is the Docker/container technology used inside Pods. A Node is the machine running Pods.

Key Concept: Understand the Kubernetes hierarchy: Pod (contains Containers) → Deployment (manages Pods) → Node (runs Pods)


Question 2: Service Types (Multiple-Select)

Which of the following are valid Kubernetes Service types? (Select ALL that apply)

A) ClusterIP B) NodePort C) LoadBalancer D) PortForward E) ExternalName

Your Answers: ___

Click to reveal answer

Correct Answer: A, B, C, E

Explanation:

  • A) ClusterIP ✓ Default service type, exposes service on cluster-internal IP only
  • B) NodePort ✓ Exposes service on each node’s IP at a static port
  • C) LoadBalancer ✓ Exposes service externally using cloud provider’s load balancer
  • D) PortForward ✗ This is NOT a service type; kubectl port-forward is a CLI command for temporary port forwarding
  • E) ExternalName ✓ Maps service to a DNS name

Key Concept: Know all four service types. PortForward is a debugging tool, not a service type.


Question 3: ConfigMaps and Secrets (Single-Select)

You have sensitive database passwords that need to be passed to your Pod. Which object should you use?

A) ConfigMap B) Secret C) Namespace D) ServiceAccount

Your Answer: ___

Click to reveal answer

Correct Answer: B) Secret

Explanation: Secrets are designed specifically for storing sensitive data like passwords, API keys, and tokens. ConfigMaps are for non-sensitive configuration. While both can be mounted as volumes, Secrets are base64-encoded and designed for sensitive information. Namespaces are for cluster organization. ServiceAccounts are for Pod authentication.

Key Concept: ConfigMap = non-sensitive configuration. Secret = sensitive data. Never store secrets in ConfigMaps.


Question 4: Kubernetes Manifests (Scenario-Based)

You’re examining a Kubernetes manifest and see this structure:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: web-container
    image: nginx:latest

What does apiVersion: v1 indicate?

A) The version of Kubernetes running on your cluster B) The version of the API resource definition being used C) The version of the container image D) The version of your application

Your Answer: ___

Click to reveal answer

Correct Answer: B) The version of the API resource definition being used

Explanation: apiVersion specifies which Kubernetes API version is being used to define this resource. Different resource types use different API versions (v1, apps/v1, batch/v1, etc.). It’s NOT about your cluster version or your application version.

Key Concept: apiVersion defines the Kubernetes API schema, kind defines the object type, and metadata contains object identification.


Question 5: Deployment and ReplicaSets (Single-Select)

What is the relationship between a Deployment and a ReplicaSet?

A) Deployment and ReplicaSet are the same thing B) Deployment is a higher-level abstraction that manages ReplicaSets C) ReplicaSet is a higher-level abstraction that manages Deployments D) They serve completely different purposes and don’t interact

Your Answer: ___

Click to reveal answer

Correct Answer: B) Deployment is a higher-level abstraction that manages ReplicaSets

Explanation: When you create a Deployment, Kubernetes automatically creates and manages ReplicaSets for you. The Deployment handles rolling updates, versioning, and rollbacks. ReplicaSets ensure the desired number of Pod replicas are running. You typically interact with Deployments, not ReplicaSets directly.

Key Concept: Deployment → ReplicaSet → Pods (hierarchy of control)


Question 6: Namespace Isolation (Single-Select)

What is the primary purpose of Kubernetes Namespaces?

A) To isolate network traffic between Pods B) To provide logical cluster partitioning and resource quotas C) To encrypt data in transit D) To manage container images

Your Answer: ___

Click to reveal answer

Correct Answer: B) To provide logical cluster partitioning and resource quotas

Explanation: Namespaces organize cluster resources logically, allow multiple teams to share a cluster, and can enforce resource quotas. They don’t automatically isolate network traffic (that’s done with Network Policies). They don’t encrypt data or manage images.

Key Concept: Namespaces = logical organization. Network Policies = network isolation.


Question 7: Pod Lifecycle (Scenario-Based)

A Pod’s main container crashes and exits. You’ve configured a liveness probe that checks every 10 seconds. What happens?

A) The Pod remains in a Running state indefinitely B) The Pod terminates and Kubernetes considers it failed C) Kubernetes restarts the container automatically D) The Pod is marked as Completed

Your Answer: ___

Click to reveal answer

Correct Answer: C) Kubernetes restarts the container automatically

Explanation: The liveness probe detects that the container is unhealthy, and Kubernetes restarts it according to the Pod’s restart policy (default: restart always). The Pod remains Running as long as the restart policy allows. It doesn’t terminate unless the restart policy is set to Never.

Key Concept: Liveness Probe = “Is the app alive?” → Failed check → Restart container. Readiness Probe = “Is app ready for traffic?” → Failed check → Remove from service.


Question 8: RBAC Concepts (Single-Select)

Which Kubernetes object defines a set of permissions that can be assigned to users?

A) RoleBinding B) ServiceAccount C) Role D) ClusterRole

Your Answer: ___

Click to reveal answer

Correct Answer: C) Role (or D) ClusterRole—both are acceptable)

Explanation: A Role defines permissions (what actions can be performed on what resources). A RoleBinding connects a Role to a user/service account. ServiceAccount is an identity for Pods. ClusterRole is like Role but cluster-scoped instead of namespace-scoped.

Key Concept: Role = permissions. RoleBinding = assigns Role to user/service account.


Question 9: Storage Basics (Single-Select)

Which of these is NOT a valid reason to use PersistentVolumes in Kubernetes?

A) To provide storage that survives Pod restarts B) To share data between multiple Pods C) To replace Docker volumes entirely D) To abstract underlying storage implementation

Your Answer: ___

Click to reveal answer

Correct Answer: C) To replace Docker volumes entirely

Explanation: PersistentVolumes are for Kubernetes-managed storage with lifecycle independent of Pods. They’re not meant to replace Docker volumes—they’re a layer above. Docker volumes can still exist; PVs provide Kubernetes-level storage management.

Key Concept: PersistentVolume = Kubernetes storage abstraction. PersistentVolumeClaim = request for storage. StatefulSets commonly use PVs for data persistence.


Question 10: Labels and Selectors (Single-Select)

You have 10 Pods with the label env: production. A Service has a selector env: production. How many Pods does this Service route traffic to?

A) 0 B) 10 C) It depends on the Service type D) 5

Your Answer: ___

Click to reveal answer

Correct Answer: B) 10

Explanation: Labels and selectors allow Services to dynamically discover and route to matching Pods. The selector env: production matches all Pods with that label. The Service routes traffic to all matching Pods regardless of Service type.

Key Concept: Selectors = dynamic Pod discovery. Labels = key-value metadata for selection.


Question 11: Service Discovery (Single-Select)

How can a Pod discover another service within the same namespace?

A) Via IP address lookup on a DNS server B) Via DNS name: service-name C) Via DNS name: service-name.namespace.svc.cluster.local D) Both B and C are correct

Your Answer: ___

Click to reveal answer

Correct Answer: D) Both B and C are correct

Explanation: Within the same namespace, you can use the short form service-name. Kubernetes DNS automatically expands this to the full form service-name.namespace.svc.cluster.local. Both work; short form is just a shortcut.

Key Concept: Kubernetes automatically provides DNS for service discovery. Format: service-name.namespace.svc.cluster.local.


Question 12: Init Containers (Multiple-Select)

What are true statements about Init Containers? (Select ALL that apply)

A) Init containers run in parallel with the application container B) All init containers must complete successfully before the main container starts C) Init containers are useful for setup tasks before the app starts D) Init containers share the same network namespace as the main container E) Init containers cannot access volume mounts

Your Answers: ___

Click to reveal answer

Correct Answer: B, C, D

Explanation:

  • A) ✗ Init containers run sequentially (one at a time), not in parallel
  • B) ✓ All init containers must complete successfully before proceeding
  • C) ✓ Common use: downloading config files, setting permissions, database migrations
  • D) ✓ Init containers share network namespace and volumes with the main container
  • E) ✗ Init containers can access volume mounts

Key Concept: Init Containers = setup phase before main container. Sequential execution. Ideal for initialization logic.


Question 13: Ingress Resource (Single-Select)

What does an Ingress resource provide in Kubernetes?

A) A load balancer for distributing traffic across Pods B) HTTP and HTTPS routing rules for external access C) A way to manage internal DNS D) Security policies for all incoming traffic

Your Answer: ___

Click to reveal answer

Correct Answer: B) HTTP and HTTPS routing rules for external access

Explanation: Ingress provides Layer 7 (application layer) routing based on hostnames and paths. You define rules like “route traffic to api.example.com to the API service” and “route www.example.com to the web service.” Ingress is NOT itself a load balancer; it defines rules for an ingress controller to implement.

Key Concept: Service (Layer 4) for internal/external IP exposure. Ingress (Layer 7) for HTTP/HTTPS domain and path-based routing.


Question 14: Resource Requests vs Limits (Scenario-Based)

You set a Pod with request: cpu: 500m and limits: cpu: 1000m. What does this mean?

A) The Pod always gets 500m CPU B) The Pod is guaranteed 500m, but can burst up to 1000m if available C) The Pod never gets more than 500m CPU D) The limits setting is ignored if requests are set

Your Answer: ___

Click to reveal answer

Correct Answer: B) The Pod is guaranteed 500m, but can burst up to 1000m if available

Explanation:

  • Request (500m): Kubernetes reserves this amount; used for scheduling decisions
  • Limit (1000m): Maximum CPU the Pod can consume; Kubernetes throttles if exceeded
  • The Pod gets 500m guaranteed for scheduling, but can use up to 1000m if the node has spare capacity

Key Concept: Request = reservation for scheduling. Limit = cap on usage.


Domain 2: Container Orchestration (Questions 15-18)

Question 15: Horizontal Pod Autoscaler (Single-Select)

An HPA is configured to scale a Deployment between 2 and 10 replicas based on CPU utilization. Currently, the Deployment has 5 replicas and CPU usage is 30%. If the target CPU is 50%, what happens?

A) HPA immediately scales down to 2 replicas B) HPA keeps the Deployment at 5 replicas C) HPA immediately scales up to 10 replicas D) HPA scales down to 3 replicas

Your Answer: ___

Click to reveal answer

Correct Answer: B) HPA keeps the Deployment at 5 replicas

Explanation: Current CPU usage (30%) is below target (50%), so no scaling is needed. HPA only scales when usage exceeds the target. Even though there’s capacity to scale down, HPA doesn’t scale down at 30%; it would only scale down if usage continued to drop below 50% for some time.

Key Concept: HPA compares actual metrics to target. Scale up if actual > target. Scale down if actual < target for sustained period.


Question 16: Rolling Updates (Single-Select)

During a rolling update of a Deployment, what happens to existing Pods?

A) All old Pods are terminated immediately, new Pods created B) New Pods are gradually created while old Pods are gradually terminated C) Old Pods and new Pods run simultaneously until a cutover D) The Deployment pauses; manual approval is required for each Pod update

Your Answer: ___

Click to reveal answer

Correct Answer: B) New Pods are gradually created while old Pods are gradually terminated

Explanation: Rolling updates ensure zero (or minimal) downtime. New Pods start first, readiness probes verify they’re healthy, then old Pods are terminated. This is controlled by maxSurge and maxUnavailable settings.

Key Concept: Rolling Update = gradual Pod replacement. Zero downtime (ideally). Controlled by strategy settings.


Question 17: DaemonSet vs Deployment (Multiple-Select)

Which statements are TRUE about DaemonSets? (Select ALL that apply)

A) DaemonSets run one Pod on every node in the cluster B) DaemonSets are ideal for agent/monitoring workloads C) DaemonSet replicas can be manually scaled like Deployments D) DaemonSets automatically handle node additions/removals E) DaemonSets ignore taints and tolerations

Your Answers: ___

Click to reveal answer

Correct Answer: A, B, D

Explanation:

  • A) ✓ One Pod per node (that matches any selectors/tolerations)
  • B) ✓ Perfect for logging agents, monitoring daemons, network plugins
  • C) ✗ DaemonSets don’t have a replicas field; they automatically adjust to node count
  • D) ✓ Automatically place Pods on new nodes; remove from deleted nodes
  • E) ✗ DaemonSets respect taints and tolerations

Key Concept: DaemonSet = one Pod per matching node. Self-managing per node count.


Question 18: Job Completion (Single-Select)

A Kubernetes Job completes with 3 successful Pods. What is the expected state?

A) The Job remains in Running state B) The Job transitions to Completed; Pods are not automatically deleted C) The Job transitions to Completed; Pods are automatically deleted D) The Job transitions to Failed state

Your Answer: ___

Click to reveal answer

Correct Answer: B) The Job transitions to Completed; Pods are not automatically deleted

Explanation: When a Job completes, it transitions to Succeeded status. The Pods remain (so you can inspect logs), but they’re not running. You can manually delete them, or use ttlSecondsAfterFinished to auto-delete after a delay.

Key Concept: Job = run to completion. Pods available for log inspection after completion.


Domain 3: Cloud Native Architecture (Questions 19-22)

Question 19: Microservices Architecture (Single-Select)

Which characteristic is essential for microservices architecture?

A) All services use the same programming language B) Services are loosely coupled and independently deployable C) Services share a single database D) Services communicate synchronously via direct function calls

Your Answer: ___

Click to reveal answer

Correct Answer: B) Services are loosely coupled and independently deployable

Explanation: Microservices thrive on independence. Each service has its own database, can use different languages, and deploys independently. Loose coupling minimizes impact of changes to one service on others.

Key Concept: Microservices = independent, loosely coupled, own data, own deployment.


Question 20: Container Image Best Practices (Multiple-Select)

Which practices improve container image security and efficiency? (Select ALL that apply)

A) Use specific image tags instead of :latest B) Always use latest tag for automatic updates C) Use distroless base images when possible D) Scan images for vulnerabilities E) Include application source code in images

Your Answers: ___

Click to reveal answer

Correct Answer: A, C, D

Explanation:

  • A) ✓ Specific tags (e.g., v1.2.3) for reproducibility and control
  • B):latest is unpredictable and risky in production
  • C) ✓ Distroless images (no shell, package manager) = smaller, more secure
  • D) ✓ Vulnerability scanning identifies security issues early
  • E) ✗ Never include source code in production images; build separately

Key Concept: Image security = scanning, minimal base images, specific tags, multi-stage builds.


Question 21: 12-Factor App Principle (Single-Select)

Which principle from the 12-Factor App methodology relates to configuration?

A) Configuration should be stored in the codebase B) Configuration should be stored in environment variables C) Configuration should be compiled into the binary D) Each environment hardcodes its own configuration

Your Answer: ___

Click to reveal answer

Correct Answer: B) Configuration should be stored in environment variables

Explanation: The 12-Factor App’s “Config” principle: Store config in environment variables, not in code. This allows the same image to run in dev, staging, production with different configs. Kubernetes ConfigMaps and Secrets implement this.

Key Concept: 12-Factor = environment variables for config. Enables build-once, run-anywhere deployment.


Question 22: API Gateway Concept (Single-Select)

What is the primary purpose of an API Gateway in cloud-native architecture?

A) To provide load balancing only B) To enforce HTTPS encryption C) To serve as a single entry point for client requests with routing, authentication, and rate limiting D) To replace the need for multiple services

Your Answer: ___

Click to reveal answer

Correct Answer: C) To serve as a single entry point for client requests with routing, authentication, and rate limiting

Explanation: An API Gateway acts as a facade for backend services. It routes requests to appropriate services, enforces authentication/authorization, applies rate limiting, and can handle cross-cutting concerns. It doesn’t replace services; it’s a client-facing entry point.

Key Concept: API Gateway = entry point, request routing, auth enforcement, rate limiting, request/response transformation.


Domain 4: Cloud Native Observability (Questions 23-24)

Question 23: Observability Pillars (Multiple-Select)

Which are core pillars of cloud-native observability? (Select ALL that apply)

A) Metrics B) Logs C) Traces D) Container images E) Environment variables

Your Answers: ___

Click to reveal answer

Correct Answer: A, B, C

Explanation:

  • A) ✓ Metrics = quantitative measurements (CPU, memory, requests/sec)
  • B) ✓ Logs = text-based events and output from applications
  • C) ✓ Traces = distributed request flows across services
  • D) ✗ Container images are deployment artifacts, not observability
  • E) ✗ Environment variables are configuration, not observability

Key Concept: Observability “Three Pillars” = Metrics + Logs + Traces. Understand each purpose.


Question 24: Monitoring vs Observability (Single-Select)

What is the key difference between monitoring and observability?

A) Monitoring and observability are the same thing B) Monitoring tells you WHAT is happening; observability tells you WHY C) Monitoring is for metrics only; observability includes logs and traces too D) Observability is only needed for small clusters

Your Answer: ___

Click to reveal answer

Correct Answer: B) Monitoring tells you WHAT is happening; observability tells you WHY

Explanation:

  • Monitoring: Predefined checks and alerts (CPU > 80%? Alert!)
  • Observability: Ability to ask arbitrary questions about system behavior and understand causation

Observability is broader: you can monitor what you observe, but observability lets you explore unexpected behaviors.

Key Concept: Monitoring = predetermined alerts. Observability = ability to investigate anything (requires logs, metrics, traces).


Domain 5: Cloud Native Application Delivery (Questions 25)

Question 25: CI/CD Pipeline (Single-Select)

What is the purpose of the “Continuous Integration” phase in a CI/CD pipeline?

A) To automatically deploy code to production B) To continuously integrate code changes and run automated tests C) To provide version control for code D) To monitor applications in production

Your Answer: ___

Click to reveal answer

Correct Answer: B) To continuously integrate code changes and run automated tests

Explanation: CI = Continuous Integration = code is merged frequently (multiple times per day) and automated tests run immediately to catch integration issues. This ensures code quality before deployment.

  • CI: Build, test, validate quality
  • CD: Deploy to production (Continuous Deployment) or make deployable (Continuous Delivery)

Key Concept: CI/CD = fast feedback. CI catches quality issues. CD gets changes to production quickly.


Practice Exam Scoring

Count your correct answers:

Questions 1-14 (Kubernetes Fundamentals): ___ / 14 Questions 15-18 (Container Orchestration): ___ / 4 Questions 19-22 (Cloud Native Architecture): ___ / 4 Questions 23-24 (Observability): ___ / 2 Question 25 (Application Delivery): ___ / 1

Total Score: ___ / 25

Percentage: ( ___ / 25) × 100 = ___%

How Did You Do?

ScoreInterpretation
24-25 (96-100%)Excellent! Ready to test.
22-23 (88-92%)Very good. One more week of targeted review.
20-21 (80-84%)Good foundation. Two weeks of focused study.
18-19 (72-79%)Adequate but needs improvement. Focus on weak domains.
Below 18More preparation needed. Return to study materials.

Next Steps

If you scored 20+: You’re likely ready for the real exam. Take more full-length practice tests on Sailor.sh to build confidence and simulate exam conditions.

If you scored 15-19: You have a solid foundation but need targeted review. Identify which domains you struggled with and focus there. Then take more practice tests.

If you scored below 15: Return to study materials for the domains where you struggled most. Don’t take the real exam until you consistently score 20+ on practice tests.

Get More Practice

These 25 questions provide a snapshot, but the real exam has 60 questions. For comprehensive preparation:

Key Takeaways from These Questions

  1. Understand hierarchy: Pod → Deployment → Node
  2. Know service types: ClusterIP, NodePort, LoadBalancer, ExternalName
  3. Distinguish similar concepts: Requests vs Limits, Monitoring vs Observability
  4. Master relationships: Deployment ↔ ReplicaSet, Role ↔ RoleBinding
  5. Remember best practices: Specific tags, distroless images, secure secrets
  6. Understand Kubernetes self-healing: Liveness probes, node failures, rolling updates

Ready for more comprehensive practice? Start your KCNA preparation with Sailor.sh and access unlimited practice exams, domain-specific quizzes, and detailed explanations. Take the free sample quiz to benchmark your current level and identify preparation priorities.

Questions about specific topics? Review our detailed guides:

Good luck with your KCNA certification journey!

Limited Time Offer: Get 80% off all Mock Exam Bundles | Sale ends in 7 days. Start learning today.

Claim Now