CCNA Kcna Container Orchestration Questions — Page 3 of 3

151

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.

Practice this question →

152

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

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.

Practice this question →

153

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

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.

Practice this question →

154

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.

Practice this question →

155

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.

Practice this question →

156

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.

Practice this question →

157

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.

Practice this question →

158

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.

Practice this question →

159

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.

Practice this question →

160

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

`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.

Practice this question →

161

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.

Practice this question →

162

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.

Practice this question →

163

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.

Practice this question →

164

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

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.

Practice this question →

165

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 determines if a container is still running (alive). If the liveness probe fails, Kubernetes restarts the container based on the `restartPolicy`. This is distinct from a readiness probe, which checks if a container is ready to accept traffic and removes it from Service endpoints if it fails.

Exam trap

The trap here is that candidates confuse the purpose of liveness and readiness probes, often thinking liveness controls traffic routing or that readiness triggers restarts, when in fact liveness governs restarts and readiness governs traffic inclusion.

How to eliminate wrong answers

Option A is wrong because it describes the function of a readiness probe, not a liveness probe; a liveness probe checks if the container is alive, not if it is ready to serve traffic. Option B is wrong because it reverses the roles: a readiness probe indicates if the container is ready to serve traffic, while a liveness probe indicates if it is healthy (alive) and should be restarted on failure. Option D is wrong because the two probes serve different purposes—liveness for restarting unhealthy containers, readiness for traffic routing—and they can use different endpoints (e.g., `/healthz` vs `/ready`).

Practice this question →

166

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 A and B are correct. Containers have lower overhead than virtual machines because they do not require a separate guest OS per instance, making them more lightweight. Containers share the host OS kernel, which allows them to be efficient and portable.

In contrast, each virtual machine includes a full guest OS running on top of a hypervisor, leading to higher resource usage. Option C is false because virtual machines have their own kernel, not shared with the host. Option D is false because containers share the host kernel and do not run their own OS kernel.

Option E is false because virtual machines provide stronger isolation due to hardware virtualization.

Practice this question →

167

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.

Practice this question →

168

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

Kubernetes Service is the correct choice because it provides a stable network endpoint (IP address and DNS name) for a set of pods, enabling service discovery via DNS or environment variables. This allows microservices to locate and communicate with each other over HTTP without hardcoding IP addresses, which is essential for independent deployability and scalability.

Exam trap

A common trap in CNCF exams is confusing the Horizontal Pod Autoscaler (HPA), which scales pods, with the Kubernetes Service, which provides stable network endpoints for service discovery. Remember: HPA handles scaling, Service handles discovery.

How to eliminate wrong answers

Option B (Horizontal Pod Autoscaler) is wrong because it only adjusts the number of pod replicas based on CPU/memory metrics, not service discovery. Option C (ConfigMap) is wrong because it is used for injecting configuration data (e.g., environment variables) into pods, not for network endpoint resolution. Option D (PersistentVolume) is wrong because it provides storage abstraction for stateful workloads, not network-level service location.

Practice this question →

169

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

A failing readiness probe causes the pod to be removed from the Service's Endpoints list, even if the pod is running and matches the selector. The kubelet checks the readiness probe periodically; if it fails, the pod is marked as not ready, and the Service controller removes its IP from the Endpoints object, preventing traffic from being forwarded to it.

Exam trap

The CNCF-KCNA exam often tests the distinction between liveness and readiness probes; the trap here is that candidates assume a running pod automatically receives traffic, overlooking that readiness probes explicitly gate traffic admission.

How to eliminate wrong answers

Option A is wrong because changing the Service type to NodePort would expose the Service externally but does not affect internal traffic routing to a pod that is not receiving traffic due to readiness issues; the core problem is pod readiness, not Service type. Option B is wrong because a Service only selects pods within its own namespace; if the pod were in a different namespace, it would not match the selector at all, and the question states the pod has the matching label, implying it is in the same namespace. Option D is wrong because while defining a container port is a best practice, it is not required for traffic to reach the pod; the Service can forward traffic to any port the pod listens on, and the absence of a container port definition does not prevent the pod from receiving traffic if the port is known.

Practice this question →

170

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

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.

Practice this question →

171

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.

Practice this question →

172

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

The KCNA exam 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.

Practice this question →

173

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.

Practice this question →