Courseiva

CCNA Container Orchestration Questions

75 of 210 questions · Page 1/3 · Container Orchestration · Answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

Which of the following is a key benefit of container orchestration compared to running containers manually?

A.Containers use less memory
B.Automatic scaling and self-healing
C.Orchestration eliminates the need for container images
D.Containers run faster when orchestrated
AnswerB

Orchestrators such as Kubernetes continuously reconcile desired state, automatically scaling pods to match demand and restarting failed containers, which manual container management cannot provide. This satisfies the requirement for resilience and elasticity without operator intervention.

Why this answer

Container orchestration platforms like Kubernetes provide automatic scaling and self-healing capabilities that are not available when running containers manually. Self-healing automatically restarts failed containers, reschedules them when nodes fail, and replaces containers that fail health checks, while scaling adjusts the number of replicas based on CPU/memory metrics or custom metrics. Manual container management requires operators to monitor and intervene for each failure or load change, making orchestration essential for production-grade reliability and elasticity.

Exam trap

CNCF exams test that orchestration's primary benefits are automation, resilience, and declarative management, not raw speed or memory savings. Avoid choosing options that claim performance or resource improvements.

How to eliminate wrong answers

Option A is wrong because container orchestration does not inherently reduce memory usage; memory consumption depends on the container image and application, not the orchestration layer. Option C is wrong because orchestration still requires container images (e.g., Docker images stored in a registry) to run pods; it does not eliminate the need for images. Option D is wrong because orchestration does not make containers run faster; it adds a small overhead for scheduling and API calls, and performance is determined by the runtime and host OS, not the orchestrator.

Practice this question →
2
Multi-Selecthard

Which THREE are valid container runtimes that implement the Kubernetes CRI? (Choose three.)

Select 3 answers
A.Docker (via dockershim, deprecated)
B.containerd
C.runc
D.CRI-O
E.rkt
AnswersA, B, D

Docker's CRI support came only through dockershim, an in-tree adapter that Kubernetes removed in v1.24. It still counts as a valid CRI-implementing runtime historically, satisfying the stem, though the deprecation means containerd or CRI-O is now preferred.

Why this answer

Docker (via dockershim) is correct because Kubernetes historically shipped an in-tree CRI adapter called dockershim that translated CRI calls to the Docker Engine API, allowing Docker to serve as a container runtime until its deprecation in v1.24. containerd is correct because it natively implements the CRI plugin (cri plugin enabled by default), making it a first-class Kubernetes container runtime. CRI-O is correct because it was purpose-built as a lightweight CRI implementation for Kubernetes using OCI-compliant runtimes like runc. runc is not a CRI implementation; it is a low-level OCI runtime invoked by higher-level runtimes such as containerd and CRI-O to actually create containers. rkt is not a CRI runtime; it was an alternative container engine that was deprecated and never implemented the Kubernetes CRI.

Exam trap

KCNA often tests the confusion between CRI implementations (containerd, CRI-O, dockershim) and OCI runtimes (runc, crun) — candidates incorrectly pick runc because it 'runs containers'.

Practice this question →
3
Multi-Selecteasy

Which TWO of the following are benefits of using containers over virtual machines? (Choose 2)

Select 2 answers
A.Containers are more lightweight and start faster than VMs
B.Containers require hypervisor software to run
C.Containers include a full guest operating system
D.Containers are portable across different environments
E.Containers provide stronger isolation than VMs
AnswersA, D

Containers share the host OS kernel and do not need to boot an OS, so they start in seconds.

Why this answer

Containers share the host OS kernel and run as isolated processes, making them lightweight and able to start in milliseconds, unlike VMs which require booting a full guest OS. This efficiency stems from container images being mere megabytes compared to gigabytes for VM images, and containers using cgroups and namespaces for resource management rather than a hypervisor.

Exam trap

The trap here is that candidates confuse container isolation with VM isolation, assuming containers are more secure, when in fact VMs provide stronger isolation due to hardware virtualization, and CNCF often tests this distinction by offering 'stronger isolation' as a distractor.

Practice this question →
4
MCQhard

A Kubernetes cluster is experiencing network latency. The team suspects that the number of services and endpoints is causing iptables performance degradation. Which CNI plugin or network policy approach is most likely to improve performance?

A.Switch to Flannel with host-gw backend
B.Use Calico with iptables mode
C.Use an eBPF-based CNI plugin like Cilium
D.Apply a default-deny NetworkPolicy
AnswerC

Cilium replaces iptables with eBPF programs attached in the kernel, giving O(1) service lookup instead of sequential rule traversal. As services and endpoints grow, iptables latency scales linearly; eBPF hash-map lookups stay constant, directly resolving the degradation described.

Why this answer

C is correct because eBPF-based CNI plugins like Cilium bypass the traditional iptables chains entirely, using a kernel-level BPF (Berkeley Packet Filter) program to handle service load balancing and network policy enforcement. This eliminates the O(n) scaling issue of iptables rules with the number of services and endpoints, significantly reducing latency in large clusters.

Exam trap

The trap here is that candidates often assume any CNI change or network policy adjustment can fix iptables performance, but only eBPF-based solutions fundamentally change the data path to avoid iptables scaling limitations.

How to eliminate wrong answers

Option A is wrong because Flannel with host-gw backend only improves pod-to-pod routing by using direct host routes, but it does not address iptables performance degradation for service load balancing; Flannel still relies on iptables or IPVS for Service ClusterIP forwarding. Option B is wrong because Calico with iptables mode uses the same iptables data path that is already causing performance issues; it would not improve latency and may even worsen it with additional policy rules. Option D is wrong because applying a default-deny NetworkPolicy adds more iptables rules to enforce isolation, which increases the rule count and further degrades iptables performance, the opposite of what is needed.

Practice this question →
5
MCQmedium

You need to run a batch job that processes a queue and then terminates. Which Kubernetes resource should you use?

A.Deployment
B.DaemonSet
C.StatefulSet
D.Job
AnswerD

A Job creates pods that run to completion and then stops, tracking successful termination. Unlike a Deployment, which maintains a desired replica count indefinitely, a Job suits the queue-processing batch workload that must finish and exit.

Why this answer

A Job is the correct Kubernetes resource for running a batch process that executes a finite task (e.g., processing a queue) and then terminates. Unlike controllers that maintain a desired state indefinitely, a Job creates one or more Pods and ensures they run to successful completion, after which the Job itself completes and no further Pods are created.

Exam trap

CNCF often tests the misconception that a Deployment can be used for any workload, but the trap here is that a Deployment's restart policy (Always) makes it unsuitable for terminating batch jobs, whereas a Job's restart policy (OnFailure or Never) is specifically designed for finite tasks.

How to eliminate wrong answers

Option A is wrong because a Deployment is designed for long-running, stateless applications that must maintain a desired replica count indefinitely; it will restart Pods upon completion, which is the opposite of a terminating batch job. Option B is wrong because a DaemonSet ensures that a copy of a Pod runs on every (or selected) Node in the cluster, typically for cluster-wide services like logging or monitoring, not for a one-time batch task. Option C is wrong because a StatefulSet is intended for stateful applications that require stable, unique network identities and persistent storage, such as databases, and it maintains a sticky identity across restarts, which is unnecessary and inappropriate for a terminating queue-processing job.

Practice this question →
6
MCQhard

You are designing a microservices application. Which of the following is a key principle of microservices architecture?

A.Services are loosely coupled and can be deployed independently
B.Services are tightly coupled to allow fast communication
C.All services must be written in the same programming language
D.All services must share a common database
AnswerA

Loose coupling means services interact through well-defined interfaces with minimal shared state, so each can be built, tested and released on its own schedule. This satisfies the independent deployability requirement, distinguishing microservices from monolithic or tightly coupled tiers.

Why this answer

Microservices architecture is fundamentally defined by loose coupling and independent deployability. Each service encapsulates its own domain logic, communicates via lightweight protocols like HTTP/REST or gRPC, and can be updated, scaled, or deployed without affecting other services. This aligns with the Kubernetes-native pattern of managing each microservice as a separate Deployment or StatefulSet, enabling continuous delivery and resilience.

Exam trap

CNCF often tests the misconception that microservices require a single shared database or a single programming language, confusing microservices with a distributed monolith; the trap here is assuming that 'fast communication' (Option B) justifies tight coupling, when in reality loose coupling is prioritized for resilience and independent deployability.

How to eliminate wrong answers

Option B is wrong because tight coupling contradicts the core principle of microservices; it would create a monolithic dependency graph where a change in one service requires coordinated changes in others, negating the benefits of independent scaling and fault isolation. Option C is wrong because microservices explicitly allow polyglot programming — each service can be written in the language best suited for its task (e.g., Go for high-throughput services, Python for data processing) and communicate over standard protocols. Option D is wrong because sharing a single database creates tight coupling at the data layer, violating service autonomy; each microservice should own its private database (database-per-service pattern) to avoid schema conflicts and enable independent schema evolution.

Practice this question →
7
MCQmedium

A team runs a stateless web application and wants to update its container image with zero downtime while gradually shifting traffic to the new version. They also need the ability to pause the rollout, inspect the new Pods, and then resume. Which Kubernetes workload and strategy best supports this workflow?

A.A StatefulSet with the OnDelete update strategy.
B.A CronJob scheduled to delete old Pods at a fixed interval.
C.A Deployment using the RollingUpdate strategy with maxSurge and maxUnavailable.
D.A Job with parallelism set to the desired replica count.
AnswerC

A Deployment with the RollingUpdate strategy replaces Pods incrementally while keeping the application available, and its maxSurge and maxUnavailable settings control the pace of the transition. The rollout can be paused with 'kubectl rollout pause', inspected, and resumed with 'kubectl rollout resume', exactly matching the requested workflow.

Why this answer

A Deployment with the RollingUpdate strategy is the standard Kubernetes mechanism for zero-downtime, incremental updates of stateless applications. maxSurge and maxUnavailable let the team tune how many extra and unavailable Pods are allowed during the transition. The 'kubectl rollout pause' and 'kubectl rollout resume' commands support inspecting the new revision before completing the rollout.

Exam trap

The trap here is assuming that pause/resume and gradual traffic shifting are generic to all workload controllers, when they are specifically supported by Deployment rollouts with the RollingUpdate strategy.

Practice this question →
8
MCQmedium

A developer wants to run a container image locally for testing before deploying to a Kubernetes cluster. Which tool is most appropriate for this task?

A.Ansible
B.Docker
C.Kubernetes
D.Terraform
AnswerB

Docker runs OCI container images directly on a local host through its daemon, satisfying the requirement to test the image before cluster deployment. Unlike Kubernetes, which orchestrates containers across nodes, Docker provides the single-machine runtime needed here, letting the developer validate image behaviour locally without cluster overhead.

Why this answer

Docker is the most appropriate tool for running a container image locally because it is a container runtime that directly executes containers on a local machine using the OCI (Open Container Initiative) image specification. Unlike Kubernetes, which is designed for orchestrating containers across a cluster, Docker provides a simple `docker run` command to spin up a container from an image for testing purposes.

Exam trap

The exam often tests the distinction between container runtimes (Docker) and orchestration platforms (Kubernetes), trapping candidates who think Kubernetes is needed for any container operation, even a simple local test.

How to eliminate wrong answers

Option A is wrong because Ansible is an IT automation tool for configuration management, application deployment, and task automation, not a container runtime; it cannot run a container image directly. Option C is wrong because Kubernetes is a container orchestration platform designed to manage clusters of containers across multiple nodes, and running it locally for a single container test is overkill and requires a full cluster setup (e.g., minikube or kind), making Docker the simpler and more direct choice. Option D is wrong because Terraform is an infrastructure-as-code tool for provisioning and managing cloud resources, not for running containers; it has no capability to execute a container image locally.

Practice this question →
9
Multi-Selectmedium

Which TWO of the following are benefits of container orchestration?

Select 2 answers
A.Ability to run containers without a kernel
B.Manual scaling of containers
C.High availability through self-healing
D.Automated scaling based on demand
E.Simplified network configuration for each container
AnswersC, D

Orchestrators automatically restart failed containers.

Why this answer

Container orchestration platforms like Kubernetes implement self-healing mechanisms through controllers such as ReplicaSets and StatefulSets. These controllers continuously monitor the desired state of pods and automatically restart, reschedule, or replace containers that fail, crash, or become unresponsive, ensuring high availability without manual intervention.

Exam trap

The trap here is that candidates confuse the ability to run containers without a kernel (Option A) with the concept of container isolation, but containers always depend on the host kernel, and Kubernetes orchestration does not change that.

Practice this question →
10
MCQmedium

A developer wants to run a containerized application locally for development. Which tool is most appropriate?

A.CRI-O
B.Docker Compose
C.containerd
D.Kubernetes
AnswerB

Docker Compose defines and runs multi-container applications from a single YAML file, orchestrating linked services, networks and volumes with one command. For local development requiring several cooperating containers, this satisfies the need to start the whole stack together rather than managing each container individually.

Why this answer

Docker Compose is the most appropriate tool for running a containerized application locally during development because it allows you to define and manage multi-container applications using a simple YAML file. It handles container lifecycle, networking, and volume mounts with a single `docker compose up` command, making it ideal for local development workflows where rapid iteration and simplicity are key.

Exam trap

The trap here is that candidates confuse container runtimes (CRI-O, containerd) or orchestration platforms (Kubernetes) with development tools, assuming any container-related technology can run apps locally, but the KCNA exam specifically tests the understanding that Docker Compose is the standard for local multi-container development.

How to eliminate wrong answers

Option A (CRI-O) is wrong because it is a lightweight container runtime designed for Kubernetes, not a tool for local development; it lacks the developer-friendly features like `docker compose up` and is typically used in production clusters. Option C (containerd) is wrong because it is a low-level container runtime that manages container lifecycle but does not provide orchestration or multi-container application definitions; it is a building block for higher-level tools like Docker or Kubernetes, not a development tool. Option D (Kubernetes) is wrong because it is a full-scale container orchestration platform intended for production deployments across clusters; running it locally (e.g., via Minikube or kind) adds unnecessary complexity and overhead compared to Docker Compose for simple development scenarios.

Practice this question →
11
MCQmedium

An application requires stable network identities and persistent storage. Which workload type should be used?

A.Deployment
B.DaemonSet
C.Job
D.StatefulSet
AnswerD

StatefulSet assigns each pod a stable, ordinal hostname and its own PersistentVolumeClaim, so network identity and storage survive rescheduling. Deployments give pods random names and share or lose volumes, failing the persistence and stable-identity requirement.

Why this answer

StatefulSet is the correct workload type because it provides stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage (via PersistentVolumeClaims that persist across Pod rescheduling). This makes it ideal for stateful applications like databases, where each Pod requires a stable identity and dedicated storage that survives restarts.

Exam trap

The KCNA exam often tests the misconception that Deployments can handle stateful workloads by using PersistentVolumeClaims, but they fail to account for the lack of stable network identities and ordered pod management that StatefulSet provides.

How to eliminate wrong answers

Option A is wrong because Deployment is designed for stateless applications; it creates pods with random, ephemeral identities and does not guarantee stable network names or persistent storage per pod. Option B is wrong because DaemonSet ensures one pod per node, typically for node-level services like logging or monitoring, and does not provide stable identities or persistent storage for stateful workloads. Option C is wrong because Job is intended for batch processing tasks that run to completion, not for long-running stateful services requiring stable identities and persistent storage.

Practice this question →
12
MCQeasy

Which of the following is a benefit of using an orchestrator like Kubernetes?

A.Direct access to the host kernel for performance tuning
B.Guaranteed zero downtime for all updates
C.Automatic scaling based on CPU utilization
D.Manual scaling based on traffic spikes
AnswerC

Kubernetes Horizontal Pod Autoscaler adjusts replica counts based on observed CPU utilisation against defined targets, adding or removing pods automatically. This removes manual capacity intervention, satisfying the benefit of responding to load changes without operator action.

Why this answer

Kubernetes, as a container orchestrator, provides built-in Horizontal Pod Autoscaling (HPA) that automatically adjusts the number of pod replicas based on observed CPU utilization (or custom metrics). This is a core benefit because it allows applications to handle varying load without manual intervention, improving resource efficiency and availability.

Exam trap

The trap here is that candidates confuse 'automatic scaling' with 'manual scaling' or assume Kubernetes guarantees zero downtime, but the exam tests the specific benefit of automated, policy-driven scaling based on metrics like CPU utilization.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not provide direct access to the host kernel; containers share the host kernel via namespaces and cgroups, and direct kernel access would break isolation and security. Option B is wrong because Kubernetes cannot guarantee zero downtime for all updates; while it supports rolling updates and strategies like maxSurge and maxUnavailable to minimize disruption, factors like application bugs or resource constraints can still cause downtime. Option D is wrong because manual scaling based on traffic spikes is not a benefit of using an orchestrator; orchestrators like Kubernetes automate scaling, and manual scaling is a legacy approach that defeats the purpose of orchestration.

Practice this question →
13
MCQhard

A Kubernetes cluster runs a critical application that must be highly available. The application consists of three pods managed by a Deployment. To ensure the application remains accessible during a node failure, which configuration should be applied?

A.Set podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution to enforce pods on different nodes.
B.Set nodeAffinity to require pods to run on specific nodes.
C.Set topologySpreadConstraints with maxSkew: 1 and whenUnsatisfiable: ScheduleAnyway.
D.Set podAntiAffinity to prefer scheduling pods on different nodes.
AnswerA

requiredDuringSchedulingIgnoredDuringExecution makes the anti-affinity a hard rule. The scheduler will not place two pods with the matching labels on the same node. This ensures that the three pods are spread across at least three nodes, so a single node failure only affects one pod, maintaining availability. This is the strongest guarantee for spreading pods.

Why this answer

To guarantee that pods are spread across different nodes, a hard pod anti-affinity rule is needed. requiredDuringSchedulingIgnoredDuringExecution enforces that no two pods with the specified labels can be on the same node. This ensures that a single node failure does not take down all replicas. Soft anti-affinity, topology spread with ScheduleAnyway, and node affinity do not provide the same hard guarantee.

Exam trap

The trap here is confusing preferred anti-affinity or topology spread with ScheduleAnyway as sufficient for high availability; only hard requirements guarantee spreading.

Practice this question →
14
MCQmedium

A pod is in the 'CrashLoopBackOff' state. You run 'kubectl logs mypod' and see an error related to missing environment variables. The pod is part of a Deployment. What is the best way to fix this without recreating the entire Deployment?

A.Use kubectl set env to add the environment variables to the pod
B.Delete the pod and rely on the Deployment to recreate it
C.Update the Deployment's pod template to include the missing environment variables
D.Edit the pod directly using kubectl edit pod mypod
AnswerC

Updating the Deployment's spec triggers a rolling update, creating new pods with the correct environment.

Why this answer

The Deployment's pod template defines the desired state for its ReplicaSet. Updating the template to include the missing environment variables causes the Deployment to perform a rolling update, creating new pods with the correct configuration. This is the declarative, Kubernetes-native approach that maintains the Deployment's lifecycle management.

Note that `kubectl set env deployment/<name> KEY=value` is also a valid imperative way to update the Deployment's pod template and trigger the same rolling update; it is not the same as editing the pod directly.

Exam trap

Kubernetes often tests the misconception that you can fix a pod's configuration by editing the pod directly, when in fact the Deployment's controller will replace or reconcile those changes, making a template update the durable fix. Be careful not to confuse editing a pod directly with updating the Deployment's pod template imperatively via `kubectl set env`.

How to eliminate wrong answers

Option A is wrong because 'kubectl set env' modifies the environment of a running pod, but the pod is in CrashLoopBackOff and will be recreated from the Deployment's template; the change is ephemeral and not persisted. Option B is wrong because deleting the pod only triggers the ReplicaSet to recreate it from the same faulty template, resulting in the same CrashLoopBackOff. Option D is wrong because editing the pod directly with 'kubectl edit pod' only changes the live pod object, which is not managed by the Deployment; the ReplicaSet will revert the pod to the template's specification upon any reconciliation.

Practice this question →
15
Multi-Selectmedium

Which two of the following are container runtimes that implement the Container Runtime Interface (CRI)? (Choose two.)

Select 2 answers
A.Docker
B.containerd
C.Podman
D.CRI-O
E.runc
AnswersB, D

containerd implements CRI and is a common runtime.

Why this answer

containerd is a core container runtime that implements the Container Runtime Interface (CRI), which is the Kubernetes API for integrating container runtimes. It was originally extracted from Docker and is now a graduated CNCF project, providing a stable CRI-compatible interface for managing container lifecycles.

Exam trap

The exam often tests the misconception that Docker is a CRI-compliant runtime, when in fact it required the now-removed dockershim, and that runc is a CRI implementation rather than a low-level OCI runtime.

Practice this question →
16
MCQmedium

Which of the following is a benefit of using container orchestration platforms like Kubernetes?

A.Increased network latency
B.Manual scaling of applications
C.Self-healing (automatic restart of failed containers)
D.Tighter coupling between microservices
AnswerC

Kubernetes continuously reconciles desired state against actual state via its control loop; when a container or node fails, the ReplicaSet controller recreates the pod automatically. This self-healing restarts failed containers without human intervention, directly delivering the availability benefit the question asks about.

Why this answer

Kubernetes includes a built-in controller (the kubelet and ReplicaSet controller) that continuously monitors the desired state of pods. If a container fails or its process crashes, the kubelet automatically restarts it based on the pod's restart policy (e.g., Always), ensuring high availability without manual intervention. This self-healing capability is a core benefit of container orchestration, reducing downtime and operational overhead.

Exam trap

CNCF often tests the misconception that container orchestration platforms like Kubernetes increase complexity and latency, but the correct answer highlights that they actually automate recovery and improve resilience, not degrade performance.

How to eliminate wrong answers

Option A is wrong because container orchestration platforms like Kubernetes typically reduce network latency through service discovery and intelligent load balancing (e.g., kube-proxy with iptables/IPVS), not increase it. Option B is wrong because Kubernetes enables automatic scaling via Horizontal Pod Autoscaler (HPA) based on CPU/memory metrics or custom metrics, eliminating the need for manual scaling. Option D is wrong because Kubernetes promotes loose coupling between microservices through declarative APIs, service abstractions (ClusterIP), and decoupled communication patterns, not tighter coupling.

Practice this question →
17
Multi-Selectmedium

Which TWO of the following are benefits of using a container orchestration platform like Kubernetes? (Select 2)

Select 2 answers
A.Manual deployment of containers to servers
B.Requirement for a hypervisor on every node
C.Self-healing of failed containers
D.Static infrastructure that never changes
E.Automatic scaling of applications based on demand
AnswersC, E

Kubernetes continuously reconciles desired state against actual state, restarting or rescheduling containers whose liveness probes fail or whose nodes die. This automated remediation removes manual intervention, directly delivering the self-healing benefit the question asks you to identify.

Why this answer

Option C is correct because Kubernetes continuously reconciles desired state with actual state: its controllers (e.g., ReplicaSet, Deployment) detect crashed or unhealthy pods via liveness/readiness probes and restart or reschedule them, providing self-healing. Option E is correct because Kubernetes supports automatic scaling through the Horizontal Pod Autoscaler (HPA), which adjusts replica counts based on metrics such as CPU utilization or custom metrics, and the Cluster Autoscaler, which adds or removes nodes as demand changes. Option A is wrong because orchestration automates container scheduling and deployment rather than requiring manual placement.

Option B is wrong because Kubernetes runs containers via a container runtime (containerd, CRI-O) on each node and does not require a hypervisor. Option D is wrong because orchestration platforms are designed for dynamic, declarative infrastructure that changes as workloads and scaling demands evolve.

Exam trap

A common misconception is that container orchestration requires hypervisors or static infrastructure, but the correct understanding is that Kubernetes abstracts the underlying hardware and provides dynamic, self-healing, and auto-scaling capabilities without hypervisors.

Practice this question →
18
MCQmedium

An administrator runs 'kubectl get pods' and sees that a pod named 'app-pod' is in 'CrashLoopBackOff'. They run 'kubectl logs app-pod' and see a segmentation fault error. What is the most likely cause?

A.The node is out of memory
B.The container has a configuration error
C.The application code has a bug
D.The readiness probe is misconfigured
AnswerC

A segmentation fault indicates the application process accessed invalid memory, which is a defect within the application code itself. CrashLoopBackOff results because Kubernetes repeatedly restarts the container after each crash, confirming the code bug as the cause.

Why this answer

A segmentation fault (segfault) is a specific error caused by a program attempting to access memory it does not have permission to access, typically due to a bug in the application code (e.g., null pointer dereference, buffer overflow). Since the container starts but then crashes repeatedly (CrashLoopBackOff), the segfault indicates the application itself is failing, not the infrastructure or configuration. This is the most direct cause of the pod entering CrashLoopBackOff.

Exam trap

CNCF often tests the distinction between application-level errors (like segfaults) and infrastructure or configuration issues, tempting candidates to blame resource constraints or probe misconfiguration when the logs clearly point to a runtime crash.

How to eliminate wrong answers

Option A is wrong because a node out-of-memory condition would cause the pod to be evicted or fail to schedule, not produce a segmentation fault in the application logs; the kubelet would report an OOMKilled status, not a segfault. Option B is wrong because a configuration error (e.g., missing environment variable, incorrect command) would typically result in an immediate container exit with a non-zero exit code or a startup failure, not a segmentation fault which is a runtime memory access violation. Option D is wrong because a misconfigured readiness probe would cause the pod to be marked as not ready and removed from service endpoints, but the container would continue running and not crash; the logs would show probe failures, not a segfault.

Practice this question →
19
MCQhard

An administrator manages a cluster where a Namespace named 'analytics' contains a ResourceQuota that limits pods to 10. A developer applies a manifest containing a ReplicaSet with replicas: 12 in that Namespace. The ReplicaSet controller creates the first 10 Pods successfully, but the remaining 2 Pods are rejected. Which statement best describes what the developer will observe and why?

A.The ReplicaSet scales itself down to 10 replicas and reports a status condition indicating the quota was exceeded.
B.The ReplicaSet status shows fewer ready replicas than desired, and the events for the ReplicaSet include quota-related failures for the denied Pods.
C.The API server accepts all 12 Pods but marks 2 of them with a Failed phase due to the quota, and the ReplicaSet ignores those Pods.
D.The 2 extra Pods are created but remain in a Pending state until quota becomes available, and the ReplicaSet reports 12 ready replicas.
AnswerB

When a ResourceQuota is exceeded, the API server rejects the Pod create request during admission, so only 10 Pods exist. The ReplicaSet controller keeps reconciling toward 12 and records warning events such as 'FailedCreate' with a message about exceeding quota. Its status shows ready and available replicas below the desired count, which matches this observation.

Why this answer

ResourceQuota is enforced by an admission controller in the API server, so Pod creation requests beyond the allowed count are rejected outright. The ReplicaSet controller continues to reconcile toward 12 replicas, records FailedCreate events describing the quota violation, and reports status with fewer ready replicas than desired. No extra Pod objects are persisted, and the ReplicaSet spec is not automatically lowered.

Exam trap

The trap here is believing that quota-denied Pods are created in a Pending or Failed phase, when they are actually rejected before being stored.

Practice this question →
20
MCQhard

You have a Deployment with three replicas. You want to update the container image but ensure that only one pod is updated at a time, and the update proceeds only if the new pod becomes healthy. Which update strategy should you configure?

A.RollingUpdate with maxSurge=3 and maxUnavailable=1
B.RollingUpdate with maxSurge=1 and maxUnavailable=0
C.Canary deployment via Ingress
D.Recreate strategy
AnswerB

RollingUpdate with maxSurge=1 and maxUnavailable=0 replaces pods incrementally: one new pod is created while all existing replicas stay available, and the rollout advances only once that pod passes its readiness probe. This satisfies the constraints of updating a single pod at a time and gating progress on new-pod health.

Why this answer

A RollingUpdate strategy with maxSurge=1 and maxUnavailable=0 ensures that exactly one new pod is created before any old pod is terminated, and the update only proceeds when the new pod passes its readiness probe (i.e., becomes healthy). This guarantees that at all times during the update, the desired number of replicas (3) are available, and only one pod is updated at a time, matching the requirement.

Exam trap

In the KCNA exam, candidates often misinterpret that maxSurge controls the number of pods updated at a time, when in reality it controls the number of extra pods allowed above the desired count, while maxUnavailable controls the number of pods that can be unavailable during the update; candidates may incorrectly choose Option A thinking maxSurge=1 means one pod at a time, but maxSurge=3 allows three new pods to be created simultaneously, violating the 'only one pod updated at a time' constraint.

How to eliminate wrong answers

Option A is wrong because maxSurge=3 allows up to 3 extra pods to be created simultaneously, which could update multiple pods at once, violating the 'only one pod updated at a time' constraint. Option C is wrong because a Canary deployment via Ingress is a traffic-splitting technique that routes a percentage of traffic to a new version, but it does not inherently control pod update ordering or ensure that only one pod is updated at a time; it is a higher-level routing strategy, not a Deployment update strategy. Option D is wrong because the Recreate strategy terminates all existing pods before creating new ones, causing downtime and violating the requirement that the update proceeds only if the new pod becomes healthy (since all pods are replaced simultaneously).

Practice this question →
21
MCQhard

You need to deploy a batch job that processes a queue and runs to completion. The job should run exactly once and create exactly one pod per work item, but some items may fail. Which Kubernetes resource is best suited?

A.Deployment
B.Job
C.CronJob
D.DaemonSet
AnswerB

A Job creates one or more pods that run to completion, tracking successful completions and retrying failed pods until the specified count succeeds. This matches the batch queue-processing requirement where each work item runs exactly once and failures are retried.

Why this answer

A Kubernetes Job is the correct resource for batch processing tasks that run to completion, such as processing a queue where each work item corresponds to a pod. By configuring the `.spec.completions` and `.spec.parallelism` fields, you can ensure exactly one pod per work item and control concurrency. The Job automatically retries failed pods (up to a configurable limit) without restarting the entire batch, making it ideal for handling some failures.

In contrast, a Deployment (A) is for long-running, continuously available services; a CronJob (C) is for scheduled recurring jobs; and a DaemonSet (D) runs a pod on every node for infrastructure tasks. Therefore, Job (B) is the best fit.

Exam trap

The KCNA exam often tests the distinction between batch and long-running workloads, and the trap here is that candidates may confuse a Job with a Deployment because both can create multiple pods, but a Deployment is designed for continuous availability, not one-time execution.

How to eliminate wrong answers

Option A is wrong because a Deployment is intended for long-running, stateless applications that maintain a desired number of replicas, not for batch jobs that run to completion; it would restart pods indefinitely, violating the 'run exactly once' requirement. Option C is wrong because a CronJob schedules Jobs on a time-based schedule, but the question specifies a one-time batch job that processes a queue and runs to completion, not a recurring task. Option D is wrong because a DaemonSet ensures exactly one pod runs on each node in the cluster, which is used for node-level services like logging or monitoring, not for processing a queue with one pod per work item.

Practice this question →
22
MCQmedium

A company wants to adopt immutable infrastructure for its containerized applications. Which practice BEST exemplifies immutability?

A.Developers use kubectl exec to change environment variables in a running pod
B.When a container fails, the orchestrator terminates it and launches a new container from the same image
C.A configuration management tool runs periodically to ensure containers are up-to-date
D.An operator logs into a running container and applies a security patch with apt-get update
AnswerB

Immutability means containers are never patched or modified in place. Terminating the failed container and starting a fresh one from the identical image preserves the immutable artefact, satisfying the constraint that running instances are replaced rather than mutated.

Why this answer

Immutable infrastructure means that once a container is deployed from a specific image, it is never modified in place. When a container fails, the orchestrator (e.g., Kubernetes) terminates it and launches a new container from the same image, ensuring consistency and reproducibility. This approach eliminates configuration drift and aligns with the principle that all changes should be made by rebuilding the image, not by altering running instances.

Exam trap

The trap here is that candidates confuse immutability with automation, thinking that any automated update (like a config management tool) is acceptable, when in fact immutability in Kubernetes requires that no changes are made to running containers — only new images are deployed via rolling updates or similar mechanisms.

How to eliminate wrong answers

Option A is wrong because using kubectl exec to change environment variables in a running pod directly modifies the container's state, violating immutability by introducing runtime changes that are not captured in the image. Option C is wrong because a configuration management tool that runs periodically to update containers implies in-place modifications, which contradicts the immutable model where updates should come from deploying new images. Option D is wrong because logging into a running container and applying a security patch with apt-get update mutates the container's filesystem, creating a snowflake server that cannot be reliably reproduced from the original image.

Practice this question →
23
MCQmedium

You have a Deployment running 3 replicas. You need to update the container image without downtime. Which command updates the image while performing a rolling update?

A.kubectl replace deployment my-deployment --image=nginx:1.25
B.kubectl set image deployment/my-deployment nginx=nginx:1.25
C.kubectl scale deployment my-deployment --image=nginx:1.25
D.kubectl update deployment my-deployment --image=nginx:1.25
AnswerB

kubectl set image patches the Deployment's pod template, triggering the default RollingUpdate strategy, which replaces pods incrementally so the 3-replica service stays available. It names the container (nginx) and new tag directly, satisfying the no-downtime constraint without editing YAML.

Why this answer

`kubectl set image` triggers a rolling update on the Deployment, updating the container image gradually without downtime. Kubernetes automatically manages the rollout by creating new Pods with the new image and terminating old ones, ensuring the desired replica count is maintained throughout the process.

Exam trap

The trap is that candidates may confuse `kubectl set image` with non-existent or incorrect commands like `kubectl update` or `kubectl replace`, or mistakenly think `kubectl scale` can change images. In Kubernetes, only `kubectl set image` (or `kubectl edit`/`kubectl apply` with a modified manifest) triggers a rolling update for container images.

How to eliminate wrong answers

Option A is wrong because `kubectl replace` is used to replace a resource from a file or stdin, not to update an image directly; it would require a full YAML/JSON definition and does not inherently perform a rolling update. Option C is wrong because `kubectl scale` only changes the replica count of a Deployment, not the container image; the `--image` flag is not valid for the scale command. Option D is wrong because `kubectl update` is not a valid kubectl command; the correct imperative command for updating images is `kubectl set image`.

Practice this question →
24
MCQmedium

Which of the following is a benefit of container orchestration?

A.Requires a hypervisor for each container
B.Manual scaling of containers
C.Static infrastructure with no changes
D.Self-healing of failed containers
AnswerD

Controllers continuously compare observed pod state against the declared desired state, restarting or rescheduling containers that fail. This reconciliation loop restores availability without human action, which is precisely the self-healing benefit the question asks for.

Why this answer

Container orchestration platforms like Kubernetes provide self-healing capabilities by automatically restarting failed containers, rescheduling them on healthy nodes, and replacing or terminating containers that fail health checks. This ensures high availability and reduces manual intervention, which is a core benefit of orchestration.

Exam trap

CNCF often tests the misconception that container orchestration is only about initial deployment, when in fact its key value is ongoing automated management like self-healing and scaling.

How to eliminate wrong answers

Option A is wrong because container orchestration does not require a hypervisor for each container; containers share the host OS kernel and run as isolated processes, unlike VMs that need a hypervisor. Option B is wrong because container orchestration enables automatic scaling (e.g., horizontal pod autoscaling in Kubernetes), not manual scaling, which would defeat the purpose of automation. Option C is wrong because container orchestration promotes dynamic infrastructure with automated deployment, scaling, and updates, not static infrastructure with no changes.

Practice this question →
25
MCQeasy

Which component in Kubernetes is responsible for managing the lifecycle of pods and ensuring the desired number of replicas are running?

A.Kube-proxy
B.Kubelet
C.Controller Manager
D.ReplicaSet
AnswerD

ReplicaSet controllers continuously reconcile actual pod counts against the declared replica specification, creating or deleting pods to maintain the desired state. This directly satisfies the stem's requirement for lifecycle management and replica enforcement, unlike kube-scheduler (placement only) or kubelet (node-local pod execution).

Why this answer

The ReplicaSet (option D) is the Kubernetes controller that ensures a specified number of pod replicas are running at any given time. It manages pod lifecycle by creating or deleting pods to match the desired replica count defined in its spec, and it is the fundamental building block for higher-level controllers like Deployments.

Exam trap

In Kubernetes certification exams, candidates often confuse the Controller Manager (which hosts multiple controllers) with the specific controller (e.g., ReplicaSet) that performs the actual work, leading to selecting the broader component instead of the precise one.

How to eliminate wrong answers

Option A is wrong because kube-proxy is a network proxy that runs on each node, handling service-to-pod traffic routing via iptables or IPVS rules, not pod lifecycle or replica management. Option B is wrong because kubelet is the node agent that ensures containers are running in a pod as defined by the PodSpec, but it does not manage replica counts or pod lifecycle across nodes — it only acts on pods assigned to its node. Option C is wrong because the Controller Manager is a control plane component that runs multiple controllers (including ReplicaSet, Deployment, etc.) as a single binary, but it is not the specific component responsible for managing pod replicas — that is the ReplicaSet controller itself.

Practice this question →
26
MCQhard

A pod uses a ServiceAccount that has a RoleBinding to a Role with 'get', 'list', 'watch' on 'pods'. The pod tries to list pods in the same namespace. Will the request succeed?

A.No, because there is a deny rule for pods
B.Yes, because the Role grants 'list' on pods
C.No, because ServiceAccount cannot list pods
D.Yes, but only if the ServiceAccount also has a ClusterRoleBinding
AnswerB

RoleBinding binds the Role to the ServiceAccount within the same namespace, and the Role explicitly grants 'list' on pods, so the API server authorises the request. The namespace constraint is satisfied because both the Role and the pod reside in the same namespace.

Why this answer

In Kubernetes RBAC, permissions are additive. The Role grants 'list' on pods, so the ServiceAccount can list pods. There is no deny rule; RBAC is deny by default, but the permission is explicitly granted.

Option A is incorrect because there is no deny rule for pods. Option C is incorrect because a ServiceAccount can list pods if it has the appropriate RBAC permissions. Option D is incorrect because a ClusterRoleBinding is not required; a RoleBinding in the same namespace is sufficient.

Practice this question →
27
MCQmedium

A workload running in a namespace called 'payments' is defined by a Pod spec with restartPolicy: Always. The cluster's kubelet on node 'worker-3' is healthy, the API server is reachable, and the scheduler has placed the Pod on worker-3. After the Pod's only container exits with code 0, a platform engineer observes that the Pod restarts repeatedly even though the application completed its work successfully. Which Kubernetes behavior explains this observation?

A.The ReplicaSet controller recreates the Pod because the Pod's desired replica count is set to one.
B.The kubelet applies the Pod's liveness probe and restarts the container when the probe fails after the process exits.
C.The kubelet restarts the container because restartPolicy: Always restarts containers regardless of the exit code.
D.The scheduler evicts the Pod and reschedules it to another node, which causes the container to start again.
AnswerC

For a Pod with restartPolicy: Always, the kubelet restarts any container that terminates, including a container that exits with code 0. The restart decision is based on the policy, not on whether the application reported success, so a one-shot job-like container will keep restarting under this policy. This matches the observed repeated restarts.

Why this answer

With restartPolicy: Always, the kubelet treats every container termination as a reason to restart, even a successful exit with code 0. That policy is the correct default for long-running services but is wrong for run-to-completion work; such work should use restartPolicy: OnFailure or Never, or be modeled as a Job. The repeated restarts observed on worker-3 are therefore expected kubelet behavior for the Pod's policy.

Exam trap

The trap here is assuming that an exit code of 0 prevents a restart, when restartPolicy: Always restarts the container regardless of exit status.

Practice this question →
28
Multi-Selecteasy

Which TWO statements about container images are correct? (Choose two.)

Select 2 answers
A.Images are always pulled from a private registry
B.Each layer is identified by a unique hash
C.Images can be modified at runtime by writing to the container layer
D.Images are built from a series of read-only layers
E.Images are stored on the host filesystem after being pulled
AnswersB, D

Content-addressed storage means each layer's digest is computed from its contents, so identical layers share one hash across images and registries. This satisfies the stem's requirement for a correct statement about container images: immutability and deduplication follow directly from that unique hash, and any byte change produces a different digest.

Why this answer

Option B is correct because container image layers are content-addressable: each layer is identified by a unique cryptographic digest (hash) of its content, which is how registries and runtimes verify integrity and deduplicate layers. Option D is correct because an image is constructed as a stack of read-only layers, typically defined by Dockerfile instructions, with each layer adding or changing files on top of the previous one. Option A is incorrect because images can be pulled from public registries such as Docker Hub as well as private registries, so 'always' is false.

Option C is incorrect because writing at runtime happens in the writable container layer created on top of the image, not by modifying the image layers themselves. Option E is incorrect because after a pull, image layers are stored in the container runtime's local storage area (for example, /var/lib/docker or /var/lib/containers) rather than simply as arbitrary files on the host filesystem.

Exam trap

CNCF often tests the misconception that images are stored directly on the host filesystem like regular files, when in reality they are stored in a runtime-managed cache (e.g., /var/lib/docker) and are not directly accessible as ordinary files.

Practice this question →
29
MCQmedium

A pod spec includes a liveness probe that runs 'cat /tmp/healthy'. The probe is configured with initialDelaySeconds: 10, periodSeconds: 5. At what point does the kubelet first execute the probe?

A.Immediately after the pod is created
B.Only when the container is unhealthy
C.5 seconds after the container starts
D.10 seconds after the container starts
AnswerD

initialDelaySeconds: 10 tells the kubelet to wait ten seconds after the container starts before running the first liveness probe. periodSeconds: 5 only governs subsequent intervals, so the initial execution occurs at the ten-second mark, not earlier.

Why this answer

The kubelet first executes the liveness probe 10 seconds after the container starts because `initialDelaySeconds: 10` tells the kubelet to wait that long before initiating the first probe. The `periodSeconds: 5` only defines the interval between subsequent probes, not the initial delay. This ensures the container has time to start and create the `/tmp/healthy` file before being checked.

Exam trap

The trap here is confusing `initialDelaySeconds` with `periodSeconds`, leading candidates to think the probe runs after 5 seconds (the period) instead of 10 seconds (the initial delay).

How to eliminate wrong answers

Option A is wrong because the kubelet does not execute probes immediately after pod creation; it waits for the container to start and then applies `initialDelaySeconds`. Option B is wrong because liveness probes are executed periodically regardless of container health, not only when the container is unhealthy; the probe itself determines health. Option C is wrong because `periodSeconds: 5` controls the interval between probes after the first one, not the initial delay; the first probe occurs after `initialDelaySeconds`, which is 10 seconds.

Practice this question →
30
MCQmedium

A DevOps team notices that a new deployment of a web application is not receiving traffic even though the pods are running. The deployment has a selector matching the pod labels, and a Service of type ClusterIP exists. What is the most likely cause?

A.The Service's targetPort does not match the container's containerPort.
B.The pods do not have a readiness probe defined.
C.The Service type should be NodePort to receive traffic.
D.The Service is not exposed via an Ingress.
AnswerA

The Service routes traffic to the targetPort, which must match the port the container listens on.

Why this answer

The most likely cause is that the Service's targetPort does not match the container's containerPort. In Kubernetes, a Service routes traffic to pods by forwarding packets to the port specified in the Service's `targetPort` field. If this does not match the `containerPort` defined in the pod's container spec, the traffic will be dropped because the kube-proxy will forward packets to a closed port on the pod, resulting in no connectivity even though the pods are running.

Exam trap

The trap here is that candidates often confuse the Service's `port` (the port the Service listens on) with `targetPort` (the port on the pod), assuming they must match, or they incorrectly attribute the issue to missing readiness probes or Ingress resources.

How to eliminate wrong answers

Option B is wrong because a readiness probe controls whether a pod is considered ready to receive traffic, but its absence does not prevent traffic from being sent to the pod; it simply means the pod will always be considered ready. Option C is wrong because a Service of type ClusterIP is perfectly capable of receiving traffic within the cluster; NodePort is only needed for external access from outside the cluster, not for internal traffic. Option D is wrong because an Ingress is an optional API object for HTTP/HTTPS routing and is not required for a ClusterIP Service to receive traffic; the Service itself can be accessed directly via its cluster IP.

Practice this question →
31
MCQmedium

A Kubernetes cluster has a single control plane node and two worker nodes. The control plane node fails. What is the immediate impact on the workloads running on the worker nodes?

A.All workloads will stop immediately
B.Existing workloads continue running, but no new pods can be scheduled
C.The kubelet on worker nodes will restart all pods
D.Workloads will be automatically migrated to another cluster
AnswerB

Worker nodes run kubelet and their containers independently, so existing pods keep serving traffic. However, the scheduler and controller manager reside on the failed control plane, so no new pods can be placed and failed pods are not replaced, satisfying the immediate-impact constraint.

Why this answer

In Kubernetes, the control plane is responsible for scheduling new pods and maintaining desired state via the API server, controller manager, and scheduler. When the control plane fails, the kubelets on worker nodes continue to run existing pods based on their local state, but the scheduler cannot assign new pods to nodes, and the API server is unavailable for updates or scaling operations.

Exam trap

CNCF often tests the misconception that the control plane is required for all pod operations, leading candidates to assume workloads stop immediately, when in fact the kubelet provides resilience for existing pods.

How to eliminate wrong answers

Option A is wrong because existing workloads are managed by the kubelet on each worker node, which runs pods independently of the control plane; they do not stop immediately. Option C is wrong because the kubelet does not restart all pods upon control plane failure; it only restarts pods that have failed according to its local restart policy, not as a reaction to the control plane being down. Option D is wrong because Kubernetes does not automatically migrate workloads to another cluster; migration requires manual intervention or a multi-cluster management tool like KubeFed or a service mesh.

Practice this question →
32
MCQeasy

Refer to the exhibit. How many containers are defined in this Pod?

A.2
B.1
C.3
D.0
AnswerA

The exhibit lists two distinct container specifications within the Pod's spec.containers array, so the Pod defines two containers. Each entry has its own name and image, and Kubernetes schedules them together in the shared network namespace, confirming the count of two.

Why this answer

The exhibit shows a Pod manifest with two container definitions under the `containers` field: one named `nginx` and one named `sidecar`. In Kubernetes, the number of containers in a Pod is determined by counting the entries in the `spec.containers` list, not including init containers or ephemeral containers unless explicitly specified. Therefore, the correct answer is 2.

Exam trap

The trap here is that candidates may miscount containers by including init containers or ephemeral containers, or mistakenly think the number of images referenced equals the number of containers, when the manifest explicitly lists only two containers in the `containers` array.

How to eliminate wrong answers

Option B is wrong because it assumes only one container is defined, but the manifest clearly lists two container entries under `spec.containers`. Option C is wrong because it suggests three containers, which would require a third entry in the `containers` list or additional init containers, neither of which is present. Option D is wrong because a Pod must have at least one container to be valid; the manifest explicitly defines two containers, so zero is incorrect.

Practice this question →
33
MCQmedium

A pod is stuck in 'Pending' state. You run 'kubectl describe pod mypod' and see the event '0/4 nodes are available: 4 Insufficient cpu'. What is the most likely cause?

A.The pod has exceeded its memory limit
B.The pod's image pull is failing
C.None of the nodes have enough CPU resources to satisfy the pod's request
D.The pod's liveness probe is failing
AnswerC

The scheduler cannot bind the pod because every node's allocatable CPU is below the pod's requested `resources.requests.cpu`. The event "4 Insufficient cpu" confirms all four nodes failed the CPU predicate during filtering, leaving no feasible node. This directly satisfies the stem's constraint: insufficient CPU capacity across the cluster.

Why this answer

The '0/4 nodes are available: 4 Insufficient cpu' event directly indicates that the Kubernetes scheduler attempted to place the pod on each of the four nodes but found that none had enough allocatable CPU capacity to satisfy the pod's CPU request (specified in the container's `resources.requests.cpu`). This causes the pod to remain in 'Pending' state because the scheduler cannot find a feasible node.

Exam trap

A common pitfall is confusing resource 'requests' (used for scheduling) with 'limits' (used for throttling/eviction). Candidates may mistakenly think 'Insufficient cpu' refers to CPU limits being exceeded, rather than the scheduler failing to find a node with enough free CPU to meet the request.

How to eliminate wrong answers

Option A is wrong because exceeding a memory limit causes a pod to be terminated (OOMKilled) or evicted, not stuck in 'Pending' state with an 'Insufficient cpu' event. Option B is wrong because image pull failures generate events like 'Failed to pull image' or 'ErrImagePull', not a node-level scheduling failure. Option D is wrong because liveness probe failures occur after the pod is already running (affecting the 'Running' state), not during scheduling when the pod is still 'Pending'.

Practice this question →
34
MCQhard

When using a Service of type ClusterIP, how do pods reach the service?

A.Via the service's cluster IP and port
B.Via the node's IP address and a high port
C.Via an external load balancer
D.Directly via the pod's IP address
AnswerA

ClusterIP assigns a stable virtual IP; kube-proxy programs iptables or IPVS rules on each node so traffic sent to that IP and port is load-balanced to a backing pod. DNS resolves the service name to this address.

Why this answer

A Service of type ClusterIP exposes a stable virtual IP (the cluster IP) and port within the cluster. Pods reach the Service by sending traffic to this cluster IP and port, which is then load-balanced by kube-proxy (using iptables, IPVS, or eBPF rules) to one of the backing pod endpoints. This is the default and most fundamental Service type in Kubernetes.

Exam trap

CNCF often tests the misconception that ClusterIP Services are only reachable from within the same pod or node, when in fact they are reachable from any pod in the cluster (across nodes) via the cluster IP, thanks to kube-proxy's distributed routing rules.

How to eliminate wrong answers

Option B is wrong because reaching a Service via the node's IP address and a high port is the behavior of a NodePort Service, not ClusterIP. Option C is wrong because an external load balancer is used by a LoadBalancer Service, which is built on top of NodePort and ClusterIP, not by ClusterIP itself. Option D is wrong because pods do not reach the Service directly via a pod's IP address; that would bypass the Service abstraction and load balancing, and the Service's cluster IP is the intended stable endpoint.

Practice this question →
35
Multi-Selectmedium

Which THREE of the following are true about container lifecycle? (Choose 3)

Select 3 answers
A.A container can be paused and resumed
B.A container can be hibernated to save state to disk
C.A container goes through a 'built' phase before running
D.A container terminates when its main process exits
E.A container can be stopped and later restarted
AnswersA, D, E

Pausing freezes all processes in the container's cgroup via the freezer, and resuming unfreezes them, so state is preserved without a restart. This satisfies the lifecycle claim that a running container can be suspended and later continued.

Why this answer

Option A is correct because container runtimes such as Docker support pausing a running container (e.g., `docker pause`), which freezes all processes via the cgroup freezer, and resuming it later with `docker unpause`. Option D is correct because a container's lifecycle is tied to its main process (PID 1); when that process exits, the container terminates and its writable layer stops. Option E is correct because a stopped container retains its filesystem and configuration, allowing it to be restarted later with `docker start`, resuming the same container instance.

Option B is not correct because containers do not hibernate state to disk the way virtual machines or operating systems do; there is no standard container hibernation mechanism. Option C is not correct because 'built' is a phase of creating an image, not a container lifecycle stage; containers are created and then started, not built.

Exam trap

KCNA often tests the container-vs-VM lifecycle boundary — candidates who transfer VM concepts like hibernation or 'built phase' onto containers pick the wrong options.

Practice this question →
36
MCQhard

You are asked to deploy a Kubernetes service that exposes a set of pods internally within the cluster only. The service should not be accessible from outside the cluster. Which Service type should you choose?

A.ClusterIP
B.NodePort
C.ExternalName
D.LoadBalancer
AnswerA

ClusterIP assigns a virtual IP reachable only from within the cluster, satisfying the internal-only constraint. Unlike NodePort or LoadBalancer, it provisions no external listener or cloud load balancer, so pods remain unexposed outside the cluster network.

Why this answer

ClusterIP is the default Kubernetes Service type that exposes the service on a cluster-internal IP address. This makes the service reachable only from within the cluster, which is exactly what is required for internal-only communication between pods. No external traffic can reach a ClusterIP service unless an ingress controller or proxy is explicitly configured.

Exam trap

CNCF often tests the misconception that ClusterIP is only for inter-pod communication within the same namespace, but it actually works across all namespaces within the cluster, and the trap is that candidates confuse it with NodePort when they think 'internal only' means 'no external access' but forget that NodePort inherently opens external access.

How to eliminate wrong answers

Option B is wrong because NodePort exposes the service on a static port on each node's IP address, making it accessible from outside the cluster via <NodeIP>:<NodePort>. Option C is wrong because ExternalName maps a service to a DNS name (via CNAME records) and does not expose pods internally; it is used to provide an alias for an external service. Option D is wrong because LoadBalancer provisions an external load balancer (e.g., from a cloud provider) and assigns a public IP, making the service accessible from outside the cluster.

Practice this question →
37
MCQeasy

What is the primary purpose of the Open Container Initiative (OCI)?

A.To provide a container runtime called Docker
B.To create a container orchestration platform
C.To define the Kubernetes Container Runtime Interface (CRI)
D.To standardize container image and runtime specifications
AnswerD

The OCI publishes the image-spec and runtime-spec, defining a common image format and runtime behaviour so any compliant runtime can run any compliant image. This standardisation prevents vendor lock-in and guarantees portability across container tooling.

Why this answer

The Open Container Initiative (OCI) is an open governance structure that standardizes container image and runtime specifications. It ensures that any OCI-compliant image can run on any OCI-compliant runtime, promoting interoperability across the container ecosystem. This is the core purpose, not to provide a specific runtime or orchestration tool.

Exam trap

The CNCF exam often tests the distinction between a standard (OCI) and an implementation (Docker, containerd), so candidates mistakenly associate the OCI with Docker or Kubernetes rather than its role as a neutral specification body.

How to eliminate wrong answers

Option A is wrong because Docker is a specific container runtime and toolset, not the purpose of the OCI; the OCI standardizes specifications, not a particular implementation. Option B is wrong because container orchestration platforms like Kubernetes are separate projects; the OCI focuses on low-level image and runtime standards, not orchestration. Option C is wrong because the Kubernetes Container Runtime Interface (CRI) is a Kubernetes-specific plugin interface for runtimes, while the OCI defines the broader industry standard for container formats and runtimes.

Practice this question →
38
MCQhard

You need to run a stateful application that requires stable network identities and persistent storage per pod. Which Kubernetes resource is BEST suited?

A.DaemonSet
B.StatefulSet
C.Job
D.Deployment
AnswerB

StatefulSet assigns each pod a stable ordinal hostname and its own PersistentVolumeClaim, so replicas keep predictable DNS names and storage across restarts. This directly satisfies the stem's requirement for stable network identities and per-pod persistent storage, which a Deployment's interchangeable pods cannot provide.

Why this answer

StatefulSet is the correct choice because it is specifically designed for stateful applications that require stable, unique network identifiers (e.g., pod names like `web-0`, `web-1`) and persistent storage that persists across pod rescheduling. Each pod in a StatefulSet gets a dedicated PersistentVolumeClaim, and the ordinal index ensures consistent identity, which is critical for databases like Cassandra or MySQL.

Exam trap

A common misconception is that Deployment can handle stateful workloads by using PersistentVolumeClaims, but Deployment pods lack stable identities and ordered startup/shutdown, which are essential for many stateful applications.

How to eliminate wrong answers

Option A is wrong because DaemonSet ensures one pod per node for cluster-wide services (e.g., logging agents), but it does not guarantee stable network identities or per-pod persistent storage. Option C is wrong because Job is intended for batch processing tasks that run to completion, not for long-running stateful applications requiring stable storage and identity. Option D is wrong because Deployment provides stateless, interchangeable pods with random names and shared or ephemeral storage, making it unsuitable for applications that require stable network identities and persistent storage per pod.

Practice this question →
39
Multi-Selectmedium

Which two of the following are characteristics of container images built using OCI standards? (Choose two.)

Select 2 answers
A.They are portable across different container runtimes
B.They are composed of layers that can be cached and reused
C.They include a full guest operating system
D.They can only be run by Docker
E.They require a hypervisor to run
AnswersA, B

OCI image specifications define a runtime-agnostic manifest and filesystem bundle, so any compliant runtime (Docker, containerd, CRI-O) can pull and execute the same image. This portability satisfies the stem's requirement by decoupling the artefact from a single vendor's engine.

Why this answer

Option A is correct because OCI (Open Container Initiative) image specifications define a runtime-agnostic format, so an image built to OCI standards can be pulled and executed by any OCI-compliant runtime such as containerd, CRI-O, or Docker, not just one vendor's engine. Option B is correct because OCI images are built as a stack of content-addressable layers, each identified by a digest, which allows runtimes and registries to cache and reuse unchanged layers across builds and pulls, reducing storage and transfer overhead. Option C is incorrect because containers share the host kernel and do not bundle a full guest operating system; that characteristic belongs to virtual machines.

Option D is incorrect because OCI compliance explicitly enables portability beyond Docker to other runtimes like containerd and CRI-O. Option E is incorrect because containers run directly on the host kernel via namespaces and cgroups, requiring no hypervisor (except in specialized VM-isolated setups, which are not the norm for OCI images).

Exam trap

KCNA often tests the misconception that containers are 'lightweight VMs' — candidates pick 'full guest OS' or 'requires hypervisor' because they conflate container isolation with virtualization.

Practice this question →
40
MCQeasy

You are deploying a stateful application that requires each pod to have a stable, unique network identity and its own persistent storage. Which Kubernetes resource should you use?

A.DaemonSet
B.ReplicaSet
C.Deployment
D.StatefulSet
AnswerD

StatefulSet is designed for stateful applications, providing stable, unique network identifiers (like pod-0, pod-1) and stable persistent storage per pod via volumeClaimTemplates. Each pod gets its own PVC, and the pod's hostname and storage are preserved across rescheduling. This makes StatefulSet ideal for databases, message queues, and other stateful workloads that require stable identity and storage.

Why this answer

StatefulSet is the correct resource for stateful applications because it provides stable network identities and persistent storage per pod. Each pod in a StatefulSet gets a unique ordinal index, a stable hostname, and its own PersistentVolumeClaim. Deployments, DaemonSets, and ReplicaSets are designed for stateless workloads and do not offer these guarantees.

Exam trap

The trap here is assuming that a Deployment can provide per-pod persistent storage, but Deployments share a single PVC across all replicas if specified, which is not suitable for stateful applications.

Practice this question →
41
MCQhard

A Kubernetes cluster has two nodes: control-plane and worker. The worker node runs several pods. The control-plane node becomes unreachable. What is the immediate impact on the pods running on the worker node?

A.All pods are immediately terminated
B.Pods continue running, but new pods cannot be scheduled
C.Pods are rescheduled to the control-plane node
D.The worker node is automatically cordoned
AnswerB

Pods keep running because kubelet on the worker node maintains their containers independently of the control-plane; the API server's absence only prevents scheduling decisions, so no new pods can be placed. This satisfies the stem's immediate-impact constraint: existing workloads survive, while scheduling halts until the control-plane returns.

Why this answer

When the control-plane node becomes unreachable, the kube-controller-manager cannot communicate with the kubelet on the worker node, so it stops performing scheduling and reconciliation. However, the kubelet on the worker node continues to run existing pods based on the last known desired state stored locally, and the pods themselves are managed by the container runtime (e.g., containerd) independently of the control-plane. Therefore, pods continue running normally, but no new pods can be scheduled because the scheduler, which runs on the control-plane, is unavailable.

Exam trap

The trap here is that candidates often assume the control-plane is required for all pod operations, confusing the control-plane's role in scheduling and reconciliation with the kubelet's independent ability to maintain running workloads, leading them to choose immediate termination or automatic rescheduling.

How to eliminate wrong answers

Option A is wrong because pods are not immediately terminated; the kubelet on the worker node continues to maintain running pods even without contact with the control-plane, as the pod lifecycle is managed locally. Option C is wrong because pods cannot be rescheduled to the control-plane node; the control-plane node is typically tainted (e.g., node-role.kubernetes.io/control-plane:NoSchedule) to prevent workload pods from running on it, and the scheduler is unavailable to make such decisions. Option D is wrong because the worker node is not automatically cordoned; cordoning is a manual or scheduler-driven action that marks a node as unschedulable, but the control-plane being unreachable does not trigger an automatic cordon of the worker node.

Practice this question →
42
MCQeasy

Which of the following is a key benefit of container orchestration?

A.Manual scaling of applications
B.Requires manual intervention for pod failures
C.Only supports monolithic applications
D.Automated scaling, self-healing, and declarative management
AnswerD

Orchestrators such as Kubernetes continuously reconcile observed state against declared manifests, automatically restarting failed containers and scaling replicas to match load. This declarative control loop delivers self-healing and elastic scaling, which are the defining operational benefits over manually managed containers.

Why this answer

Container orchestration platforms like Kubernetes provide automated scaling (HPA/VPA/cluster autoscaler), self-healing (restarting failed containers, rescheduling pods, replacing unhealthy nodes), and declarative management (desired-state YAML reconciled by controllers). These three capabilities are the defining value proposition that distinguishes orchestration from manually running `docker run` commands.

Exam trap

KCNA often tests the contrast between orchestration's automated, declarative model and manual/imperative alternatives, so distractors describing manual scaling or manual failure recovery are designed to catch candidates who don't internalize the 'automated + declarative' framing.

How to eliminate wrong answers

Option A is wrong because manual scaling is precisely what orchestration eliminates — orchestration automates scaling via metrics-driven controllers, not manual intervention. Option B is wrong because requiring manual intervention for pod failures is the opposite of orchestration's self-healing behavior; controllers like ReplicaSet and Deployment automatically recreate failed pods. Option C is wrong because orchestration platforms are designed for microservices and support diverse workloads (stateless, stateful, batch, DaemonSets), not just monoliths.

Practice this question →
43
MCQeasy

What is the primary purpose of a container orchestration platform like Kubernetes?

A.To provide a lightweight runtime for running a single container
B.To automate the deployment, scaling, and management of containerized applications
C.To manage virtual machines and their hypervisors
D.To compile source code into container images
AnswerB

Kubernetes automates deployment, scaling and management of containerised applications, satisfying the stem's demand for the platform's primary purpose. Its control plane reconciles desired state against actual state, handling scheduling, self-healing and horizontal scaling across nodes — capabilities manual container management cannot provide at scale.

Why this answer

Kubernetes is a container orchestration platform designed to automate the deployment, scaling, and management of containerized applications across clusters of hosts. It handles scheduling, load balancing, self-healing, and rolling updates, which are beyond the scope of a single container runtime.

Exam trap

The exam often tests the distinction between a container runtime (e.g., Docker) and an orchestration platform (e.g., Kubernetes), so candidates mistakenly think orchestration is just about running containers rather than managing them at scale.

How to eliminate wrong answers

Option A is wrong because a lightweight runtime for running a single container is the purpose of a container engine like Docker or containerd, not an orchestration platform. Option C is wrong because managing virtual machines and their hypervisors is the role of a hypervisor or VM orchestration tool like vSphere or OpenStack, not Kubernetes, which abstracts pods over VMs or bare metal. Option D is wrong because compiling source code into container images is the function of a build tool like Docker Build or Kaniko, not a runtime orchestrator like Kubernetes.

Practice this question →
44
Multi-Selectmedium

Which THREE of the following are key benefits of container orchestration? (Choose 3)

Select 3 answers
A.Built-in network isolation between all containers
B.Declarative management using desired state configuration
C.High availability through replication and load balancing
D.Automatic code compilation from source repositories
E.Self-healing capabilities that restart failed containers
AnswersB, C, E

Users define the desired state, and the orchestrator works to achieve and maintain it.

Why this answer

Declarative management using desired state configuration is a core benefit of container orchestration platforms like Kubernetes. Instead of manually issuing commands to start, stop, or scale containers, you define the desired state of your application (e.g., 'run 3 replicas of nginx:1.25') in a YAML or JSON manifest. The orchestrator's control loop continuously reconciles the actual state with this desired state, automatically making changes to achieve and maintain it.

Exam trap

The CNCF exam often tests the distinction between features provided by the container runtime (like network isolation) versus features provided by the orchestrator (like desired state management and self-healing), leading candidates to incorrectly select runtime features as orchestration benefits.

Practice this question →
45
MCQeasy

What is the primary benefit of using containers over virtual machines?

A.Containers provide stronger isolation between applications
B.Containers include a full operating system per instance
C.Containers require a hypervisor to run
D.Containers are lightweight and share the host OS kernel
AnswerD

Containers share the host operating system kernel, so each container packages only the application and its dependencies rather than a full guest OS. This removes hypervisor and duplicate-kernel overhead, making containers lighter and faster to start than virtual machines.

Why this answer

Containers are lightweight because they share the host OS kernel, avoiding the overhead of a separate guest OS per instance. Unlike VMs, which require a hypervisor and a full OS for each virtual machine, containers run as isolated processes on the same kernel, enabling faster startup times and higher density. This shared-kernel model is the primary benefit, as it reduces resource consumption and improves efficiency in orchestrated environments like Kubernetes.

Exam trap

The trap here is that candidates confuse 'isolation' with 'security' and assume containers are more secure because they are lightweight, but the primary benefit is resource efficiency, not stronger isolation—VMs actually provide better isolation via hardware virtualization.

How to eliminate wrong answers

Option A is wrong because containers provide weaker isolation than virtual machines, as they share the host kernel and rely on namespaces and cgroups for process-level separation, whereas VMs use hardware-level virtualization with a hypervisor for stronger isolation. Option B is wrong because containers do not include a full operating system per instance; they package only the application and its dependencies, while the OS kernel is shared from the host. Option C is wrong because containers do not require a hypervisor to run; they run directly on the host OS using the kernel's container runtime (e.g., runc), whereas VMs require a hypervisor (e.g., KVM, VMware) to virtualize hardware.

Practice this question →
46
MCQeasy

What is the primary difference between a container and a virtual machine (VM)?

A.Containers are slower to start than VMs
B.Containers require a hypervisor to run
C.Containers share the host OS kernel, whereas VMs each have their own guest OS
D.Containers virtualize hardware, while VMs virtualize the operating system
AnswerC

Containers share the host OS kernel, so each container image excludes a kernel and starts in seconds with minimal overhead. VMs run a full guest OS per instance on the hypervisor, consuming far more memory and disk. This kernel-sharing boundary is the defining architectural difference the question asks for.

Why this answer

The primary difference is that containers share the host operating system kernel, while each virtual machine runs its own complete guest OS. This means containers are lightweight processes with isolated user spaces, whereas VMs include a full OS stack (kernel, drivers, libraries) per instance. This architectural distinction is why containers start in seconds and have minimal overhead, while VMs require booting a guest OS and consume more resources.

Exam trap

Commonly tested misconception: candidates often think containers are 'lightweight VMs' or that they virtualize hardware, when in fact containers share the host kernel and use OS-level virtualization, which is a fundamentally different isolation model.

How to eliminate wrong answers

Option A is wrong because containers are faster to start than VMs — containers start in milliseconds as they are just processes on the host kernel, whereas VMs require booting a full guest OS, which takes seconds to minutes. Option B is wrong because containers do not require a hypervisor; they run directly on the host OS using kernel features like cgroups and namespaces, while VMs require a hypervisor (Type 1 or Type 2) to virtualize hardware. Option D is wrong because it reverses the concepts: containers virtualize the operating system (via OS-level virtualization), while VMs virtualize hardware (via hypervisor and guest OS).

Practice this question →
47
Multi-Selectmedium

Which THREE are benefits of using a container orchestration platform? (Select 3)

Select 3 answers
A.Guarantees zero downtime during deployments
B.Declarative configuration management
C.Automated scaling based on demand
D.Eliminates the need for cloud infrastructure
E.High availability through automatic failover
AnswersB, C, E

Declarative configuration management lets you define the desired state of workloads in manifests, and the orchestrator continuously reconciles actual state to match it. This satisfies the stem's benefit requirement by automating scheduling, self-healing and scaling without manual intervention, ensuring consistent, reproducible deployments across the cluster.

Why this answer

Option B is correct because container orchestration platforms such as Kubernetes use declarative configuration management, where you define the desired state in manifests (YAML) and the control plane continuously reconciles actual state to match it. Option C is correct because orchestration platforms provide automated scaling based on demand, for example Kubernetes Horizontal Pod Autoscaler adjusts replica counts using metrics like CPU utilization. Option E is correct because orchestration platforms deliver high availability through automatic failover, rescheduling pods onto healthy nodes when a node or container fails, and supporting self-healing and rolling updates.

Option A is not correct because zero downtime is not guaranteed; it depends on proper configuration such as readiness probes, rolling update strategy, and sufficient capacity, so downtime can still occur. Option D is not correct because orchestration platforms run on infrastructure, including cloud or on-premises resources, and do not eliminate the need for cloud infrastructure.

Exam trap

The trap is the absolute language in option A ('guarantees zero downtime') — exam writers include absolute claims as distractors because orchestration reduces downtime but cannot guarantee its complete elimination without application-level cooperation.

Practice this question →
48
Multi-Selecteasy

Which TWO are benefits of using a container orchestration platform like Kubernetes? (Select TWO.)

Select 2 answers
A.Increases application complexity
B.Requires a dedicated hypervisor for each container
C.Automatic service discovery and load balancing
D.Self-healing (automatic restart of failed containers)
E.Manual scaling of applications
AnswersC, D

Kubernetes assigns each Service a stable virtual IP and DNS name, then distributes traffic across matching healthy pods automatically. This removes the need for applications to track individual pod addresses, satisfying the requirement for built-in service discovery and load balancing.

Why this answer

Option C is correct because Kubernetes provides built-in service discovery through Services and DNS (CoreDNS), automatically routing traffic to healthy Pods and distributing load across replicas via kube-proxy, eliminating manual endpoint configuration. Option D is correct because Kubernetes controllers such as the ReplicaSet and kubelet continuously reconcile desired state, automatically restarting or rescheduling failed containers to maintain the declared replica count. Option A is incorrect because orchestration platforms are designed to reduce operational complexity by abstracting infrastructure management, not increase application complexity.

Option B is incorrect because Kubernetes runs containers via a container runtime (containerd, CRI-O) on shared nodes; it does not require a dedicated hypervisor per container. Option E is incorrect because Kubernetes supports automatic horizontal scaling through the Horizontal Pod Autoscaler (HPA) based on CPU, memory, or custom metrics, rather than requiring manual scaling.

Exam trap

CNCF often tests the distinction between manual and automatic scaling; candidates may incorrectly select manual scaling as a benefit because they confuse it with the ability to scale, but the question asks for benefits of using the platform, which include automation, not manual effort.

Practice this question →
49
MCQhard

A cluster runs the Horizontal Pod Autoscaler (HPA) v2 for a Deployment named queue-worker. The HPA is configured with minReplicas: 2, maxReplicas: 10, and a target average CPU utilization of 60%. Metrics Server is installed and reports CPU for the Pods. During a burst, CPU utilization rises to 95% and stays there, but the Deployment remains at 2 replicas. Which condition most likely explains why the HPA is not scaling out?

A.The Deployment's Pod template does not set CPU requests, so the HPA cannot compute utilization.
B.The HPA needs a PodDisruptionBudget before it can scale the Deployment.
C.The HPA's maxReplicas of 10 is lower than the current node capacity, so it refuses to scale.
D.Metrics Server only reports node metrics, so the HPA must use custom metrics instead.
AnswerA

HPA calculates CPU utilization as a percentage of the requested CPU, not the limit or node capacity. If the container spec omits resources.requests.cpu, the HPA cannot derive a utilization percentage and reports unknown metrics, so it will not scale even when actual usage is high. Setting CPU requests on the Pod template is required for CPU-based autoscaling to function.

Why this answer

The HPA computes CPU utilization against the container's CPU request. Without resources.requests.cpu in the Pod template, the utilization metric is unavailable and the HPA cannot decide to scale, so replicas remain at the minimum even during sustained high CPU. PodDisruptionBudgets, Metrics Server scope, and maxReplicas are not the cause in this scenario.

Exam trap

The trap here is assuming the HPA scales on raw CPU usage, when it actually scales on CPU utilization relative to the container's CPU request.

Practice this question →
50
Multi-Selecthard

Which three of the following are benefits of container orchestration? (Choose three.)

Select 3 answers
A.High availability through replication
B.Scaling services up or down
C.Manual deployment of containers to specific hosts
D.Self-healing by restarting failed containers
E.Bare metal performance
AnswersA, B, D

Replication controllers and ReplicaSets maintain the desired pod count across nodes, automatically rescheduling workloads when a node fails. This directly delivers the high availability the stem asks for, since orchestration continuously reconciles observed state against declared state rather than relying on manual intervention or a single host staying healthy.

Why this answer

Container orchestration platforms such as Kubernetes and Docker Swarm provide high availability through replication (A) by running multiple identical instances of a service across nodes, so the failure of one replica or node does not take the service down. They also enable scaling services up or down (B) declaratively, adjusting the number of replicas to match demand via controllers like Deployments or ReplicaSets. Self-healing by restarting failed containers (D) is a core orchestration capability: the orchestrator monitors container and node health and automatically reschedules or restarts containers that crash or become unresponsive.

Option C is incorrect because orchestration automates scheduling and placement of containers rather than requiring manual deployment to specific hosts, which is the opposite of its benefit. Option E is incorrect because bare metal performance is a characteristic of running directly on hardware, not a benefit provided by orchestration, which typically adds an abstraction layer.

Exam trap

KCNA often tests the distinction between orchestration benefits and container runtime or infrastructure features, so candidates might mistakenly select 'bare metal performance' as a benefit when it is actually a property of the underlying hardware, not orchestration.

Practice this question →
51
Multi-Selecthard

Which THREE of the following are benefits of using container orchestration? (Choose three.)

Select 3 answers
A.High availability through automated failover
B.Decomposition of applications into microservices
C.Simplified networking with flat network topology
D.Self-healing by restarting failed containers
E.Automatic scaling of applications based on demand
AnswersA, D, E

Automated failover satisfies the high-availability constraint: when a node or pod fails, the orchestrator reschedules workloads onto healthy nodes without manual intervention. Controllers continuously reconcile observed state against declared desired state, so replicas are restored automatically, keeping services reachable despite individual component failures.

Why this answer

Option A is correct because container orchestration platforms such as Kubernetes continuously monitor node and pod health and automatically reschedule or failover workloads to healthy nodes, providing high availability without manual intervention. Option D is correct because orchestrators implement self-healing by detecting failed or unhealthy containers (for example, via liveness probes in Kubernetes) and automatically restarting or replacing them to maintain the desired state. Option E is correct because orchestrators support automatic scaling of applications based on demand, such as Kubernetes Horizontal Pod Autoscaler adjusting replica counts according to CPU utilization or custom metrics.

Option B is not a benefit of orchestration itself; decomposing applications into microservices is an architectural design choice that can be deployed on orchestration but is not provided by it. Option C is also not a benefit of orchestration; simplified flat networking is a characteristic of some container network plugins (like flannel or Calico overlay networks), not an inherent benefit of the orchestration layer.

Exam trap

CNCF often tests the distinction between architectural patterns (like microservices) and operational benefits of orchestration, so candidates mistakenly select decomposition as a direct benefit when it is actually a design choice that orchestration supports.

Practice this question →
52
MCQeasy

A developer needs to run a one-off batch job that processes a dataset and then terminates. The job should run to completion and not restart after successful completion. Which Kubernetes resource is most appropriate for this task?

A.DaemonSet
B.StatefulSet
C.Deployment
D.Job
AnswerD

A Job creates one or more pods and ensures they successfully complete. It is ideal for batch processing, as it tracks successful completions and does not restart pods after success. The Job controller terminates the pod once the task finishes, matching the requirement for a one-off job.

Why this answer

A Job is the correct resource for batch workloads that run to completion. It ensures the specified number of successful pod completions and then stops, making it ideal for one-off tasks. Other controllers like Deployments or StatefulSets are intended for continuous operation and would not terminate after the task finishes.

Exam trap

The trap here is assuming that any workload controller can run a batch job, when only Job (or CronJob) is designed for run-to-completion tasks.

Practice this question →
53
MCQeasy

Based on the exhibit, why is the pod web-pod not running?

A.A network policy is blocking the image pull.
B.The container image is not available in the registry.
C.The node does not have enough memory.
D.The pod was not scheduled onto a node.
AnswerB

Kubernetes reports ImagePullBackOff or ErrImagePull when the kubelet cannot fetch the specified image, meaning the tag is absent or the registry credentials are wrong. That condition, not scheduling or resource pressure, explains why web-pod is not running.

Why this answer

The pod's status indicates an ImagePullBackOff error, which occurs when the kubelet fails to pull the specified container image from the registry. This typically means the image name or tag is incorrect, the registry is unreachable, or the image does not exist in the registry. The exhibit shows the pod is stuck in a waiting state with the reason 'ErrImagePull' or 'ImagePullBackOff', directly pointing to a missing or inaccessible image.

Exam trap

The KCNA exam often tests the distinction between pod scheduling failures (e.g., resource constraints, taints/tolerations) and container runtime failures (e.g., image pull errors), so candidates may confuse a 'Pending' pod with an 'ImagePullBackOff' pod, both of which are not running but have different root causes.

How to eliminate wrong answers

Option A is wrong because network policies in Kubernetes control traffic between pods, not image pull operations; image pulls are handled by the container runtime (e.g., containerd, CRI-O) and are subject to registry authentication and network connectivity, not NetworkPolicy objects. Option C is wrong because a memory shortage on the node would manifest as an OOMKilled or Pod eviction, not an ImagePullBackOff error; the exhibit shows no resource pressure events. Option D is wrong because the pod has been scheduled onto a node (as indicated by the pod status showing a node name), but the container fails to start due to the image pull issue; unscheduled pods would show a 'Pending' status with no node assigned.

Practice this question →
54
MCQmedium

A container image built using a Dockerfile with multiple layers is stored in a registry. When a node pulls this image, which statement about layers is true?

A.Layers that are already cached on the node are reused and only new layers are downloaded
B.Layers are merged into a single layer before download
C.All layers must be downloaded each time the image is pulled
D.Only the topmost layer is downloaded; lower layers are streamed from the registry
AnswerA

Cached layers are content-addressed by digest, so the node verifies each layer locally and fetches only digests absent from its local store. This satisfies the stem's constraint: a multi-layer image pull avoids re-downloading unchanged layers, transferring just the new layers.

Why this answer

Container images are composed of read-only layers, each representing a set of filesystem changes. When a node pulls an image, the container runtime (e.g., containerd or CRI-O) checks its local layer cache against the manifest's layer digests (SHA256 hashes). Layers already present locally are reused, and only missing layers are downloaded from the registry, which optimizes bandwidth and storage.

Exam trap

The KCNA exam often tests the misconception that layers are merged or streamed, but the correct behavior is that each layer is a separate, immutable blob that is cached independently and reused across images.

How to eliminate wrong answers

Option B is wrong because layers are never merged into a single layer before download; they remain separate and are stored as individual blobs in the registry and on the node, enabling layer sharing across images. Option C is wrong because the container runtime uses the layer cache to avoid re-downloading unchanged layers; only layers not already cached are downloaded. Option D is wrong because all layers must be fully downloaded and stored locally before the image can be used; the runtime does not stream layers on demand from the registry.

Practice this question →
55
MCQeasy

What is the purpose of a readiness probe in a Kubernetes pod?

A.To determine if the pod should be terminated
B.To check if the pod is alive and restart it if not
C.To measure CPU usage of the container
D.To signal that the pod is ready to accept traffic
AnswerD

A readiness probe determines whether a container is prepared to serve requests, controlling whether the pod's IP is included in Service endpoints. Failing probes remove the pod from load balancing without restarting it, satisfying the requirement to signal traffic acceptance rather than container liveness or startup completion.

Why this answer

A readiness probe in Kubernetes determines whether a container inside a pod is ready to start accepting traffic. If the probe fails, the pod is removed from the Service's endpoints, ensuring that only healthy pods receive requests. This is distinct from liveness probes, which check if the container is alive and should be restarted.

Exam trap

The trap here is that candidates often confuse readiness probes with liveness probes, mistakenly thinking both are used for restarting unhealthy containers, when in fact readiness probes only control traffic routing and do not trigger restarts.

How to eliminate wrong answers

Option A is wrong because readiness probes do not determine pod termination; that is the role of the liveness probe or the pod's terminationGracePeriodSeconds. Option B is wrong because checking if the pod is alive and restarting it is the purpose of a liveness probe, not a readiness probe. Option C is wrong because measuring CPU usage is done via metrics servers or resource monitoring tools like Prometheus, not through probes.

Practice this question →
56
MCQmedium

Which Kubernetes resource should be used to run a one-time task that performs a computation and then exits?

A.DaemonSet
B.StatefulSet
C.Job
D.Deployment
AnswerC

A Job creates one or more pods that run to completion, then stops restarting them once the task succeeds. This directly satisfies the stem's requirement for a one-time computation that exits, unlike a Deployment, which maintains a continuous desired replica count for long-running services.

Why this answer

A Kubernetes Job is designed specifically for finite, one-time tasks that run to completion and then exit. Unlike controllers that maintain a desired number of continuously running Pods, a Job creates one or more Pods and tracks their successful termination, making it the correct choice for a computation that should run once and stop.

Exam trap

The trap here is that candidates confuse a Job with a Deployment because both can run containers, but a Deployment is designed for long-running services, not for tasks that should terminate after completion.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on every (or selected) Node in the cluster, intended for long-running background services like log collectors or monitoring agents, not for one-time tasks. Option B is wrong because a StatefulSet manages stateful applications with stable, unique network identities and persistent storage, designed for workloads like databases that require ordered deployment and scaling, not ephemeral computations. Option D is wrong because a Deployment manages a ReplicaSet to maintain a desired number of continuously running Pods, supporting rolling updates and self-healing, which is unnecessary overhead for a task that should exit after completion.

Practice this question →
57
Multi-Selecthard

A developer is troubleshooting a Pod that is stuck in Pending state. The node has sufficient CPU and memory, and the scheduler logs show no errors. Which two factors could prevent the Pod from being scheduled? (Choose two.)

Select 2 answers
A.A taint on all nodes that the Pod does not tolerate
B.The Pod's container image has a latest tag
C.The Pod's ServiceAccount is missing
D.A nodeSelector that does not match any node's labels
E.The Pod has no resource requests defined
AnswersA, D

Taints repel Pods unless the Pod has a matching toleration. If every node is tainted and the Pod lacks the toleration, the scheduler will not place it, resulting in Pending. This is independent of resource availability. Taints and tolerations are a frequent cause of unschedulable Pods in multi-tenant clusters.

Why this answer

Node selectors and taints both restrict which nodes can run a Pod. A nodeSelector that matches no node or a taint that the Pod does not tolerate will leave the Pod unschedulable, resulting in Pending. Image tags, missing resource requests, and ServiceAccount issues affect other stages or have different symptoms, so they are not correct.

Exam trap

The trap here is assuming any Pod configuration error causes Pending, when Pending specifically indicates the scheduler cannot place the Pod.

Practice this question →
58
MCQmedium

A developer wants to deploy a stateless web application that should scale to 5 replicas. Each replica must be identical and should be automatically replaced if it fails. Which Kubernetes resource should be used?

A.StatefulSet
B.DaemonSet
C.Deployment
D.ReplicationController
AnswerC

Deployment manages stateless pods through ReplicaSet, maintaining exactly five identical replicas and automatically replacing failed pods to satisfy the self-healing and scaling constraints. Its rolling update strategy suits stateless workloads, unlike StatefulSet's stable identities or DaemonSet's per-node scheduling.

Why this answer

A Deployment is the correct resource because it manages a ReplicaSet to ensure the desired number of identical, stateless pod replicas (5) are running. It provides declarative updates, self-healing (automatic replacement of failed pods), and scaling capabilities, which directly match the requirement for a stateless web application.

Exam trap

The trap here is that candidates often confuse StatefulSet with Deployment for stateless apps because both can manage multiple replicas, but StatefulSet is specifically for stateful workloads requiring ordered deployment and stable identities, not for identical, interchangeable replicas.

How to eliminate wrong answers

Option A is wrong because StatefulSet is designed for stateful applications that require stable, unique network identities and persistent storage, not for stateless web apps where replicas are identical and can be replaced arbitrarily. Option B is wrong because DaemonSet ensures that a copy of a pod runs on every (or selected) node in the cluster, which is used for cluster-level services like logging or monitoring, not for scaling a stateless web app to a specific replica count. Option D is wrong because ReplicationController is the older, deprecated predecessor of Deployment; it can maintain a desired number of pod replicas but lacks advanced features like rolling updates, declarative management, and is not the recommended resource for modern Kubernetes deployments.

Practice this question →
59
MCQeasy

Which Kubernetes resource is used to run a batch job that runs to completion?

A.DaemonSet
B.StatefulSet
C.Job
D.Deployment
AnswerC

A Job creates pods that run until successful completion, tracking completions and retrying failures. Unlike a Deployment, which maintains a continuously running replica set, a Job suits finite batch workloads that must terminate once their task finishes.

Why this answer

A Kubernetes Job is specifically designed to run a finite task to completion, creating one or more Pods and ensuring they successfully terminate. Unlike controllers that maintain a desired state of running Pods, a Job tracks the number of successful completions and stops when the specified parallelism or completions count is reached.

Exam trap

The trap here is that candidates confuse a Job with a Deployment because both can run Pods, but a Deployment is designed for long-running services with continuous availability, while a Job is the only controller that tracks and terminates upon successful completion.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, intended for long-running services like log collectors or monitoring agents, not for batch jobs that run to completion. Option B is wrong because a StatefulSet manages stateful applications with unique network identities and persistent storage, designed for workloads like databases that require stable identities and ordered deployment, not for ephemeral batch tasks. Option D is wrong because a Deployment manages ReplicaSets to provide declarative updates for stateless applications that should run continuously, ensuring a specified number of replicas are always running, which is the opposite of a job that terminates upon completion.

Practice this question →
60
MCQmedium

An administrator must run a privileged DaemonSet on every node, including the control-plane node, to collect host logs. The control-plane node has a taint node-role.kubernetes.io/control-plane:NoSchedule. Which change allows the DaemonSet Pods to be scheduled on the control-plane node while keeping the taint intact?

A.Remove the taint from the control-plane node with kubectl taint nodes --all node-role.kubernetes.io/control-plane-.
B.Set spec.template.spec.nodeName to the control-plane node name in the DaemonSet.
C.Add a toleration for key node-role.kubernetes.io/control-plane with operator Exists and effect NoSchedule to the DaemonSet Pod template.
D.Add a nodeSelector for node-role.kubernetes.io/control-plane to the DaemonSet Pod template.
AnswerC

Tolerations allow Pods to be scheduled onto nodes with matching taints without removing the taint. Using operator Exists with effect NoSchedule tolerates the control-plane taint regardless of its value, so the DaemonSet can place a Pod on that node. The taint remains, preserving the default scheduling restriction for other workloads.

Why this answer

Taints repel Pods unless the Pod declares a matching toleration. Adding a toleration with operator Exists and effect NoSchedule for the control-plane taint lets the DaemonSet schedule there while leaving the taint in place, so other workloads remain excluded. Removing the taint, pinning with nodeName, or using a nodeSelector does not meet the requirement of keeping the taint intact.

Exam trap

The trap here is confusing nodeSelector or node labels with tolerations, when only a toleration overrides a NoSchedule taint without removing it.

Practice this question →
61
MCQmedium

A DevOps engineer wants to deploy a stateful application that requires stable network identities and persistent storage. Which Kubernetes resource is most appropriate?

A.DaemonSet
B.StatefulSet
C.Deployment
D.ReplicaSet
AnswerB

StatefulSet gives each pod a stable, ordinal hostname and its own PersistentVolumeClaim, so replicas keep predictable network identities and storage across restarts and rescheduling. Deployments provide neither guarantee, making them unsuitable for the stable identity and persistence this stateful workload requires.

Why this answer

StatefulSet is the correct choice because it is designed specifically for stateful applications that require stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage (via PersistentVolumeClaims that persist across Pod rescheduling). Unlike Deployments, StatefulSet guarantees ordered, graceful deployment and scaling, which is essential for applications like databases or distributed systems that rely on stable identities.

Exam trap

The trap here is that candidates confuse StatefulSet with Deployment, assuming Deployments can handle stateful workloads by adding persistent volumes, but they overlook the critical need for stable network identities and ordered Pod management that only StatefulSet provides.

How to eliminate wrong answers

Option A (DaemonSet) is wrong because it ensures one Pod per Node for daemon-like workloads (e.g., logging agents, monitoring) and does not provide stable network identities or per-Pod persistent storage. Option C (Deployment) is wrong because it is designed for stateless applications; Pods are interchangeable and get random hostnames, and PersistentVolumeClaims are shared or recreated, breaking identity and storage persistence. Option D (ReplicaSet) is wrong because it is a lower-level resource that only maintains a desired replica count without any guarantees for stable identities, ordered operations, or persistent storage binding.

Practice this question →
62
Multi-Selecthard

Which THREE of the following are true about the Open Container Initiative (OCI)? (Select 3)

Select 3 answers
A.OCI is governed solely by Docker Inc.
B.OCI only applies to Linux containers
C.OCI defines the container image format specification
D.OCI standards are vendor-neutral
E.OCI defines a standard for container runtime execution
AnswersC, D, E

OCI publishes the image-spec, which standardises how container images are built and laid out, including manifests, configuration and layer content. This directly satisfies the stem's requirement by defining the container image format specification, enabling any compliant runtime or registry to consume the same image.

Why this answer

Option C is correct because the Open Container Initiative publishes the OCI Image Format Specification, which standardizes how container images (manifest, config, and layer filesystem changesets) are structured so any compliant tool can build, pull, and run them. Option D is correct because OCI is a vendor-neutral, open governance project hosted under the Linux Foundation, with contributions from many companies rather than a single vendor, ensuring interoperability across ecosystems. Option E is correct because OCI also defines the Runtime Specification, which describes how a container runtime executes a filesystem bundle (covering lifecycle operations such as create, start, and kill) and is implemented by runtimes like runc.

Option A is wrong because OCI is not governed solely by Docker Inc.; it operates under the Linux Foundation with broad industry participation. Option B is wrong because OCI specifications are platform-agnostic and also apply to Windows containers, not only Linux containers.

Exam trap

CNCF often tests the misconception that OCI is Docker-specific or Linux-only, when in fact it is a vendor-neutral, cross-platform standard governed by the Linux Foundation.

Practice this question →
63
Multi-Selectmedium

Which TWO of the following are benefits of using a container orchestration platform like Kubernetes? (Choose two.)

Select 2 answers
A.Inability to manage container networking
B.Requirement to run applications on a single node
C.Self-healing by restarting failed containers
D.Manual rollback of application versions
E.Automated scaling of applications based on demand
AnswersC, E

Kubernetes continuously reconciles desired state against actual state via controllers such as the ReplicaSet, automatically recreating or restarting containers that fail liveness probes or crash. This removes manual intervention, directly delivering the self-healing benefit the question asks for.

Why this answer

Option C is correct because Kubernetes continuously reconciles desired state with actual state via controllers such as ReplicaSet and kubelet, so when a container or Pod fails, it is automatically restarted or rescheduled to maintain the declared replica count. Option E is correct because Kubernetes provides the Horizontal Pod Autoscaler (HPA), which scales the number of Pod replicas automatically based on metrics like CPU utilization or custom metrics, enabling demand-based scaling. Option A is incorrect because Kubernetes actually provides robust container networking through the Container Network Interface (CNI), Services, and Ingress, rather than lacking it.

Option B is incorrect because Kubernetes is a distributed system designed to schedule workloads across a cluster of multiple nodes, not to confine applications to a single node. Option D is incorrect because Kubernetes supports automated rollouts and rollbacks via Deployments (for example, kubectl rollout undo), so rollback is not inherently manual.

Exam trap

KCNA often tests candidate understanding of what Kubernetes actually provides versus common misconceptions, and the trap is picking plausible-sounding but inverted statements (like 'inability to manage networking') or confusing manual operations with the automated capabilities Kubernetes delivers.

Practice this question →
64
Multi-Selectmedium

Which TWO of the following are required fields when defining a container in a Kubernetes Pod spec? (Choose 2)

Select 2 answers
A.env
B.image
C.name
D.resources
E.ports
AnswersB, C

The `image` field is mandatory because the kubelet needs a container image reference to pull and instantiate the container's filesystem and process. Without it, the Pod spec fails validation, satisfying the stem's requirement for a required field alongside `name`.

Why this answer

In a Kubernetes Pod spec, the `name` and `image` fields are mandatory for each container definition. The `name` field uniquely identifies the container within the Pod, and the `image` field specifies the container image to run (e.g., `nginx:1.25`). Without these two fields, the Pod creation will fail with a validation error from the Kubernetes API server.

Exam trap

CNCF often tests the misconception that `ports` or `resources` are required because they appear in most example Pod specs, but the KCNA exam expects you to know that only `name` and `image` are mandatory per the Kubernetes API specification.

Practice this question →
65
Multi-Selecthard

Which TWO are characteristics of the microservices architecture that are supported by container orchestration?

Select 2 answers
A.Tight coupling between services to ensure performance
B.Independent deployment of each service
C.Decomposition of an application into small, independent services
D.Monolithic codebase with centralized deployment
E.Use of a single, shared database for all services
AnswersB, C

Container orchestration lets each microservice be built, versioned and released on its own schedule, so teams deploy independently without coordinating a monolithic release. This satisfies the stem's requirement by matching the architectural trait of decoupled, autonomous service delivery.

Why this answer

Option B is correct because container orchestration platforms such as Kubernetes let each microservice be built, versioned, and rolled out on its own schedule, so a change to one service does not force redeployment of the others. Option C is correct because microservices architecture decomposes an application into small, independently runnable services, and orchestration supports this by scheduling, scaling, and networking each service as a separate workload. Options A, D, and E are not characteristics of microservices supported by orchestration: tight coupling, a monolithic codebase with centralized deployment, and a single shared database all describe monolithic or tightly integrated designs that contradict the independence and loose coupling that orchestration enables.

Exam trap

A common misconception tested in the KCNA exam is that microservices require a shared database or tight coupling for performance, but the correct answer emphasizes independent deployment and decomposition, which are the defining characteristics supported by container orchestration.

Practice this question →
66
MCQeasy

Which of the following is a key principle of microservices architecture?

A.Shared database schema for all services
B.Tight coupling between services
C.Loose coupling and independent deployability
D.Building a large, monolithic codebase
AnswerC

Loose coupling lets each microservice evolve, scale and be deployed without coordinated releases of other services, since communication occurs through well-defined APIs rather than shared internal state. Independent deployability is the operational outcome that enables frequent, low-risk releases.

Why this answer

Microservices architecture emphasizes breaking an application into small, independently deployable services that communicate over well-defined APIs. The correct answer is C: Loose coupling and independent deployability are key principles. Option A (shared database) contradicts the principle of service autonomy.

Option B (tight coupling) is the opposite of what microservices aim for. Option D (monolithic codebase) is what microservices avoid.

Practice this question →
67
MCQmedium

A pod is stuck in the 'Pending' state. You run 'kubectl describe pod mypod' and see the event: '0/3 nodes are available: 1 node had taint that the pod didn't tolerate, 2 Insufficient cpu.' What is the most likely cause?

A.The pod's liveness probe is failing
B.The pod's resource requests exceed available node capacity and a node taint is not tolerated
C.The pod's container runtime is not installed
D.The pod's image pull secret is missing
AnswerB

The scheduler events show two independent blockers: insufficient CPU on two nodes and an untolerated taint on the third. The pod's resource requests exceed schedulable capacity, and no node both satisfies those requests and tolerates the taint.

Why this answer

The pod is in 'Pending' state because the scheduler cannot find a node that meets its requirements. The event '0/3 nodes are available: 1 node had taint that the pod didn't tolerate, 2 Insufficient cpu' directly indicates that the pod's resource requests exceed the available CPU on two nodes, and the remaining node has a taint that the pod does not tolerate. This matches option B: the pod's resource requests exceed available node capacity and a node taint is not tolerated.

Exam trap

The trap here is that candidates may confuse 'Pending' state with post-scheduling issues like probe failures or image pull errors, but the event message explicitly points to scheduling failures (resource insufficiency and taint intolerance), which are the only reasons a pod remains unscheduled.

How to eliminate wrong answers

Option A is wrong because a failing liveness probe would cause the pod to be restarted or marked as 'CrashLoopBackOff', not stuck in 'Pending' — liveness probes only run after the pod is scheduled and started. Option C is wrong because if the container runtime were not installed, the kubelet would report a 'ContainerRuntimeNotReady' condition, and the pod would not even be considered for scheduling; the scheduler would not produce 'Insufficient cpu' events. Option D is wrong because a missing image pull secret would cause an 'ImagePullBackOff' or 'ErrImagePull' error after the pod is scheduled, not a 'Pending' state with resource-related scheduling failures.

Practice this question →
68
Multi-Selectmedium

Which TWO statements about containers are true compared to virtual machines? (Select TWO.)

Select 2 answers
A.Containers are more lightweight and start faster than VMs
B.Containers include a full guest operating system
C.Containers are more portable across different environments
D.Containers provide stronger isolation than VMs
E.Containers require a hypervisor to run
AnswersA, C

Because they share the host kernel and do not need to boot an OS, containers are lightweight and start quickly.

Why this answer

Containers share the host OS kernel and run as isolated processes, requiring no hypervisor or full OS boot. This makes them lightweight (megabytes vs gigabytes) and allows them to start in milliseconds, whereas VMs must boot a full guest OS, which takes seconds to minutes.

Exam trap

A common pitfall in CNCF exams is believing containers provide stronger isolation than VMs, but VMs offer hardware-level isolation via a hypervisor, while containers rely on kernel-level isolation which is inherently weaker.

Practice this question →
69
MCQmedium

Which command would you run to get a list of all pods in all namespaces?

A.kubectl get pods --namespace=*
B.kubectl get pods --global
C.kubectl get pods --all-namespaces
D.kubectl get pods --include-uninitialized
AnswerC

The --all-namespaces flag instructs kubectl to query every namespace in the cluster, returning pods across all of them in one output, which directly satisfies the requirement to list pods cluster-wide rather than only the current namespace.

Why this answer

`kubectl get pods --all-namespaces` (or its shorthand `-A`) retrieves pods from every namespace in the cluster. This flag overrides the default behavior of `kubectl get pods`, which only returns pods in the current namespace (usually `default`).

Exam trap

CNCF often tests the misconception that a wildcard or global flag exists for namespace selection, leading candidates to choose `--namespace=*` or `--global` instead of the correct `--all-namespaces` flag.

How to eliminate wrong answers

Option A is wrong because `--namespace=*` is not a valid kubectl syntax; the asterisk wildcard is not supported for namespace selection, and kubectl will return an error. Option B is wrong because `--global` is not a valid kubectl flag; it does not exist and would cause a parsing error. Option D is wrong because `--include-uninitialized` is a deprecated flag that was used in older Kubernetes versions to include pods that had not yet been fully initialized, but it does not affect namespace scope and is no longer supported in recent releases.

Practice this question →
70
Multi-Selecthard

Which THREE of the following are key characteristics of microservices architecture?

Select 3 answers
A.Independent deployment of services
B.Decomposition by business capability
C.Single monolithic codebase
D.Shared database schema across services
E.Loose coupling between services
AnswersA, B, E

Each microservice can be deployed independently.

Why this answer

Microservices architecture mandates that each service can be independently deployed, updated, and scaled without affecting other services. This is achieved through separate deployment pipelines, containerization (e.g., Docker), and orchestration platforms like Kubernetes that manage service lifecycles independently. Independent deployment enables continuous delivery and reduces the blast radius of changes.

Exam trap

A common misconception is that microservices can share a single database or persistent volume in Kubernetes for simplicity. However, each service should own its data to maintain loose coupling and independent deployability within a Kubernetes cluster.

Practice this question →
71
MCQhard

You need to deploy an application that requires exactly one pod per cluster node for logging purposes. Which Kubernetes workload resource should you use?

A.DaemonSet
B.Job
C.StatefulSet
D.Deployment
AnswerA

A DaemonSet ensures exactly one pod replica runs on every cluster node, satisfying the one-pod-per-node logging constraint. Unlike Deployments, which schedule arbitrary replica counts, DaemonSets automatically add pods to new nodes and remove them when nodes leave the cluster.

Why this answer

A DaemonSet ensures that a copy of a pod runs on every node in the cluster, or on a subset of nodes if a node selector is used. This is the correct resource for deploying a logging agent that must be present on each node to collect logs from that node's containers and system components.

Exam trap

The trap here is that candidates often confuse DaemonSet with Deployment, assuming a Deployment with replicas equal to the node count will achieve the same effect, but Deployments do not guarantee one pod per node and can schedule multiple pods on the same node or leave nodes empty.

How to eliminate wrong answers

Option B (Job) is wrong because a Job creates one or more pods that run to completion and then stop, which is unsuitable for a continuously running logging daemon that must persist on every node. Option C (StatefulSet) is wrong because StatefulSet is designed for stateful applications that require stable, unique network identities and persistent storage, not for ensuring one pod per node. Option D (Deployment) is wrong because a Deployment manages replicas across the cluster without guaranteeing that a pod runs on every node; it uses a scheduler to distribute pods based on resource availability, not node coverage.

Practice this question →
72
MCQmedium

You need to ensure that a set of pods in a Deployment can be reached by other pods using a stable IP address and DNS name. Which Kubernetes object should you use?

A.Service
B.NetworkPolicy
C.Ingress
D.ConfigMap
AnswerA

A Service provides a stable virtual IP address and DNS name that load-balances traffic across the Deployment's pods, satisfying the reachability requirement. Pod IPs are ephemeral, so clients must target the Service rather than individual pod addresses.

Why this answer

A Service provides a stable IP address and DNS name for a set of pods, abstracting the underlying pod IPs that can change due to scaling or failures. By default, a Service uses a cluster-internal virtual IP and DNS record (e.g., <service-name>.<namespace>.svc.cluster.local) that other pods can resolve, ensuring reliable connectivity without needing to track individual pod IPs.

Exam trap

The trap here is that candidates confuse Ingress (external HTTP routing) with internal service discovery, or think NetworkPolicy provides addressing, when only a Service offers a stable virtual IP and DNS name for pod-to-pod communication.

How to eliminate wrong answers

Option B (NetworkPolicy) is wrong because it defines firewall rules for pod-to-pod traffic, not a stable IP or DNS name. Option C (Ingress) is wrong because it manages external HTTP/HTTPS traffic routing to Services, not internal pod-to-pod communication with a stable IP. Option D (ConfigMap) is wrong because it stores configuration data as key-value pairs, not network endpoints.

Practice this question →
73
Drag & Dropmedium

Drag and drop the steps for a rolling update of a Kubernetes Deployment into the correct order.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Change the image, apply, monitor rollout, verify health, and rollback if issues arise.

Practice this question →
74
MCQmedium

What is the Open Container Initiative (OCI) responsible for?

A.Certifying Kubernetes administrators
B.Providing a hosted container registry
C.Defining standards for container images and runtimes
D.Managing the Kubernetes source code
AnswerC

The Open Container Initiative publishes open specifications covering container image formats and runtime behaviour, ensuring portability across compliant engines. This directly addresses the stem's question by defining industry standards for container images and runtimes rather than orchestration or networking.

Why this answer

The Open Container Initiative (OCI) is a Linux Foundation project that defines open industry standards for container formats and runtimes. Specifically, it maintains the OCI Image Specification (which standardizes the container image format, including layers and configuration) and the OCI Runtime Specification (which defines the lifecycle and interface for container runtimes like runc). This ensures interoperability between different container tools and platforms.

Exam trap

The trap here is that candidates confuse the OCI with the CNCF, assuming the OCI manages Kubernetes or its certification, when in fact the OCI focuses solely on container format and runtime standards, while the CNCF oversees Kubernetes and its ecosystem.

How to eliminate wrong answers

Option A is wrong because certifying Kubernetes administrators is the responsibility of the Cloud Native Computing Foundation (CNCF) through the Certified Kubernetes Administrator (CKA) program, not the OCI. Option B is wrong because providing a hosted container registry is a service offered by cloud providers (e.g., Docker Hub, Amazon ECR, Google Container Registry) or self-hosted solutions, not a function of the OCI. Option D is wrong because managing the Kubernetes source code is the role of the CNCF and the Kubernetes community via the Kubernetes GitHub repository; the OCI focuses on container standards, not Kubernetes-specific code.

Practice this question →
75
MCQeasy

A developer wants to run a one-off database migration task in Kubernetes that must complete successfully and then stop. The task should not restart after successful completion, and the developer wants to inspect logs after it finishes. Which resource should be created?

A.A bare Pod with restartPolicy set to Always
B.A CronJob with schedule set to a date in the past
C.A Deployment with a single replica
D.A Job with restartPolicy set to OnFailure or Never
AnswerD

A Job is designed for run-to-completion workloads. Setting the Pod template's restartPolicy to OnFailure or Never ensures the container is not restarted after it exits successfully. The Job controller tracks successful completions, and the completed Pod remains available for log inspection until manually deleted or cleaned up by a TTL controller.

Why this answer

A Job is the correct resource for run-to-completion tasks. By setting the Pod template's restartPolicy to OnFailure or Never, the container stops after a successful exit, and the Job records completion. The completed Pod remains for log inspection, unlike a Deployment or bare Pod with Always restart policy, which would keep restarting the container.

Exam trap

The trap here is confusing a Job with a Deployment and assuming that a single-replica Deployment will run a task just once.

Practice this question →
Page 1 of 3 · 210 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Container Orchestration questions.

Start 20-question session