CCNA Kcna Container Orchestration Questions

61 of 211 questions · Page 3/3 · Kcna Container Orchestration topic · Answers revealed

151
MCQeasy

Which component is responsible for managing the lifecycle of containers on a Kubernetes node?

A.kube-scheduler
B.kube-controller-manager
C.kube-apiserver
D.kubelet
AnswerD

The kubelet runs on each node and ensures containers are running and healthy.

Why this answer

The kubelet is the primary node agent that runs on each Kubernetes node. It is responsible for ensuring that containers are running in a Pod as expected by interacting with the container runtime (e.g., Docker, containerd) to manage the container lifecycle—starting, stopping, and monitoring containers based on PodSpecs received from the API server.

Exam trap

CNCF often tests the distinction between control-plane components (scheduler, controller-manager, API server) and node-level agents (kubelet), so the trap here is assuming that container lifecycle management is a control-plane function rather than a node-level responsibility.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning Pods to nodes based on resource availability and constraints, not for managing container lifecycles on a node. Option B is wrong because kube-controller-manager runs controller processes (e.g., ReplicaSet, Deployment controllers) that regulate cluster state, but it does not directly interact with containers on individual nodes. Option C is wrong because kube-apiserver serves as the front-end for the Kubernetes control plane, exposing the Kubernetes API, but it does not manage container lifecycles on nodes; it only provides the interface for kubelet to retrieve Pod specifications.

152
Multi-Selecthard

Which TWO statements about the Container Runtime Interface (CRI) are correct? (Select 2)

Select 2 answers
A.Docker is the primary CRI implementation
B.CRI is responsible for pulling container images
C.CRI allows Kubernetes to use different container runtimes
D.CRI is an OCI specification
E.containerd and CRI-O are CRI-compliant runtimes
AnswersC, E

CRI is a plugin interface that abstracts the container runtime.

Why this answer

Options A and D are correct. CRI is a plugin interface that enables Kubernetes to use different container runtimes (A). It is implemented by runtimes like containerd and CRI-O (D).

Option B is false—CRI is not an OCI spec; OCI has image and runtime specs. Option C is false—Docker was deprecated as a runtime in favor of CRI-compliant runtimes. Option E is false—CRI defines the interface, but the runtime implements it.

153
Multi-Selectmedium

Which THREE of the following are characteristics of a microservices architecture? (Select 3)

Select 3 answers
A.Services share the same database schema
B.Loose coupling between services
C.Independent deployment of services
D.All services are packaged in a single monolithic deployment
E.Decomposition of application into small, independent services
AnswersB, C, E

Services communicate via APIs, reducing dependencies.

Why this answer

Option B is correct because microservices architecture emphasizes loose coupling, where each service communicates via well-defined APIs (e.g., REST, gRPC) and does not share internal implementation details. This allows services to evolve independently without affecting others, which is a core principle of the architecture.

Exam trap

CNCF often tests the misconception that microservices share a database or are deployed as a single unit, confusing them with monolithic or service-oriented architectures (SOA) that may share schemas.

154
MCQmedium

A team wants to deploy a batch job that runs once to process a large dataset. The job should run to completion and then terminate. Which Kubernetes resource should be used?

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

Job runs pods until completion, ideal for batch processing.

Why this answer

A Job resource is designed for batch processing tasks that run to completion and then terminate. It creates one or more Pods and ensures they successfully finish their work, making it the correct choice for a one-time data processing job.

Exam trap

CNCF often tests the distinction between long-running workloads (Deployments, DaemonSets) and finite tasks (Jobs), so the trap here is confusing a one-time batch job with a CronJob due to the word 'batch' or assuming a Deployment can handle termination.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures a Pod runs on every node (or a subset) for continuous daemon-like services, not for a one-time batch job. Option B is wrong because a CronJob is used for scheduled, recurring tasks, not a single run. Option C is wrong because a Deployment manages long-running, stateless applications with desired replicas and rolling updates, not a terminating batch job.

155
MCQmedium

What is the concept of 'immutable infrastructure' as applied to Kubernetes?

A.Configuration is stored in environment variables only
B.Containers are rebuilt from the same base image every time
C.Infrastructure components are never replaced; they are updated in place
D.Pods are replaced with new versions rather than being modified
AnswerD

Correct. Immutable infrastructure replaces rather than patches.

Why this answer

Immutable infrastructure in Kubernetes means that instead of modifying running Pods or their containers (e.g., patching a binary or updating a config file in place), you replace the entire Pod with a new version. This is enforced by Kubernetes' declarative model: when you update a Deployment's Pod template, the controller creates new Pods with the new image and terminates the old ones. This ensures consistency, repeatability, and eliminates configuration drift, as every change results in a fresh, identical instance from the same image.

Exam trap

CNCF often tests the distinction between 'immutable' (replace) and 'mutable' (update in place), and the trap here is that candidates confuse the concept with build-time practices (like using the same base image) or configuration injection methods, rather than the core runtime behavior of replacing Pods.

How to eliminate wrong answers

Option A is wrong because storing configuration only in environment variables is a specific pattern (e.g., 12-factor app), but it does not define immutability; immutable infrastructure requires replacing the entire unit, not just how config is injected. Option B is wrong because rebuilding containers from the same base image every time describes a build practice (e.g., using Dockerfile layers), but immutability is about the runtime behavior of replacing Pods, not the image build process. Option C is wrong because it describes mutable infrastructure (e.g., SSHing into a server to apply updates), which is the exact opposite of immutability; immutable infrastructure mandates that components are never updated in place—they are destroyed and recreated.

156
Multi-Selecthard

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

Select 3 answers
A.Docker is an OCI runtime specification
B.OCI is governed by the Cloud Native Computing Foundation (CNCF)
C.OCI defines both an image spec and a runtime spec
D.containerd is an OCI-compliant container runtime
E.Docker images are OCI-compliant
AnswersC, D, E

The OCI maintains the Image Specification and Runtime Specification.

Why this answer

The OCI defines the image spec and runtime spec, ensuring interoperability between container tools. containerd is an OCI-compliant runtime. Docker images are OCI-compliant. Docker itself is not a runtime spec but a platform that uses runtimes.

157
MCQmedium

A company wants to run a batch job that processes data and then terminates. Which Kubernetes resource should they use?

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

Jobs create one or more pods and ensure they successfully terminate, ideal for batch processing.

Why this answer

A Job is the correct Kubernetes resource for a batch job that processes data and then terminates. Unlike controllers that maintain a desired state (like Deployments), a Job creates one or more Pods and ensures they run to successful completion. Once the specified number of Pods terminate successfully, the Job is considered complete and does not restart the Pods, making it ideal for one-off or finite processing tasks.

Exam trap

CNCF often tests the distinction between controllers that maintain a desired state (Deployment, DaemonSet) versus controllers that run to completion (Job, CronJob), and the trap here is that candidates may confuse a CronJob with a Job, forgetting that CronJob adds a scheduling layer for periodic execution, not for a single run.

How to eliminate wrong answers

Option A is wrong because a CronJob is designed for scheduling recurring tasks on a time-based schedule (e.g., every hour), not for a single batch job that runs once and terminates. Option C is wrong because a Deployment is meant to run a set of Pods continuously, ensuring a specified number of replicas are always running; it will restart Pods if they exit, which is the opposite of a terminating batch job. Option D is wrong because a DaemonSet ensures that a copy of a Pod runs on every (or selected) node in the cluster, typically for long-running system services like log collectors or monitoring agents, not for one-off batch processing.

158
MCQeasy

What is the purpose of the 'kubectl scale' command?

A.To update the container image of a Deployment
B.To delete a resource
C.To view the logs of a pod
D.To change the number of replicas in a Deployment
AnswerD

kubectl scale changes the replica count.

Why this answer

kubectl scale changes the number of replicas in a Deployment, ReplicaSet, or similar resource.

159
MCQeasy

What is the primary purpose of the Container Runtime Interface (CRI) in Kubernetes?

A.To store container images in a registry
B.To define the format of container images
C.To manage container network interfaces
D.To provide a standard interface between the kubelet and container runtimes
AnswerD

CRI is a plugin interface that enables the kubelet to use different container runtimes.

Why this answer

The Container Runtime Interface (CRI) is a plugin protocol that enables the kubelet to use any OCI-compliant container runtime (e.g., containerd, CRI-O) without needing to recompile Kubernetes. It defines gRPC APIs for runtime and image service operations, abstracting the runtime implementation from the kubelet's pod lifecycle management.

Exam trap

CNCF often tests the distinction between CRI (runtime abstraction) and CNI (network abstraction), so the trap here is confusing container runtime management with container networking, leading candidates to pick Option C.

How to eliminate wrong answers

Option A is wrong because storing container images in a registry is the function of a container registry (e.g., Docker Hub, Amazon ECR), not the CRI; the CRI's image service pulls images from registries but does not store them. Option B is wrong because defining the format of container images is the responsibility of the OCI Image Specification, not the CRI; the CRI consumes images in that format but does not define it. Option C is wrong because managing container network interfaces is the role of the Container Network Interface (CNI), not the CRI; the CRI focuses on runtime and image operations, while CNI handles network attachment.

160
Multi-Selectmedium

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

Select 2 answers
A.Container images include a full operating system kernel
B.Container images can be stored in a registry like Docker Hub
C.Container images are built from a series of layers
D.Container images are immutable once built
E.Container images can only be built on Linux
AnswersB, C

Registries store and distribute images.

Why this answer

Container images are built in layers and can be stored in registries. They are not immutable once built (they can be overwritten), and they include only the application and dependencies, not a full OS kernel.

161
MCQeasy

Which component in Kubernetes is responsible for maintaining the desired state of the cluster?

A.kube-scheduler
B.kube-proxy
C.kube-controller-manager
D.kubelet
AnswerC

The controller manager runs controllers that enforce the desired state.

Why this answer

The kube-controller-manager is the component that runs controller processes, which are control loops that watch the shared state of the cluster through the API server and make changes to move the current state toward the desired state. It is responsible for ensuring that the cluster's actual state matches the desired state defined in Kubernetes objects such as Deployments, ReplicaSets, and StatefulSets.

Exam trap

CNCF often tests the distinction between the kube-controller-manager and the kubelet, where candidates mistakenly think the kubelet maintains the cluster's desired state because it manages containers on a node, but the kubelet only ensures the pod's containers are healthy on its local node, not the cluster-wide desired state.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and scheduling policies, not for maintaining the desired state of the cluster. Option B is wrong because kube-proxy is a network proxy that runs on each node and implements part of the Kubernetes Service concept by maintaining network rules, not for maintaining desired state. Option D is wrong because kubelet is an agent that runs on each node and ensures containers are running in a pod as expected, but it only manages the state on its specific node and does not maintain the overall desired state of the cluster.

162
MCQhard

Which of the following best describes immutable infrastructure?

A.Servers that are updated in-place with configuration management tools
B.Infrastructure that is version-controlled and deployed using blue/green deployments
C.Infrastructure components that are replaced rather than changed after deployment
D.Infrastructure that uses only read-only file systems
AnswerC

Immutable infrastructure replaces components instead of modifying them.

Why this answer

Immutable infrastructure means that servers or containers are never modified after deployment; any change requires replacing the resource with a new version.

163
Multi-Selectmedium

Which THREE are benefits of using container orchestration platforms like Kubernetes?

Select 3 answers
A.High availability through automatic container restart and replication
B.Automatic scaling of container replicas based on resource usage
C.Self-healing by replacing failed containers without manual intervention
D.Simplified application development by eliminating the need for code changes
E.Elimination of the need for monitoring and logging
AnswersA, B, C

Orchestrators monitor container health and automatically restart failed containers, ensuring high availability.

Why this answer

Options A, B, and D are correct. Orchestration provides high availability (A), scaling (B), and self-healing (D). Option C is false — orchestration adds complexity, not simplicity.

Option E is false — manual intervention can be reduced, but orchestration does not eliminate the need for management.

164
MCQhard

A Service of type ClusterIP is created for a Deployment, but Pods in other namespaces cannot reach it. What is the most likely cause?

A.NetworkPolicies are blocking cross-namespace traffic
B.The Pods in other namespaces are using the short Service name without the namespace suffix
C.The Service is not publishing the correct port
D.The Service selector does not match the Pod labels
AnswerB

Cross-namespace access requires the full DNS name including the namespace.

Why this answer

The most likely cause is that Pods in other namespaces are using the short Service name (e.g., `my-service`) without appending the namespace suffix (e.g., `my-service.other-namespace.svc.cluster.local`). Kubernetes DNS resolves short names only within the same namespace; cross-namespace resolution requires the fully qualified domain name (FQDN) or at least the `<service>.<namespace>.svc` form. Without this, the DNS lookup fails, making the Service unreachable from other namespaces.

Exam trap

The trap here is that candidates often assume DNS works globally across namespaces with short names, but Kubernetes DNS only resolves short names within the same namespace by default, requiring the namespace suffix for cross-namespace access.

How to eliminate wrong answers

Option A is wrong because NetworkPolicies are not enabled by default and would require explicit configuration to block cross-namespace traffic; the question states Pods 'cannot reach it' without mentioning any NetworkPolicy, so this is not the most likely cause. Option C is wrong because if the Service were not publishing the correct port, it would affect all clients, not just those in other namespaces, and the question specifically isolates the issue to cross-namespace access. Option D is wrong because if the Service selector did not match the Pod labels, the Service would have no endpoints at all, making it unreachable from any namespace, not just from other namespaces.

165
MCQmedium

An application running in a Kubernetes pod needs to access a database that is deployed on a VM outside the cluster. The database IP is stable. Which is the best way to expose the database to the pod?

A.Expose the database via Ingress
B.Create a Service of type ExternalName pointing to the database hostname
C.Use a Headless Service
D.Create an EndpointSlice manually with the pod IP
AnswerB

ExternalName service provides a DNS alias to an external resource.

Why this answer

Option B is correct because a Service of type ExternalName provides a DNS-based abstraction for external resources, mapping a Kubernetes service name to an external DNS name (the database hostname). This allows the pod to access the database via a stable in-cluster DNS name without needing to manage IP changes or network policies for external endpoints. It is the simplest and most Kubernetes-native way to expose a stable external IP to a pod.

Exam trap

Cisco often tests the misconception that Ingress can handle any external service, but Ingress is strictly for HTTP/HTTPS traffic and cannot expose raw TCP services like databases.

How to eliminate wrong answers

Option A is wrong because Ingress is designed for HTTP/HTTPS traffic routing to internal services, not for exposing external databases (which typically use non-HTTP protocols like TCP). Option C is wrong because a Headless Service is used for stateful applications or service discovery of pod IPs within the cluster, not for pointing to an external resource. Option D is wrong because manually creating an EndpointSlice with the pod IP would require the database to be running as a pod inside the cluster, which contradicts the scenario where the database is on an external VM.

166
Multi-Selectmedium

Which TWO statements accurately describe the concept of immutable infrastructure in the context of container orchestration? (Select two.)

Select 2 answers
A.Configuration changes can be applied via SSH into the container
B.Container images are versioned and promoted through environments without modification
C.When an update is needed, a new container image is built and deployed, and old containers are destroyed
D.Containers are updated in place by executing commands inside running containers
E.Stateful applications require mutable infrastructure
AnswersB, C

Immutable infrastructure promotes the same image through development, staging, and production without changes, ensuring consistency.

Why this answer

Option B is correct because immutable infrastructure treats container images as immutable artifacts that are versioned and promoted through environments (e.g., dev, staging, prod) without modification. This ensures consistency and reproducibility, as the same image is deployed across all stages without patching or altering it in place.

Exam trap

CNCF often tests the distinction between mutable and immutable patterns by presenting options that describe in-place updates (like SSH or exec commands) as valid, which candidates mistakenly accept if they confuse operational debugging with infrastructure management.

167
MCQmedium

Which of the following is a container runtime that implements the Container Runtime Interface (CRI)?

A.rkt
B.Docker
C.containerd
D.Hyper-V
AnswerC

containerd is a CRI-compliant runtime used by Kubernetes.

Why this answer

containerd is a core container runtime that implements the CRI and is commonly used in Kubernetes.

168
MCQeasy

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

A.Containers provide stronger isolation than VMs
B.Containers can run any operating system kernel
C.Containers are lightweight and share the host OS kernel
D.Containers require a hypervisor to run
AnswerC

Containers share the host kernel and have minimal overhead, making them lightweight.

Why this answer

Option C is correct because containers virtualize at the operating system level, sharing the host OS kernel while running in isolated user-space instances. This eliminates the need for a full guest OS per workload, making containers significantly more lightweight in terms of memory, disk usage, and startup time compared to virtual machines, which each require a separate kernel and hypervisor.

Exam trap

CNCF often tests the misconception that containers provide stronger isolation than VMs, when in fact VMs offer hardware-enforced isolation via the hypervisor, and containers rely on software-enforced kernel isolation, which is weaker.

How to eliminate wrong answers

Option A is wrong because containers provide weaker isolation than VMs; VMs use a hypervisor to enforce hardware-level isolation between guest kernels, while containers rely on kernel features like namespaces and cgroups, which share the host kernel and have a larger attack surface. Option B is wrong because containers cannot run any operating system kernel; they must use the same kernel as the host OS (e.g., Linux containers on a Linux host), and running a different kernel (e.g., Windows containers on Linux) requires a VM layer. Option D is wrong because containers do not require a hypervisor to run; they run directly on the host OS using container runtime engines like Docker or containerd, whereas VMs require a hypervisor (Type 1 or Type 2) to manage guest operating systems.

169
MCQeasy

What is a key advantage of containers compared to virtual machines?

A.Containers provide stronger isolation than VMs
B.Containers are lightweight and share the host OS kernel
C.Containers include a full guest operating system
D.Containers require hypervisor software to run
AnswerB

This is correct; containers share the kernel, leading to lower overhead.

Why this answer

Containers are lightweight because they share the host operating system kernel, avoiding the overhead of a separate guest OS per instance. Unlike VMs, which each include a full OS and require hypervisor mediation, containers run as isolated user-space processes on the same kernel, enabling faster startup times and higher density. This kernel sharing is the fundamental architectural advantage that makes containers more resource-efficient than virtual machines.

Exam trap

The trap here is that candidates often confuse 'isolation' with 'security' and assume containers are more secure because they are lightweight, but Cisco tests the understanding that VMs provide stronger isolation via separate kernels and hypervisor-enforced boundaries.

How to eliminate wrong answers

Option A is wrong because containers provide weaker isolation than VMs, as they share the host kernel and rely on kernel namespaces and cgroups for separation, whereas VMs use a hypervisor to provide hardware-level isolation with separate kernels. Option C is wrong because containers do not include a full guest operating system; they package only the application and its dependencies, leveraging the host OS kernel. Option D is wrong because containers do not require hypervisor software to run; they run directly on the host OS using the container runtime (e.g., containerd, Docker), while hypervisors are needed for VMs.

170
MCQeasy

Which command would you use to view the logs of a specific container in a pod?

A.kubectl logs <pod-name>
B.kubectl logs <container-name>
C.kubectl logs <pod-name> -c <container-name>
D.kubectl describe pod <pod-name>
AnswerC

The -c flag specifies the container name.

Why this answer

kubectl logs with the -c flag allows you to specify a container name when a pod has multiple containers.

171
MCQmedium

A developer wants to deploy a stateful application that requires stable network identities and persistent storage per pod instance. Which Kubernetes resource is most appropriate?

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

StatefulSets provide ordered, unique pod names and persistent storage per replica.

Why this answer

StatefulSet is the correct choice because it is specifically designed for stateful applications that require stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage per pod instance (via PersistentVolumeClaims that are not shared across replicas). Unlike Deployments, StatefulSet maintains a sticky identity for each pod, ensuring that on rescheduling, the pod retains its name, network identity, and bound storage.

Exam trap

CNCF often tests the misconception that a Deployment with PersistentVolumeClaims is sufficient for stateful workloads, but the trap is that Deployments do not guarantee stable network identities or ordered pod naming, which are critical for applications like databases that rely on hostname-based clustering.

How to eliminate wrong answers

Option A (DaemonSet) is wrong because it ensures exactly one pod runs on each node, which is ideal for node-level agents (e.g., log collectors, monitoring daemons), not for stateful applications needing stable identities and per-instance storage. Option B (Job) is wrong because it is designed for batch or one-off tasks that run to completion, not for long-running stateful services that require persistent storage and stable network identities. Option C (Deployment) is wrong because it treats pods as ephemeral and interchangeable; while it supports persistent storage via PersistentVolumeClaims, it does not guarantee stable network identities or ordered pod naming, so a rescheduled pod gets a new name and IP, breaking stateful expectations.

172
MCQmedium

A user wants to ensure that a pod is automatically restarted if its main process crashes. Which Kubernetes controller should they use?

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

Deployments maintain desired pod count and restart failed pods via ReplicaSet.

Why this answer

A Deployment is the correct controller because it manages a ReplicaSet, which ensures a specified number of pod replicas are running at all times. If the main process in a pod crashes, the ReplicaSet detects the pod failure (via the kubelet's liveness probe or the pod's phase becoming 'Failed') and automatically creates a new pod to replace it, thereby restarting the application. This self-healing behavior is a core feature of Deployments, making them ideal for stateless applications that need continuous availability.

Exam trap

CNCF often tests the misconception that a 'restart' means the same pod is reused, but in Kubernetes, a Deployment (via ReplicaSet) creates a completely new pod, while the 'restartPolicy' field only controls container restarts within the same pod — the trap is confusing pod-level restart (ReplicaSet replacement) with container-level restart (kubelet action).

How to eliminate wrong answers

Option B (Job) is wrong because a Job is designed to run a finite task to completion; it does not automatically restart pods if the main process crashes — instead, it may create a new pod only if the Job's restart policy is set to 'OnFailure', but the Job itself is not intended for long-running, always-on services. Option C (DaemonSet) is wrong because it ensures that a copy of a pod runs on every node (or a subset of nodes), but its primary purpose is node-level services (e.g., logging, monitoring), not automatic restart of a crashed main process in a general-purpose application; while DaemonSets do use a controller that recreates pods on failure, the question asks for a controller that ensures restart for a single application, and DaemonSet is node-scoped, not workload-scoped. Option D (CronJob) is wrong because it runs Jobs on a scheduled basis; it does not provide continuous pod restart — it only creates Jobs at specified times, and the underlying Job's behavior applies, but the CronJob itself does not monitor or restart crashed pods between scheduled runs.

173
MCQeasy

What is the Container Runtime Interface (CRI)?

A.A plugin interface that allows kubelet to use a variety of container runtimes
B.A specification for container images
C.A registry for storing container images
D.A command-line tool for managing containers
AnswerA

CRI enables kubelet to communicate with runtimes.

Why this answer

The Container Runtime Interface (CRI) is a plugin interface that enables the kubelet to communicate with different container runtimes (e.g., containerd, CRI-O) without needing to know their internal implementation details. It defines a gRPC-based protocol for managing container lifecycles, image operations, and pod sandboxes, allowing Kubernetes to remain runtime-agnostic.

Exam trap

CNCF often tests whether candidates confuse CRI with the OCI runtime spec or with container image formats, so the trap is assuming CRI defines image structure rather than the runtime-kubelet interface.

How to eliminate wrong answers

Option B is wrong because container images are defined by the OCI Image Specification, not by CRI. Option C is wrong because registries (like Docker Hub or Harbor) are storage systems for images, not an interface for runtime integration. Option D is wrong because command-line tools (e.g., crictl) may use CRI under the hood, but CRI itself is an API, not a CLI tool.

174
MCQeasy

Which command is used to create a Deployment that runs an nginx container with 3 replicas?

A.kubectl create pod nginx --image=nginx --replicas=3
B.kubectl run nginx --image=nginx --replicas=3
C.kubectl create deployment nginx --image=nginx --replicas=3
D.kubectl scale deployment nginx --replicas=3
AnswerC

This command creates a Deployment named nginx with the specified image and replicas.

Why this answer

The correct command uses 'kubectl create deployment' with the --image and --replicas flags.

175
MCQeasy

What is a key benefit of container orchestration platforms like Kubernetes?

A.Containers are tightly coupled to the underlying hardware
B.Each container runs its own operating system kernel
C.Containers can only run on a single host
D.Self-healing capabilities automatically restart failed containers
AnswerD

Orchestration platforms automatically restart failed containers, improving reliability.

Why this answer

Option C is correct. Container orchestration automates deployment, scaling, and management. A key benefit is self-healing—containers that fail are automatically restarted.

Option A is incorrect because containers share the host OS kernel, they do not have their own kernel. Option B is incorrect because containers run on a single host by default; orchestration manages multiple hosts. Option D is incorrect because containers are not tied to specific hardware.

176
MCQeasy

What is a key benefit of using containers over virtual machines for application deployment?

A.Containers can only run on Linux
B.Containers require a hypervisor to run
C.Containers provide stronger isolation than VMs
D.Containers are more lightweight and start faster than VMs
AnswerD

Containers share the host OS kernel and do not need to boot a guest OS, leading to faster startup times and lower overhead.

Why this answer

Containers share the host OS kernel and run as isolated processes, requiring no separate guest OS per instance. This makes them significantly more lightweight and faster to start than VMs, which must boot a full guest OS. For application deployment, this translates to higher density, lower resource overhead, and near-instant startup times.

Exam trap

The trap here is that candidates often confuse 'stronger isolation' with 'better security' and pick Option C, not realizing that VMs actually provide stronger isolation due to separate kernels and hardware virtualization, while containers are designed for lightweight efficiency, not maximum isolation.

How to eliminate wrong answers

Option A is wrong because containers are not limited to Linux; Windows containers run on Windows Server and Docker Desktop supports both Linux and Windows containers via appropriate runtimes. 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, whereas VMs require a hypervisor to virtualize hardware. Option C is wrong because VMs provide stronger isolation than containers; each VM has its own separate kernel and hardware virtualization, while containers share the host kernel, making isolation weaker by design.

177
Multi-Selecthard

Which THREE of the following are benefits of using a container orchestration platform like Kubernetes? (Select three.)

Select 3 answers
A.Built-in image building and registry
B.Declarative management: specify desired state and let the system converge
C.Faster application startup times
D.Automatic scaling of applications based on demand
E.Self-healing: automatic restart of failed containers
AnswersB, D, E

Kubernetes uses a declarative model where you define the desired state and controllers work to achieve it.

Why this answer

Kubernetes provides self-healing (restart failed containers), scaling (automatic horizontal scaling), and declarative management (desired state reconciliation). Option A is a benefit of containers themselves, not orchestration; Option E is a feature of container runtimes.

178
MCQeasy

Which component is responsible for running containers on a Kubernetes node?

A.kube-controller-manager
B.kube-proxy
C.kube-apiserver
D.kubelet
AnswerD

The kubelet runs on each node and manages pod lifecycles, including starting containers via the container runtime.

Why this answer

The kubelet is the primary node agent that runs on each Kubernetes node. It is responsible for ensuring that containers are running in a Pod as expected, by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers based on PodSpecs received from the API server.

Exam trap

The trap here is that candidates often confuse kubelet with kube-controller-manager, thinking the controller manager handles node-level container operations, but the kubelet is the only component that directly manages containers on the node.

How to eliminate wrong answers

Option A is wrong because the kube-controller-manager runs controller processes (like Node Controller, Replication Controller) at the control plane level, not on worker nodes, and does not directly manage containers. Option B is wrong because kube-proxy is a network proxy that handles network rules and service load balancing on each node, but it does not run or manage containers. Option C is wrong because kube-apiserver is the front-end of the Kubernetes control plane that exposes the Kubernetes API; it validates and processes RESTful requests but does not execute container lifecycle operations on nodes.

179
MCQmedium

You are writing a Deployment YAML (apps/v1) for a stateless web application. The application should have 3 replicas and use rolling updates with maxSurge=1 and maxUnavailable=0. Which field should you set under spec.strategy?

A.type: Recreate
B.type: Canary
C.type: OnDelete
D.type: RollingUpdate with rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }
AnswerD

This matches the requirement.

Why this answer

Option D is correct because the Deployment's `spec.strategy.type` must be set to `RollingUpdate` to enable a controlled, incremental update of pods. The `rollingUpdate` field then allows you to specify `maxSurge: 1` (one extra pod above the desired count during update) and `maxUnavailable: 0` (ensure all existing pods remain available during the update), which is the exact configuration for a zero-downtime rolling update with a single surge pod.

Exam trap

CNCF often tests the misconception that `maxSurge` and `maxUnavailable` are top-level fields under `spec.strategy`, when in fact they must be nested inside `rollingUpdate` and the `type` must explicitly be set to `RollingUpdate`.

How to eliminate wrong answers

Option A is wrong because `type: Recreate` terminates all existing pods before creating new ones, which violates the requirement for a rolling update with `maxSurge` and `maxUnavailable` settings. Option B is wrong because `Canary` is not a valid Deployment strategy type in the `apps/v1` API; it is a separate deployment pattern often implemented via service mesh or progressive delivery tools, not a native Kubernetes Deployment field. Option C is wrong because `OnDelete` is a strategy type used by StatefulSets (not Deployments) and only triggers pod replacement when a pod is manually deleted, which does not support automated rolling updates or the specified surge/unavailable parameters.

180
MCQmedium

You need to run a batch job that processes data every hour and exits upon completion. Which Kubernetes resource should you use?

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

A Job runs a pod until successful completion.

Why this answer

A Job is the correct Kubernetes resource because it is designed to run a finite task to completion, such as a batch job that processes data every hour and then exits. Unlike a Deployment, which maintains a desired number of continuously running Pods, a Job ensures that a specified number of Pods successfully terminate, making it ideal for one-off or scheduled batch workloads.

Exam trap

CNCF often tests the distinction between a CronJob (the scheduler) and a Job (the actual workload), so candidates mistakenly choose CronJob because the question mentions 'every hour', but the resource that runs and exits is the Job, not the CronJob.

How to eliminate wrong answers

Option A is wrong because a Deployment is intended for long-running, stateless applications that should never exit; it continuously restarts Pods to maintain a desired replica count, which would cause the batch job to run repeatedly rather than exit upon completion. Option C is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, typically for cluster-level services like logging or monitoring, not for a batch job that runs once per hour and exits. Option D is wrong because a CronJob is used to schedule Jobs on a recurring basis (e.g., every hour), but the question specifies that the batch job 'processes data every hour and exits upon completion' — the resource that actually runs and exits is a Job, while the CronJob is the scheduler that creates the Job; the question asks for the resource that runs the workload, not the scheduler.

181
MCQhard

An administrator needs to ensure that Pods from two different Deployments cannot communicate with each other. Which Kubernetes resource should be used?

A.NetworkPolicy
B.RBAC Role
C.PodSecurityPolicy
D.ResourceQuota
AnswerA

NetworkPolicy defines ingress/egress rules for pod communication.

Why this answer

NetworkPolicy is the correct resource because it acts as a firewall for Kubernetes Pods, controlling ingress and egress traffic at the IP address and port level using layer 3/4 rules. By applying a NetworkPolicy that denies all traffic between the Pods of the two Deployments (e.g., using podSelector and ingress/egress rules with an empty `from` or `to` block), the administrator can enforce network isolation. This is the native Kubernetes mechanism for restricting Pod-to-Pod communication within a cluster.

Exam trap

The trap here is that candidates confuse NetworkPolicy with RBAC or PodSecurityPolicy, mistakenly thinking that authorization or security contexts can control network traffic, when in fact only NetworkPolicy (with a compatible CNI) provides layer 3/4 isolation.

How to eliminate wrong answers

Option B (RBAC Role) is wrong because RBAC controls authorization for Kubernetes API operations (e.g., creating Pods, reading Secrets) and does not manage network traffic between Pods. Option C (PodSecurityPolicy) is wrong because it defines security constraints on Pods (e.g., privileged containers, host namespaces) but has no effect on network communication between Pods. Option D (ResourceQuota) is wrong because it limits aggregate resource consumption (CPU, memory, storage) per namespace and cannot restrict network connectivity between Pods.

182
Multi-Selectmedium

Which TWO of the following are valid ways to expose a set of pods as a network service in Kubernetes?

Select 2 answers
A.Service of type NodePort
B.NetworkPolicy
C.Service of type ClusterIP
D.Ingress resource
E.Deployment with replicas
AnswersA, C

NodePort exposes the service on each node's IP at a static port.

Why this answer

A Service of type NodePort exposes a set of pods on a static port on each node's IP address, making the service accessible from outside the cluster. This is a valid Kubernetes resource for exposing pods as a network service, as it creates a mapping from a node port to the ClusterIP and then to the target pods.

Exam trap

Cisco often tests the misconception that Ingress or NetworkPolicy can directly expose pods as a network service, but Ingress requires a Service backend and NetworkPolicy only controls traffic, not exposure.

183
MCQmedium

Which command correctly creates a Deployment named 'web-app' with the image 'nginx:1.21' and 3 replicas?

A.kubectl apply deployment web-app --image=nginx:1.21 --replicas=3
B.kubectl run web-app --image=nginx:1.21 --replicas=3
C.kubectl create deployment web-app --image=nginx:1.21 --replicas=3
D.kubectl create deployement web-app --image=nginx:1.21 --replicas=3
AnswerC

This is the correct syntax to create a Deployment with the given name, image, and replica count.

Why this answer

Option C is correct because `kubectl create deployment` is the imperative command specifically designed to create a Deployment resource in Kubernetes. The `--image` flag specifies the container image, and `--replicas=3` sets the desired number of pod replicas, which matches the requirement exactly.

Exam trap

CNCF often tests the distinction between `kubectl run` (which creates a Pod, not a Deployment) and `kubectl create deployment` (which creates a Deployment with replica management), leading candidates to mistakenly choose `kubectl run` when replicas are required.

How to eliminate wrong answers

Option A is wrong because `kubectl apply` requires a manifest file or stdin input; it does not accept `--image` or `--replicas` flags directly, and the syntax `apply deployment` is invalid. Option B is wrong because `kubectl run` creates a Pod (or a Deployment only in older versions with certain flags), but it does not support the `--replicas` flag; it is used for ad-hoc pods, not multi-replica Deployments. Option D is wrong because `deployement` is a misspelling of `deployment`, which causes a command syntax error; Kubernetes CLI commands are case-sensitive and must match the exact resource name.

184
MCQeasy

Which of the following describes the Open Container Initiative (OCI) image specification?

A.A standard for container images and runtimes
B.A specification for container orchestration
C.A specification for container storage
D.A specification for container networking
AnswerA

OCI defines both image spec and runtime spec.

Why this answer

The Open Container Initiative (OCI) image specification defines a standard format for container images, ensuring that any OCI-compliant image can be run by any OCI-compliant runtime (e.g., runc, crun). This specification covers the image manifest, filesystem layers, and configuration, enabling interoperability across different container platforms like Docker, Podman, and containerd. Option A is correct because the OCI specifically standardizes both the image format and the runtime behavior, not higher-level orchestration or infrastructure concerns.

Exam trap

CNCF often tests the distinction between OCI (image/runtime) and CNI/CSI (networking/storage), so the trap here is that candidates confuse the OCI specification with other container ecosystem standards like CNI or CSI due to similar acronyms and overlapping container contexts.

How to eliminate wrong answers

Option B is wrong because container orchestration is the domain of tools like Kubernetes, Docker Swarm, and Nomad, which manage scheduling, scaling, and service discovery—not the OCI image specification. Option C is wrong because container storage is addressed by separate standards like the Container Storage Interface (CSI), which defines how storage systems are exposed to containerized workloads, not by the OCI image spec. Option D is wrong because container networking is governed by the Container Network Interface (CNI), which specifies how network plugins configure network interfaces for containers, whereas the OCI image spec focuses solely on image and runtime standards.

185
MCQhard

A developer creates a Deployment with 3 replicas. After updating the pod template, they run 'kubectl rollout status deployment/my-deployment' and see that the rollout is stuck. Which command should they use to investigate the rollout history?

A.kubectl get events
B.kubectl describe deployment my-deployment
C.kubectl rollout history deployment/my-deployment
D.kubectl logs deployment/my-deployment
AnswerC

This command displays the rollout history, including revisions and cause of updates.

Why this answer

Option A is correct. 'kubectl rollout history' shows revisions and changes. Option B ('kubectl describe deployment') shows current state but not history. Option C ('kubectl get events') shows cluster events but not rollout history.

Option D ('kubectl logs') shows logs of pods, not deployment rollout history.

186
Multi-Selectmedium

Which TWO statements about Docker Compose and Kubernetes are correct?

Select 2 answers
A.Kubernetes is only used in production environments
B.Docker Compose and Kubernetes use the same YAML manifest format
C.Kubernetes provides built-in auto-scaling and self-healing capabilities
D.Docker Compose is designed for single-host container orchestration
E.Docker Compose supports multi-node clustering out-of-the-box
AnswersC, D

Kubernetes includes features like Horizontal Pod Autoscaler and automatic restart of failed containers.

Why this answer

Options A and D are correct. Docker Compose is primarily for single-host container orchestration (A). Kubernetes provides built-in features like auto-scaling and self-healing (D).

Option B is false — Kubernetes can also be used in production. Option C is false — Docker Compose does not manage a cluster; it uses a single Docker daemon. Option E is false — Docker Compose uses a compose file, not YAML manifests? Actually both use YAML, but the statement is misleading; Compose uses docker-compose.yml, Kubernetes uses YAML manifests, but they are not interchangeable.

187
MCQmedium

A team deploys a microservice that requires sticky sessions. The service runs on Kubernetes with multiple replicas. Which Kubernetes resource should be used to ensure requests from a client are consistently routed to the same pod?

A.Headless Service
B.Service with sessionAffinity: ClientIP
C.Ingress with default settings
D.Deployment with hostNetwork: true
AnswerB

This configuration ensures requests from the same client IP go to the same pod.

Why this answer

Option B is correct because setting `sessionAffinity: ClientIP` on a Kubernetes Service ensures that all requests from the same client IP are routed to the same Pod. This is the standard Kubernetes mechanism for implementing sticky sessions without requiring changes to the application or ingress layer.

Exam trap

CNCF often tests the misconception that Ingress or Headless Services can handle session affinity by default, but only a Service with `sessionAffinity: ClientIP` provides this at the Kubernetes networking layer without additional configuration.

How to eliminate wrong answers

Option A is wrong because a Headless Service does not provide load balancing or session affinity; it returns the IPs of all Pods directly, requiring the client to handle routing. Option C is wrong because an Ingress with default settings does not maintain session affinity; it typically passes traffic to a Service without any stickiness, and Ingress controllers like NGINX require additional annotations (e.g., `nginx.ingress.kubernetes.io/affinity`) to enable sticky sessions. Option D is wrong because `hostNetwork: true` binds the Pod directly to the node's network stack, bypassing Kubernetes service networking entirely, and does not provide any session affinity mechanism.

188
MCQmedium

You have a Kubernetes cluster with multiple nodes. You need to ensure that a pod runs on a node that has an SSD. How should you achieve this?

A.Manually edit kube-scheduler configuration
B.Use a DaemonSet to run the pod on all nodes
C.Use a nodeSelector with the label 'disktype: ssd'
D.Use a toleration for the node
AnswerC

nodeSelector is a simple field that matches node labels, making it the easiest way to schedule pods on nodes with SSDs.

Why this answer

Option C is correct because nodeSelector is the simplest and most direct way to constrain a Pod to run only on nodes that have a specific label, such as 'disktype=ssd'. When you add a nodeSelector field to the Pod spec, the kube-scheduler filters nodes that do not have the matching label, ensuring the Pod lands on a node with an SSD.

Exam trap

The trap here is confusing tolerations (which allow scheduling onto tainted nodes) with node selection mechanisms like nodeSelector or nodeAffinity, leading candidates to pick D when they need a label-based constraint.

How to eliminate wrong answers

Option A is wrong because manually editing the kube-scheduler configuration is unnecessary and overly complex; node scheduling constraints are handled via Pod spec fields like nodeSelector, nodeAffinity, or taints/tolerations, not by modifying the scheduler itself. Option B is wrong because a DaemonSet runs a copy of the Pod on every node (or a subset defined by nodeSelector), but the question asks to ensure the Pod runs on a node with an SSD, not on all nodes. Option D is wrong because tolerations are used to allow Pods to schedule onto nodes with matching taints, not to select nodes based on labels like 'disktype=ssd'; tolerations alone do not guarantee placement on a specific node type.

189
Multi-Selectmedium

Which TWO of the following correctly describe the difference between Docker Compose and Kubernetes? (Choose 2)

Select 2 answers
A.Docker Compose can manage containers across multiple hosts
B.Docker Compose is suitable for production-grade deployments
C.Kubernetes provides built-in auto-scaling and self-healing
D.Kubernetes supports rolling updates and rollbacks
E.Both Docker Compose and Kubernetes use the same YAML format
AnswersC, D

Kubernetes offers features like HorizontalPodAutoscaler and ReplicaSet controllers for auto-scaling and self-healing.

Why this answer

Docker Compose is designed for single-host container orchestration with a simple YAML file, while Kubernetes is a multi-host container orchestration platform with advanced features like auto-scaling and self-healing.

190
Multi-Selecthard

Which THREE of the following are true about the Container Runtime Interface (CRI)? (Choose 3)

Select 3 answers
A.Docker natively implements the CRI
B.CRI is part of the Open Container Initiative (OCI)
C.CRI allows kubelet to communicate with different container runtimes
D.containerd implements the CRI
E.CRI-O is a lightweight runtime designed for Kubernetes
AnswersC, D, E

CRI defines the API between kubelet and container runtime.

Why this answer

CRI is a plugin interface that enables kubelet to use different container runtimes without recompiling. containerd and CRI-O are CRI-compliant runtimes. Docker was deprecated as a Kubernetes runtime and is not CRI-native; it uses dockershim.

191
MCQhard

An administrator wants to ensure that a pod only runs on nodes that have a specific GPU. Which mechanism should be used to achieve this?

A.Node affinity with requiredDuringSchedulingIgnoredDuringExecution
B.Tolerations and taints
C.Pod anti-affinity
D.ResourceQuota
AnswerA

Node affinity can require the pod to be scheduled on nodes with a specific label (e.g., 'gpu: true').

Why this answer

Node affinity allows you to constrain which nodes a pod can be scheduled on based on node labels, such as labeling nodes with 'gpu: true' and using requiredDuringSchedulingIgnoredDuringExecution.

192
MCQmedium

Which Kubernetes resource is best suited for running a batch processing job that must complete successfully exactly once?

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

Job is designed for batch processing that runs to completion.

Why this answer

A Kubernetes Job is designed specifically for batch processing tasks that need to run to completion exactly once. It creates one or more Pods and ensures that a specified number of them successfully terminate, making it ideal for workloads like data processing or backups that must finish without retries or restarts.

Exam trap

CNCF often tests the distinction between one-time batch processing (Job) and recurring scheduled tasks (CronJob), so candidates mistakenly choose CronJob when the question specifies 'exactly once' rather than 'on a schedule'.

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, which is used for continuous background services like logging or monitoring, not for one-time batch jobs. Option B is wrong because a Deployment manages a set of Pods to maintain a desired number of replicas running indefinitely, with rolling updates and self-healing, which is unsuitable for a job that must complete and not restart. Option C is wrong because a CronJob is used for scheduling recurring tasks on a time-based schedule, not for a one-time batch job that must run exactly once.

193
Multi-Selectmedium

Which TWO of the following are true about the Open Container Initiative (OCI)?

Select 2 answers
A.OCI requires the use of containerd
B.OCI defines the Dockerfile format
C.OCI is a Linux Foundation project
D.OCI specifies the image format and runtime specification
E.OCI defines the Container Runtime Interface (CRI)
AnswersC, D

OCI is hosted under the Linux Foundation.

Why this answer

OCI defines standards for container images and runtimes to ensure interoperability.

194
MCQeasy

Which of the following is an example of immutable infrastructure?

A.SSH into a server to apply patches
B.Manually installing packages on a running container
C.Using configuration management tools to update software on running servers
D.Rebuilding a server from a pre-baked image and replacing the old one
AnswerD

This is the essence of immutable infrastructure.

Why this answer

Immutable infrastructure means that once a server or container is deployed, it is never modified in place. Instead, any change requires building a new image and redeploying. Option D describes exactly this: rebuilding from a pre-baked image and replacing the old server, which is the core pattern of immutability in container orchestration (e.g., Kubernetes rolling updates or Recreate deployments).

Exam trap

CNCF often tests the misconception that configuration management tools (like Ansible or Puppet) are inherently immutable, but they are actually used for mutable infrastructure because they apply changes to running systems rather than replacing them entirely.

How to eliminate wrong answers

Option A is wrong because SSHing into a server to apply patches is a classic mutable infrastructure pattern — it modifies a running system in place, which breaks the immutability principle. Option B is wrong because manually installing packages on a running container directly alters its filesystem and state, making it mutable and unreproducible from the original image. Option C is wrong because using configuration management tools (like Ansible or Chef) to update software on running servers still mutates the live environment, which is the opposite of the immutable approach where changes are made only at the image build stage.

195
MCQmedium

A pod is in the 'Pending' state. Which of the following is a likely cause?

A.The liveness probe is failing
B.The container image is not found in the registry
C.No node has sufficient resources to run the pod
D.The container exited with OOMKilled
AnswerC

Insufficient resources cause the scheduler to keep the pod Pending.

Why this answer

A pod enters the 'Pending' state when it has been accepted by the API server but cannot be scheduled onto a node. The most common cause is insufficient cluster resources (CPU, memory, or ephemeral storage) on any available node to satisfy the pod's resource requests. The Kubernetes scheduler continuously evaluates node resource availability and will leave the pod in Pending until a suitable node is found or the request times out.

Exam trap

CNCF often tests the distinction between pod scheduling failures (Pending) and runtime failures (CrashLoopBackOff, OOMKilled, ImagePullBackOff), tempting candidates to confuse post-scheduling errors with pre-scheduling conditions.

How to eliminate wrong answers

Option A is wrong because a failing liveness probe causes the pod to be restarted (CrashLoopBackOff) or marked as Unhealthy, but does not prevent the pod from being scheduled; the pod must first be Running for probes to execute. Option B is wrong because an image not found in the registry results in an ImagePullBackOff or ErrImagePull error, which occurs after the pod is scheduled to a node, not while it is still in Pending. Option D is wrong because OOMKilled (exit code 137) is a container termination reason that occurs after the pod is Running, not during the scheduling phase; it would be visible in the pod status as CrashLoopBackOff or Terminated.

196
Multi-Selecthard

Which TWO statements accurately describe Kubernetes scheduling?

Select 2 answers
A.The kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints.
B.Tolerations allow a pod to be scheduled on a node with matching taints.
C.A pod with no resource requests will always be scheduled on the node with the most available resources.
D.Node affinity allows a pod to specify preferred or required nodes for scheduling.
E.Taints are applied to pods to prevent them from being scheduled on certain nodes.
AnswersA, D

The scheduler evaluates resource requests, affinity, taints/tolerations, etc., to place pods.

Why this answer

Option A is correct because the kube-scheduler is the default scheduler in Kubernetes that watches for newly created pods with no assigned node and selects an optimal node for them based on resource availability, constraints, policies, and affinity/anti-affinity rules. It uses a filtering phase to find feasible nodes and a scoring phase to rank them, ensuring efficient resource utilization.

Exam trap

Cisco often tests the distinction between taints (applied to nodes) and tolerations (applied to pods), and the trap here is confusing the direction of the relationship — candidates may incorrectly think taints are applied to pods to prevent scheduling on certain nodes.

197
MCQeasy

Which of the following is a key difference between containers and virtual machines?

A.Containers share the host OS kernel; VMs run a separate guest OS
B.Both containers and VMs share the host kernel
C.Containers have a full guest OS, VMs share the host kernel
D.Containers require a hypervisor, VMs do not
AnswerA

Containers are lightweight because they share the kernel.

Why this answer

The key difference is that containers virtualize at the operating system level, sharing the host OS kernel via namespaces and cgroups, while each virtual machine runs a full, separate guest OS on top of a hypervisor. This architectural distinction means containers are more lightweight and start faster, but VMs provide stronger isolation because they do not share the host kernel.

Exam trap

CNCF often tests the misconception that containers and VMs are fundamentally similar in kernel sharing, leading candidates to choose Option B, which incorrectly claims both share the host kernel.

How to eliminate wrong answers

Option B is wrong because it states both containers and VMs share the host kernel; in reality, VMs run a separate guest OS with its own kernel and do not share the host kernel. Option C is wrong because it reverses the relationship: containers do not have a full guest OS—they share the host kernel—while VMs run a full guest OS. Option D is wrong because it claims containers require a hypervisor and VMs do not; in fact, VMs require a hypervisor (Type 1 or Type 2) to manage guest OSes, while containers run directly on the host OS without a hypervisor.

198
MCQmedium

A Kubernetes cluster has a Deployment running three replicas of an application. You need to update the container image to a new version with zero downtime. Which approach is most appropriate?

A.Use 'kubectl set image deployment/<name> <container>=<new-image>' to trigger a rolling update
B.Manually delete each pod and rely on the ReplicaSet to recreate them with the new image
C.Delete the Deployment and recreate it with the new image
D.Scale the Deployment to zero and then scale back up with the new image
AnswerA

This command updates the image and initiates a rolling update, ensuring zero downtime.

Why this answer

Option A is correct because `kubectl set image deployment/<name> <container>=<new-image>` triggers a rolling update, which is the default update strategy for Deployments. This gradually replaces old pods with new ones, ensuring that the desired number of replicas is always available, thus achieving zero downtime.

Exam trap

CNCF often tests the misconception that manually deleting pods or scaling to zero is a valid zero-downtime strategy, but these actions cause service disruption because they do not maintain the desired number of available replicas during the update.

How to eliminate wrong answers

Option B is wrong because manually deleting pods does not update the Deployment's pod template; the ReplicaSet will recreate pods using the old image, not the new one. Option C is wrong because deleting the Deployment causes a period of unavailability until the new Deployment is created and pods are scheduled, violating zero downtime. Option D is wrong because scaling to zero removes all pods, causing downtime, and scaling back up with a new image requires a separate update step, which is not a zero-downtime approach.

199
MCQeasy

What is the purpose of the Container Runtime Interface (CRI)?

A.To manage container networking
B.To define a standard for container images
C.To orchestrate multi-container pods
D.To allow kubelet to communicate with different container runtimes
AnswerD

CRI abstracts the runtime implementation so kubelet can work with any CRI-compliant runtime.

Why this answer

The Container Runtime Interface (CRI) is a plugin interface that enables the kubelet to use a variety of container runtimes without needing to recompile the Kubernetes components. It defines the API for creating, starting, stopping, and deleting containers, allowing the kubelet to communicate with runtimes like containerd, CRI-O, or Docker (via dockershim, now deprecated). Option D is correct because the CRI's primary purpose is to abstract the runtime implementation from the kubelet, enabling interoperability.

Exam trap

The trap here is that candidates confuse the CRI with the CNI or OCI, assuming the CRI manages networking or image standards, when in fact it strictly defines the runtime API for container lifecycle operations.

How to eliminate wrong answers

Option A is wrong because container networking is managed by the Container Network Interface (CNI), not the CRI. Option B is wrong because container image standards are defined by the Open Container Initiative (OCI) image spec, not the CRI. Option C is wrong because orchestrating multi-container pods is a core function of the kubelet and the Kubernetes control plane, not the CRI; the CRI only handles the low-level runtime operations for individual containers within a pod.

200
MCQhard

Which Kubernetes resource can be used to define network policies that control traffic between pods?

A.Service
B.PodSecurityPolicy
C.NetworkPolicy
D.Ingress
AnswerC

Correct. NetworkPolicy defines rules for pod-to-pod communication.

Why this answer

NetworkPolicy is a Kubernetes resource that defines how groups of pods are allowed to communicate with each other and other network endpoints. It works by specifying ingress and egress rules using pod selectors, namespace selectors, and IP blocks, and is enforced by a network plugin (CNI) that supports it, such as Calico or Cilium.

Exam trap

CNCF often tests the misconception that Ingress or Service can restrict pod-to-pod traffic, but Ingress only handles external HTTP/HTTPS traffic and Service only provides connectivity, not policy enforcement.

How to eliminate wrong answers

Option A is wrong because a Service is an abstraction that exposes a set of pods as a network service, but it does not control traffic between pods via rules; it only provides stable endpoints and load balancing. Option B is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) controls security-sensitive aspects of pod specification (e.g., privilege escalation, host namespaces), not network traffic between pods. Option D is wrong because an Ingress manages external HTTP/HTTPS traffic to services inside the cluster, not east-west traffic between pods.

201
MCQhard

Your application consists of a frontend and a backend. The frontend needs to communicate with the backend using a stable DNS name. The backend is deployed as a Deployment with 3 replicas. Which Kubernetes resource should you create to provide a stable DNS name for the backend?

A.EndpointSlice
B.Service of type NodePort
C.Ingress
D.Service of type ClusterIP
AnswerD

A ClusterIP Service provides a stable internal IP and DNS name for pod-to-pod communication within the cluster.

Why this answer

A Service of type ClusterIP provides a stable virtual IP and DNS name (e.g., my-service.namespace.svc.cluster.local) that load-balances traffic across the backend Pods. This is the correct resource because the frontend only needs a stable DNS name for internal cluster communication, and ClusterIP is the default Service type that fulfills this requirement without exposing the backend externally.

Exam trap

CNCF often tests the misconception that a Service of type NodePort is required for any DNS-based communication, but the trap here is that ClusterIP is the correct choice for internal cluster DNS stability, while NodePort is only needed for external access.

How to eliminate wrong answers

Option A is wrong because EndpointSlice is a resource that tracks network endpoints (IPs and ports) for a Service, but it does not provide a DNS name or stable endpoint itself. Option B is wrong because a Service of type NodePort exposes the backend on a static port on every Node's IP, which is intended for external access and introduces unnecessary exposure and complexity for internal-only communication. Option C is wrong because Ingress is an API object that manages external HTTP/HTTPS routing to Services, not a resource that provides a stable DNS name for internal cluster communication.

202
MCQhard

A team notices that a ReplicaSet is not creating the desired number of pods. The ReplicaSet YAML is correctly configured with replicas: 3. The cluster has sufficient resources. What is the most likely cause?

A.The ReplicaSet is paused
B.The pod template references an invalid image pull secret
C.The nodeSelector does not match any node
D.A ResourceQuota in the namespace limits the number of pods
AnswerB

Invalid image pull secret would cause pods to fail with ImagePullBackOff, reducing the ready count.

Why this answer

Option B is correct because an invalid image pull secret in the pod template prevents the kubelet from authenticating with the container registry, causing the pod creation to fail. The ReplicaSet controller attempts to create pods, but the scheduler cannot pull the image, so the pods remain in a pending or ImagePullBackOff state, never reaching the desired count of 3.

Exam trap

The trap here is that candidates often assume a nodeSelector mismatch or ResourceQuota is the issue, but the question specifies 'not creating the desired number of pods' — a nodeSelector mismatch still creates the pod object, while an invalid image pull secret prevents the pod from becoming Ready, causing the ReplicaSet to appear to not create pods when in fact it creates them but they fail to run.

How to eliminate wrong answers

Option A is wrong because ReplicaSets do not have a 'paused' field; only Deployments have a paused status, which suspends rollout but does not affect ReplicaSet pod creation directly. Option C is wrong because if the nodeSelector does not match any node, the scheduler cannot place the pod, but the ReplicaSet would still create the pod object (it would remain in Pending state), not fail to create it entirely. Option D is wrong because a ResourceQuota limits the total number of pods in a namespace, but the question states the cluster has sufficient resources, and a quota would cause pod creation to fail with a specific error, not silently prevent creation; the ReplicaSet would still attempt to create pods and report the quota violation.

203
MCQmedium

What is the difference between a liveness probe and a readiness probe?

A.Liveness probe checks if the container is ready to serve traffic
B.Readiness probe indicates if the container is healthy; liveness indicates if it should be restarted
C.Liveness probe indicates if the container is alive; if it fails, the container is restarted
D.Both probes serve the same purpose but with different endpoints
AnswerC

Liveness probes restart unhealthy containers; readiness probes control traffic routing.

Why this answer

A liveness probe indicates if a container is running; if it fails, kubelet restarts the container. A readiness probe indicates if a container is ready to serve traffic; if it fails, the Pod is removed from Service endpoints.

204
Multi-Selectmedium

Which TWO statements about containers compared to virtual machines are correct? (Select 2)

Select 2 answers
A.Containers have lower overhead than virtual machines
B.Containers are lightweight and share the host OS kernel
C.Virtual machines share the host OS kernel
D.Each container runs its own operating system kernel
E.Virtual machines provide weaker isolation than containers
AnswersA, B

Containers do not need a full guest OS, so they have lower overhead.

Why this answer

Options B and D are correct. Containers share the host OS kernel, making them lightweight and portable (B). They have lower overhead than VMs because they do not require a full OS per instance (D).

Option A is false—containers do not have a separate kernel. Option C is false—VMs can run any OS, but containers share the host kernel. Option E is false—VMs have stronger isolation but at the cost of more resources.

205
MCQhard

You have a microservices application where Service A needs to discover the IP of Service B. Both services run in the same Kubernetes cluster. Which approach is the most Kubernetes-native way for Service A to reach Service B?

A.Use the Kubernetes DNS service to resolve the Service name 'service-b'
B.Use an external service registry like Consul or etcd
C.Hardcode the cluster IP of Service B in the configuration of Service A
D.Use environment variables injected by the Kubernetes API into each pod
AnswerA

Kubernetes DNS automatically creates DNS records for Services, making this the standard approach for service discovery.

Why this answer

Kubernetes has a built-in DNS service (typically CoreDNS) that automatically creates DNS records for Services. When Service A resolves the name 'service-b' (or 'service-b.<namespace>.svc.cluster.local'), the DNS returns the cluster IP of Service B's Service object, which then load-balances traffic to the healthy Pods. This is the most Kubernetes-native approach because it leverages the platform's own service discovery mechanism without external dependencies.

Exam trap

The trap here is that candidates may think environment variables (Option D) are the primary Kubernetes-native method, but the exam emphasizes DNS as the modern, recommended approach, while environment variables are a legacy fallback with limitations.

How to eliminate wrong answers

Option B is wrong because using an external service registry like Consul or etcd adds unnecessary complexity and is not Kubernetes-native; Kubernetes already provides DNS-based service discovery. Option C is wrong because hardcoding the cluster IP of Service B is fragile — cluster IPs can change if the Service is recreated, and this approach does not handle scaling or Pod restarts. Option D is wrong because while Kubernetes does inject environment variables (e.g., SERVICE_B_SERVICE_HOST) for Services created before the Pod, this method is deprecated, less reliable (depends on Pod creation order), and does not update dynamically if the Service IP changes.

206
MCQmedium

You are designing a microservices application that requires each service to be independently deployable and scalable. The services communicate over HTTP and need service discovery. Which orchestration feature BEST addresses the need for service discovery?

A.Kubernetes Service
B.Horizontal Pod Autoscaler
C.ConfigMap
D.PersistentVolume
AnswerA

A Service provides a stable endpoint (IP and DNS name) for a set of pods, enabling service discovery.

Why this answer

Option C is correct. Kubernetes Services provide stable IP addresses and DNS names that enable service discovery within the cluster. Option A refers to scaling, not discovery.

Option B is about configuration, not discovery. Option D is a storage abstraction.

207
MCQhard

A user creates a Service of type ClusterIP with a selector matching pods labeled 'app: myapp'. However, a pod named 'myapp-pod' with label 'app: myapp' is not receiving traffic. What is a possible reason?

A.The Service type should be NodePort
B.The pod is in a different namespace
C.The pod's readiness probe is failing
D.The pod's container port is not defined
AnswerC

Services only forward traffic to pods that pass readiness probes.

Why this answer

Services target pods by selector; if the pod is not ready due to failing readiness probes, it won't receive traffic.

208
MCQmedium

You create a Service of type ClusterIP with the name 'my-service' in the 'default' namespace. What DNS name resolves to the service's cluster IP from a pod in the same namespace?

A.my-service.default.svc.cluster.local
B.my-service.svc.cluster.local
C.my-service.default.cluster.local
D.my-service.cluster.local
AnswerA

This is the fully qualified domain name, but from the same namespace, just 'my-service' also works. However, this is a correct FQDN.

Why this answer

Option A is correct because Kubernetes DNS resolves a Service's ClusterIP using the fully qualified domain name (FQDN) format `<service>.<namespace>.svc.cluster.local`. Since the Service 'my-service' is in the 'default' namespace, a pod in the same namespace can reach it via `my-service.default.svc.cluster.local`. The DNS query returns the ClusterIP of the Service, allowing pods to communicate with it reliably.

Exam trap

The trap here is that candidates often forget the mandatory 'svc' subdomain in the FQDN, mistakenly thinking the namespace directly precedes 'cluster.local', or they omit the namespace entirely when the Service is in the same namespace as the pod.

How to eliminate wrong answers

Option B is wrong because it omits the namespace component; the correct FQDN must include the namespace (e.g., 'default') before 'svc'. Option C is wrong because it uses 'cluster.local' instead of 'svc.cluster.local'; the 'svc' subdomain is mandatory for Service DNS records. Option D is wrong because it drops both the namespace and the 'svc' subdomain, resulting in an incomplete and unresolvable DNS name.

209
MCQmedium

A Kubernetes administrator needs to restrict inbound traffic to a set of pods. Only pods with the label 'app: frontend' in the same namespace should be allowed to reach the pods on TCP port 8080. Which resource should be used?

A.Ingress
B.PodSecurityPolicy
C.ServiceAccount
D.NetworkPolicy
AnswerD

NetworkPolicy defines network access rules between pods.

Why this answer

NetworkPolicy is the correct resource because it is a Kubernetes-native object that defines how groups of pods are allowed to communicate with each other and other network endpoints. By specifying a pod selector matching 'app: frontend' and an ingress rule allowing TCP port 8080, you can restrict inbound traffic to only those pods with that label in the same namespace.

Exam trap

The trap here is that candidates confuse Ingress (external HTTP routing) with NetworkPolicy (internal pod-to-pod traffic control), leading them to choose Ingress when the question explicitly restricts inbound traffic within the same namespace.

How to eliminate wrong answers

Option A is wrong because Ingress is an API object that manages external HTTP/S traffic to services, not pod-to-pod traffic within the cluster. Option B is wrong because PodSecurityPolicy is a cluster-level resource that controls security-sensitive aspects of pod specification (e.g., privilege escalation, host namespaces), not network traffic rules. Option C is wrong because a ServiceAccount provides an identity for processes running in a pod to authenticate to the Kubernetes API server, it does not enforce network-level access controls.

210
Multi-Selecthard

Which THREE of the following are correct statements about Kubernetes Deployments?

Select 3 answers
A.Deployments support canary deployments natively
B.A Deployment manages ReplicaSets
C.A Deployment directly manages Pods
D.The default update strategy is RollingUpdate
E.Deployment supports rolling back to an earlier revision
AnswersB, D, E

Deployment creates and manages ReplicaSets to ensure the desired state.

Why this answer

A Deployment manages ReplicaSets, which in turn manage Pods. This is the core abstraction: the Deployment controller creates and updates ReplicaSets to achieve the desired state, and each ReplicaSet ensures a specified number of Pod replicas are running. This layered architecture enables features like rolling updates and rollbacks without the Deployment directly interacting with individual Pods.

Exam trap

Cisco often tests the misconception that Deployments directly manage Pods, when in fact they manage ReplicaSets, and that canary deployments are a built-in feature of Deployments, whereas they require external traffic management.

211
MCQmedium

A pod is in CrashLoopBackOff. You check the logs and see 'Error: container process not found'. What is the most likely cause?

A.The pod has insufficient memory
B.The liveness probe is misconfigured
C.The container's entrypoint or command is incorrect
D.The container image is missing
AnswerC

If the entrypoint doesn't exist or fails, the container exits, causing CrashLoopBackOff.

Why this answer

The container's entrypoint or command may be misconfigured, causing the container to exit immediately.

← PreviousPage 3 of 3 · 211 questions total

Ready to test yourself?

Try a timed practice session using only Kcna Container Orchestration questions.