Kubernetes and Cloud Native Associate KCNA KCNA Questions 526–600 | Page 8/14

526

Multi-Selectmedium

Which two of the following are responsibilities of the kubelet? (Select TWO.)

Select 2 answers

A.Reporting the node's status to the control plane

B.Implementing network rules for services

C.Assigning pods to nodes based on resource availability

D.Storing cluster state in a key-value store

E.Ensuring that containers are running in a pod as specified

AnswersA, E

The kubelet sends node status updates to the API server.

Why this answer

The kubelet ensures containers are running and healthy, and reports node status. Options A and D are correct.

Full explanation →

527

MCQeasy

Which component runs on every worker node and is responsible for ensuring that containers are running in a pod according to the pod specification?

A.kube-scheduler

B.kubelet

C.container runtime

D.kube-proxy

AnswerB

The kubelet ensures containers defined in pod specs are running and healthy.

Why this answer

The kubelet is the primary node agent that ensures containers are running as expected.

Full explanation →

528

MCQeasy

A Pod has two containers. You need to see the logs of the second container named 'sidecar'. Which kubectl command should you use?

A.kubectl logs pod-name --container sidecar

B.kubectl logs sidecar pod-name

C.kubectl logs pod-name sidecar

D.kubectl logs pod-name -c sidecar

AnswerD

-c specifies the container name.

Why this answer

When a pod has multiple containers, the -c flag specifies which container to get logs from.

Full explanation →

529

MCQhard

You have a microservices application with a frontend service that needs to communicate with a backend service running in a different namespace ('backend-ns'). The default namespace for the frontend is 'frontend-ns'. What DNS name should the frontend use to reach the backend service named 'backend-svc'?

A.backend-svc.frontend-ns.svc.cluster.local

B.backend-svc.backend-ns.svc.cluster.local

C.backend-svc.backend-ns.cluster.local

D.backend-svc

AnswerB

This is the correct FQDN for cross-namespace service discovery.

Why this answer

In Kubernetes, DNS names for services follow the pattern <service>.<namespace>.svc.cluster.local. For cross-namespace access, the fully qualified name is backend-svc.backend-ns.svc.cluster.local. Option A is the short name within the same namespace; Option C is the cluster domain but incorrect namespace; Option D is not a valid DNS pattern.

Full explanation →

530

MCQeasy

Which of the following is a core principle of the 12-factor app methodology?

A.Treat logs as event streams

B.Store configuration in the application code

C.Store logs in the local filesystem of each container

D.Use shared filesystems for persistent storage

AnswerA

Logs should be emitted as stdout/stderr and collected by a log aggregator.

Why this answer

The 12-factor app methodology emphasizes treating logs as event streams, not files, to enable centralized processing.

Full explanation →

531

MCQhard

Which of the following is a characteristic of immutable infrastructure?

A.Infrastructure is version-controlled using Git

B.Infrastructure components are never changed after deployment; they are replaced

C.Servers are updated in-place with configuration management tools

D.Containers are used to ensure portability

AnswerB

Immutable infrastructure replaces components rather than modifying them.

Why this answer

Immutable infrastructure means that instead of modifying existing servers, new instances are created from an image and old ones are replaced.

Full explanation →

532

MCQhard

A user wants to ensure that a Deployment undergoes a rolling update with zero downtime, and that new Pods are fully ready before old Pods are terminated. Which field in the Deployment spec controls this behavior?

A.spec.minReadySeconds

B.spec.strategy.rollingUpdate.maxUnavailable and maxSurge

C.spec.replicas

D.spec.template.spec.containers[].resources

AnswerB

These fields control how many Pods can be unavailable and how many can be created above the desired count during a rolling update.

Why this answer

Option B is correct because `spec.strategy.rollingUpdate.maxUnavailable` and `maxSurge` control how many Pods can be unavailable and how many can be created above the desired count during a rolling update. Setting `maxUnavailable=0` ensures no old Pods are terminated until new Pods are fully ready, achieving zero-downtime updates. `maxSurge` allows extra Pods to be created before old ones are removed, enabling a controlled rollout.

Exam trap

CNCF often tests the misconception that `minReadySeconds` controls the rolling update order, but it only affects the Pod's availability status after readiness, not the termination timing of old Pods.

How to eliminate wrong answers

Option A is wrong because `spec.minReadySeconds` defines the minimum time a Pod must be ready before it is considered available, but it does not control the order or parallelism of Pod termination during a rolling update. Option C is wrong because `spec.replicas` sets the desired number of Pod replicas but has no direct influence on the update strategy or the readiness check before terminating old Pods. Option D is wrong because `spec.template.spec.containers[].resources` defines CPU and memory requests/limits for containers, which affects scheduling but not the rolling update behavior or Pod readiness gating.

Full explanation →

533

MCQeasy

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

A.To check if the container is alive and restart it if not

B.To verify the container's CPU and memory usage

C.To ensure the container can write to persistent storage

D.To check if the container is ready to accept traffic

AnswerD

Readiness probes indicate whether the pod should receive traffic; if not, the pod is removed from services.

Why this answer

Readiness probes determine if a container is ready to serve traffic; if it fails, the pod is removed from service endpoints.

Full explanation →

534

Matchingmedium

Match each Kubernetes component to its role in the control plane.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Exposes the Kubernetes API and acts as the front-end

Runs controller processes like Node and Replication controllers

Assigns pods to nodes based on resource availability

Consistent and highly-available key-value store for all cluster data

Interacts with underlying cloud provider's APIs

Why these pairings

These are the core control plane components in a Kubernetes cluster.

Full explanation →

535

MCQeasy

A company wants to ensure that a database pod runs on a node with SSD storage. How should this be achieved?

A.Label SSD nodes with 'disk=ssd' and add a nodeSelector to the pod

B.Set a resource request for local SSD storage in the pod spec

C.Use pod anti-affinity to avoid non-SSD nodes

D.Add a taint to nodes without SSDs and a toleration to the pod

AnswerA

nodeSelector ensures the pod is scheduled only on nodes with the matching label.

Why this answer

Option A is correct because nodeSelector is a field in the Pod spec that constrains which nodes the Pod can be scheduled on, based on node labels. By labeling nodes with SSD storage as 'disk=ssd' and adding a nodeSelector with that label to the Pod, Kubernetes will only schedule the Pod on nodes that have the matching label, ensuring it runs on SSD storage.

Exam trap

Cisco often tests the distinction between scheduling constraints (nodeSelector/node affinity) and repulsion mechanisms (taints/tolerations), trapping candidates who confuse tolerations as a way to select nodes rather than as a way to bypass node restrictions.

How to eliminate wrong answers

Option B is wrong because resource requests for local SSD storage are not supported in the standard Kubernetes resource model; storage is requested via PersistentVolumeClaims, not as a compute resource in the Pod spec. Option C is wrong because pod anti-affinity is used to avoid co-locating Pods on the same node or topology, not to select nodes based on hardware characteristics like SSD storage. Option D is wrong because taints and tolerations are used to repel Pods from nodes unless they have a matching toleration, but they do not actively select nodes with specific hardware; a toleration would allow the Pod to run on non-SSD nodes if they are not tainted, and tainting all non-SSD nodes is impractical and does not guarantee scheduling on SSD nodes.

Full explanation →

536

MCQeasy

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

A.To allow kubelet to use different container runtimes

B.To manage persistent storage for containers

C.To provide a network plugin interface for pods

D.To define a standard for container images

AnswerA

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

Why this answer

CRI is a plugin interface that enables kubelet to use different container runtimes without needing to recompile.

Full explanation →

537

MCQhard

In a CI pipeline, image scanning is integrated to detect vulnerabilities. What is the best practice when a critical vulnerability is found in a base image?

A.Fail the pipeline and notify the team to fix the base image

B.Deploy to production and patch later

C.Automatically patch the image in the pipeline

D.Ignore the vulnerability and proceed with deployment

AnswerA

Failing the pipeline enforces security.

Why this answer

The pipeline should fail so that the vulnerability is addressed before deployment, preventing insecure images from reaching production.

Full explanation →

538

MCQeasy

Which CNCF project maturity level indicates that a project has adopted the CNCF Code of Conduct and is considered early-stage?

A.Sandbox

B.Incubating

C.Graduated

D.Experimental

AnswerA

Sandbox projects are early-stage and have accepted the CNCF Code of Conduct.

Why this answer

The CNCF has three maturity levels: sandbox (early-stage), incubating (growing), and graduated (mature). Sandbox projects are early-stage and have accepted the CNCF Code of Conduct.

Full explanation →

539

MCQhard

You notice that a newly created Pod remains in 'Pending' state. Which of the following is the MOST likely cause?

A.The Pod manifest has a syntax error

B.The container image does not exist

C.There are insufficient resources available on any node to meet the Pod's requests

D.The Service does not exist

AnswerC

Scheduler cannot place the Pod, so it stays Pending.

Why this answer

The scheduler cannot find a node that satisfies the Pod's resource requirements (CPU/memory requests), node affinity, or taints/tolerations.

Full explanation →

540

Multi-Selecteasy

Which TWO of the following are characteristics of microservices architecture? (Choose 2)

Select 2 answers

A.All services share the same database

B.Services can be deployed independently

C.Communication between services is often via APIs

D.The entire application is deployed as a single unit

E.Services are tightly coupled

AnswersB, C

Each microservice can be developed, deployed, and scaled independently.

Why this answer

Option B is correct because microservices architecture is defined by the ability to deploy each service independently without affecting other services. This independence enables teams to update, scale, and roll back individual components, which is a core principle of container orchestration platforms like Kubernetes that manage these services as separate units.

Exam trap

The trap here is that candidates confuse microservices with service-oriented architecture (SOA) or mistakenly think that sharing a database or tight coupling is acceptable, when in fact microservices require database-per-service and loose coupling to achieve independent deployability.

Full explanation →

541

MCQhard

A pod has resource requests of 512Mi memory and 500m CPU, and limits of 1Gi memory and 1 CPU. The node has 4Gi memory and 2 CPU cores. If the pod tries to use 700m CPU, what will happen?

A.The pod will be throttled to 500m CPU

B.The pod will be allowed to use 700m CPU

C.The pod will be evicted from the node

D.The pod will be terminated for exceeding the limit

AnswerB

The pod can use up to the CPU limit (1000m) if the node has capacity.

Why this answer

The pod's CPU request is 500m, and its CPU limit is 1 CPU (1000m). When the pod attempts to use 700m CPU, it is below the limit of 1000m, so it is allowed to burst up to that amount. Kubernetes uses the CPU request for scheduling and the limit for throttling; since 700m is within the limit, no throttling occurs.

The pod is not evicted or terminated because it has not exceeded its memory limit or violated any resource constraints.

Exam trap

The trap here is that candidates confuse CPU requests with limits, thinking that exceeding the request triggers throttling or eviction, when in fact throttling only occurs at the limit and eviction is tied to memory or node pressure, not CPU usage below the limit.

How to eliminate wrong answers

Option A is wrong because throttling to 500m CPU would only occur if the pod exceeded its CPU limit, but 700m is below the 1000m limit, so the pod is allowed to burst. Option C is wrong because eviction happens when a node runs out of resources (e.g., memory pressure) or when a pod exceeds its memory limit, not for CPU usage below the limit. Option D is wrong because termination for exceeding a limit applies only when the pod surpasses its memory limit or violates a hard resource constraint; CPU usage below the limit does not trigger termination.

Full explanation →

542

MCQmedium

A team is using Kustomize to manage configurations for different environments. They want to create a variant of a base deployment that uses a different number of replicas. Which Kustomize feature should they use?

A.Generators

B.Patches

C.Bases

D.Components

AnswerB

Why this answer

Kustomize uses overlays to customize bases for different environments. Patches are used to modify specific fields. Option B (Patches) is correct for changing replicas.

Option A (Bases) is the common configuration. Option C (Components) is a newer feature for reusable pieces. Option D (Generators) creates ConfigMaps/Secrets.

Full explanation →

543

MCQeasy

A developer wants to run a one-time task that creates a database schema and then exits. Which Kubernetes workload type is most appropriate?

A.DaemonSet

B.StatefulSet

C.Deployment

D.Job

AnswerD

Jobs run to completion.

Why this answer

A Job is the correct choice because it is designed for finite, one-time tasks that run to completion, such as creating a database schema. Unlike long-running workloads, a Job creates one or more Pods and ensures they terminate successfully after the task finishes, making it ideal for batch processing or initialization tasks.

Exam trap

The trap here is that candidates confuse a one-time task with a Deployment because they think of 'running a container' generically, forgetting that Deployments enforce a restart policy that would keep the task running indefinitely.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on all (or selected) nodes, intended for continuous background services like logging or monitoring, not for one-time tasks. Option B is wrong because a StatefulSet is used for stateful applications requiring stable, unique network identities and persistent storage, such as databases, and is designed for long-running rather than ephemeral tasks. Option C is wrong because a Deployment manages a set of identical Pods with a desired replica count, ensuring they run continuously and are automatically restarted if they exit, which is unsuitable for a task that should exit after completion.

Full explanation →

544

MCQhard

In a container image built from a Dockerfile, what is the purpose of the CMD instruction?

A.To specify a command that always runs at build time

B.To copy files into the image

C.To provide default arguments for the ENTRYPOINT instruction

D.To define environment variables

AnswerC

CMD can provide default arguments to ENTRYPOINT, or be the main command if ENTRYPOINT is not set.

Why this answer

CMD provides defaults for an executing container, which can be overridden by command-line arguments. It sets the command to run when the container starts.

Full explanation →

545

MCQhard

Which of the following is a key principle of the 12-factor app methodology related to managing configuration?

A.Store configuration in the application code

B.Use environment variables for configuration

C.Embed configuration in the build process

D.Use a configuration file in the application directory

AnswerB

Environment variables provide a clean separation between code and config, allowing easy changes across environments.

Why this answer

The 12-factor app methodology states that configuration should be stored in environment variables (or external to the code) to vary between deployments without changing code. Hardcoding is the opposite. ConfigMaps are Kubernetes-specific but the principle is broader.

Secrets are for sensitive data but not the only way.

Full explanation →

546

Multi-Selecthard

Which TWO of the following are valid reasons to use a DaemonSet instead of a Deployment? (Select 2)

Select 2 answers

A.You need to run exactly one pod per node for log collection

B.You need to deploy a monitoring agent that should run on every node

C.You need to ensure a pod runs on the control-plane node only

D.You need to run a batch job that completes and exits

E.You need to run a stateless web application with multiple replicas

AnswersA, B

DaemonSets ensure one pod per node.

Why this answer

DaemonSets run a pod on each node, ideal for logging and monitoring agents. They are not for stateless apps or batch jobs.

Full explanation →

547

MCQmedium

A Deployment named 'app-deploy' is configured with strategy type: RollingUpdate. You want to update the container image to a new version. What kubectl command should you use?

A.kubectl apply -f updated-deployment.yaml

B.kubectl edit deployment app-deploy

C.kubectl patch deployment app-deploy -p '{"spec":{"template":{"spec":{"containers":[{"name":"app","image":"new:tag"}]}}}}'

D.kubectl set image deployment/app-deploy app=new:tag

AnswerD

This directly updates the container image.

Why this answer

kubectl set image is the standard declarative command to update the container image in a Deployment.

Full explanation →

548

Multi-Selectmedium

Which THREE of the following are valid ways to expose a Service to external traffic? (Select exactly three.)

Select 3 answers

A.Ingress

B.ExternalName

C.ClusterIP

D.NodePort

E.LoadBalancer

AnswersA, D, E

Ingress provides HTTP/HTTPS routing to services.

Why this answer

NodePort, LoadBalancer, and Ingress are methods to expose services externally. ClusterIP is internal only. ExternalName maps to an external DNS name but does not expose via external IP.

Full explanation →

549

Multi-Selecthard

Which THREE are responsibilities of the OpenTelemetry project? (Select three.)

Select 3 answers

A.Visualize telemetry data

B.Store long-term telemetry data

C.Provide instrumentation libraries

D.Define a standard for telemetry data

E.Provide a vendor-agnostic Collector

AnswersC, D, E

Why this answer

OpenTelemetry provides SDKs for instrumentation, a collector for processing, and APIs for standards.

Full explanation →

550

MCQeasy

What is the primary advantage of using Helm to package a Kubernetes application?

A.It automatically scales applications based on load

B.It enforces security policies on deployments

C.It provides a templating engine to parameterize Kubernetes manifests

D.It manages network policies between services

AnswerC

Helm uses Go templates to allow users to inject values into manifests.

Why this answer

Helm packages Kubernetes manifests into a single chart, allowing easy installation, upgrades, and rollbacks with parameterization via values.yaml.

Full explanation →

551

Multi-Selectmedium

Which TWO of the following are best practices for implementing observability in a cloud-native environment?

Select 2 answers

A.Store all raw observability data indefinitely for forensic analysis

B.Use only metrics and avoid logs to reduce complexity

C.Add unique request IDs to logs for end-to-end tracing correlation

D.Randomly sample all traces and logs to reduce storage

E.Use structured logging (e.g., JSON format) for easier automated parsing

AnswersC, E

Request IDs help correlate logs across microservices for tracing.

Why this answer

Option C is correct because adding unique request IDs (e.g., via OpenTelemetry trace IDs or custom correlation IDs) to logs enables end-to-end tracing across microservices. This allows operators to correlate a single user request as it traverses multiple services, which is essential for debugging distributed systems in a cloud-native environment.

Exam trap

Cisco often tests the misconception that 'more data is always better' (Option A) or that 'simplifying to one data type is efficient' (Option B), while the correct approach balances cost, performance, and diagnostic value through structured logging and correlation IDs.

Full explanation →

552

MCQeasy

Which Open Container Initiative (OCI) specification defines the format of container images?

A.Runtime Spec

B.Image Spec

C.Container Runtime Interface (CRI)

D.Dockerfile specification

AnswerB

OCI Image Spec standardizes container image format.

Why this answer

The OCI Image Spec defines the format and content of container images, including the manifest, configuration, and layers. This ensures that any OCI-compliant runtime can run images built by any OCI-compliant tool, enabling interoperability across different container platforms.

Exam trap

The trap here is confusing the OCI Runtime Spec (which deals with running containers) with the OCI Image Spec (which deals with packaging images), or mistaking the Kubernetes CRI plugin interface for an OCI standard.

How to eliminate wrong answers

Option A is wrong because the OCI Runtime Spec defines the lifecycle and configuration of running containers (e.g., bundle format, state machine), not the image format. Option C is wrong because the Container Runtime Interface (CRI) is a Kubernetes API for integrating container runtimes (like containerd or CRI-O), not an OCI specification for image format. Option D is wrong because the Dockerfile specification is a Docker-specific build instruction format, not an OCI standard; OCI images are built from layers, not directly from Dockerfiles.

Full explanation →

553

Multi-Selectmedium

Which TWO of the following are true about Kubernetes Services? (Select 2)

Select 2 answers

A.Services automatically handle Pod replication and scaling.

B.Services can distribute traffic across Pods using labels and selectors.

C.Services can only expose Pods internally within the cluster.

D.Services provide a stable IP address and DNS name for a set of Pods.

E.Services are required for Pods to have persistent storage.

AnswersB, D

Services use label selectors to target Pods.

Why this answer

Services provide a stable IP and DNS name, and they load balance traffic across Pods. Services are not used for stateful storage (use StatefulSet or PVC) and they do not manage Pod replicas (Deployment does).

Full explanation →

554

MCQeasy

What is the smallest deployable unit in Kubernetes?

A.Deployment

B.Node

C.Pod

D.Container

AnswerC

A Pod is the smallest deployable unit in Kubernetes.

Why this answer

A Pod is the smallest and simplest Kubernetes object. It represents a single instance of a running process.

Full explanation →

555

MCQhard

A financial services company runs a critical trading application on Kubernetes. The application is deployed as a Deployment with 3 replicas. Each pod exposes metrics on port 8080 and uses a ConfigMap to load configuration. Recently, after a configuration change via a ConfigMap update, two of the three pods started crashing with an out-of-memory (OOM) error, while the third pod continues to run fine. The team verified that the ConfigMap was updated correctly and that the application code did not change. The pods have resource limits set: memory limit of 512Mi and request of 256Mi. The application's memory usage before the change was around 200Mi. The new configuration increases the in-memory cache size. The team suspects the issue is related to the configuration change. What is the best course of action?

A.Scale the Deployment to 5 replicas to distribute the memory load.

B.Remove the memory limit from the container spec to allow unlimited memory usage.

C.Revert the ConfigMap to the previous configuration and monitor memory usage.

D.Increase the memory limit in the Deployment manifest to a higher value, such as 1Gi, and perform a rolling update.

AnswerD

This directly addresses the OOM caused by increased cache size.

Why this answer

Option D is correct because the OOM errors are directly caused by the increased memory usage from the larger in-memory cache, which exceeds the current 512Mi memory limit. Increasing the limit to 1Gi accommodates the new cache size while preserving resource boundaries, and a rolling update applies the change without downtime. This aligns with Kubernetes best practices of setting realistic resource limits based on application requirements.

Exam trap

CNCF often tests the misconception that scaling replicas or removing limits solves resource exhaustion, when the correct approach is to adjust resource limits to match the application's new requirements.

How to eliminate wrong answers

Option A is wrong because scaling to 5 replicas does not resolve the OOM issue; each pod still has a 512Mi limit, and the new configuration causes each pod to exceed that limit, so more replicas would just crash more pods. Option B is wrong because removing the memory limit removes a critical safeguard, risking node instability and potential OOM kills of other pods or system processes; Kubernetes requires limits for predictable scheduling and resource isolation. Option C is wrong because reverting the ConfigMap only avoids the problem temporarily without addressing the need for a larger cache; the team should adjust limits to support the new configuration rather than abandoning the intended change.

Full explanation →

556

MCQmedium

Which service mesh component is responsible for handling inter-service communication as a sidecar proxy?

A.Mixer

B.Pilot

C.Envoy

D.Citadel

AnswerC

Why this answer

Envoy is the correct answer because it is the sidecar proxy component in Istio that handles all inter-service communication. It intercepts traffic between microservices and applies routing, load balancing, and security policies defined by the control plane. Envoy runs as a sidecar container alongside each service instance, managing inbound and outbound traffic at the L4/L7 layer.

Exam trap

CNCF often tests the distinction between data-plane and control-plane components, so the trap here is that candidates may confuse Pilot (control plane) with the sidecar proxy that actually handles traffic, or incorrectly associate Mixer with traffic management due to its former role in policy enforcement.

How to eliminate wrong answers

Option A (Mixer) is wrong because Mixer was a deprecated Istio component used for telemetry collection and policy enforcement, not for proxying inter-service traffic; it was removed in Istio 1.5. Option B (Pilot) is wrong because Pilot is the control plane component that translates high-level routing rules into Envoy configuration and distributes them to sidecars, but it does not handle data-plane traffic itself. Option D (Citadel) is wrong because Citadel is the Istio security component responsible for certificate issuance and key management for mTLS, not for proxying service-to-service communication.

Full explanation →

557

MCQmedium

A pod is stuck in 'Pending' state. After running 'kubectl describe pod', you see the event: '0/3 nodes are available: 3 Insufficient cpu'. What is the most likely cause?

A.The pod's CPU request exceeds the available CPU on all nodes

B.The pod is exceeding its memory limit

C.The network plugin is not installed

D.The container image is too large

AnswerA

The scheduler reports insufficient CPU resources.

Why this answer

The pod requires more CPU than any node can allocate, so it remains pending.

Full explanation →

558

MCQhard

Your organization runs a cloud-native e-commerce platform on Kubernetes. The platform consists of several microservices: a frontend service, an order service, a payment service, and a shipping service. All services communicate via HTTP REST APIs. Recently, during a flash sale event, the platform experienced a cascading failure. The order service became overwhelmed with requests and started responding slowly. This caused the frontend service to time out waiting for order responses, and eventually the frontend service crashed due to exhausted thread pools. The payment and shipping services were unaffected because they are called asynchronously via a message queue. You need to redesign the system to prevent such cascading failures in the future. Which approach is the most effective?

A.Scale up the frontend service to handle more concurrent requests

B.Convert all inter-service communication to synchronous calls with retries

C.Increase the timeout values in the frontend service configuration

D.Implement circuit breakers in the frontend service for calls to the order service

AnswerD

Circuit breakers prevent cascading failures by failing fast.

Why this answer

Option D is correct because implementing circuit breakers in the frontend service for calls to the order service prevents cascading failures by monitoring failure rates and automatically tripping the circuit when the order service becomes slow or unresponsive. This stops the frontend from exhausting its thread pools waiting for timeouts, allowing it to fail fast and return a fallback response. Circuit breakers are a proven resilience pattern in cloud-native architectures, especially for synchronous HTTP REST calls where latency spikes can propagate.

Exam trap

CNCF often tests the misconception that scaling or increasing timeouts is a sufficient fix for cascading failures, but the trap here is that these options treat symptoms rather than applying the circuit breaker pattern, which is the standard resilience mechanism for synchronous calls in cloud-native systems.

How to eliminate wrong answers

Option A is wrong because scaling up the frontend service only increases the number of concurrent requests it can handle, but does not address the root cause—the order service being overwhelmed—and may actually worsen the cascading failure by allowing more requests to pile up and exhaust thread pools faster. Option B is wrong because converting all inter-service communication to synchronous calls with retries would increase coupling and amplify failures; retries during overload can cause retry storms, further degrading the order service and increasing latency. Option C is wrong because increasing timeout values only delays the inevitable thread pool exhaustion, as the frontend will hold connections longer without reducing the load on the order service, and may lead to resource starvation under sustained high traffic.

Full explanation →

559

MCQhard

A Kubernetes Deployment is configured with 'strategy.type: RollingUpdate'. The team wants to ensure that during an update, no more than 25% of pods are unavailable at any time. Which specification should be added?

A.spec.minReadySeconds: 30

B.spec.replicas: 4

C.strategy.rollingUpdate.maxUnavailable: 25%

D.strategy.rollingUpdate.maxSurge: 25%

AnswerC

maxUnavailable sets the maximum number of pods that can be unavailable during a rolling update.

Why this answer

The 'maxUnavailable' field in the rolling update strategy controls how many pods can be unavailable during the update. Setting it to 25% ensures at most 25% are down.

Full explanation →

560

MCQeasy

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

A.Container

B.Node

C.Pod

D.Deployment

AnswerC

A Pod is the smallest deployable unit that can be created and managed.

Why this answer

The Pod is the smallest deployable unit in Kubernetes because it represents a single instance of a running process in the cluster and encapsulates one or more containers that share the same network namespace, storage volumes, and lifecycle. Containers are not directly scheduled onto Nodes; instead, Kubernetes always schedules and manages Pods, making the Pod the atomic unit of deployment.

Exam trap

CNCF often tests the misconception that a Container is the smallest unit because candidates come from Docker backgrounds, but Kubernetes abstracts containers into Pods as the fundamental scheduling and deployment atom.

How to eliminate wrong answers

Option A is wrong because a Container is not a standalone deployable unit in Kubernetes; containers are always wrapped inside a Pod and cannot be created or scheduled directly by the API server. Option B is wrong because a Node is a worker machine (physical or virtual) that hosts Pods, but it is not a deployable unit — you do not deploy a Node; you deploy Pods onto Nodes. Option D is wrong because a Deployment is a higher-level controller that manages the desired state and lifecycle of ReplicaSets and Pods, but it is not the smallest unit — it orchestrates Pods, which are the actual deployable entities.

Full explanation →

561

MCQmedium

Which control plane component is responsible for persisting the entire cluster state?

A.kube-controller-manager

B.etcd

C.kube-apiserver

D.kube-scheduler

AnswerB

etcd is the distributed key-value store that stores all cluster data.

Why this answer

etcd is the key-value store that stores all cluster state data, including configuration, state, and metadata.

Full explanation →

562

MCQmedium

A team is designing a Kubernetes cluster for a production workload that requires high availability. They have three worker nodes in different availability zones. Which statement about scheduling Pods is correct?

A.Use nodeSelector to assign Pods to nodes in different zones.

B.Add tolerations for the zone taint.

C.Use podAntiAffinity with a requiredDuringSchedulingIgnoredDuringExecution rule.

D.Define a Pod topology spread constraint with topologyKey: topology.kubernetes.io/zone.

AnswerD

Topology spread constraints explicitly spread Pods across zones for high availability.

Why this answer

Option D is correct because a Pod topology spread constraint with `topologyKey: topology.kubernetes.io/zone` explicitly instructs the scheduler to distribute Pods evenly across the specified failure domains (availability zones). This ensures that if one zone fails, the remaining zones still have running Pods, achieving high availability for the production workload.

Exam trap

Cisco often tests the distinction between mechanisms that merely allow placement (tolerations, nodeSelector) versus those that enforce distribution (topology spread constraints), leading candidates to confuse permission with active scheduling policy.

How to eliminate wrong answers

Option A is wrong because `nodeSelector` only matches Pods to nodes with specific labels, but it does not enforce distribution across zones; Pods could still be scheduled on a single zone if all matching nodes are there. Option B is wrong because tolerations allow Pods to be scheduled on tainted nodes (e.g., zone-specific taints), but they do not guarantee spread across zones; they merely permit scheduling on nodes that would otherwise repel the Pod. Option C is wrong because `podAntiAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` prevents Pods from being co-located on the same node (or topology), but it does not ensure balanced distribution across zones; it only avoids placing replicas together, which could still result in all replicas landing in one zone if only one zone has enough nodes.

Full explanation →

563

Multi-Selecteasy

Which TWO components run on every worker node in a Kubernetes cluster?

Select 2 answers

A.kube-scheduler

B.kubelet

C.etcd

D.kube-proxy

E.kube-apiserver

AnswersB, D

kubelet is the primary node agent that ensures containers are running in a Pod.

Why this answer

The kubelet is the primary node agent that runs on every worker node, responsible for managing pod lifecycle and ensuring containers are running as expected. kube-proxy runs on every node to handle network routing and load balancing for Kubernetes services, implementing rules via iptables or IPVS.

Exam trap

CNCF often tests the distinction between control plane components and worker node components, trapping candidates who assume that all core Kubernetes components (like kube-scheduler or etcd) run on every node.

Full explanation →

564

MCQhard

An administrator wants to ensure that a Deployment named 'webapp' always has exactly 3 replicas running across distinct nodes to improve fault tolerance. Which field in the Deployment spec should they configure?

A.replicas: 3

B.template.spec.affinity.podAntiAffinity

C.strategy.type: Recreate

D.template.spec.nodeName

AnswerB

PodAntiAffinity can prevent scheduling multiple pods on the same node.

Why this answer

PodAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution can enforce that pods are scheduled on different nodes.

Full explanation →

565

Matchingmedium

Match each cloud native concept to its definition.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Lightweight, standalone executable package that includes everything needed

Architectural style that structures an app as a collection of loosely coupled services

Automated configuration, coordination, and management of containers

Approach where servers are never modified after deployment; replaced instead

Specifying the desired state, letting the system achieve and maintain it

Why these pairings

These are foundational cloud native principles and patterns.

Full explanation →

566

MCQeasy

A developer wants to monitor the health of a Kubernetes deployment by checking if the number of ready replicas matches the desired replicas. Which metric from kube-state-metrics should they query?

A.kube_deployment_status_replicas_ready

B.kube_deployment_spec_replicas

C.kube_node_status_condition

D.kube_pod_container_status_running

AnswerA

This metric shows ready replicas, enabling comparison with desired replicas.

Why this answer

Option A is correct because `kube_deployment_status_replicas_ready` directly exposes the number of ready replicas for a Deployment, which can be compared against `kube_deployment_spec_replicas` to determine if the desired state matches the actual healthy state. This metric is emitted by kube-state-metrics, which generates Prometheus-compatible metrics from Kubernetes API objects, making it the standard choice for monitoring Deployment health.

Exam trap

The trap here is that candidates might confuse metrics that show pod state (like `kube_pod_container_status_running`) with Deployment-level readiness, not realizing that a pod can be running but not ready, and that the correct metric must reflect the Deployment's own status field.

How to eliminate wrong answers

Option B is wrong because `kube_deployment_spec_replicas` only shows the desired number of replicas as defined in the Deployment spec, not the actual ready count, so it cannot alone indicate health. Option C is wrong because `kube_node_status_condition` tracks node-level conditions (e.g., Ready, DiskPressure) and has no relation to Deployment replica health. Option D is wrong because `kube_pod_container_status_running` counts containers in Running state, not ready replicas of a Deployment, and does not account for readiness probes or desired replica counts.

Full explanation →

567

Multi-Selecteasy

Which TWO of the following are true about container images? (Choose 2)

Select 2 answers

A.Container images include a full operating system kernel

B.Container images are immutable once created

C.Container images are stored in a container registry

D.Container images consist of read-only layers

E.Container images are built using a Dockerfile

AnswersC, D

Images are pushed to and pulled from registries like Docker Hub.

Why this answer

Container images are built in layers, each representing a set of filesystem changes. Images are stored in registries. The Dockerfile defines the build process, not the image itself.

Full explanation →

568

MCQeasy

Which component of the control plane is the only one that directly interacts with etcd?

A.kube-apiserver

B.kube-controller-manager

C.kube-scheduler

D.kubelet

AnswerA

The API server is the only component that directly reads and writes to etcd.

Why this answer

The kube-apiserver is the only component that communicates with etcd. All other components (scheduler, controller-manager) interact with etcd indirectly through the API server.

Full explanation →

569

Multi-Selectmedium

Which TWO of the following are valid uses of Kubernetes Namespaces? (Select 2)

Select 2 answers

A.Setting CPU and memory limits at the namespace level

B.Enforcing network policies per namespace

C.Providing logical separation between different environments (e.g., dev, staging, prod) within the same cluster

D.Isolating node resources for different workloads

E.Enabling RBAC authentication for users in a namespace

AnswersB, C

NetworkPolicies can be applied within a namespace to control traffic between pods.

Why this answer

Option B is correct because Kubernetes NetworkPolicies are namespace-scoped resources that allow you to define ingress and egress traffic rules for pods within a specific namespace. By applying a NetworkPolicy to a namespace, you can isolate workloads from each other, controlling which pods can communicate based on labels and ports, which is a fundamental use of namespaces for security and segmentation.

Exam trap

CNCF often tests the misconception that namespaces can enforce resource limits directly, when in fact ResourceQuotas and LimitRanges are the mechanisms that operate within a namespace, not the namespace itself.

Full explanation →

570

MCQmedium

In a service mesh architecture, which component is responsible for intercepting and managing traffic between microservices?

A.Control plane

B.API gateway

C.Service registry

D.Sidecar proxy

AnswerD

The sidecar proxy, such as Envoy, runs alongside each service and intercepts all network traffic to and from the service.

Why this answer

The sidecar proxy (usually Envoy) is deployed alongside each service instance and handles all incoming and outgoing traffic, enabling observability, traffic management, and security. The control plane manages configuration but does not handle data plane traffic. The API gateway is a separate component for external traffic.

The service registry is a pattern but not a specific service mesh component.

Full explanation →

571

MCQeasy

What is the Container Runtime Interface (CRI)?

A.A tool for building container images

B.A standard for container runtime logs

C.A specification for container images

D.An API between kubelet and container runtime

AnswerD

Correct. CRI allows kubelet to communicate with runtimes like containerd and CRI-O.

Why this answer

CRI is a plugin interface that enables kubelet to use different container runtimes without needing to recompile.

Full explanation →

572

MCQeasy

Which command is used to view detailed information about a specific pod, including events and conditions?

A.kubectl logs pod

B.kubectl describe pod

C.kubectl exec pod

D.kubectl get pod

AnswerB

This command shows detailed information about a specific pod.

Why this answer

The 'kubectl describe pod' command provides detailed information about a pod, including its state, events, and conditions.

Full explanation →

573

MCQmedium

In a multi-cloud architecture, what is a common use case for a service mesh?

A.To enable secure service-to-service communication across clusters

B.To synchronize Kubernetes resources across clouds

C.To provide cloud-agnostic block storage

D.To provide a single ingress gateway for all clouds

AnswerA

Service mesh provides mTLS and traffic management across clusters.

Why this answer

A service mesh, such as Istio or Linkerd, provides a dedicated infrastructure layer for handling service-to-service communication. In a multi-cloud architecture, its common use case is to enable secure, observable, and resilient communication between services running in different Kubernetes clusters across clouds, using mutual TLS (mTLS) for encryption and traffic policies for routing.

Exam trap

CNCF often tests the misconception that a service mesh is a general-purpose tool for all cross-cloud operations, when in reality it is specifically designed for service-to-service communication (east-west traffic) and does not handle resource synchronization, storage, or ingress gateway functions.

How to eliminate wrong answers

Option B is wrong because synchronizing Kubernetes resources across clouds is typically done by tools like Karmada, Cluster API, or Terraform, not by a service mesh, which focuses on network traffic management. Option C is wrong because cloud-agnostic block storage is provided by storage abstraction layers like CSI (Container Storage Interface) drivers or solutions like Rook/Ceph, not by a service mesh, which operates at Layer 7 (HTTP/gRPC) and Layer 4 (TCP). Option D is wrong because a single ingress gateway for all clouds is the role of a multi-cluster ingress controller or global load balancer (e.g., NGINX Ingress Controller with external-dns), while a service mesh handles east-west traffic between services, not north-south ingress traffic.

Full explanation →

574

MCQhard

A developer creates the Pod manifest shown. When the Pod runs, the liveness probe fails and the container is restarted repeatedly. What is the most likely cause?

A.The liveness probe port (8080) does not match the container port (80).

B.The initialDelaySeconds of 3 is too short for Nginx to start.

C.The periodSeconds of 5 causes too frequent probing.

D.The image nginx:latest does not have a /healthz endpoint.

AnswerA

Correct. The probe checks port 8080, but Nginx listens on port 80, so the probe fails.

Why this answer

The liveness probe is configured to check TCP on port 8080, but the container exposes port 80 for Nginx. Since the probe will never successfully connect to port 8080, it always fails, causing the container to be restarted repeatedly. The probe must target the same port that the application is listening on.

Exam trap

CNCF often tests the distinction between TCP and HTTP probes, and the trap here is that candidates assume a TCP probe can target any port without matching the container's listening port, or they confuse the probe port with the container port defined in the Pod spec.

How to eliminate wrong answers

Option B is wrong because an initialDelaySeconds of 3 is generally sufficient for Nginx to start, as Nginx starts very quickly (often under 1 second). Option C is wrong because a periodSeconds of 5 is a reasonable probing interval and does not cause failures; frequent probing alone does not cause restarts unless the probe itself is misconfigured. Option D is wrong because the liveness probe is a TCP check, not an HTTP GET request, so it does not require a /healthz endpoint; a TCP probe only checks that the port is open, which Nginx provides on port 80.

Full explanation →

575

Multi-Selectmedium

Which THREE are key benefits of using a service mesh in a cloud-native architecture? (Choose 3)

Select 3 answers

A.Persistent storage management for stateful applications.

B.Mutual TLS (mTLS) encryption between services.

C.Automatic horizontal scaling of pods.

D.Observability through distributed tracing and metrics.

E.Traffic management such as canary deployments and circuit breaking.

AnswersB, D, E

Service mesh can enforce mTLS for secure communication.

Why this answer

Option B is correct because a service mesh, such as Istio or Linkerd, transparently enables mutual TLS (mTLS) encryption between service sidecar proxies without requiring application code changes. This ensures all inter-service communication is encrypted and authenticated, which is a core security benefit in a zero-trust cloud-native architecture.

Exam trap

CNCF often tests the misconception that a service mesh provides infrastructure-level features like storage or scaling, when in reality it is strictly a Layer 4/7 networking and security abstraction that operates independently of compute or storage resources.

Full explanation →

576

MCQmedium

An administrator needs to expose a set of pods running a web application on a static port on each node's IP address. Which Service type should they use?

A.ClusterIP

B.NodePort

C.ExternalName

D.LoadBalancer

AnswerB

NodePort opens a specific port on all nodes and routes traffic to the service.

Why this answer

A NodePort service exposes the application on a static port (30000–32767) on every node's IP address, making the pods accessible externally via <NodeIP>:<NodePort>. This matches the requirement to expose pods on a static port on each node's IP address without needing an external load balancer.

Exam trap

CNCF often tests the misconception that NodePort is the only way to expose services externally, but the trap here is confusing NodePort with LoadBalancer, which also provides external access but requires cloud provider integration and does not guarantee a static port on each node.

How to eliminate wrong answers

Option A is wrong because ClusterIP exposes the service only on a cluster-internal IP, making it unreachable from outside the cluster. Option C is wrong because ExternalName maps a service to an external DNS name via CNAME records, not to node IPs or ports. Option D is wrong because LoadBalancer provisions an external cloud load balancer with a public IP, which is overkill and not required for exposing on each node's static port.

Full explanation →

577

MCQmedium

A company is deploying a microservices application on Kubernetes. They want to ensure that configuration data, such as database URLs and feature flags, can be updated without rebuilding container images. Which Kubernetes resource should they use?

A.Secrets

B.Services

C.Deployments

D.ConfigMaps

AnswerD

ConfigMaps store non-sensitive configuration data that can be consumed by pods.

Why this answer

ConfigMaps are the correct Kubernetes resource for decoupling configuration data (like database URLs and feature flags) from container images. They allow you to inject configuration as environment variables or mounted volumes without rebuilding or redeploying the container image, enabling runtime updates.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming that all configuration must be stored in Secrets, but the KCNA exam tests the distinction that ConfigMaps are for non-sensitive data and Secrets are for sensitive data.

How to eliminate wrong answers

Option A is wrong because Secrets are designed for sensitive data (e.g., passwords, tokens) and are not intended for general configuration like database URLs or feature flags; using Secrets for non-sensitive data adds unnecessary complexity and security overhead. Option B is wrong because Services are a networking abstraction that provides stable endpoints for Pods, not a mechanism for storing or injecting configuration data. Option C is wrong because Deployments manage the desired state and lifecycle of Pods (e.g., scaling, rolling updates), but they do not store configuration data; configuration is typically provided via ConfigMaps or Secrets referenced in the Pod spec.

Full explanation →

578

Multi-Selectmedium

Which TWO actions can improve the DORA metric 'Mean Time to Recovery (MTTR)'?

Select 2 answers

A.Increasing deployment frequency

B.Slowing down the release cycle

C.Using feature flags to disable faulty code quickly

D.Adding more manual approval steps

E.Implementing automated rollback on health check failure

AnswersC, E

Feature flags allow instant disabling of problematic features.

Why this answer

Reducing MTTR involves quick detection and rollback or fix of failures.

Full explanation →

579

MCQhard

In a YAML manifest for a Deployment, which field defines the number of pod replicas?

A.spec.strategy.replicas

B.metadata.replicas

C.spec.replicas

D.spec.template.replicas

AnswerC

spec.replicas is the correct field for setting the number of replicas.

Why this answer

In a Kubernetes Deployment manifest, the `spec.replicas` field is the correct place to define the desired number of pod replicas. This field is a top-level attribute under the Deployment's `spec` object, and the ReplicaSet controller uses this integer value to ensure the specified number of Pods are running at all times.

Exam trap

The trap here is that candidates confuse the `spec.replicas` field with `spec.template` or `metadata`, or incorrectly assume that replica count is nested under `strategy` or `template`, leading them to pick A, B, or D.

How to eliminate wrong answers

Option A is wrong because `spec.strategy.replicas` does not exist; the `strategy` field defines the update strategy (e.g., RollingUpdate or Recreate), not replica count. Option B is wrong because `metadata.replicas` is not a valid field; `metadata` contains labels, annotations, and the resource name, not replica configuration. Option D is wrong because `spec.template.replicas` is invalid; the `template` field describes the Pod template (e.g., containers, volumes) and does not include a replicas field.

Full explanation →

580

MCQeasy

What is the primary purpose of a container registry in a CI/CD pipeline?

A.To manage Kubernetes secrets

B.To store source code and trigger builds

C.To run CI/CD pipelines

D.To host container images for deployment

AnswerD

Container registries store built images that can be pulled by Kubernetes or other orchestration platforms.

Why this answer

A container registry stores and distributes container images. After building and scanning, images are pushed to a registry so that deployment tools can pull them to run containers.

Full explanation →

581

MCQhard

Which GitOps tool is a CNCF graduated project that synchronizes Kubernetes clusters with a Git repository?

A.Argo CD

B.Tekton

C.Jenkins X

D.Flux

AnswerA

Argo CD is a CNCF graduated project.

Why this answer

Argo CD is a CNCF graduated project for GitOps on Kubernetes.

Full explanation →

582

MCQhard

You have a Deployment with the following rollout strategy: rollingUpdate: maxSurge: 1, maxUnavailable: 0. What behavior does this configuration enforce?

A.The rollout will terminate all old pods at once and then create new ones

B.The rollout will create all new pods first, then delete all old pods

C.The rollout will terminate one old pod before creating a new one

D.The rollout will create one additional pod before terminating the old pod, ensuring zero downtime

AnswerD

This strategy ensures at least desired replicas are always running.

Why this answer

Option D is correct because the rolling update strategy `maxSurge: 1, maxUnavailable: 0` ensures that during the rollout, one additional pod is created above the desired replica count before any existing pod is terminated. This guarantees that the total number of available pods never drops below the desired count, achieving zero downtime. The `maxUnavailable: 0` setting prevents any pod from being taken down until a new one is ready, while `maxSurge: 1` allows one extra pod to be created temporarily.

Exam trap

The trap here is that candidates often confuse `maxSurge` and `maxUnavailable` with simple 'one-by-one' termination, failing to realize that `maxUnavailable: 0` forces the creation of a new pod before any old pod is removed, ensuring zero downtime.

How to eliminate wrong answers

Option A is wrong because terminating all old pods at once would violate `maxUnavailable: 0`, which explicitly prohibits any pods from being unavailable during the update. Option B is wrong because creating all new pods first would exceed the `maxSurge: 1` limit, which only allows one extra pod above the desired count, not a full parallel creation. Option C is wrong because terminating one old pod before creating a new one would temporarily reduce the available pod count below the desired replicas, violating `maxUnavailable: 0`; the correct behavior is to create a new pod first (surge) before terminating the old one.

Full explanation →

583

MCQmedium

Which of the following is a graduated CNCF project?

A.OpenTelemetry

B.K3s

C.KubeEdge

D.Prometheus

AnswerD

Prometheus is a graduated project for monitoring.

Why this answer

Prometheus is a graduated CNCF project, having reached the graduation maturity level in August 2018. It is a core monitoring and alerting toolkit widely adopted in cloud-native environments, and its graduation status reflects its stability, widespread use, and strong governance within the CNCF ecosystem.

Exam trap

The trap here is that candidates may confuse 'graduated' with 'incubating' or 'sandbox' status, especially for popular projects like OpenTelemetry or KubeEdge that are widely used but have not yet reached the highest maturity level in the CNCF lifecycle.

How to eliminate wrong answers

Option A is wrong because OpenTelemetry is an incubating CNCF project, not graduated; it is a collection of APIs and SDKs for observability but has not yet reached the graduation maturity level. Option B is wrong because K3s is a CNCF sandbox project, not graduated; it is a lightweight Kubernetes distribution designed for edge and resource-constrained environments, but it remains at the sandbox maturity level. Option C is wrong because KubeEdge is a CNCF incubating project, not graduated; it extends Kubernetes to edge computing but has not achieved graduation status.

Full explanation →

584

MCQhard

You have a Service of type ClusterIP named 'my-svc' in the 'default' namespace. A Pod in the same cluster wants to reach this Service using DNS. What is the fully qualified domain name (FQDN) that resolves to the Service's cluster IP?

A.my-svc.default.svc.cluster.local

B.my-svc.default.cluster.local

C.default.my-svc.svc.cluster.local

D.my-svc.svc.default.cluster.local

AnswerA

Correct format: <service>.<namespace>.svc.cluster.local.

Why this answer

Option A is correct because the standard DNS naming convention for a Kubernetes Service is `<service-name>.<namespace>.svc.cluster.local`. This FQDN resolves to the ClusterIP of the Service, allowing Pods to discover and communicate with the Service using DNS. The `svc` subdomain is a fixed part of the cluster domain, and `cluster.local` is the default cluster domain suffix.

Exam trap

The trap here is that candidates often forget the `svc` subdomain or mix up the order of service name and namespace, leading them to choose options that omit `svc` or reverse the components, which Cisco tests to see if you know the exact DNS format for Kubernetes Services.

How to eliminate wrong answers

Option B is wrong because it omits the required `svc` subdomain, which is part of the standard Kubernetes DNS schema; without `svc`, the DNS query will not match the Service record. Option C is wrong because it reverses the order of the service name and namespace, placing the namespace first, which does not follow the `<service>.<namespace>.svc.cluster.local` format. Option D is wrong because it places `svc` after the namespace instead of before it, and also incorrectly orders the components; the correct structure is `<service>.<namespace>.svc.cluster.local`.

Full explanation →

585

MCQhard

A user runs 'kubectl exec -it pod1 -- /bin/sh' and gets an error: 'error: unable to upgrade connection: container not found'. The pod is running and has one container named 'app'. What is the most likely issue?

A.The pod is not running

B.The container does not have a shell binary

C.The user does not have permission to exec into pods

D.The container name was not specified and the pod has multiple containers

AnswerD

When multiple containers exist, you must specify '-c' flag; otherwise, kubectl may fail to find the container.

Why this answer

Option C is correct. The error 'container not found' typically means the container name is missing or incorrect. 'kubectl exec' defaults to the first container, but if the pod has multiple containers, you must specify '-c' flag. Option A (no shell binary) would give a different error.

Option B (pod status) is not the issue since the error is about container not found. Option D (service account) is not related.

Full explanation →

586

MCQhard

You have a Service named 'my-svc' in namespace 'default'. A pod in namespace 'other' tries to reach it using the DNS name 'my-svc'. What is the correct DNS name for cross-namespace service discovery?

A.my-svc

B.my-svc.default

C.my-svc.other

D.my-svc.namespace

AnswerB

Why this answer

For cross-namespace service discovery, the DNS name is <service-name>.<namespace>.svc.cluster.local. So, to reach 'my-svc' in namespace 'default' from another namespace, the correct DNS name is 'my-svc.default.svc.cluster.local'. A shorter form 'my-svc.default' also works.

Full explanation →

587

MCQmedium

In an event-driven architecture using a message broker, which component is responsible for receiving events and forwarding them to subscribed services?

A.Service mesh

B.Message broker

C.API gateway

D.Load balancer

AnswerB

Message broker decouples event producers and consumers.

Why this answer

A message broker (like Kafka or RabbitMQ) receives and forwards events. An API gateway routes HTTP requests, a service mesh handles service-to-service communication, and a load balancer distributes network traffic.

Full explanation →

588

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Increase the memory limit in the pod's container resource specification

B.Increase the CPU request for the container

C.Delete the namespace and redeploy all workloads

D.Delete and recreate the pod to clear the crash loop

AnswerA

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

Option B is correct. OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. The solution is to increase the memory limit in the container's resource specification.

Option A would not help — restarting the pod without addressing the root cause will result in the same failure. Option C addresses CPU, not memory. Option D (deleting the namespace) is destructive and unnecessary.

Full explanation →

589

MCQmedium

Which Kubernetes object is used to store non-sensitive configuration data that can be consumed by pods?

A.Secret

B.ServiceAccount

C.ConfigMap

D.PersistentVolume

AnswerC

ConfigMaps store non-sensitive configuration.

Why this answer

ConfigMap is used to store non-sensitive configuration data as key-value pairs or files.

Full explanation →

590

MCQmedium

A team uses a Deployment with 3 replicas and a RollingUpdate strategy. They update the container image. During the update, one of the new pods fails to start. What will happen by default?

A.The update pauses, keeping the remaining old replicas running

B.The entire update is rolled back and all old pods are deleted

C.The Deployment automatically rolls back to the previous image

D.The failed pod is terminated and not retried

AnswerA

The rolling update stops when a new pod fails, ensuring availability of old pods.

Why this answer

By default, a Deployment with a RollingUpdate strategy uses a `maxUnavailable` of 25% and a `maxSurge` of 25%. When a new pod fails to start (e.g., CrashLoopBackOff or ImagePullBackOff), the ReplicaSet controller will not create additional new pods beyond the surge limit, and the update will effectively pause because the new ReplicaSet cannot reach its desired replica count. The old ReplicaSet remains running with its existing pods, ensuring availability is maintained.

Exam trap

Cisco often tests the misconception that a failed pod in a rolling update triggers an automatic rollback or deletion, when in fact the default behavior is to pause the update and keep old replicas running until the issue is resolved manually.

How to eliminate wrong answers

Option B is wrong because the Deployment does not automatically roll back or delete old pods; it only pauses the rollout, leaving old replicas running. Option C is wrong because a failed pod does not trigger an automatic rollback to the previous image; rollback requires manual intervention or a specific `kubectl rollout undo` command. Option D is wrong because the failed pod is not simply terminated and not retried; the ReplicaSet controller will retry creating the pod indefinitely (with exponential backoff) until the image issue is resolved or the rollout is manually paused.

Full explanation →

591

MCQmedium

A user runs 'kubectl get pods -n default' but receives an error: 'Error from server (Forbidden): pods is forbidden: User cannot list resource pods in API group'. What is the most likely cause?

A.The pod does not exist in the namespace

B.The user's kubeconfig file is corrupted

C.The user lacks RBAC permissions to list pods

D.The API server is down

AnswerC

The Forbidden error indicates insufficient permissions.

Why this answer

This error indicates a lack of RBAC permissions for the user to list pods in the default namespace.

Full explanation →

592

MCQmedium

A Kubernetes Deployment manages a set of pods. What is the primary purpose of a Deployment?

A.To declare the desired state for a set of pods and manage rolling updates

B.To store configuration data as key-value pairs

C.To run a batch job to completion

D.To expose a set of pods as a network service

AnswerA

Deployments handle declarative updates.

Why this answer

A Deployment provides declarative updates for Pods and ReplicaSets, enabling rolling updates and rollbacks.

Full explanation →

593

Multi-Selectmedium

Which THREE of the following are core principles of immutable infrastructure? (Choose 3)

Select 3 answers

A.Rollbacks are performed by redeploying a previous image

B.Infrastructure is patched by applying updates to running servers

C.Infrastructure components are never modified after deployment

D.Deployments are reproducible and consistent

E.All changes are made by updating configuration files on running instances

AnswersA, C, D

Since each deployment is a complete image, rollback is simply deploying an older image.

Why this answer

Immutable infrastructure means that components are replaced, not modified. This ensures consistency, reliability, and easy rollbacks. Patching running instances is mutable.

Full explanation →

594

MCQeasy

What is the primary purpose of the CNCF (Cloud Native Computing Foundation)?

A.To provide cloud infrastructure services

B.To develop proprietary cloud technologies

C.To standardize container runtimes only

D.To host and nurture open-source cloud-native projects

AnswerD

CNCF hosts projects like Kubernetes, Prometheus, and Envoy, providing governance and support.

Why this answer

The CNCF's primary purpose is to host and nurture open-source cloud-native projects, such as Kubernetes, Prometheus, and Envoy, by providing governance, community support, and a neutral home for their development. It does not provide cloud infrastructure services itself, nor does it develop proprietary technologies; instead, it fosters an ecosystem of interoperable, vendor-neutral projects. The CNCF also manages the Cloud Native Landscape and defines standards like the Open Container Initiative (OCI) for container runtimes and images, but its scope extends far beyond just standardizing container runtimes.

Exam trap

The trap here is that candidates often confuse the CNCF's role with that of a cloud provider or a standards body focused solely on containers, leading them to choose Option A or C, but the CNCF's core function is to host and nurture a broad ecosystem of open-source cloud-native projects under a neutral governance model.

How to eliminate wrong answers

Option A is wrong because the CNCF does not provide cloud infrastructure services (e.g., compute, storage, or networking); those are offered by cloud providers like AWS, Azure, or GCP. Option B is wrong because the CNCF explicitly promotes open-source, vendor-neutral projects, not proprietary technologies; its charter prohibits vendor lock-in and encourages community-driven development. Option C is wrong because while the CNCF hosts the OCI specification for container runtimes (e.g., runc), its mission encompasses the entire cloud-native stack, including orchestration (Kubernetes), service meshes (Istio), observability (Prometheus), and serverless (Knative), not just container runtimes.

Full explanation →

595

MCQhard

A ClusterIP Service named 'db-service' in namespace 'prod' selects pods with label 'app: database'. A pod in the same cluster needs to reach this service using DNS. What is the fully qualified domain name (FQDN) for the service?

A.db-service.cluster.local

B.db-service.prod.svc.cluster.local

C.db-service.svc.cluster.local

D.db-service.prod.cluster.local

AnswerB

This is the standard FQDN for a Service.

Why this answer

The DNS name for a Service is <service>.<namespace>.svc.cluster.local.

Full explanation →

596

MCQmedium

Which of the following is a benefit of using a service mesh?

A.Simplified storage management

B.Automatic scaling of applications

C.Enhanced observability and traffic control

D.Direct database access

AnswerC

Service mesh provides detailed observability and traffic management features.

Why this answer

A service mesh provides observability (metrics, tracing), traffic management (routing, load balancing), and security (mTLS) without requiring changes to application code. It does not directly manage storage or scaling.

Full explanation →

597

Multi-Selecthard

Which THREE of the following are valid ways to expose a Service to external traffic?

Select 3 answers

A.ExternalName

B.Headless

C.LoadBalancer

D.NodePort

E.ClusterIP

AnswersA, C, D

ExternalName maps the Service to an external DNS name.

Why this answer

Option A (ExternalName) is correct because it exposes a Service to external traffic by mapping the Service to an external DNS name (e.g., `my-service.default.svc.cluster.local` to `example.com`) via a CNAME record. This allows internal pods to reach an external service using a stable Kubernetes Service name, effectively exposing the Service to external traffic through DNS resolution.

Exam trap

CNCF often tests the misconception that Headless Services can be used for external exposure because they lack a cluster IP, but in reality they only provide DNS-based pod discovery and no external connectivity.

Full explanation →

598

MCQmedium

A developer wants to expose a set of pods running a web application on a stable IP address. Which Kubernetes resource should they create?

A.Service

B.ConfigMap

C.Ingress

D.NetworkPolicy

AnswerA

A Service provides a stable cluster IP and load balancing to pods.

Why this answer

A Service provides a stable IP and DNS name to access a set of pods.

Full explanation →

599

MCQeasy

Which of the following is a key benefit of using containers over virtual machines?

A.Each container runs its own operating system

B.Containers provide stronger isolation than VMs

C.Containers require hypervisor to run

D.Containers share the host OS kernel

AnswerD

Containers share the host OS kernel, making them lightweight.

Why this answer

Containers share the host operating system kernel, which makes them lightweight and fast to start compared to virtual machines. Each container runs as an isolated user-space process on the same kernel, avoiding the overhead of a separate guest OS per instance. This shared-kernel architecture is a fundamental design principle of containerization technologies like Docker and containerd.

Exam trap

The trap here is that candidates often confuse the lightweight nature of containers with stronger isolation, but the key trade-off is that containers share the host kernel, making them less isolated than VMs, not more.

How to eliminate wrong answers

Option A is wrong because each container does not run its own operating system; containers share the host OS kernel and only include the application and its dependencies. Option B is wrong because containers provide weaker isolation than VMs, as they share the host kernel and rely on kernel namespaces and cgroups, whereas VMs use a hypervisor to provide hardware-level isolation. Option C is wrong because containers do not require a hypervisor to run; they run directly on the host OS using the kernel's container runtime, while VMs require a hypervisor.

Full explanation →

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 526–600