Courseiva

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 451–525

833 questions total · 12pages · All types, answers revealed

Take a mock examExam hub
Page 6

Page 7 of 12

Page 8
451
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

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 source code. By defining a standard API (gRPC-based) for runtime operations like pulling images and managing containers, CRI decouples Kubernetes from specific runtime implementations such as containerd, CRI-O, or Docker (via dockershim). This abstraction allows cluster administrators to choose the most suitable runtime for their environment while maintaining compatibility with the Kubernetes control plane.

Exam trap

A common exam trap is confusing the CRI's role in runtime abstraction with storage (CSI) or networking (CNI) interfaces, leading candidates to select options B or C.

How to eliminate wrong answers

Option B is wrong because persistent storage management is handled by the Container Storage Interface (CSI), not the CRI; CRI focuses solely on runtime operations like container lifecycle and image management. Option C is wrong because network plugin interfaces for pods are provided by the Container Network Interface (CNI), which handles IP allocation and network connectivity, not the CRI. Option D is wrong because container image standards are defined by the Open Container Initiative (OCI) image spec, not the CRI; the CRI consumes OCI-compliant images but does not define the image format itself.

Full explanation →
452
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 →
453
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 →
454
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

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 →
455
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 →
456
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 →
457
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

The CMD instruction in a Dockerfile provides default arguments for the ENTRYPOINT instruction when the container is run. If no ENTRYPOINT is defined, CMD itself serves as the default command to execute. This allows users to override the default behavior at runtime by appending arguments to `docker run`, which replace the CMD values while preserving the ENTRYPOINT.

Exam trap

The KCNA exam often tests the distinction between CMD and RUN, where candidates mistakenly think CMD runs at build time, but the trap is that CMD only defines runtime defaults and is overridable, unlike RUN which executes during image creation.

How to eliminate wrong answers

Option A is wrong because CMD specifies a command that runs at container runtime, not at build time; build-time commands are handled by RUN. Option B is wrong because copying files into the image is the purpose of the COPY or ADD instruction, not CMD. Option D is wrong because defining environment variables is the role of the ENV instruction, not CMD.

Full explanation →
458
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 →
459
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

Ingress is correct because it provides HTTP/HTTPS routing rules to expose Services externally, typically using a reverse proxy like NGINX or HAProxy. It operates at Layer 7, allowing host and path-based routing to multiple Services behind a single external endpoint, which is a valid way to expose traffic.

Exam trap

Candidates often mistakenly think ExternalName is an external exposure method, but it only creates a DNS alias within the cluster and does not route external traffic.

Full explanation →
460
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 →
461
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 →
462
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

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

The KCNA exam 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 →
463
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 →
464
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

Kubernetes Services use label selectors to identify a set of Pods and then distribute incoming traffic to those Pods. This is the core mechanism that decouples the Service from the specific Pod instances, enabling load balancing and dynamic routing.

Exam trap

A common misconception is that Services handle Pod scaling or replication; in fact, Services only provide stable networking and load balancing to a set of Pods selected by labels.

Full explanation →
465
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

The Pod is the smallest and simplest unit in the Kubernetes object model. It represents a single instance of a running process in the cluster and encapsulates one or more containers with shared storage and network resources. Deployments manage ReplicaSets, which in turn manage Pods, but the Pod itself is the atomic deployable unit.

Exam trap

The trap here is that candidates often confuse 'container' as the smallest unit because they think of Docker containers, but Kubernetes abstracts containers into Pods to enforce resource sharing and lifecycle management.

How to eliminate wrong answers

Option A is wrong because a Deployment is a higher-level abstraction that manages ReplicaSets and Pods; it is not the smallest deployable unit. Option B is wrong because a Node is a worker machine (physical or virtual) in the cluster that hosts Pods, not a deployable unit itself. Option D is wrong because a Container is the runtime environment for an application, but Kubernetes does not deploy containers directly; it wraps them inside a Pod to provide shared networking and storage context.

Full explanation →
466
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

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 →
467
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 →
468
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 is stuck in 'Pending' state because the Kubernetes scheduler cannot find a node that satisfies the pod's resource requirements. The event '0/3 nodes are available: 3 Insufficient cpu' explicitly indicates that every node in the cluster lacks sufficient allocatable CPU capacity to meet the pod's CPU request. This means the sum of CPU requests across all pods on each node, plus the new pod's request, exceeds the node's CPU capacity, causing the scheduler to leave the pod unscheduled.

Exam trap

A common mistake in Kubernetes is confusing resource requests (used for scheduling) with resource limits (used for runtime enforcement). Candidates may incorrectly think a pod stuck in 'Pending' is due to exceeding a limit rather than an unsatisfied request.

How to eliminate wrong answers

Option B is wrong because exceeding a memory limit causes a pod to be terminated (OOMKilled) or restarted, not stuck in 'Pending' state; 'Pending' relates to scheduling, not runtime resource limits. Option C is wrong because a missing network plugin (e.g., CNI) would cause pods to fail with 'CrashLoopBackOff' or 'ContainerCreating' errors, not a scheduling failure due to insufficient CPU. Option D is wrong because a large container image affects image pull time and can cause 'ImagePullBackOff' or 'ErrImagePull' events, but does not prevent the scheduler from assigning the pod to a node; the pod would still be scheduled and then fail during container creation.

Full explanation →
469
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

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 →
470
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 →
471
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 →
472
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 distributed key-value store that serves as the single source of truth for the entire cluster state, including all objects (Pods, Services, ConfigMaps, etc.) and their desired and current status. The kube-apiserver is the only component that directly communicates with etcd, ensuring that all state changes are persisted durably and consistently. Without etcd, the cluster would have no record of its configuration or running workloads.

Exam trap

A common trap is to think the kube-apiserver persists state because it is the central API gateway, but in reality, the API server is stateless and relies entirely on etcd for durable storage.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager is a control loop that watches the shared state through the API server and makes changes to move the current state toward the desired state; it does not persist any data itself. Option C is wrong because kube-apiserver is the front-end for the control plane that validates and processes REST requests, but it delegates all persistent storage to etcd and does not store data locally. Option D is wrong because kube-scheduler is responsible for assigning Pods to Nodes based on resource availability and constraints; it reads cluster state from the API server but never writes or persists any state.

Full explanation →
473
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

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

The KCNA exam 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 →
474
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 →
475
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

The correct matches are: Microservices with loosely coupled services, Service Mesh with service-to-service communication, Serverless with cloud provider managing resources, and Orchestration with automated management. Common confusions include swapping definitions between Microservices and Service Mesh, or between Serverless and Orchestration.

Full explanation →
476
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

`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 →
477
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 of the Kubernetes control plane that directly interacts with etcd. It acts as the front-end for the control plane, exposing the Kubernetes API, and all reads and writes to the cluster's state stored in etcd must go through the API server. Other components like the kube-controller-manager and kube-scheduler only communicate with etcd indirectly via the kube-apiserver, never directly.

Exam trap

The trap here is that candidates often assume the kube-controller-manager or kube-scheduler directly access etcd because they manage cluster state, but in reality they only interact with etcd indirectly through the kube-apiserver.

How to eliminate wrong answers

Option B is wrong because the kube-controller-manager watches and reconciles cluster state by making API calls to the kube-apiserver, not by directly querying or writing to etcd. Option C is wrong because the kube-scheduler assigns pods to nodes by communicating with the kube-apiserver to update pod bindings, and it never directly accesses etcd. Option D is wrong because kubelet is a node-level agent that interacts only with the kube-apiserver (e.g., to report node status or watch for pod assignments) and has no direct connection to etcd.

Full explanation →
478
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

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 →
479
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 →
480
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

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 kubelet. It defines a gRPC API (protocol buffers) for the kubelet to communicate with the container runtime, covering operations like pod lifecycle management and image management. Option D correctly identifies this as the API between the kubelet and the container runtime.

Exam trap

The trap here is that candidates often confuse the CRI with container image specifications (OCI Image Spec) or container runtime tools (like Docker), but the CRI is strictly an API interface between the kubelet and the runtime, not a tool or a specification for images.

How to eliminate wrong answers

Option A is wrong because building container images is the job of tools like Docker Build, Buildah, or Kaniko, not the CRI, which is an interface for runtime orchestration. Option B is wrong because the CRI does not standardize container runtime logs; log management is handled by the kubelet via the logging interface (e.g., using the 'kubectl logs' command) and the container runtime's logging driver. Option C is wrong because container image specifications are defined by the OCI Image Spec (Open Container Initiative), not by the CRI, which focuses on runtime operations like starting and stopping containers.

Full explanation →
481
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 retrieves detailed information about a specific pod, including its current state, metadata, labels, annotations, container details, resource limits, and a chronological list of events and conditions (e.g., PodScheduled, Initialized, Ready, ContainersReady). This makes it the correct tool for viewing comprehensive pod status and lifecycle events.

Exam trap

The trap here is that candidates often confuse `kubectl get pod` (which shows a summary) with `kubectl describe pod` (which shows full details and events), leading them to choose the 'get' option when the question explicitly asks for 'detailed information including events and conditions'.

How to eliminate wrong answers

Option A is wrong because `kubectl logs pod` only streams or retrieves the console output (stdout/stderr) from a container within a pod, not the pod's metadata, conditions, or events. Option C is wrong because `kubectl exec pod` runs a command inside a container of the pod for interactive debugging, not for viewing pod details or events. Option D is wrong because `kubectl get pod` outputs a concise, tabular summary of pods (name, status, restarts, age) without the detailed conditions, events, or full configuration that `describe` provides.

Full explanation →
482
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 →
483
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 →
484
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

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 →
485
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 →
486
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 →
487
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 →
488
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 →
489
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 →
490
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 →
491
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

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 in this question is that candidates often mistakenly think 'maxSurge: 1, maxUnavailable: 0' allows one old pod to be terminated before a new one starts (like a 'one-by-one' strategy). In reality, 'maxUnavailable: 0' forces a new pod to be created and become ready before any existing pod is removed, ensuring zero downtime. This is Kubernetes-specific and differs from simpler rolling update strategies.

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 →
492
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 →
493
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

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 →
494
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

Kubernetes DNS resolves service names using the format `<service>.<namespace>.svc.cluster.local`. For cross-namespace access, the namespace must be included. Since the pod is in namespace 'other' and the service is in 'default', the correct DNS name is 'my-svc.default' (the full cluster domain suffix is optional).

Exam trap

The trap here is that candidates assume a bare service name works globally across namespaces, forgetting that Kubernetes DNS scopes short names to the pod's own namespace.

How to eliminate wrong answers

Option A is wrong because a bare service name like 'my-svc' only resolves within the same namespace; a pod in namespace 'other' would get a DNS lookup failure or a different service. Option C is wrong because 'my-svc.other' would look for a service named 'my-svc' in namespace 'other', not in 'default'. Option D is wrong because 'my-svc.namespace' is not a valid Kubernetes DNS pattern; the literal word 'namespace' is not substituted—the actual namespace name must be used.

Full explanation →
495
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 →
496
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

OOMKilled indicates the container was terminated because it exceeded its memory limit. The correct resolution is to increase the memory limit (option A). Option B (increasing CPU request) does not address memory consumption.

Option C (deleting the namespace) is overly destructive and unnecessary. Option D (deleting and recreating the pod) would restart the container but would immediately fail again due to the same memory limit, so it does not resolve the root cause.

Full explanation →
497
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 the correct Kubernetes object for storing non-sensitive configuration data, such as environment variables, command-line arguments, or configuration files, that can be consumed by pods. Unlike Secrets, ConfigMaps store data in plaintext and are designed for configuration that does not require encryption, making them ideal for application settings that are not confidential.

Exam trap

Kubernetes often tests the distinction between ConfigMap and Secret, trapping candidates who assume all configuration data must be stored in Secrets, ignoring that ConfigMap is the correct choice for non-sensitive data.

How to eliminate wrong answers

Option A is wrong because Secret is specifically designed to store sensitive data (e.g., passwords, tokens, SSH keys) and is base64-encoded, not plaintext, making it unsuitable for non-sensitive configuration. Option B is wrong because ServiceAccount is an identity object used to control pod-level authentication to the Kubernetes API, not for storing configuration data. Option D is wrong because PersistentVolume is a storage resource that provides persistent storage volumes to pods, not a mechanism for injecting configuration data like key-value pairs or files.

Full explanation →
498
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

The KCNA exam 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 →
499
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 →
500
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 →
501
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 →
502
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 correct FQDN for a Kubernetes Service follows the pattern <service-name>.<namespace>.svc.cluster.local. Since the 'db-service' ClusterIP Service is in the 'prod' namespace, the FQDN is 'db-service.prod.svc.cluster.local'. This allows any pod in the cluster to resolve the service's cluster IP via DNS, using the cluster domain 'cluster.local' by default.

Exam trap

The trap here is that candidates often forget the 'svc' subdomain or the namespace component, leading them to pick options like 'db-service.cluster.local' or 'db-service.svc.cluster.local', which are only valid for services in the default namespace or are incomplete.

How to eliminate wrong answers

Option A is wrong because it omits the namespace and the 'svc' subdomain, resulting in 'db-service.cluster.local', which is not a valid Kubernetes service DNS name. Option C is wrong because it includes 'svc' but omits the namespace 'prod', leading to 'db-service.svc.cluster.local', which would only work if the service were in the 'default' namespace. Option D is wrong because it uses 'prod.cluster.local' instead of 'prod.svc.cluster.local', missing the mandatory 'svc' component that distinguishes service DNS records from pod DNS records.

Full explanation →
503
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 →
504
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 in Kubernetes provides a stable IP address and DNS name to expose a set of pods, abstracting away pod IP changes due to scaling or restarts. It acts as a load balancer across the pods, typically using ClusterIP (default), NodePort, or LoadBalancer types. This directly meets the requirement of exposing pods on a stable IP.

Exam trap

The CNCF exam often tests the distinction between Ingress and Service, where candidates mistakenly choose Ingress for stable IP exposure, but Ingress only provides host/path-based routing and requires a Service to actually reach pods.

How to eliminate wrong answers

Option B (ConfigMap) is wrong because it is used to store configuration data as key-value pairs, not to provide network access or a stable IP to pods. Option C (Ingress) is wrong because it manages external HTTP/HTTPS routing to Services, not a stable IP for pods; it requires a Service to function and does not itself assign an IP. Option D (NetworkPolicy) is wrong because it defines firewall rules for pod-to-pod traffic, not exposure or stable IP assignment.

Full explanation →
505
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 →
506
Multi-Selectmedium

Which TWO statements about Kubernetes namespaces are true?

Select 2 answers
A.All Kubernetes objects are namespaced.
B.Namespaces automatically isolate services in different namespaces from communicating.
C.Namespaces provide network isolation between pods by default.
D.Namespaces are used to divide cluster resources between multiple users or teams.
E.Resource quotas can be applied to a namespace to limit aggregate resource consumption.
AnswersD, E

Correct; namespaces provide logical isolation.

Why this answer

Namespaces are a fundamental mechanism in Kubernetes for dividing cluster resources among multiple users or teams, enabling multi-tenancy and resource management through policies like Role-Based Access Control (RBAC) and ResourceQuotas. Option E is correct because ResourceQuotas are Kubernetes objects that can be applied to a namespace to enforce aggregate limits on CPU, memory, and other resources, preventing any single team from exhausting cluster capacity.

Exam trap

The trap here is that candidates confuse namespaces with network isolation, assuming that simply placing resources in different namespaces automatically blocks cross-namespace traffic, when in fact Kubernetes allows all pod-to-pod communication across namespaces by default and requires explicit NetworkPolicy rules to restrict it.

Full explanation →
507
MCQhard

Your organization runs a microservices application on a Kubernetes cluster with 5 worker nodes (each with 4 vCPU, 16GB RAM). The application consists of 20 microservices, each deployed as a Deployment with 3 replicas. Recently, after a new microservice 'inventory' was deployed with resource requests of 2 CPU and 4GB memory per pod, the cluster started experiencing pod scheduling failures. Many existing pods are in 'Pending' state with events indicating 'Insufficient cpu' or 'Insufficient memory'. The cluster has cluster autoscaling enabled (node pool ranging from 3 to 10 nodes), but new nodes are not being added quickly enough, and the existing nodes are heavily utilized. You need to resolve the scheduling failures while ensuring the inventory service can scale. Which course of action should you take?

A.Increase the cluster autoscaler max nodes to 20 and set a 0-second scale-up delay.
B.Set resource limits equal to requests for all microservices to guarantee resources.
C.Reduce the CPU request of the inventory deployment to 1 CPU per pod to allow better packing on existing nodes while cluster autoscaler catches up.
D.Delete all pending pods and recreate them manually.
AnswerC

Lowering requests improves packing and reduces pending status immediately.

Why this answer

Reducing the CPU request of the inventory deployment to 1 CPU per pod allows the scheduler to pack pods more efficiently on existing nodes, alleviating immediate 'Insufficient cpu' and 'Insufficient memory' failures while the cluster autoscaler provisions new nodes. This approach balances short-term scheduling needs with the ability to scale the inventory service later, as requests can be adjusted upward once the cluster has more capacity.

Exam trap

The trap here is that candidates may think increasing cluster autoscaler limits or setting limits equal to requests will solve the problem, but they overlook that the autoscaler cannot instantaneously add nodes and that setting limits does not free up existing resources, while reducing requests directly addresses the immediate scheduling bottleneck.

How to eliminate wrong answers

Option A is wrong because increasing the cluster autoscaler max nodes to 20 and setting a 0-second scale-up delay does not address the immediate scheduling failures; the autoscaler cannot add nodes instantly due to cloud provider provisioning latency, and the existing nodes are already heavily utilized, so pods will remain pending. Option B is wrong because setting resource limits equal to requests for all microservices does not free up resources; it only prevents bursting, which does not resolve the existing resource shortage on the nodes. Option D is wrong because deleting all pending pods and recreating them manually does not change the underlying resource constraints; the scheduler will still fail to place them due to insufficient CPU and memory on the nodes.

Full explanation →
508
MCQmedium

According to the 12-factor app methodology, how should an application store configuration that varies between deployments (e.g., database connection strings)?

A.In a configuration file that is version-controlled
B.In a database table
C.In environment variables
D.Hard-coded in the application code
AnswerC

Environment variables provide a clean separation and are easy to change per deployment.

Why this answer

The 12-factor app recommends strict separation of config from code, storing config in environment variables.

Full explanation →
509
MCQhard

A developer creates a Deployment with replicas: 3 and strategy type: RollingUpdate with maxSurge: 1 and maxUnavailable: 1. During a rolling update, the Deployment controller creates a new ReplicaSet. After the new ReplicaSet has 2 pods ready, the node running one of the original ReplicaSet's pods fails. What is the MOST likely number of total pods running after the node failure, assuming no other actions?

A.2 pods running
B.4 pods running
C.3 pods running
D.1 pod running
AnswerA

Before node failure: old ReplicaSet scaled down to 1, new up to 2 (total 3). Node failure kills the old pod, leaving 2 new pods running.

Why this answer

Initially, the Deployment has 3 old pods. The rolling update starts: with maxSurge=1, the controller creates a new pod. Once it's ready, it terminates one old pod to keep desired replicas at 3.

Then it creates another new pod. After the second new pod is ready, it terminates a second old pod. At this point, the new ReplicaSet has 2 ready pods, and the old ReplicaSet has only 1 pod remaining.

The node running that last old pod fails, killing it. Thus, only the 2 new pods are running, giving a total of 2 pods.

Exam trap

Candidates may mistakenly think that the failed pod is immediately replaced by the Deployment controller to maintain the desired replica count, leading to 3 pods (2 new + 1 replacement). They might also overlook that the failed pod is no longer running, incorrectly counting 3 pods (2 new + 1 old). In reality, right after the node failure, only the 2 new pods are running, and the controller has not yet reacted.

How to eliminate wrong answers

Option B (4 pods running) is wrong because the maxSurge: 1 limits the total number of pods during the update to 4 (3 desired + 1 surge), but after the node failure, one pod is lost, and the controller does not create a replacement due to maxUnavailable: 1 already being satisfied. Option C (3 pods running) is wrong because it assumes the original ReplicaSet's pod on the failed node is still counted, but it is terminated by the node failure, and the rolling update has already scaled down one original pod, leaving only 2 pods from the new ReplicaSet. Option D (1 pod running) is wrong because the new ReplicaSet had 2 ready pods before the node failure, and those pods are on other nodes, so they remain running.

Full explanation →
510
MCQmedium

A developer wants to run a stateless web application with 5 replicas and ensure that when a new version is released, Pods are updated one by one with no downtime. Which Kubernetes resource is best suited?

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

Deployment manages replicas and supports rolling updates.

Why this answer

A Deployment is the correct resource because it is designed for managing stateless, replicated applications with declarative updates. It supports rolling updates (configurable via `strategy.type: RollingUpdate`), which update Pods one by one, ensuring zero downtime by gradually replacing old Pods with new ones while maintaining the desired replica count.

Exam trap

The trap here is that candidates may confuse StatefulSet with Deployment because both support rolling updates, but StatefulSet is specifically for stateful workloads requiring ordered Pod identity and persistent storage, not for stateless web apps where Pods are ephemeral and interchangeable.

How to eliminate wrong answers

Option A is wrong because a Job is used for running batch or one-off tasks to completion, not for continuously running stateless web applications or managing rolling updates. Option B is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes), which is intended for node-level services like logging or monitoring, not for scaling a stateless web app with a fixed replica count. Option C is wrong because a StatefulSet is designed for stateful applications that require stable, unique network identities and persistent storage (e.g., databases), and its rolling update behavior is more conservative (e.g., ordered, graceful shutdown) but it is not the best fit for a stateless web app where Pods are interchangeable.

Full explanation →
511
Multi-Selecteasy

Which TWO of the following are characteristics of a Kubernetes Pod?

Select 2 answers
A.Pods can only run a single container
B.Pods are the smallest deployable units in Kubernetes
C.Containers within a Pod share the same network namespace
D.Pods are designed to be long-lived and rarely replaced
E.Pods are typically replicated by a Deployment or ReplicaSet
AnswersB, C

Pods are the atomic unit of scheduling.

Why this answer

B is correct because Pods are the smallest and most fundamental deployable units in Kubernetes, representing a single instance of a running process in the cluster. A Pod encapsulates one or more containers, storage resources, and a unique network IP, and is the atomic unit of scheduling. This is defined in the Kubernetes core API and is a foundational concept for the KCNA exam.

Exam trap

CNCF often tests the misconception that Pods are long-lived or that they can only run a single container, confusing Pods with virtual machines or containers themselves, while the key exam point is that Pods are the smallest deployable unit and share network namespaces.

Full explanation →
512
Matchingmedium

Match each Kubernetes command (kubectl) to its primary function.

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

Concepts
Matches

List one or more resources

Show detailed state of a resource

Create or update resources from a file or stdin

Execute a command inside a container

Print logs from a container in a pod

Why these pairings

The correct matches are: kubectl get for listing resources, kubectl describe for detailed info, and kubectl apply for applying configurations. Common confusions include swapping the functions of kubectl delete and kubectl logs.

Full explanation →
513
Multi-Selecthard

Which TWO of the following are true about service discovery in Kubernetes? (Choose 2)

Select 2 answers
A.Ingress resources can be used for internal service discovery
B.Service discovery is only available for pods on the same node
C.Environment variables are injected into pods for each Service
D.Services are assigned a DNS name in the form <service>.<namespace>.svc.cluster.local
E.Headless Services provide a stable virtual IP for service discovery
AnswersC, D

When a pod starts, environment variables are set for each active Service.

Why this answer

Kubernetes provides DNS-based service discovery, where Services get DNS names resolved by CoreDNS. Services also have environment variables injected into pods. Headless Services do not provide a single IP; they return the pod IPs.

Ingress is for external traffic, not internal service discovery.

Full explanation →
514
MCQmedium

You run 'kubectl get pods' and see a pod with status 'Pending'. Which is the most likely cause?

A.The pod's container has crashed
B.The scheduler cannot find a node that meets the pod's resource requirements
C.The container image is not found
D.The pod has been deleted by a controller
AnswerB

Pending often means the scheduler is unable to place the pod due to resource constraints.

Why this answer

A pod with status 'Pending' indicates that the pod has been accepted by the cluster but is not yet running. The most common cause is that the Kubernetes scheduler cannot find a node that satisfies the pod's resource requests (CPU, memory) or other constraints (node selector, taints/tolerations, affinity rules). The scheduler continuously evaluates nodes and if none match, the pod remains in Pending state until a suitable node becomes available.

Exam trap

The CNCF's KCNA exam often tests the distinction between pod lifecycle phases (Pending, Running, Succeeded, Failed, Unknown) and common error states (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly associate 'Pending' with image or runtime issues rather than scheduling failures.

How to eliminate wrong answers

Option A is wrong because a container crash would result in a 'CrashLoopBackOff' or 'Error' status, not 'Pending'. Option C is wrong because an unfound container image would cause an 'ImagePullBackOff' or 'ErrImagePull' status, not 'Pending'. Option D is wrong because if a pod is deleted by a controller, it would simply disappear from the list; 'Pending' is a lifecycle phase before the pod is scheduled, not a deletion state.

Full explanation →
515
MCQhard

Which of the following correctly describes the concept of 'immutable infrastructure' in the context of container orchestration?

A.Infrastructure components are recreated from a known good state rather than modified
B.Configuration changes are applied via SSH into running containers
C.Servers are never rebooted
D.Container images are updated in-place by patching existing layers
AnswerA

This is the core idea of immutability.

Why this answer

Immutable infrastructure means that once a container image is built, it is never modified; updates are done by replacing the entire container with a new image.

Full explanation →
516
MCQhard

A cluster administrator wants to ensure that a specific pod only runs on nodes that have an SSD for local storage. The nodes with SSDs have the label 'disk-type: ssd'. How should the administrator configure the pod to enforce this constraint?

A.Add a toleration for node.kubernetes.io/disk-type: ssd
B.Add a nodeSelector with 'disk-type: ssd' to the pod spec
C.Use a readiness probe to check for SSD
D.Add an annotation 'disk-type: ssd' to the pod
AnswerB

nodeSelector is the simplest way to constrain a pod to nodes with specific labels.

Why this answer

The `nodeSelector` field in a Pod spec is the standard Kubernetes mechanism for constraining a Pod to run only on nodes that match specific labels. By setting `nodeSelector: { disk-type: ssd }`, the scheduler will ensure the Pod is placed exclusively on nodes with that label, enforcing the administrator's requirement.

Exam trap

The trap here is that candidates confuse tolerations (for taints) with node selectors (for labels), or think annotations or probes can influence scheduling, when only `nodeSelector` or node affinity directly control node placement based on labels.

How to eliminate wrong answers

Option A is wrong because tolerations are used to allow Pods to run on nodes with taints, not to select nodes based on labels; a toleration for `node.kubernetes.io/disk-type: ssd` would be meaningless as this is not a well-known taint key. Option C is wrong because a readiness probe checks whether a container is ready to serve traffic, not the hardware characteristics of the node; it cannot enforce node selection. Option D is wrong because annotations are metadata for non-identifying information and are not used by the scheduler for node placement decisions.

Full explanation →
517
MCQeasy

What is the purpose of a circuit breaker pattern in microservices?

A.To distribute traffic across multiple instances
B.To stop cascading failures by preventing calls to a failing service
C.To encrypt communication between services
D.To automatically retry failed requests
AnswerB

The circuit breaker opens when failures reach a threshold, stopping calls and allowing the service to recover.

Why this answer

The circuit breaker pattern prevents an application from repeatedly trying to execute an operation that is likely to fail, allowing it to recover gracefully.

Full explanation →
518
Multi-Selecthard

Which THREE of the following practices are essential for a secure cloud native CI/CD pipeline?

Select 3 answers
A.Sign container images and verify signatures during deployment
B.Store secrets in plain text in the pipeline configuration
C.Use a single long-lived service account for all pipeline steps
D.Scan container images for vulnerabilities before deployment
E.Apply least-privilege IAM roles to pipeline components
AnswersA, D, E

Ensures image integrity and authenticity.

Why this answer

Signing container images (e.g., using Cosign or Notary) and verifying those signatures during deployment ensures that only trusted, unmodified images are deployed, preventing supply chain attacks. This practice enforces image integrity and provenance, which is a core security requirement for cloud native CI/CD pipelines.

Exam trap

CNCF often tests the misconception that storing secrets in plain text is acceptable if the pipeline is 'internal' or 'trusted,' but the KCNA exam emphasizes that secrets must never be stored in plain text in any CI/CD configuration.

Full explanation →
519
Multi-Selectmedium

Which TWO of the following are core principles of the 12-factor app? (Choose 2.)

Select 2 answers
A.Shared state
B.Manual deployment
C.Dependencies
D.Singleton processes
E.Config
AnswersC, E

Why this answer

The 12-factor app includes principles such as explicit dependency declaration (Dependencies) and strict separation of config from code (Config).

Full explanation →
520
MCQmedium

A Pod is stuck in 'Pending' state. Which command is most helpful to diagnose the issue?

A.kubectl logs my-pod
B.kubectl get events
C.kubectl describe pod my-pod
D.kubectl top pod my-pod
AnswerC

This shows events and status conditions that indicate why the Pod is pending (e.g., insufficient resources).

Why this answer

'kubectl describe pod my-pod' provides detailed information about the pod's current state, including events, conditions, and resource constraints. When a pod is stuck in 'Pending', it typically means the scheduler cannot place it on a node due to issues like insufficient CPU/memory, persistent volume claims not being bound, or node selector mismatches. The 'describe' command surfaces these specific reasons in the 'Events' section and 'Conditions' field, making it the most direct diagnostic tool.

Exam trap

CNCF often tests the misconception that 'kubectl logs' is the universal debugging command, but for pending pods, logs are unavailable because containers haven't started, making 'kubectl describe' the correct choice for pre-run failures.

How to eliminate wrong answers

Option A is wrong because 'kubectl logs my-pod' retrieves container logs, but a pod in 'Pending' state has not started any containers yet, so there are no logs to fetch; this command is useful only after the pod is running. Option B is wrong because 'kubectl get events' shows cluster-wide events, which can be noisy and may not filter to the specific pod; while it can include scheduling failures, it lacks the pod-specific context and resource details that 'describe' provides. Option D is wrong because 'kubectl top pod my-pod' shows real-time resource usage metrics, which are only available for running pods; a pending pod has no resource consumption data to report.

Full explanation →
521
MCQmedium

A developer created a Deployment with image 'myapp:v1' and then ran 'kubectl set image deployment/myapp myapp=myapp:v2'. What is the effect of this command?

A.It updates the Service selector to point to pods with the new image.
B.It updates the Deployment's pod template to use the new image, triggering a rolling update.
C.It creates a new Deployment named 'v2' with the new image.
D.It immediately restarts all pods with the new image.
AnswerB

The command modifies the Deployment's container image, initiating a rolling update.

Why this answer

The `kubectl set image deployment/myapp myapp=myapp:v2` command updates the pod template within the Deployment's specification to use the new image `myapp:v2`. This change triggers a rolling update, where the Deployment controller creates new pods with the updated image and gradually terminates old pods, ensuring zero downtime. The command does not affect Services, create new Deployments, or restart pods immediately without a rolling update strategy.

Exam trap

CNCF often tests the distinction between updating a Deployment's pod template (which triggers a rolling update) versus directly restarting pods or modifying Services, leading candidates to mistakenly think the command affects Service selectors or creates a new Deployment.

How to eliminate wrong answers

Option A is wrong because `kubectl set image` only modifies the Deployment's pod template; it does not update Service selectors, which are used to route traffic to pods based on labels, not image versions. Option C is wrong because the command updates the existing Deployment's pod template in place, not creating a new Deployment; Kubernetes Deployments are versioned through their pod template changes, not by creating separate Deployment objects. Option D is wrong because the command does not immediately restart all pods; it updates the desired state in the Deployment's pod template, and the Deployment controller performs a rolling update according to the `strategy` field (defaulting to RollingUpdate), which gradually replaces pods rather than restarting them all at once.

Full explanation →
522
MCQeasy

Which Kubernetes component is responsible for maintaining the desired state of the cluster by running controller loops?

A.kube-controller-manager
B.etcd
C.kube-apiserver
D.kube-scheduler
AnswerA

The kube-controller-manager runs controller processes that reconcile the actual state with the desired state.

Why this answer

The kube-controller-manager is the component that runs controller loops to regulate the state of the cluster. Each controller (e.g., Node Controller, Replication Controller) watches the shared state via the API server and makes changes to drive the actual cluster state toward the desired state defined in the control plane. This is the core mechanism for self-healing and maintaining declarative configuration.

Exam trap

CNCF often tests the misconception that the API server (kube-apiserver) is responsible for maintaining desired state because it is the central hub, but the API server only serves the API and stores state in etcd, while the actual reconciliation is done by the controller-manager's loops.

How to eliminate wrong answers

Option B (etcd) is wrong because etcd is a distributed key-value store used for cluster data persistence, not for running controller loops; it stores the desired and current state but does not reconcile them. Option C (kube-apiserver) is wrong because the API server is the front-end for the Kubernetes control plane that validates and processes RESTful requests, but it does not execute controller logic or maintain desired state through loops. Option D (kube-scheduler) is wrong because the scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for running controller loops to maintain desired state.

Full explanation →
523
MCQeasy

Which Kubernetes object is used to logically isolate resources within a cluster, such as for separating environments like dev and prod?

A.ClusterRole
B.ResourceQuota
C.Node
D.Namespace
AnswerD

Namespaces partition the cluster into virtual sub-clusters.

Why this answer

D is correct because a Namespace is the Kubernetes object designed to logically isolate resources within a single cluster. By creating separate Namespaces for environments like dev and prod, you can apply distinct policies, quotas, and access controls without needing multiple physical clusters.

Exam trap

The trap here is that candidates often confuse Namespaces with other cluster-scoped or resource-limiting objects, mistakenly thinking a ClusterRole or ResourceQuota can provide logical isolation, when in fact Namespaces are the fundamental building block for environment separation.

How to eliminate wrong answers

Option A is wrong because a ClusterRole is a cluster-scoped RBAC object that defines permissions across the entire cluster, not a mechanism for isolating resources or environments. Option B is wrong because a ResourceQuota is an object that sets hard limits on resource consumption (e.g., CPU, memory) within a specific Namespace, but it does not itself create logical isolation or separate environments. Option C is wrong because a Node is a worker machine (physical or virtual) that runs Pods; it is a compute resource, not an object for logically separating environments within a cluster.

Full explanation →
524
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 CPU request for the container
B.Increase the memory limit in the pod's container resource specification
C.Delete and recreate the pod to clear the crash loop
D.Delete the namespace and redeploy all workloads
AnswerB

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

The OOMKilled status indicates the container was terminated because it exceeded its memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, which allows the container to use more memory without being killed by the Out-Of-Memory (OOM) killer. This resolves the root cause by providing sufficient memory for the workload.

Exam trap

The trap here is that candidates confuse CPU and memory resource management, assuming increasing CPU requests can resolve memory-related OOM kills, or they opt for a destructive restart instead of adjusting the resource specification.

How to eliminate wrong answers

Option A is wrong because increasing the CPU request does not address memory exhaustion; CPU and memory are independent resources, and OOMKilled is triggered by memory limits, not CPU. Option C is wrong because deleting and recreating the pod only restarts the container with the same resource limits, so it will immediately crash again due to the same memory constraint. Option D is wrong because deleting the entire namespace and redeploying all workloads is an extreme, unnecessary action that disrupts all other workloads and does not fix the underlying memory limit issue.

Full explanation →
Page 6

Page 7 of 12

Page 8

All pages

123456789101112

Practice KCNA by domain

Target a specific domain to shore up weak areas.

Kubernetes FundamentalsContainer OrchestrationCloud Native ArchitectureCloud Native ObservabilityCloud Native Application Delivery
See all domains with question counts →