Courseiva

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 1–75

930 questions total · 13pages · All types, answers revealed

Take a mock examExam hub

Page 1 of 13

Page 2
1
MCQmedium

You have a ConfigMap named 'app-config' with key 'database.url'. Which environment variable reference in a Pod spec injects this value correctly?

A.env: - name: DATABASE_URL valueFrom: configMapKeyRef: name: app-config key: database.url
B.env: - name: DATABASE_URL value: "$(APP_CONFIG_DATABASE_URL)"
C.env: - name: DATABASE_URL valueFrom: secretKeyRef: name: app-config key: database.url
D.env: - name: DATABASE_URL valueFrom: configMapRef: name: app-config key: database.url
AnswerA

configMapKeyRef injects a single named key from a ConfigMap as an environment variable, satisfying the requirement to map key 'database.url' into DATABASE_URL. The name field targets the 'app-config' ConfigMap and key selects the exact entry, so the container receives that value at startup.

Why this answer

It uses the `configMapKeyRef` field under `valueFrom` to reference a specific key (`database.url`) from the ConfigMap named `app-config`. This is the standard Kubernetes syntax for injecting a single key from a ConfigMap as an environment variable into a Pod.

Exam trap

The trap here is that candidates may confuse `configMapKeyRef` with `configMapRef` (which is used with `envFrom`, not `valueFrom`) or mistakenly use `secretKeyRef` for ConfigMaps, thinking the syntax is interchangeable.

How to eliminate wrong answers

Option B is wrong because `$(APP_CONFIG_DATABASE_URL)` is not a valid Kubernetes syntax for referencing ConfigMap values; it resembles a shell variable substitution, not a Kubernetes environment variable reference. Option C is wrong because it uses `secretKeyRef`, which is for referencing Secrets, not ConfigMaps; ConfigMaps must use `configMapKeyRef`. Option D is wrong because `configMapRef` is not a valid field under `valueFrom`; the correct field is `configMapKeyRef`.

Full explanation →
2
MCQmedium

A team wants to manage their Kubernetes infrastructure using code. Which tool is specifically designed for Infrastructure as Code (IaC) and can manage Kubernetes resources?

A.Helm
B.kubectl
C.Kustomize
D.Terraform
AnswerD

Terraform is a declarative IaC tool with a Kubernetes provider that manages cluster resources as code, tracking state and planning changes. It satisfies the requirement for a purpose-built IaC tool capable of provisioning and managing Kubernetes objects.

Why this answer

Terraform is a dedicated Infrastructure as Code (IaC) tool that uses declarative configuration files (HCL) to provision and manage cloud resources, including Kubernetes clusters and their workloads. It maintains state to track resource dependencies and can orchestrate Kubernetes resources via its Kubernetes provider, making it the correct choice for managing Kubernetes infrastructure as code.

Exam trap

The trap here is that candidates confuse Helm or Kustomize as IaC tools because they manage Kubernetes resources declaratively, but they lack the infrastructure provisioning and state management capabilities that define true Infrastructure as Code.

How to eliminate wrong answers

Option A is wrong because Helm is a package manager for Kubernetes that deploys pre-packaged applications (charts) but is not an IaC tool; it manages releases and templates, not infrastructure state. Option B is wrong because kubectl is a command-line client for interacting with Kubernetes API directly, used for imperative or ad-hoc operations, not for declarative infrastructure provisioning or state management. Option C is wrong because Kustomize is a configuration customization tool that overlays patches on Kubernetes manifests without managing infrastructure state or provisioning resources outside of Kubernetes.

Full explanation →
3
Multi-Selecthard

Which three of the following are true about Services in Kubernetes? (Select three.)

Select 3 answers
A.A Service provides a stable IP address for a set of pods
B.A Service can load balance traffic across multiple pods
C.A Service can be used for internal cluster traffic only using ClusterIP
D.A Service can store configuration data for applications
E.A Service can replace an Ingress for HTTP routing
AnswersA, B, C

A Service's ClusterIP is virtual and stable, remaining constant while backing pods are created, deleted or rescheduled. This satisfies the decoupling constraint in the stem: clients address a fixed virtual IP, and kube-proxy translates it to current endpoint IPs, so pod churn never breaks connectivity.

Why this answer

Option A is correct because a Kubernetes Service is assigned a stable virtual IP (the ClusterIP) and DNS name that front a dynamic set of pod endpoints, so clients get a consistent address even as pods are created or destroyed. Option B is correct because kube-proxy programs iptables/IPVS (or the equivalent) rules so that traffic sent to the Service's ClusterIP is load balanced across the matching pods selected by the Service's label selector. Option C is correct because the default ClusterIP Service type exposes the Service only on an internal, cluster-routable virtual IP, making it reachable solely from within the cluster unless NodePort, LoadBalancer, or an Ingress is added.

Option D is not correct because storing configuration data is the role of ConfigMaps and Secrets, not Services, which only handle network endpoint abstraction. Option E is not correct because Ingress provides HTTP/HTTPS layer-7 host- and path-based routing via an ingress controller, whereas a Service only offers layer-4 (or simple L7 with newer Gateway API) access to a single set of pods and cannot perform Ingress-style routing.

Exam trap

Candidates often confuse Services with other resources: Services do not store configuration data (that's ConfigMaps/Secrets) and do not provide HTTP routing (that's Ingress). Services operate at Layer 4 (TCP/UDP), not Layer 7, so they cannot replace Ingress for HTTP-specific routing.

Full explanation →
4
MCQmedium

Which component on each worker node is responsible for ensuring that containers are running as specified in the Pod manifest?

A.kube-scheduler
B.container runtime
C.kubelet
D.kube-proxy
AnswerC

kubelet runs on every worker node and reconciles the node's containers against their PodSpecs, starting, stopping and reporting container status. This directly satisfies the stem's requirement for the per-node component ensuring containers run as specified in the Pod manifest.

Why this answer

The kubelet is the primary node agent that runs on each worker node. It receives Pod manifests (via the API server or a file) and ensures the containers described in those manifests are running and healthy. It interacts with the container runtime (e.g., containerd) to create, start, and stop containers as needed, continuously reconciling the actual state with the desired state defined in the Pod spec.

Exam trap

A common trap in the KCNA exam is confusing the kubelet with the container runtime. Remember: the kubelet is the Kubernetes agent that ensures containers are running as specified, while the container runtime is the underlying software (like containerd) that actually executes the containers.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is a control plane component responsible for assigning Pods to nodes based on resource requirements and constraints; it does not run on worker nodes nor manage container lifecycle. Option B is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it is the kubelet that instructs the runtime which containers to run and monitors their status; the runtime itself does not interpret Pod manifests or enforce desired state. Option D is wrong because kube-proxy is a network proxy that runs on each node, managing network rules (e.g., iptables, IPVS) for service load balancing; it has no role in ensuring containers are running.

Full explanation →
5
MCQmedium

In the 12-factor app methodology, which factor describes the practice of storing configuration in environment variables?

A.Backing services
B.Config
C.Processes
D.Build, release, run
AnswerB

The Config factor requires configuration to be stored in environment variables rather than committed to code, enabling the same deployment artefact to run across environments. This separation lets operators change settings without rebuilding, exactly as the stem describes.

Why this answer

The Config factor (Factor III) of the 12-factor app methodology mandates that configuration—such as database URLs, credentials, or feature flags—be stored in environment variables. This decouples configuration from code, allowing the same build to be deployed across different environments without code changes, and prevents accidental commits of secrets to version control.

Exam trap

CNCF often tests the distinction between 'Config' and 'Backing services'—candidates mistakenly think storing database credentials in environment variables is a 'Backing services' concern, but it is actually a 'Config' concern because the credentials are configuration, not the service itself.

How to eliminate wrong answers

Option A is wrong because 'Backing services' (Factor IV) treats attached services (databases, caches, message queues) as disposable resources accessed via URL or binding, not about storing configuration. Option C is wrong because 'Processes' (Factor VI) concerns stateless execution and sharing nothing between processes, not configuration storage. Option D is wrong because 'Build, release, run' (Factor V) describes the strict separation of build, release, and run stages to ensure immutability, not the mechanism for injecting configuration.

Full explanation →
6
MCQeasy

A security team wants to audit which users performed privileged actions in a Kubernetes cluster. They need a record of API requests, including the user, verb, resource, and response status. Which Kubernetes feature should they enable?

A.Metrics-server
B.Pod Security Admission
C.Event recording
D.Audit logging
AnswerD

Kubernetes audit logging records API server requests, capturing details such as the authenticated user, the verb, the resource, and the response status. Enabling audit policies and log backends provides the security team with the requested record of privileged actions. This directly satisfies the requirement to audit who did what in the cluster, making it the correct feature.

Why this answer

Audit logging in Kubernetes records API server requests with user, verb, resource, and response details, which is exactly what the security team needs to trace privileged actions. Event recording is limited to cluster events, metrics-server provides resource metrics, and Pod Security Admission enforces policies but does not create an audit trail. Only audit logging delivers the required request-level records.

Exam trap

The trap here is confusing event recording with audit logging, assuming that cluster events provide a complete record of API requests and user actions.

Full explanation →
7
MCQmedium

In a service mesh architecture, which component is responsible for intercepting and managing traffic to and from a pod?

A.Sidecar proxy
B.Ingress controller
C.API gateway
D.Control plane
AnswerA

The sidecar proxy runs alongside each pod, intercepting inbound and outbound traffic at the pod level. It enforces the mesh's routing, mTLS and telemetry policies, which is why it, rather than the control plane, handles per-pod traffic management.

Why this answer

The sidecar proxy (e.g., Envoy) runs alongside each service instance and intercepts all network traffic, enabling features like traffic management and observability.

Full explanation →
8
MCQhard

When using OpenTelemetry, what is the role of the 'Collector'?

A.To alert on abnormal metrics
B.To store traces for long-term retention
C.To receive, process, and export telemetry data in a vendor-neutral way
D.To instrument application code manually
AnswerC

The Collector's pipeline receives telemetry via receivers, optionally processes it, then exports through exporters, decoupling applications from backends. This vendor-neutral mediation satisfies the stem's requirement that data be handled independently of any specific monitoring vendor.

Why this answer

The OpenTelemetry Collector is a vendor-agnostic proxy that receives telemetry data (traces, metrics, logs) from instrumented applications, processes it (e.g., batching, filtering, enrichment), and exports it to one or more backends (e.g., Jaeger, Prometheus, or any OTLP-compatible system). It decouples data generation from data storage, enabling flexible, scalable observability pipelines without vendor lock-in.

Exam trap

CNCF often tests the misconception that the Collector is a storage or alerting system, when in fact it is a stateless pipeline component that only receives, processes, and exports telemetry data.

How to eliminate wrong answers

Option A is wrong because alerting on abnormal metrics is the responsibility of monitoring systems like Prometheus with Alertmanager, not the OpenTelemetry Collector, which focuses on data ingestion, processing, and export. Option B is wrong because long-term storage of traces is handled by backend systems (e.g., Jaeger, Tempo) or databases; the Collector is a pipeline component that forwards data, not a persistent store. Option D is wrong because manual instrumentation of application code is done using OpenTelemetry SDKs and APIs (e.g., for traces, metrics), while the Collector operates as a separate infrastructure component that receives already-instrumented telemetry.

Full explanation →
9
MCQeasy

Which command is used to rollback a Helm release to a previous revision?

A.helm history <release-name>
B.helm rollback <release-name> <revision>
C.helm install <release-name>
D.helm upgrade <release-name>
AnswerB

Helm stores each release's revision history, so `helm rollback <release-name> <revision>` redeploys a specified earlier revision, restoring its manifests and values. This directly satisfies the requirement to revert a release to a previous revision, unlike `helm upgrade`, which moves forward to a new revision.

Why this answer

The `helm rollback` command rolls back a release to a specified revision. Option B (helm rollback <release-name> <revision>) is the correct command. Option A (helm history) shows revision history, not a rollback.

Option C (helm install) installs a new release. Option D (helm upgrade) upgrades to a new version, not a rollback.

Full explanation →
10
MCQmedium

An SRE team is reviewing a stateless web tier that runs as a Deployment. They want the platform to automatically add replicas when average CPU utilization across the Pods rises above a target, and to remove replicas when load drops, without any manual intervention. Which Kubernetes resource should they configure?

A.HorizontalPodAutoscaler
B.PodDisruptionBudget
C.Cluster Autoscaler
D.VerticalPodAutoscaler
AnswerA

The HorizontalPodAutoscaler adjusts the replica count of a scalable workload such as a Deployment based on observed metrics. With the autoscaling/v2 API you can set a CPU utilization target, and the controller periodically compares the metrics-server-reported usage against that target and scales the replica count up or down within the configured minimum and maximum. This is exactly the desired automatic behaviour.

Why this answer

The HorizontalPodAutoscaler is the controller that reads metrics such as average CPU utilization and adjusts a Deployment's replica count within a min/max range. The VerticalPodAutoscaler resizes individual Pods, Cluster Autoscaler resizes the node pool, and PodDisruptionBudget only protects availability during voluntary disruptions, so none of them provide demand-driven replica scaling.

Exam trap

The trap here is confusing scaling the number of Pods with scaling the resources inside a Pod or scaling the nodes that host them.

Full explanation →
11
MCQeasy

Which component runs on every node and is responsible for ensuring that containers are running as specified in Pod manifests?

A.kubelet
B.kube-proxy
C.container runtime
D.kube-controller-manager
AnswerA

The kubelet is the node agent that watches the API server for PodSpecs bound to its node and starts, stops and health-checks the containers to match that declared state. It therefore satisfies the stem's constraint of running on every node.

Why this answer

The kubelet is the primary node agent that runs on every node in a Kubernetes cluster. It is responsible for ensuring that containers described in Pod manifests (typically provided via the API server) are running and healthy. The kubelet does not manage containers directly; instead, it interacts with the container runtime (e.g., containerd, CRI-O) to create, start, and stop containers as specified.

Exam trap

The trap here is that candidates confuse the container runtime (which actually runs containers) with the kubelet (which ensures the desired state from Pod manifests), leading them to pick 'container runtime' instead of 'kubelet'.

How to eliminate wrong answers

Option B is wrong because kube-proxy is a network proxy that runs on each node, handling network rules and forwarding traffic for Services, not managing container lifecycle. Option C is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it is not responsible for reconciling Pod manifests or ensuring desired state — that is the kubelet's job. Option D is wrong because kube-controller-manager runs as a control plane component (not on every node) and manages controllers like ReplicaSet and Node Controller, but does not directly interact with containers on individual nodes.

Full explanation →
12
Multi-Selecthard

A pod is stuck in Pending state. Which THREE of the following are possible causes?

Select 3 answers
A.The pod specifies a nodeSelector that does not match any node
B.The container image does not exist
C.No node has enough CPU or memory to satisfy the pod's resource requests
D.The pod has a liveness probe that is failing
E.A PersistentVolumeClaim used by the pod is not bound
AnswersA, C, E

The scheduler filters nodes by nodeSelector; if no node carries matching labels, no feasible node remains, so the pod stays Pending with no node assigned. This directly satisfies the stem's Pending constraint, since scheduling never completes.

Why this answer

Option A is correct because the scheduler filters nodes using the pod's nodeSelector (and node affinity); if no node carries matching labels, the pod cannot be placed and remains Pending. Option C is correct because the scheduler only assigns a pod to a node whose allocatable resources can satisfy the pod's resource requests; insufficient CPU/memory leaves the pod unschedulable in Pending. Option E is correct because a pod referencing an unbound PersistentVolumeClaim cannot be scheduled until the PVC is bound to a PersistentVolume, so it stays Pending.

Option B is not a scheduling cause: a nonexistent image leads to ImagePullBackOff/ErrImagePull after the pod has been scheduled to a node, so the pod is not Pending. Option D is also not a scheduling cause: a failing liveness probe only occurs after the container is running, causing restarts (CrashLoopBackOff), not a Pending phase.

Exam trap

CNCF often tests the distinction between scheduling failures (Pending) and runtime failures (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly attribute image or probe issues to the Pending state.

Full explanation →
13
MCQeasy

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
14
MCQmedium

You need to run a stateless web application with three replicas, and you want to ensure that if a pod fails, it is automatically replaced. Which Kubernetes resource should you use?

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

A Deployment manages a ReplicaSet, which maintains the desired replica count by creating replacement pods whenever one fails. This directly satisfies the self-healing requirement for three stateless replicas, unlike a bare Pod or DaemonSet, which cannot guarantee continuous availability across nodes.

Why this answer

A Deployment is the correct resource because it manages a ReplicaSet to ensure the desired number of pod replicas (three) are running at all times. If a pod fails, the Deployment's controller automatically creates a replacement pod, maintaining the stateless application's availability.

Exam trap

The trap here is that candidates confuse StatefulSet with Deployment for stateless apps because both manage replicas, but StatefulSet introduces ordered pod creation and persistent identities that are unnecessary and can cause overhead for stateless workloads.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that exactly one pod runs on each node, not a specified number of replicas, and is used for node-level services like logging or monitoring. Option B is wrong because a Job runs a finite task to completion and does not maintain a continuous set of running replicas. Option C is wrong because a StatefulSet is designed for stateful applications requiring stable network identities and persistent storage, which is unnecessary for a stateless web application.

Full explanation →
15
Multi-Selecthard

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

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

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

Why this answer

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

Exam trap

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

Full explanation →
16
Multi-Selectmedium

Which TWO of the following are valid PromQL functions? (Select two.)

Select 2 answers
A.topk()
B.histogram_quantile()
C.rate()
D.avg()
E.sum()
AnswersB, C

histogram_quantile() calculates quantiles from histogram metrics.

Why this answer

rate() and histogram_quantile() are common PromQL functions. avg_over_time() is also valid but avg is not a function, it's an aggregation operator.

Full explanation →
17
MCQhard

In the context of the 12-factor app methodology, which factor is addressed by storing configuration in environment variables?

A.IV. Backing Services
B.III. Config
C.II. Dependencies
D.I. Codebase
AnswerB

Storing configuration in environment variables directly implements factor III, Config, which mandates strict separation of config from code. This satisfies the stem's constraint by keeping deployment-specific values—credentials, endpoints, feature flags—outside the codebase, so the same artefact deploys unchanged across environments.

Why this answer

Factor III (Config) of the 12-factor app methodology explicitly states that configuration should be stored in environment variables, separating config from code so the same build can be deployed across environments. This allows credentials, endpoints, and environment-specific values to be injected at runtime rather than baked into the artifact.

Exam trap

KCNA often tests whether candidates can map a described practice to the correct numbered factor — the trap is confusing Config (III) with Backing Services (IV) or Dependencies (II), which all touch on externalized resources.

How to eliminate wrong answers

Option A is wrong because Factor IV (Backing Services) concerns treating databases, queues, and caches as attached resources swappable via config, not the storage mechanism for config itself. Option C is wrong because Factor II (Dependencies) is about explicitly declaring and isolating dependencies (e.g., via a manifest), not about configuration storage. Option D is wrong because Factor I (Codebase) is about maintaining a single codebase tracked in version control with many deploys, not about where configuration lives.

Full explanation →
18
MCQeasy

A user wants to check the resource usage of Pods in a cluster. Which command should be used to display CPU and memory usage for all Pods in the default namespace?

A.kubectl top pods
B.kubectl get pods --show-metrics
C.kubectl logs --metrics
D.kubectl describe pods
AnswerA

kubectl top pods displays the current CPU and memory usage for Pods in the default namespace. It requires the Metrics Server to be installed in the cluster. This command is the standard way to view resource usage metrics for Pods. It provides a quick overview of which Pods are consuming the most resources.

Why this answer

The correct command is kubectl top pods, which retrieves CPU and memory usage metrics from the Metrics Server. This command is specifically designed for viewing resource consumption. The other options are either invalid commands or provide different types of information, such as configuration details or logs, but not live resource usage.

Exam trap

The trap here is assuming that kubectl describe or kubectl get can provide live metrics, when only kubectl top is designed for that purpose.

Full explanation →
19
MCQmedium

Which component in a service mesh architecture is responsible for handling inter-service communication on behalf of the application container?

A.Sidecar proxy
B.Control plane
C.Ingress controller
D.API gateway
AnswerA

The sidecar proxy runs alongside each application container, intercepting inbound and outbound traffic and handling service-to-service communication, mTLS, and routing. This offloads networking concerns from the application itself, which is the defining role of the sidecar in a service mesh.

Why this answer

The sidecar proxy (e.g., Envoy) intercepts all network traffic to and from the application container, providing observability, traffic management, and security.

Full explanation →
20
MCQmedium

Which kubectl command would you use to view the logs of a specific container named 'app' in a multi-container Pod named 'web-pod'?

A.kubectl log web-pod container app
B.kubectl logs web-pod app
C.kubectl logs web-pod -c app
D.kubectl logs app web-pod
AnswerC

The -c flag scopes log retrieval to the named container, which is mandatory when a pod holds multiple containers. Without it, kubectl errors or picks the default, so -c app isolates the requested container's output.

Why this answer

The `kubectl logs` command uses the `-c` flag to specify a container name within a multi-container Pod. The correct syntax is `kubectl logs <pod-name> -c <container-name>`, which targets the 'app' container inside 'web-pod'.

Exam trap

The trap here is that candidates often forget the `-c` flag and assume `kubectl logs web-pod app` works by positional arguments, but Kubernetes requires the explicit `-c` flag for multi-container Pods.

How to eliminate wrong answers

Option A is wrong because `kubectl log` is not a valid command; the correct verb is `logs`. Option B is wrong because it omits the `-c` flag, which is required to specify a container in a multi-container Pod; without it, `kubectl logs` defaults to the first container or fails if multiple containers exist. Option D is wrong because the argument order is reversed; the pod name must come first, followed by the `-c` flag and container name.

Full explanation →
21
MCQeasy

What is the role of the kubelet on a worker node?

A.It ensures containers are running in a Pod as specified
B.It stores cluster state
C.It manages network rules for Services
D.It runs the container runtime
AnswerA

kubelet runs on each worker node, watches PodSpecs assigned to it, and starts, stops and probes containers to match the desired state. This satisfies the requirement that containers run as specified, reporting status back to the API server.

Why this answer

The kubelet is the primary node agent that runs on every worker node. Its core responsibility is to ensure that containers described in Pod specs (received from the API server via the kube-apiserver) are running and healthy. It does this by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers, and it reports the Pod and node status back to the control plane.

Exam trap

The trap here is confusing the kubelet's role with that of the container runtime (option D), as many candidates assume the kubelet directly runs containers, but it only orchestrates them via the Container Runtime Interface (CRI).

How to eliminate wrong answers

Option B is wrong because storing cluster state is the job of etcd, a distributed key-value store that runs on the control plane, not the kubelet. Option C is wrong because managing network rules for Services is handled by the kube-proxy component (which implements iptables or IPVS rules), not the kubelet. Option D is wrong because the kubelet does not run the container runtime; it communicates with the container runtime via the Container Runtime Interface (CRI) to manage containers, but the runtime itself (e.g., containerd) is a separate process.

Full explanation →
22
MCQmedium

In a service mesh architecture, what is the role of the sidecar proxy?

A.It provides persistent storage for the pod
B.It manages the lifecycle of the pod
C.It intercepts and controls network communication to and from the main container
D.It serves as the main application container
AnswerC

The sidecar proxy runs alongside the main container, transparently intercepting inbound and outbound network traffic so mesh policies for routing, mTLS, and telemetry apply without changing application code. This interception mechanism is what delivers service mesh traffic control.

Why this answer

The sidecar proxy intercepts all network traffic to/from the main container, enabling observability, traffic management, and security without modifying application code.

Full explanation →
23
MCQhard

A site reliability engineer is investigating high latency in a microservices application. They have distributed traces but need to understand how a single trace spans multiple services and where time is spent. Which OpenTelemetry concept allows correlating spans across service boundaries into a single trace?

A.Metric exemplars
B.Resource attributes
C.Span status
D.Context propagation
AnswerD

Context propagation is the mechanism that passes trace context, including trace ID and span ID, across service boundaries via headers or other carriers. It enables spans created in different services to be linked into a single distributed trace. Without it, each service would create isolated traces, so this concept directly addresses the need to correlate spans across microservices and understand end-to-end latency.

Why this answer

Context propagation carries trace and span identifiers across service calls, allowing spans from different services to be stitched into one distributed trace. Resource attributes describe the producer, span status indicates success or failure, and metric exemplars link metrics to traces, but none of these provide the cross-service linkage required. Therefore, context propagation is the concept that enables end-to-end trace correlation.

Exam trap

The trap here is assuming that attaching trace IDs to metrics or adding resource attributes is enough to correlate spans, when only context propagation actually carries trace context between services.

Full explanation →
24
MCQeasy

Which Prometheus metric type is used to represent a value that can increase or decrease over time, such as memory usage?

A.Gauge
B.Histogram
C.Summary
D.Counter
AnswerA

A gauge holds a snapshot value that can rise or fall arbitrarily, matching memory usage sampled at scrape time. Unlike counters, which only increase (or reset), gauges support set, increment and decrement operations, making them the correct type for fluctuating measurements.

Why this answer

A gauge is the Prometheus metric type designed to represent a value that can arbitrarily go up or down, such as memory usage, temperature, or current connections. Unlike counters, gauges are not monotonic and can be set to any value, making them ideal for instantaneous measurements. Memory usage fluctuates as processes allocate and free memory, so a gauge accurately captures this behavior.

Exam trap

KCNA often tests the distinction between metric types by presenting a scenario that seems like a counter (e.g., 'number of requests') but actually requires a gauge (e.g., 'current memory usage'), so candidates must carefully read whether the value can decrease.

How to eliminate wrong answers

Option B is wrong because a histogram samples observations (usually request durations or response sizes) and counts them in configurable buckets, providing a distribution, not a single fluctuating value. Option C is wrong because a summary also samples observations and calculates configurable quantiles over a sliding time window, which is not suitable for representing a simple value like memory usage. Option D is wrong because a counter is a cumulative metric that only increases (or resets to zero on restart), so it cannot represent a value that decreases, such as memory usage.

Full explanation →
25
Multi-Selecthard

Which THREE of the following are components of the OpenTelemetry project?

Select 3 answers
A.Prometheus
B.Collector
C.Specification
D.Jaeger
E.SDKs (Software Development Kits)
AnswersB, C, E

The Collector is a vendor-agnostic pipeline component that receives, processes and exports telemetry, satisfying OpenTelemetry's requirement for a decoupled data path between instrumented applications and backends. It ships as a standalone binary or agent, letting you centralise batching, filtering and retries without altering application code.

Why this answer

The OpenTelemetry project is composed of several core deliverables, and the Collector (B) is one of them: it is a vendor-neutral agent/gateway that receives, processes, and exports telemetry (traces, metrics, logs) via receivers, processors, and exporters. The Specification (C) is also a core component, defining the cross-language API, SDK, protocol (OTLP), and semantic conventions that all implementations must follow. SDKs (E) are likewise a core component, providing language-specific implementations (e.g., Java, Go, Python, .NET) that generate and export telemetry according to the specification.

Prometheus (A) is a separate CNCF monitoring system and time-series database, not a component of OpenTelemetry, though OTel can export metrics to it. Jaeger (D) is a separate distributed tracing backend (also CNCF) that predates and is independent of OpenTelemetry, even though it can receive OTLP data.

Full explanation →
26
MCQmedium

In the context of DORA metrics, which metric measures how often an organization successfully releases to production?

A.Lead time for changes
B.Deployment frequency
C.Mean time to restore (MTTR)
D.Change failure rate
AnswerB

Deployment frequency counts how often the team ships releases to production within a given period. It directly measures release cadence, distinguishing it from lead time for changes, change failure rate and mean time to restore.

Why this answer

Deployment frequency is a DORA metric that measures how often an organization deploys code to production or an operational environment.

Full explanation →
27
MCQmedium

Which Kubernetes object provides stable network endpoints and load balancing for a set of Pods?

A.NetworkPolicy
B.Deployment
C.Ingress
D.Service
AnswerD

A Service assigns a stable virtual IP and DNS name, then load-balances traffic across the backing Pods selected by its label selector. Pod IPs change as Pods restart, so the Service abstraction satisfies the requirement for stable network endpoints.

Why this answer

A Service is the Kubernetes abstraction that defines a logical set of Pods and a policy for accessing them, providing a stable IP address and DNS name that remains constant even as Pods are created or destroyed. Services use label selectors to identify target Pods and perform Layer 4 (TCP/UDP) load balancing across them, either via iptables, IPVS, or eBPF rules in kube-proxy.

Exam trap

The trap here is that candidates confuse the Ingress (Layer 7 routing) with the Service (Layer 4 load balancing), forgetting that Ingress requires a Service to forward traffic to Pods and does not itself provide stable endpoints.

How to eliminate wrong answers

Option A is wrong because a NetworkPolicy is a security resource that controls ingress and egress traffic to Pods at the network layer, not a mechanism for stable endpoints or load balancing. Option B is wrong because a Deployment manages the desired state and lifecycle of Pods (replicas, rollouts, rollbacks) but does not expose a stable network endpoint; Pod IPs are ephemeral and change on restart. Option C is wrong because an Ingress is a Layer 7 (HTTP/HTTPS) routing resource that sits in front of Services, providing host/path-based routing and TLS termination, but it does not itself provide stable endpoints or load balancing for Pods—it relies on a Service for that.

Full explanation →
28
MCQmedium

During a canary deployment using Argo Rollouts, how does the tool determine the success of the canary before promoting it?

A.By checking the rollout's status field in the YAML
B.By requiring manual approval via a webhook
C.By comparing the ReplicaSet's age to a threshold
D.By analyzing predefined metrics (e.g., error rate) via an AnalysisTemplate
AnswerD

Argo Rollouts queries predefined metrics such as error rate through an AnalysisTemplate, which defines the Prometheus or other provider queries and success thresholds. The controller evaluates these during the canary step and only promotes when results pass, satisfying the stem's requirement for automated success determination before promotion.

Why this answer

Argo Rollouts uses AnalysisTemplates to define metrics queries (e.g., Prometheus, Datadog) that are evaluated during a canary deployment. The success of the canary is determined by these predefined metrics, such as error rate or latency, against thresholds. If the analysis passes, the rollout is promoted; if it fails, the rollout is aborted or rolled back.

Exam trap

KCNA often tests the mechanism of automated analysis in Argo Rollouts, and candidates may confuse manual approval or status checks with metric-based analysis, missing the role of AnalysisTemplates.

How to eliminate wrong answers

Option A is wrong because checking the rollout's status field only indicates the current phase (e.g., Progressing, Paused), not the success based on metrics; it does not automatically determine promotion. Option B is wrong because manual approval via webhook is an optional step, not the primary method for determining success; Argo Rollouts supports automated analysis. Option C is wrong because comparing ReplicaSet age is not a metric for success; Argo Rollouts does not use age thresholds for promotion decisions.

Full explanation →
29
Multi-Selecteasy

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

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

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

Why this answer

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

Exam trap

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

Full explanation →
30
MCQeasy

Which of the following best describes the purpose of the Cloud Native Computing Foundation (CNCF)?

A.To promote cloud native technologies and host open source projects
B.To define the 12-factor app methodology
C.To provide cloud infrastructure services for enterprises
D.To develop and maintain the Kubernetes project exclusively
AnswerA

The CNCF fosters adoption of containers, service meshes and related cloud native patterns by hosting graduated, incubating and sandbox projects under neutral open governance. This matches the stem's description of promoting cloud native technologies and hosting open source projects.

Why this answer

The CNCF's primary purpose is to foster the adoption of cloud native technologies by hosting and governing open source projects like Kubernetes, Prometheus, and Envoy. It provides a neutral home for these projects, ensuring they are developed collaboratively under a vendor-neutral governance model. This aligns directly with option A, which captures both the promotional and hosting roles of the foundation.

Exam trap

CNCF often tests the misconception that the CNCF is synonymous with Kubernetes alone, but the trap here is that the CNCF's scope includes a wide ecosystem of cloud native projects, not just Kubernetes.

How to eliminate wrong answers

Option B is wrong because the 12-factor app methodology was defined by Heroku engineers in 2011, not by the CNCF, and while the CNCF promotes cloud native patterns, it did not create that specific methodology. Option C is wrong because the CNCF does not provide cloud infrastructure services (e.g., compute, storage, networking) — that is the role of cloud providers like AWS, Azure, or GCP; the CNCF is a foundation that hosts projects, not a service provider. Option D is wrong because while the CNCF hosts Kubernetes, it also hosts dozens of other projects (e.g., Prometheus, Fluentd, Linkerd) and is not exclusive to Kubernetes; its mission is broader than any single project.

Full explanation →
31
MCQmedium

Which command would you use to view the logs of a container named 'web' in a pod named 'frontend' running in the 'production' namespace?

A.kubectl logs -c web frontend --namespace production
B.kubectl logs frontend -c web -n production
C.kubectl logs frontend -n production container web
D.kubectl logs frontend web --namespace production
AnswerB

`kubectl logs` targets a single container's stdout/stderr stream, and the `-c web` flag selects the container named 'web' within the pod, while `-n production` satisfies the namespace constraint. Without `-c`, the command would fail on a multi-container pod or default to the wrong container.

Why this answer

The `kubectl logs` command requires the pod name as the first positional argument, and the `-c` flag specifies the container name when a pod has multiple containers. The `-n` flag sets the namespace. The correct syntax is `kubectl logs <pod-name> -c <container-name> -n <namespace>`, which matches option B exactly.

Exam trap

CNCF often tests the correct ordering of flags and positional arguments in `kubectl` commands, specifically that the `-c` container flag must come after the pod name, not before, and that omitting it when a pod has multiple containers will not target the intended container.

How to eliminate wrong answers

Option A is wrong because it places the `-c web` flag before the pod name, which is syntactically incorrect; the `-c` flag must follow the pod name. Option C is wrong because it uses an invalid positional argument 'container' after the pod name; `kubectl logs` does not accept a literal 'container' keyword. Option D is wrong because it omits the `-c` flag entirely, so it would attempt to view logs from the pod's default container (or fail if the pod has multiple containers and no default is defined), not specifically from the container named 'web'.

Full explanation →
32
Multi-Selectmedium

Which TWO of the following are valid ways to expose a Deployment as a Service?

Select 2 answers
A.Run 'kubectl expose deployment my-deployment --port=80 --target-port=8080'
B.Edit the Deployment and set 'spec.serviceName'
C.Run 'kubectl run my-deployment --image=nginx --expose'
D.Add a 'service' section to the Deployment's YAML manifest
E.Create a Service YAML with a selector matching the Deployment's pod labels
AnswersA, E

The imperative 'kubectl expose' command reads the Deployment's pod template, creates a Service with the matching label selector, and maps port 80 to container port 8080. It is a valid, supported way to expose a Deployment.

Why this answer

Option A is correct because 'kubectl expose deployment my-deployment --port=80 --target-port=8080' is the imperative command that creates a Service of type ClusterIP (by default) targeting the Deployment's pods, with the Service port 80 forwarding to container port 8080. Option E is correct because a Service is decoupled from the Deployment and selects its backing pods via 'spec.selector' matching the Deployment's pod template labels (e.g., app=my-deployment), so authoring a Service YAML with the correct selector is a valid declarative way to expose the Deployment. Option B is incorrect because 'spec.serviceName' is not a valid Deployment field; the closest concept, 'serviceName', belongs to StatefulSet's spec and is used for headless Service governance, not for exposing a Deployment.

Option C is incorrect because 'kubectl run' creates a new Pod (or with newer versions a Pod), not a Deployment, and '--expose' would expose that newly created resource rather than an existing Deployment. Option D is incorrect because a Deployment's manifest has no 'service' section; Services are separate API objects (kind: Service) and cannot be embedded in a Deployment spec.

Exam trap

The trap here is that candidates confuse 'kubectl run --expose' (which creates a Pod, not a Deployment) with exposing an existing Deployment, or incorrectly assume that a Deployment can contain a Service definition within its own YAML manifest.

Full explanation →
33
MCQmedium

In an event-driven architecture, what is the role of an event broker?

A.To intermediate between event producers and consumers
B.To run event-processing logic
C.To transform events into API calls
D.To store event schemas
AnswerA

An event broker decouples producers from consumers by receiving published events and routing them to subscribed parties, satisfying the asynchronous, many-to-many delivery constraint of event-driven architecture. It intermediates without producers knowing consumer identities, enabling independent scaling and fault tolerance across services.

Why this answer

In an event-driven architecture, the event broker acts as a middleware that decouples event producers from consumers by receiving events from producers and forwarding them to interested consumers. This intermediary role ensures asynchronous communication, scalability, and fault tolerance without requiring producers and consumers to be directly aware of each other. Technologies like Apache Kafka, RabbitMQ, or cloud-native services such as AWS EventBridge exemplify this pattern.

Exam trap

CNCF often tests the misconception that the event broker performs processing or transformation, but its core role is purely intermediary—routing events without executing business logic.

How to eliminate wrong answers

Option B is wrong because running event-processing logic is the responsibility of event processors or stream processing frameworks (e.g., Apache Flink, Kafka Streams), not the event broker, which focuses on routing and delivery. Option C is wrong because transforming events into API calls is a function of an API gateway or integration layer, not the event broker; brokers handle event transport, not protocol translation. Option D is wrong because storing event schemas is typically managed by a schema registry (e.g., Confluent Schema Registry) that works alongside the broker, but the broker itself does not store schemas—it stores and forwards event data.

Full explanation →
34
MCQhard

What is the main advantage of using OpenTelemetry over vendor-specific instrumentation libraries?

A.It provides a single, vendor-agnostic instrumentation standard
B.It eliminates the need for logging
C.It automatically reduces latency
D.It is the only tool that supports traces
AnswerA

OpenTelemetry supplies one vendor-neutral instrumentation standard, so traces, metrics and logs are emitted once and exported to any compatible backend. This avoids rewriting instrumentation when changing vendors, which is the core advantage over proprietary libraries.

Why this answer

OpenTelemetry provides a unified standard that avoids vendor lock-in, allowing data to be sent to any backend.

Full explanation →
35
Multi-Selecthard

Which THREE of the following are benefits of using a service mesh? (Choose 3.)

Select 3 answers
A.Database management
B.Security
C.Observability
D.Code compilation
E.Traffic management
AnswersB, C, E

A service mesh enforces mutual TLS between workloads, provides identity-based authentication and authorisation, and centralises policy, delivering encryption and access control without application changes. This satisfies the stem's security benefit, complementing traffic management, observability and resilience rather than replacing them.

Why this answer

A service mesh provides security benefits (B) by enforcing mutual TLS (mTLS) between workloads, issuing and rotating service identities/certificates, and applying fine-grained authorization policies without changing application code. It delivers observability (C) through sidecar proxies that automatically collect metrics (e.g., request rate, latency, error rates), distributed traces, and access logs across service-to-service calls. It also offers traffic management (E) via features such as dynamic routing, load balancing, retries, timeouts, circuit breaking, and canary or blue/green deployments.

The remaining options are unrelated: database management (A) is handled by database systems or DBaaS platforms, not a service mesh, and code compilation (D) is a build-time developer/CI activity that a service mesh does not perform.

Exam trap

CNCF often tests the misconception that a service mesh is a general-purpose tool for all infrastructure concerns, leading candidates to incorrectly select options like database management or code compilation, when in fact the service mesh is narrowly focused on network-level traffic management, security, and observability.

Full explanation →
36
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
37
Multi-Selectmedium

A platform engineer is troubleshooting a Pod stuck in the Pending state and wants to identify scheduling-related causes. Which two commands or outputs are most useful for diagnosing why the scheduler cannot place the Pod? (Choose two.)

Select 2 answers
A.kubectl get events --field-selector involvedObject.name=<pod-name>
B.kubectl get nodes and review the STATUS and Allocatable columns
C.kubectl describe pod <pod-name> and inspect the Events section
D.kubectl exec -it <pod-name> -- /bin/sh to inspect the node from inside
E.kubectl logs <pod-name> to read the container startup output
AnswersA, C

Filtering cluster events by the involved object name surfaces the same scheduler warnings and failure reasons in a time-ordered list, which is helpful when events have scrolled past the default kubectl describe output window. It confirms conditions such as FailedScheduling with the specific predicate that rejected each candidate node.

Why this answer

Scheduling failures are reported as events on the Pod object. Both kubectl describe pod and a field-selector-filtered kubectl get events expose FailedScheduling messages that name the blocking predicate, such as insufficient resources or an unsatisfied node affinity. Node listings and container logs or exec sessions cannot reveal scheduler decisions for a Pod that has never been bound to a node.

Exam trap

The trap here is reaching for kubectl logs or kubectl exec on a Pending Pod, when those commands require a running container and a Pending Pod has none.

Full explanation →
38
MCQhard

You have a Pod that needs to run a one-time batch job to completion. Which resource type should you use?

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

A Job's controller tracks completions and retries failed pods until the specified count succeeds, then stops. Unlike a Deployment, which restarts pods indefinitely to maintain a desired replica count, a Job suits run-to-completion batch work.

Why this answer

A Job resource is designed for running a finite task to completion, such as a batch job or a one-time computation. Unlike controllers that maintain a desired number of replicas indefinitely, a Job creates one or more Pods and tracks their successful termination. Once the specified number of completions is reached, the Job is considered finished and no further Pods are created.

Exam trap

The trap here is that candidates often confuse a Job with a Deployment, thinking that any workload that runs a container should use a Deployment, but Deployments are designed for long-running services, not ephemeral batch tasks.

How to eliminate wrong answers

Option B (StatefulSet) is wrong because StatefulSets are used for stateful applications that require stable, unique network identities and persistent storage, not for one-time batch jobs. Option C (DaemonSet) is wrong because DaemonSets ensure that a copy of a Pod runs on every (or selected) node in the cluster, typically for daemon-like services such as logging or monitoring, not for tasks that run to completion. Option D (Deployment) is wrong because Deployments manage a set of identical Pods with a desired replica count, ensuring they are always running and self-healing, which is the opposite of a one-time batch job that should terminate upon success.

Full explanation →
39
Multi-Selecthard

Which THREE of the following are features of Helm that facilitate release management? (Choose three.)

Select 3 answers
A.Canary deployment strategy
B.Rollback to a previous release revision
C.Release history and revision tracking
D.Horizontal pod autoscaling
E.Upgrade a release with new values
AnswersB, C, E

Helm stores each release revision as a numbered snapshot, so rollback restores a prior revision's rendered Kubernetes manifests and configuration. This directly satisfies the release management requirement by enabling recovery from failed upgrades without manual re-editing, reverting both the deployed resources and Helm's stored release state.

Why this answer

Helm facilitates release management through its revision-based model: option B is correct because Helm stores each install/upgrade as a numbered revision, and `helm rollback <release> <revision>` restores a prior revision, making recovery from a bad deployment straightforward. Option C is correct because Helm tracks release history and revision metadata (viewable via `helm history <release>` and stored in Kubernetes Secrets by default), which is the foundation for auditing and managing releases. Option E is correct because `helm upgrade <release> <chart> --set key=value` (or `-f values.yaml`) lets you apply new configuration values to an existing release, incrementing the revision while preserving release identity.

Option A is not a Helm feature — canary deployment is a strategy implemented by tools such as Argo Rollouts, Flagger, or service meshes, not by Helm itself. Option D is not a Helm feature either; Horizontal Pod Autoscaling is a Kubernetes controller (the `autoscaling/v2` HPA resource) that scales pods based on metrics, independent of Helm's release management.

Exam trap

KCNA often tests the misconception that Helm natively supports canary or blue/green deployments — it does not; those require external progressive delivery controllers, so candidates incorrectly select canary as a Helm release-management feature.

Full explanation →
40
MCQeasy

Which Prometheus metric type is best suited for counting the total number of HTTP requests received by a service?

A.Summary
B.Counter
C.Gauge
D.Histogram
AnswerB

A Counter is a monotonically increasing metric that only goes up, making it ideal for cumulative totals such as HTTP requests received. Rate or increase functions applied to the counter yield per-second request rates, whereas Gauge and Histogram serve different measurement purposes.

Why this answer

A counter is a cumulative metric that only increases (or resets to zero). It is ideal for counting events like HTTP requests.

Full explanation →
41
MCQeasy

Which of the following is a worker node component responsible for ensuring that containers are running in a pod as specified in the pod's spec?

A.kube-scheduler
B.kube-proxy
C.kubelet
D.etcd
AnswerC

The kubelet runs as an agent on each worker node, watching the API server for pods scheduled to that node and restarting containers to match the pod spec. This directly satisfies the stem's requirement for the node component that keeps containers running as specified.

Why this answer

The kubelet is the primary node agent that runs on each worker node. It receives PodSpecs (via the API server or a file) and ensures that the containers described in those PodSpecs are running and healthy. It does this by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers as required.

Exam trap

CNCF often tests the distinction between control plane components (scheduler, etcd) and worker node agents (kubelet, kube-proxy), and the trap here is confusing the kubelet's role of running containers with the kube-scheduler's role of placing pods onto nodes.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is a control plane component responsible for assigning pods to nodes based on resource requirements and constraints, not for running containers on a node. Option B is wrong because kube-proxy is a network proxy that runs on each node, handling network rules (e.g., iptables or IPVS) for service abstraction and pod-to-service communication, not container lifecycle management. Option D is wrong because etcd is a distributed key-value store used as Kubernetes' backing store for all cluster data, not a node-level component that manages containers.

Full explanation →
42
MCQhard

An organization uses Flux with Kustomize to manage their Kubernetes applications. They want to automatically update their deployment when a new container image is pushed to the registry. Which Flux component should they use?

A.Source Controller
B.Image Automation Controller
C.Helm Controller
D.Kustomize Controller
AnswerB

The Image Automation Controller scans image repositories and, when it detects a newly pushed tag matching policy, commits the updated image reference back to Git, which Flux then reconciles. This delivers the automatic deployment update the organisation wants.

Why this answer

The Image Automation Controller is specifically designed to watch container registries for new image tags and automatically update Kubernetes manifests (like Kustomize overlays) with the new image reference. It works in conjunction with the Image Reflector Controller to scan registries and the Image Policy to select the desired tag. Once a new image is detected and selected, the Image Automation Controller commits the updated image tag back to the Git repository, which Flux then reconciles.

This enables a fully automated GitOps workflow for image updates.

Exam trap

KCNA often tests the distinction between Flux controllers, and candidates may confuse the Image Automation Controller with the Source Controller or Kustomize Controller, forgetting that only the Image Automation Controller actively monitors registries and updates manifests.

How to eliminate wrong answers

Option A is wrong because the Source Controller is responsible for fetching artifacts from sources like Git repositories, Helm repositories, and S3 buckets; it does not monitor container registries or update image tags. Option C is wrong because the Helm Controller manages Helm releases by reconciling HelmRelease objects; it does not handle image automation or registry scanning. Option D is wrong because the Kustomize Controller applies Kustomize overlays to the cluster; it does not watch for new images or modify manifests.

Full explanation →
43
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
44
MCQmedium

Which component of the Istio service mesh is responsible for certificate signing and identity management?

A.Envoy
B.Citadel
C.Mixer
D.Pilot
AnswerB

Citadel handles certificate signing and identity management in Istio, issuing SPIFFE-based workload certificates to sidecar proxies and rotating them automatically. This satisfies the stem's requirement for the mesh component responsible for certificate signing and identity management, distinct from traffic-routing components such as Pilot or Envoy.

Why this answer

Citadel is the Istio component responsible for certificate signing, key management, and identity management, issuing SPIFFE-compliant identities to workloads. It acts as the certificate authority for the mesh, enabling mutual TLS between services.

Exam trap

KCNA often tests Istio component roles, and candidates confuse the data plane (Envoy) with control plane components (Citadel, Pilot, Mixer), picking Envoy because it 'handles security' via mTLS.

How to eliminate wrong answers

Option A is wrong because Envoy is the sidecar proxy that handles data plane traffic (routing, load balancing, mTLS termination), not certificate signing. Option C is wrong because Mixer was the policy and telemetry component (deprecated in Istio 1.5+ and replaced by Envoy extensions), not the identity manager. Option D is wrong because Pilot is the control plane component that configures Envoy proxies with routing rules and service discovery, not certificate management.

Full explanation →
45
MCQmedium

Which component on a worker node is responsible for enforcing the network rules and implementing Service abstractions?

A.kube-proxy
B.kubelet
C.container runtime
D.kube-scheduler
AnswerA

kube-proxy runs on each worker node, programming iptables or IPVS rules that translate Service virtual IPs into Pod endpoints. The kubelet manages container lifecycle, while the scheduler and controller manager run in the control plane, so neither enforces Service networking.

Why this answer

kube-proxy is the component on each worker node that implements Service abstractions by maintaining network rules (iptables, IPVS, or userspace) that allow traffic to reach Pods from inside or outside the cluster. It watches the Kubernetes API server for changes to Services and EndpointSlices, then updates the node's packet filtering rules to forward traffic to the correct backend Pods, handling load balancing and session affinity.

Exam trap

A common misconception is that kubelet or the container runtime handles Service networking, but kube-proxy is the dedicated component for implementing network rules and Service abstractions on each node.

How to eliminate wrong answers

Option B (kubelet) is wrong because kubelet is the primary node agent that manages Pod lifecycle (creating, stopping, and reporting Pod status) and mounts volumes, but it does not enforce network rules or implement Service abstractions. Option C (container runtime) is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for pulling images and running containers, not for network policy or Service proxying. Option D (kube-scheduler) is wrong because kube-scheduler runs on the control plane, not worker nodes, and is responsible for assigning Pods to nodes based on resource availability and constraints, not for enforcing network rules.

Full explanation →
46
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
47
MCQmedium

You have a Deployment named 'web-app' that manages 3 replicas. You need to update the container image from version 1.0 to 2.0 with zero downtime. Which Kubernetes feature is designed to handle this automatically when you update the Deployment's pod template?

A.ReplicationController
B.Rolling update strategy in the Deployment
C.DaemonSet
D.StatefulSet's onDelete strategy
AnswerB

Rolling updates replace pods incrementally, respecting maxSurge and maxUnavailable, so the Deployment keeps serving traffic throughout the image change from 1.0 to 2.0. This satisfies the zero-downtime constraint directly, since Kubernetes creates new pods before terminating old ones rather than recreating all three at once.

Why this answer

A Deployment's default update strategy is 'RollingUpdate', which automatically replaces old Pods with new ones in a controlled manner, ensuring zero downtime by incrementally scaling down old replicas and scaling up new replicas. When you update the container image in the Deployment's pod template, Kubernetes triggers a rolling update that maintains the desired number of replicas throughout the process.

Exam trap

The trap here is that candidates may confuse the Deployment's automatic rolling update with manual update methods (like onDelete) or think that a ReplicationController or DaemonSet can handle zero-downtime updates in the same way, but only the Deployment's RollingUpdate strategy provides this out-of-the-box behavior for stateless applications.

How to eliminate wrong answers

Option A is wrong because a ReplicationController does not support rolling updates natively; it only ensures a specified number of Pod replicas are running, and updating its pod template requires manual deletion and recreation of Pods, causing downtime. Option C is wrong because a DaemonSet ensures that a copy of a Pod runs on all (or a subset of) nodes, and it is not designed for managing stateless application replicas with zero-downtime updates; its update strategy can be RollingUpdate or OnDelete, but it is not the feature intended for a Deployment like 'web-app'. Option D is wrong because StatefulSet's onDelete strategy requires manual Pod deletion to trigger updates, which does not provide automatic zero-downtime updates; StatefulSets are designed for stateful applications and their default update strategy is RollingUpdate, but the question asks about a Deployment, not a StatefulSet.

Full explanation →
48
MCQeasy

What is the smallest deployable unit in Kubernetes?

A.Pod
B.Deployment
C.Node
D.Container
AnswerA

A Pod is the smallest deployable unit in Kubernetes, representing one or more containers that share a network namespace, storage volumes and lifecycle. Containers themselves are not scheduled independently; the scheduler places Pods onto nodes, making the Pod the atomic deployment unit.

Why this answer

A Pod is the smallest and simplest unit in the Kubernetes object model, representing a single instance of a running process in the cluster. It encapsulates one or more containers, shared storage, and a unique network IP, making it the atomic unit of scheduling and deployment.

Exam trap

The trap here is that candidates often confuse the smallest deployable unit (Pod) with the smallest runtime unit (Container), but Kubernetes always schedules and manages Pods, not individual containers.

How to eliminate wrong answers

Option B is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods, not the smallest deployable unit itself. Option C is wrong because a Node is a worker machine (physical or virtual) that hosts Pods, not a deployable object. Option D is wrong because a Container is the lowest-level runtime unit, but Kubernetes does not deploy containers directly; it always wraps them inside a Pod.

Full explanation →
49
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

Full explanation →
50
MCQmedium

A Deployment manages ReplicaSets and supports rolling updates. You want to change the container image of a Deployment without downtime. What is the recommended approach?

A.Use kubectl expose to update the image on the service
B.Delete the existing Deployment and create a new one with the updated image
C.Edit the Deployment's pod template spec to use the new image; the Deployment will automatically perform a rolling update
D.Manually delete all pods one by one; they will be recreated with the new image by the ReplicaSet
AnswerC

Updating the Deployment's pod template spec with the new image triggers the Deployment controller to create a new ReplicaSet and gradually scale it up while scaling the old one down, performing a rolling update that maintains availability without downtime.

Why this answer

Editing the Deployment's pod template spec triggers an automatic rolling update, which is the recommended approach for zero-downtime updates. The Deployment controller creates a new ReplicaSet with the updated image and gradually scales it up while scaling down the old ReplicaSet, ensuring that a minimum number of pods remain available throughout the process.

Exam trap

The trap here is that candidates may confuse `kubectl expose` with updating images, or think that manually deleting pods will trigger the new image, when in fact the ReplicaSet only recreates pods based on its current template.

How to eliminate wrong answers

Option A is wrong because `kubectl expose` creates a Service to expose a Deployment or pod, but it does not update container images; it only manages network access. Option B is wrong because deleting and recreating the Deployment would cause a period of downtime while the new Deployment is being created and pods are scheduled, violating the requirement for no downtime. Option D is wrong because manually deleting pods one by one would cause the existing ReplicaSet to recreate them with the original image, not the new one, and this approach is not automated and risks downtime if pods are deleted faster than they are recreated.

Full explanation →
51
Multi-Selectmedium

Which THREE of the following are valid options for the 'kubectl get' command to display output in different formats?

Select 3 answers
A.-o verbose
B.-o wide
C.-o json
D.-o yaml
E.--describe
AnswersB, C, D

The `-o wide` flag extends the default table with extra columns, such as node name and pod IP, satisfying the requirement to display output in a different format. It remains a tabular, human-readable view rather than structured data, but Kubernetes documents it as a distinct output format alongside `-o json` and `-o yaml`.

Why this answer

Option B (-o wide) is correct because the -o wide output format extends the default table with additional columns such as node name, IP addresses, and nominated node, which is a documented kubectl output format. Option C (-o json) is correct because kubectl supports -o json to serialize the resource as a JSON object, useful for scripting and parsing with tools like jq. Option D (-o yaml) is correct because -o yaml renders the resource as YAML, another officially supported output format for kubectl get.

The unmarked options do not belong: -o verbose is not a valid output format (verbose logging is controlled by -v/--v), and --describe is not an output format but a separate kubectl subcommand (kubectl describe) that shows detailed human-readable information.

Exam trap

CNCF often tests the distinction between output format flags (`-o`) and separate subcommands (`describe`), trapping candidates who confuse `--describe` with `-o wide` or think `-o verbose` is a real format.

Full explanation →
52
Multi-Selecthard

Which three of the following are valid ways to expose a service externally in Kubernetes? (Select THREE.)

Select 3 answers
A.Ingress
B.ExternalName
C.NodePort
D.LoadBalancer
E.ClusterIP
AnswersA, C, D

Ingress exposes HTTP and HTTPS routes from outside the cluster to Services, satisfying the external-exposure constraint. An Ingress controller provides the actual entry point, routing by host or path rules rather than allocating a node port or cloud load balancer.

Why this answer

Ingress (A) is correct because it exposes HTTP/HTTPS services externally by routing traffic through an Ingress controller to internal ClusterIP services based on host/path rules. NodePort (C) is correct because it opens a static port (default range 30000–32767) on every node's IP, forwarding external traffic to the target service. LoadBalancer (D) is correct because it provisions an external load balancer (e.g., via a cloud provider) that distributes traffic to the service, typically building on NodePort and ClusterIP.

ExternalName (B) is not a way to expose a service externally; it merely creates a CNAME DNS alias to an external hostname without proxying traffic. ClusterIP (E) is incorrect because it only provides an internal virtual IP reachable within the cluster, not from outside.

Exam trap

The trap is that candidates often mistake ExternalName (option B) and ClusterIP (option E) as external exposure methods. ExternalName only creates a DNS alias within the cluster, while ClusterIP exposes the service only internally. Only Ingress, NodePort, and LoadBalancer are valid for external exposure.

Full explanation →
53
MCQhard

A cluster has a node with the taint 'node-role.kubernetes.io/control-plane:NoSchedule'. A pod must be scheduled on this node for a special workload. Which action is required?

A.Use a nodeSelector to select the node.
B.Remove the taint from the node.
C.Add a toleration to the pod spec.
D.Use podAffinity to attract the pod to the node.
AnswerC

The control-plane taint repels pods lacking a matching toleration, so the scheduler will not place the workload there. Adding a toleration for node-role.kubernetes.io/control-plane with effect NoSchedule to the pod spec permits scheduling onto that node.

Why this answer

A taint on a node causes the scheduler to avoid placing pods on that node unless the pod explicitly tolerates the taint. By adding a toleration in the pod spec that matches the taint key, effect, and optionally the value, the pod becomes eligible to be scheduled on the tainted node. This is the standard Kubernetes mechanism for allowing pods to run on control-plane or other specially tainted nodes.

Exam trap

The trap here is that candidates confuse nodeSelector (label-based) with tolerations (taint-based), thinking that selecting a node by label can override a taint, when in fact taints are a separate, higher-priority scheduling constraint.

How to eliminate wrong answers

Option A is wrong because a nodeSelector only matches node labels, not taints; it cannot override the scheduling restriction imposed by a NoSchedule taint. Option B is wrong because removing the taint would affect all pods and is unnecessary when only a specific pod needs to run on that node; it also violates the principle of least privilege. Option D is wrong because podAffinity attracts pods based on labels of other pods, not node-level taints, and does not bypass the NoSchedule effect.

Full explanation →
54
MCQmedium

Which component in a service mesh is responsible for handling traffic management, security, and observability as a sidecar proxy?

A.Pilot
B.Mixer
C.Citadel
D.Envoy
AnswerD

Envoy is the sidecar proxy deployed alongside each workload in a service mesh, intercepting inbound and outbound traffic. It enforces traffic routing, mutual TLS, and telemetry collection, satisfying the stem's requirement for a component handling management, security and observability.

Why this answer

Envoy is the sidecar proxy used in service meshes like Istio, where it handles all data plane traffic. It intercepts inbound and outbound traffic for each service instance, enforcing traffic routing, mutual TLS, and telemetry collection. Unlike control plane components, Envoy runs as a sidecar container alongside the application, making it directly responsible for the actual traffic management, security, and observability functions at runtime.

Exam trap

KCNA often tests the distinction between control plane and data plane components in a service mesh, causing candidates to confuse control plane components like Pilot, Mixer, and Citadel with the actual data plane proxy (Envoy) that handles traffic.

How to eliminate wrong answers

Option A is wrong because Pilot is a control plane component in Istio that configures Envoy proxies with routing rules and service discovery information, but it does not handle traffic itself. Option B is wrong because Mixer is a control plane component responsible for policy checks and telemetry collection, but it was deprecated in Istio 1.5 and never acted as a sidecar proxy. Option C is wrong because Citadel is a control plane component that manages certificate issuance and rotation for mutual TLS, but it does not proxy or manage traffic.

Full explanation →
55
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
56
MCQhard

An administrator needs to grant a ServiceAccount in namespace 'dev' permission to list and watch Pods in the same namespace. Which combination of resources is required?

A.A Role and a RoleBinding in the 'dev' namespace
B.A ClusterRole and a RoleBinding in the 'dev' namespace
C.A ClusterRole and a ClusterRoleBinding
D.A Role and a ClusterRoleBinding
AnswerA

A Role defines permissions within a namespace, and a RoleBinding grants those permissions to a subject such as a ServiceAccount in that namespace. Since the requirement is limited to Pods in 'dev', a Role with verbs list and watch on pods, bound via RoleBinding, provides the necessary access without cluster-wide scope.

Why this answer

To grant a ServiceAccount permission to list and watch Pods in a single namespace, you create a Role in that namespace with the appropriate rules and bind it to the ServiceAccount using a RoleBinding. This follows the principle of least privilege, as the permissions are confined to the 'dev' namespace and do not extend cluster-wide.

Exam trap

The trap here is assuming a ClusterRoleBinding is needed for any RBAC grant, when namespaced permissions should use a Role and RoleBinding to avoid granting cluster-wide access.

Full explanation →
57
MCQeasy

A platform engineer is preparing a new cluster and wants each worker node to run a copy of a log-forwarding agent that must also run on control-plane nodes. Which Kubernetes workload resource should be used?

A.StatefulSet with podManagementPolicy: Parallel
B.Deployment with replicas equal to the number of nodes
C.CronJob with a schedule of every minute
D.DaemonSet
AnswerD

A DaemonSet ensures that a copy of a Pod runs on every eligible node in the cluster, including newly added nodes. Because the requirement is one log-forwarding agent per node, and it must tolerate control-plane taints, a DaemonSet with appropriate tolerations is the correct workload type.

Why this answer

A DaemonSet is the only workload controller that guarantees a Pod on every eligible node, which is exactly what a per-node log-forwarding agent requires. Deployments, StatefulSets, and CronJobs do not provide per-node placement semantics, so they cannot meet the requirement of running the agent on every worker and control-plane node.

Exam trap

The trap here is assuming that a Deployment with replicas equal to the node count will place one Pod per node, but Deployments do not guarantee per-node scheduling.

Full explanation →
58
MCQhard

You have a Deployment that runs a web application. You need to expose this application externally on a fixed port using a cloud load balancer. Which Service type should you use?

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

A LoadBalancer Service provisions an external cloud load balancer and assigns a stable, externally reachable IP, satisfying the requirement to expose the application externally on a fixed port. Unlike NodePort, which opens a port on every node, it integrates directly with the cloud provider's load-balancing infrastructure.

Why this answer

A LoadBalancer Service type provisions an external cloud load balancer (e.g., AWS ELB, GCP TCP/UDP Load Balancer) that exposes the application on a fixed port (typically 80/443) and distributes traffic to the Pods. This is the correct choice because the requirement explicitly asks for a cloud load balancer with a fixed external port, which is exactly what LoadBalancer provides by integrating with the underlying cloud provider's API.

Exam trap

CNCF often tests the misconception that NodePort is sufficient for external access, but the question's requirement for a 'cloud load balancer' and 'fixed port' (like 80/443) disqualifies NodePort because it uses a high port range and lacks cloud LB integration.

How to eliminate wrong answers

Option A is wrong because NodePort exposes the application on a static port on each node's IP (range 30000-32767), not via a cloud load balancer, and does not provide a fixed external port like 80 or 443. Option C is wrong because ExternalName maps a Service to a DNS name (CNAME record) and does not expose any ports or provide load balancing; it is used for external service discovery, not for exposing an application externally. Option D is wrong because ClusterIP exposes the Service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like an Ingress or a proxy.

Full explanation →
59
MCQmedium

Which component runs on every node and is responsible for maintaining network rules that allow communication to Pods from network endpoints?

A.kube-controller-manager
B.kube-proxy
C.container runtime
D.kubelet
AnswerB

kube-proxy runs as a DaemonSet on every node and programs iptables or IPVS rules, translating Service virtual IPs into Pod endpoints. This maintains the network rules enabling communication to Pods from network endpoints, exactly the responsibility the question describes.

Why this answer

B is correct because kube-proxy is the component that runs on every node in a Kubernetes cluster and is responsible for maintaining network rules (e.g., iptables, IPVS, or userspace proxy) that allow network communication to Pods from network endpoints, both inside and outside the cluster. It implements the Kubernetes Service concept by managing the mapping of Service IPs to backend Pod IPs and performing load balancing.

Exam trap

The trap here is that candidates often confuse kubelet with kube-proxy because both run on every node, but kubelet manages Pods and containers, while kube-proxy exclusively handles network rules for Service connectivity.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that regulate cluster state, but it does not run on every node nor manage per-node network rules. Option C is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for pulling images and running containers, not for maintaining network rules for Pod communication. Option D is wrong because kubelet is the primary node agent that registers the node with the API server and manages Pod lifecycle (e.g., ensuring containers are running), but it does not handle network rule maintenance for Service-to-Pod traffic.

Full explanation →
60
MCQeasy

You want to view the logs of a running pod named 'my-pod'. Which kubectl command should you use?

A.kubectl exec my-pod -- cat /var/log/container.log
B.kubectl logs my-pod
C.kubectl get pod my-pod -o yaml
D.kubectl describe pod my-pod
AnswerB

`kubectl logs my-pod` retrieves stdout and stderr from the pod's container, satisfying the requirement to view a running pod's logs. It targets the pod by name directly, without needing a pod list, selector or exec session, which is the standard mechanism for reading container output in Kubernetes.

Why this answer

The `kubectl logs my-pod` command is the correct way to retrieve the standard output and standard error logs from a running pod in Kubernetes. It directly fetches the container logs from the kubelet, which are stored on the node and rotated by the container runtime (e.g., containerd or CRI-O). This is the dedicated command for log inspection, as defined in the Kubernetes CLI documentation.

Exam trap

The trap here is that candidates confuse `kubectl exec` with `kubectl logs`, thinking they need to manually cat a log file inside the container, when Kubernetes automatically captures stdout/stderr and provides a dedicated `kubectl logs` command for that purpose.

How to eliminate wrong answers

Option A is wrong because `kubectl exec my-pod -- cat /var/log/container.log` attempts to execute a command inside the container to read a log file, but the path `/var/log/container.log` is not a standard location for Kubernetes container logs; container logs are streamed to stdout/stderr and managed by the container runtime, not stored as a file at that path. Option C is wrong because `kubectl get pod my-pod -o yaml` outputs the pod's full YAML manifest, which includes metadata, spec, and status, but does not contain the container logs. Option D is wrong because `kubectl describe pod my-pod` shows detailed information about the pod's state, events, and conditions, but does not include the actual log output from the container.

Full explanation →
61
MCQmedium

What is the purpose of kube-proxy on a worker node?

A.To run the container runtime
B.To store cluster configuration data
C.To implement network rules and handle service traffic routing
D.To monitor pod health and restart unhealthy containers
AnswerC

kube-proxy implements the Service abstraction by programming iptables, IPVS, or nftables rules on each node, directing traffic addressed to a Service's virtual IP toward the correct backend pods. This satisfies the stem's requirement for handling service traffic routing on worker nodes.

Why this answer

Kube-proxy is the component responsible for implementing network rules on each worker node, enabling service abstraction by managing IP tables or IPVS rules to route traffic to the appropriate pods. It handles service discovery and load balancing for ClusterIP, NodePort, and LoadBalancer service types, ensuring that traffic destined for a service is correctly forwarded to healthy pod endpoints.

Exam trap

CNCF often tests the misconception that kube-proxy handles pod health checks and restarts, but that is actually the kubelet's job, while kube-proxy only deals with network traffic routing and service abstraction.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is a separate component that runs containers, not kube-proxy. Option B is wrong because cluster configuration data is stored in etcd, a distributed key-value store, not in kube-proxy. Option D is wrong because monitoring pod health and restarting unhealthy containers is the responsibility of the kubelet, specifically through liveness probes and pod lifecycle management, not kube-proxy.

Full explanation →
62
MCQeasy

What is the purpose of the metrics-server in Kubernetes?

A.To provide resource usage metrics for pods and nodes
B.To manage service meshes
C.To collect application logs
D.To store historical metrics
AnswerA

The metrics-server aggregates kubelet-reported resource consumption and exposes it through the Metrics API, letting Horizontal Pod Autoscalers and kubectl top read live CPU and memory figures for pods and nodes. It satisfies the requirement for cluster-wide resource usage visibility, unlike full monitoring stacks that persist historical data.

Why this answer

The metrics-server is a cluster-wide aggregator of resource usage data. It collects CPU and memory metrics from each node's kubelet (via the Summary API) and exposes them through the Kubernetes API server using the Metrics API (metrics.k8s.io). This enables core Kubernetes components like the Horizontal Pod Autoscaler (HPA) and Vertical Pod Autoscaler (VPA) to make scaling decisions, and allows users to view resource usage with `kubectl top`.

Exam trap

KCNA often tests the distinction between metrics-server (real-time resource metrics for HPA) and full monitoring solutions like Prometheus (historical metrics and long-term storage), so candidates may incorrectly assume metrics-server stores historical data.

How to eliminate wrong answers

Option B is wrong because service mesh management is handled by dedicated tools like Istio, Linkerd, or Consul, not by metrics-server. Option C is wrong because log collection is performed by logging agents such as Fluentd, Filebeat, or Loki, not by metrics-server. Option D is wrong because metrics-server only provides real-time, in-memory metrics with a short retention period (typically 15 minutes); it does not store historical metrics—that requires a full monitoring solution like Prometheus with long-term storage.

Full explanation →
63
MCQmedium

Which Kubernetes resource provides stable network endpoints for a set of pods, enabling service discovery and load balancing?

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

A Service supplies a stable virtual IP and DNS name that front a dynamic set of pod IPs, distributing traffic across matching ready pods. This decouples clients from pod churn, delivering service discovery and load balancing.

Why this answer

A Service is the correct Kubernetes resource because it provides a stable virtual IP (ClusterIP) and DNS name that persists independently of pod lifecycles, enabling reliable service discovery and client-side load balancing across a set of pods selected by labels. This abstraction decouples clients from ephemeral pod IPs, ensuring traffic is routed to healthy pods via kube-proxy and iptables/IPVS rules.

Exam trap

CNCF often tests the misconception that Ingress provides load balancing and stable endpoints directly to pods, when in fact Ingress only routes external traffic to a Service, which is the actual resource providing those capabilities.

How to eliminate wrong answers

Option B is wrong because NetworkPolicy is a firewall rule that controls ingress/egress traffic at the pod level using IP blocks or label selectors, but it does not provide stable network endpoints or load balancing. Option C is wrong because Ingress is an API object that manages external HTTP/HTTPS routing to Services (typically via a controller like NGINX), but it does not itself provide stable endpoints or load balance directly to pods; it relies on a Service for that. Option D is wrong because EndpointSlice is a lower-level resource that tracks the actual pod IPs and ports backing a Service, but it is a data object consumed by kube-proxy, not a resource that provides stable endpoints or load balancing on its own.

Full explanation →
64
MCQmedium

A Pod has been in 'Pending' state for an unusual amount of time. Which of the following is a likely cause?

A.The container image is invalid
B.The Pod's liveness probe is failing
C.The cluster does not have enough resources to schedule the Pod
D.The Service pointing to the Pod is misconfigured
AnswerC

Insufficient allocatable CPU or memory across nodes leaves the scheduler unable to bind the Pod, so it remains Pending indefinitely. This directly satisfies the stem's scheduling-failure constraint: the kube-scheduler cannot find a node meeting the Pod's resource requests, unlike image-pull or runtime errors that occur after binding.

Why this answer

A Pod stuck in 'Pending' state indicates that the Pod has been accepted by the API server but has not been scheduled to a node. The most common cause is insufficient cluster resources (CPU, memory, or ephemeral storage) across all nodes, preventing the scheduler from finding a suitable node that meets the Pod's resource requests. The scheduler continuously evaluates nodes using predicates and priorities, and if no node passes the predicates (e.g., NodeResourcesFit), the Pod remains Pending.

Exam trap

Kubernetes certification exams often test the distinction between Pod lifecycle phases (Pending vs. Running vs. CrashLoopBackOff) and the specific conditions that cause each state, tricking candidates into confusing post-scheduling issues (like image errors or probe failures) with pre-scheduling issues.

How to eliminate wrong answers

Option A is wrong because an invalid container image causes the Pod to transition to 'ImagePullBackOff' or 'ErrImagePull' after scheduling, not to remain in 'Pending' — the scheduler can still place the Pod on a node. Option B is wrong because a failing liveness probe affects a running container, causing restarts or 'CrashLoopBackOff', but the Pod must first be scheduled and running (i.e., in 'Running' state) for probes to execute. Option D is wrong because a misconfigured Service affects network connectivity to the Pod, not the Pod's scheduling or lifecycle state — the Pod would still be scheduled and run, but traffic would fail to reach it.

Full explanation →
65
MCQmedium

Which resource type provides a stable IP address and DNS name to access a set of Pods, regardless of Pod IP changes?

A.Ingress
B.ConfigMap
C.Deployment
D.Service
AnswerD

A Service assigns a stable virtual IP and DNS name, then load-balances traffic to the selected Pods via kube-proxy. Pod IPs change on recreation, so clients address the Service instead, satisfying the requirement for stable access regardless of Pod churn.

Why this answer

A Service in Kubernetes provides a stable virtual IP (ClusterIP) and a DNS name (via CoreDNS) that remains constant even as Pods are created, destroyed, or rescheduled. This decouples client access from the ephemeral nature of Pod IPs, ensuring reliable connectivity to the Pods selected by the Service's label selector.

Exam trap

The trap here is that candidates confuse Ingress with providing a stable IP/DNS for Pods, but Ingress only routes external traffic to a Service and does not itself assign a stable internal endpoint.

How to eliminate wrong answers

Option A is wrong because an Ingress is not a resource that provides a stable IP/DNS for Pods directly; it is a layer 7 HTTP/HTTPS routing rule that exposes Services externally, relying on a Service to provide the stable endpoint. Option B is wrong because a ConfigMap is used to store non-confidential configuration data as key-value pairs, not to provide network endpoints or IP addresses. Option C is wrong because a Deployment manages the desired state and lifecycle of Pods (replicas, rolling updates) but does not assign a stable IP or DNS name; Pods managed by a Deployment get new IPs on restart.

Full explanation →
66
MCQmedium

A user runs 'kubectl get pods -n production' and sees no output. What is the most likely reason?

A.The kube-apiserver is down
B.There are no pods in the 'production' namespace
C.The user does not have permissions to list pods
D.The namespace does not exist
AnswerB

An empty result from `kubectl get pods -n production` means the API server returned zero matching objects, not an error. Since the namespace exists and the query succeeded, the production namespace simply contains no pods, satisfying the stem's observation of no output.

Why this answer

`kubectl get pods -n production` returning no output typically indicates that there are no pods in the specified namespace. The command successfully connected to the API server, authenticated, and queried the namespace, but the result set is empty. This is a common scenario when a namespace exists but has no running or pending pods.

Exam trap

The trap here is that candidates often assume no output means a cluster or permission issue, but kubectl returns explicit error messages for connectivity, authorization, or resource-not-found problems, while an empty list is silently displayed.

How to eliminate wrong answers

Option A is wrong because if the kube-apiserver were down, kubectl would return a connection error (e.g., 'Unable to connect to the server') rather than no output. Option C is wrong because if the user lacked permissions to list pods, kubectl would return a Forbidden error (HTTP 403) with a message like 'Error from server (Forbidden): pods is forbidden'. Option D is wrong because if the namespace did not exist, kubectl would return an error like 'Error from server (NotFound): namespaces "production" not found'.

Full explanation →
67
MCQmedium

A team is designing a cloud-native application and wants to ensure that the failure of a single availability zone does not cause a full outage. They deploy the application across multiple zones and configure the orchestrator to distribute replicas evenly. Which cloud-native architecture principle does this scenario primarily demonstrate?

A.Loose coupling
B.Declarative configuration
C.Design for failure
D.Immutable infrastructure
AnswerC

Distributing replicas across multiple availability zones ensures that if one zone fails, the application continues to run. This is a direct implementation of the design-for-failure principle, which assumes components will fail and builds redundancy to maintain availability. By spreading workloads, the system tolerates zone-level outages without manual intervention.

Why this answer

The scenario describes spreading replicas across multiple availability zones so that a single zone failure does not cause a full outage. This is the essence of designing for failure, where redundancy and fault isolation are built into the architecture. While other principles like declarative configuration or loose coupling may also be present, they do not directly address surviving a zone-level failure.

Exam trap

The trap here is confusing high availability techniques with unrelated cloud-native principles such as immutable infrastructure or declarative configuration, which do not directly explain zone-failure tolerance.

Full explanation →
68
MCQhard

You have a Pod with a container that runs a web server. The Pod has a memory request of 256Mi and a memory limit of 512Mi. The container attempts to allocate 600Mi of memory. What happens?

A.The memory limit is automatically increased to 600Mi
B.The container is killed by the OOM killer, and the Pod enters CrashLoopBackOff
C.The Pod is evicted from the node
D.The container is allowed to use up to 600Mi because the limit is a soft constraint
AnswerB

Exceeding the 512Mi limit triggers the kernel OOM killer, which terminates the container process rather than throttling it. Kubernetes then restarts the container per its restartPolicy, and repeated failures drive the Pod into CrashLoopBackOff. The memory limit, not the 256Mi request, is the binding constraint here.

Why this answer

When a container's memory usage exceeds its memory limit (512Mi), the Linux Out-Of-Memory (OOM) killer terminates the container process. Kubernetes then restarts the container based on the Pod's restart policy, but because the container immediately tries to allocate 600Mi again, it is repeatedly killed, resulting in a CrashLoopBackOff state. Memory limits are hard constraints enforced by the kernel via cgroups, not soft limits.

Exam trap

A common misconception is that memory limits are 'soft' or 'advisory' (like CPU limits), but in Kubernetes, memory limits are hard and enforced by the kernel's OOM killer, causing container termination when exceeded.

How to eliminate wrong answers

Option A is wrong because Kubernetes never automatically increases a resource limit; limits are static and defined in the Pod spec. Option C is wrong because Pod eviction occurs when a node is under memory pressure and the Pod's usage exceeds its request, not when a single container exceeds its limit (the container is killed in-place). Option D is wrong because memory limits are hard constraints enforced by the kernel's cgroup OOM killer, not soft constraints; the container cannot exceed the limit.

Full explanation →
69
Multi-Selecthard

Which THREE of the following are valid fields in a Kubernetes Deployment spec (apps/v1)?

Select 3 answers
A.replicas
B.template
C.selector
D.containers
E.nodeName
AnswersA, B, C

`replicas` sits under `spec` and declares the desired number of Pod replicas the ReplicaSet should maintain, satisfying the question's requirement for a genuine apps/v1 Deployment field. It is a core scaling parameter, distinct from metadata or status, and is reconciled continuously by the Deployment controller to match observed state.

Why this answer

In an apps/v1 Deployment spec, the correct top-level fields include A. replicas, which declares the desired number of Pod replicas the ReplicaSet managed by the Deployment should maintain; B. template, which is the required PodTemplateSpec describing the Pods to be created; and C. selector, which is the required LabelSelector that must match the labels in the template and determines which Pods the Deployment manages. Options D and E are not valid Deployment spec fields: containers belongs inside the Pod template's spec (spec.template.spec.containers), not directly under the Deployment spec, and nodeName is a Pod-level scheduling field under spec.template.spec, not a Deployment spec field.

Exam trap

CNCF often tests the distinction between fields that belong to the Deployment spec versus fields that belong to the Pod spec, so candidates mistakenly select `containers` or `nodeName` as top-level Deployment fields.

Full explanation →
70
MCQmedium

You want to expose a set of pods running a web application on port 80 internally within the cluster, with a stable IP address, so that other services can reach them. Which Kubernetes resource should you create?

A.Service (ClusterIP)
B.Ingress
C.Deployment
D.Pod
AnswerA

A ClusterIP Service allocates a stable virtual IP reachable only inside the cluster, exactly matching the internal exposure requirement. Its kube-proxy rules load-balance traffic across the selected pods on port 80, so other services get a consistent address despite pod restarts or rescheduling.

Why this answer

A Service of type ClusterIP provides a stable virtual IP address and DNS name that load-balances traffic to a set of pods. Since the requirement is internal cluster access with a stable IP, ClusterIP is the correct choice — it exposes the pods on a cluster-internal IP that other services can reach reliably, without needing external exposure.

Exam trap

The trap here is that candidates often confuse Ingress with internal service exposure, thinking it provides a stable internal IP, when in fact Ingress only handles external routing and requires a Service underneath.

How to eliminate wrong answers

Option B (Ingress) is wrong because Ingress is designed for external HTTP/HTTPS traffic routing (e.g., host/path-based rules) and does not provide a stable internal IP; it requires a Service to route traffic to pods. Option C (Deployment) is wrong because a Deployment manages pod replicas and updates but does not provide a stable network endpoint or IP address — it needs a Service to expose the pods. Option D (Pod) is wrong because a Pod’s IP is ephemeral and changes on restart or rescheduling, so it cannot serve as a stable endpoint for other services.

Full explanation →
71
Drag & Dropmedium

Drag and drop the steps to scale a Kubernetes Deployment horizontally into the correct order.

Drag or tap steps into the slots.

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

Why this order

Scale command, check pods, verify deployment, monitor rollout, and adjust resources if needed.

Full explanation →
72
Multi-Selectmedium

Which TWO of the following are valid Prometheus metric types?

Select 2 answers
A.Quantile
B.Counter
C.Timer
D.Meter
E.Gauge
AnswersB, E

Counter is a valid Prometheus metric type representing a monotonically increasing cumulative value that only resets on restart. It is one of the four core types alongside gauge, histogram and summary, satisfying the question's requirement for valid metric types.

Why this answer

Option B (Counter) is correct because Prometheus defines the counter metric type as a cumulative value that only increases or resets to zero on restart, typically used for counts of events or errors. Option E (Gauge) is correct because Prometheus defines the gauge metric type as a value that can arbitrarily go up and down, used for measurements like temperature, memory usage, or current queue size. The other options are not Prometheus metric types: Quantile (A) is a concept used in summary/histogram quantile calculations rather than a metric type itself, while Timer (C) and Meter (D) are metric types from other monitoring libraries such as Dropwizard Metrics or Micrometer, not native Prometheus types.

Exam trap

KCNA often tests Prometheus metric types by including terms from other monitoring ecosystems — candidates pick Timer or Meter (StatsD/Dropwizard concepts) or Quantile (a computed value, not a type) instead of the four actual Prometheus types.

Full explanation →
73
MCQeasy

Which kubectl command would you use to view detailed information about a specific pod, including events and container status?

A.kubectl explain pod
B.kubectl get pod <pod-name>
C.kubectl logs pod <pod-name>
D.kubectl describe pod <pod-name>
AnswerD

kubectl describe pod queries the API server for the pod's full status plus associated Events, showing container states, restart counts and scheduling messages. Unlike kubectl get, it surfaces the event stream needed to diagnose why a container is pending or crash-looping.

Why this answer

`kubectl describe pod <pod-name>` provides a comprehensive view of a pod's metadata, spec, status, conditions, container resource usage, and a chronological list of events (e.g., scheduling, pulling images, container restarts). This command aggregates information from the Kubernetes API server, including the pod's current state and lifecycle events, which is essential for debugging pod failures or unexpected behavior.

Exam trap

CNCF often tests the distinction between `kubectl get` (summary) and `kubectl describe` (detailed with events), expecting candidates to know that only `describe` surfaces the event stream and container state transitions needed for troubleshooting.

How to eliminate wrong answers

Option A is wrong because `kubectl explain pod` only displays the API documentation for the Pod resource schema (fields and descriptions), not runtime details or events about a specific pod instance. Option B is wrong because `kubectl get pod <pod-name>` outputs a concise summary (name, status, restarts, age) but omits detailed container status, conditions, and events. Option C is wrong because `kubectl logs pod <pod-name>` retrieves only the stdout/stderr output from the pod's containers, not the pod's metadata, status, or Kubernetes events.

Full explanation →
74
MCQhard

A Service of type ClusterIP has been created, but pods in the same namespace cannot reach it by its DNS name. The Service selector matches the pods. What is a likely cause?

A.The Service YAML does not specify a port
B.The kube-dns or CoreDNS pod is not running
C.The Service is not exposed on a node port
D.The pods are using an incorrect container runtime
AnswerB

ClusterIP resolution depends on cluster DNS: kubelet points pods at the CoreDNS (or kube-dns) Service via resolv.conf. If those pods are down, the Service still has a stable IP and matching endpoints, yet the DNS name cannot resolve, producing the failure described.

Why this answer

The DNS name resolution for a ClusterIP Service relies on the cluster's DNS service (kube-dns or CoreDNS). If the DNS pod is not running, the Service's DNS record (e.g., <service>.<namespace>.svc.cluster.local) cannot be resolved, even if the Service itself is properly configured and the pods match the selector. Without DNS, pods must use the Service's ClusterIP directly, which is not the expected behavior for name-based access.

Exam trap

The trap here is that candidates often assume DNS resolution is automatic and always available, overlooking that the DNS service itself is a critical component that must be running for name-based Service discovery to work.

How to eliminate wrong answers

Option A is wrong because a Service of type ClusterIP does not require a port specification to be reachable by DNS; the port is needed for actual traffic routing, but DNS resolution depends on the Service object existing in the API server, not on port definitions. Option C is wrong because exposing a Service on a node port (NodePort type) is unrelated to DNS resolution within the cluster; ClusterIP Services are reachable internally without node ports, and DNS works regardless of the Service type. Option D is wrong because the container runtime (e.g., containerd, CRI-O) does not affect DNS resolution; DNS is handled by the cluster's network and DNS infrastructure, not by how containers are run.

Full explanation →
75
MCQhard

You need to run a one-time batch job that processes data and then exits. The job should run to completion and not be restarted. Which Kubernetes resource should you use?

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

A Kubernetes Job creates pods that run until successful completion, then stops — exactly matching the one-time batch requirement. Unlike a Deployment or ReplicaSet, which maintain a desired replica count and restart pods indefinitely, a Job's controller tracks completion and does not restart finished pods, satisfying the "run to completion and not be restarted" constraint.

Why this answer

A Kubernetes Job is designed for one-time batch processing tasks that run to completion and are not restarted. It creates one or more Pods and ensures they successfully terminate, making it the correct choice for a non-repeating, finite workload.

Exam trap

CNCF often tests the distinction between a Job and a CronJob, where candidates might mistakenly choose a CronJob for a one-time task, or confuse a Job's restart behavior with that of a Deployment's rolling update.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on all (or a subset of) nodes, typically for long-running services like log collectors or monitoring agents, not for one-time batch jobs. Option C is wrong because a Deployment manages a set of identical Pods to maintain a desired replica count for long-running, stateless applications, and it will restart Pods if they exit, which contradicts the requirement that the job should not be restarted. Option D is wrong because a StatefulSet is used for stateful applications that require stable, unique network identities and persistent storage, such as databases, and is not intended for ephemeral batch processing.

Full explanation →

Page 1 of 13

Page 2

All pages

12345678910111213

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 →