Kubernetes and Cloud Native Associate KCNA KCNA Questions 151–225 | Page 3/13

151

MCQeasy

Which Helm command is used to upgrade a release to a newer version of a chart?

A.helm upgrade

B.helm rollback

C.helm update

D.helm install

AnswerA

`helm upgrade` applies a new chart revision to an existing release, preserving its name and revision history rather than creating a fresh deployment as `helm install` would. This directly satisfies the stem's requirement to move a release to a newer chart version while retaining release identity and enabling rollback via `helm rollback`.

Why this answer

The 'helm upgrade' command upgrades an existing release with a new chart version or configuration.

Full explanation →

152

MCQmedium

In a Helm chart, which file is used to define default configuration values that can be overridden by users during installation?

A.templates/ directory

B.charts/ directory

C.values.yaml

D.Chart.yaml

AnswerC

values.yaml holds the chart's default parameters, which templates consume at render time. Users override individual entries via their own values files or --set flags during helm install, so this file provides the overridable baseline configuration the question describes.

Why this answer

In a Helm chart, values.yaml is the file that defines default configuration values for the chart. Users can override these defaults by supplying their own values file (via -f) or using --set flags during helm install or helm upgrade. Helm merges user-supplied values with the chart's defaults at render time.

Exam trap

KCNA often tests candidates who confuse the roles of Chart.yaml (metadata) and values.yaml (configuration) — the trap is picking Chart.yaml because it sounds like the 'main' chart file.

How to eliminate wrong answers

Option A is wrong because the templates/ directory contains Kubernetes manifest templates (with Go templating syntax) that are rendered using values, not the values themselves. Option B is wrong because the charts/ directory holds dependent subcharts (vendored dependencies), not configuration values. Option D is wrong because Chart.yaml contains chart metadata — name, version, appVersion, description, dependencies — not user-overridable configuration values.

Full explanation →

153

MCQhard

A team wants to deploy a multi-cloud application that uses cloud-specific services. Which pattern is most appropriate?

A.Single-cloud vendor lock-in to reduce complexity

B.Manually managing each cloud separately without automation

C.Only using serverless functions from one provider

D.Using cloud-agnostic abstractions and infrastructure as code across providers

AnswerD

Cloud-agnostic abstractions with infrastructure as code let the team provision and manage services consistently across providers, avoiding lock-in while still integrating cloud-specific services. This satisfies the multi-cloud portability constraint better than committing to one vendor's proprietary tooling.

Why this answer

Using cloud-agnostic abstractions (e.g., Kubernetes for container orchestration, Terraform for infrastructure as code) allows the team to deploy across multiple clouds while still integrating cloud-specific services via provider-agnostic interfaces or abstraction layers. This pattern reduces vendor lock-in, enables consistent deployment workflows, and supports portability without sacrificing the ability to use unique services from each cloud provider.

Exam trap

The trap here is that candidates may think 'cloud-agnostic' means avoiding all cloud-specific services, but the correct pattern allows using them through abstraction layers, not eliminating them entirely.

How to eliminate wrong answers

Option A is wrong because single-cloud vendor lock-in contradicts the requirement for a multi-cloud application; it increases dependency on one provider and reduces flexibility. Option B is wrong because manually managing each cloud separately without automation introduces high operational overhead, configuration drift, and inconsistent deployments, which is inefficient and error-prone for multi-cloud scenarios. Option C is wrong because only using serverless functions from one provider still results in vendor lock-in and does not address the need to use cloud-specific services across multiple providers in a multi-cloud architecture.

Full explanation →

154

MCQmedium

Which kubectl command is used to create or update resources defined in a YAML file?

A.kubectl update -f file.yaml

B.kubectl create -f file.yaml

C.kubectl apply -f file.yaml

D.kubectl set -f file.yaml

AnswerC

Declarative management: apply reconciles the live object against the YAML manifest, creating it if absent or patching changed fields if present. This satisfies the stem's requirement to both create and update from one file, unlike imperative create, which fails on an existing resource.

Why this answer

`kubectl apply -f file.yaml` uses a declarative approach to create or update Kubernetes resources. It sends the YAML configuration to the API server, which compares the desired state with the current state and applies the necessary changes, storing the last-applied configuration in an annotation for future updates.

Exam trap

The trap here is that candidates confuse `kubectl create` (imperative, fails on existing resources) with `kubectl apply` (declarative, handles both create and update), or assume a non-existent `kubectl update` command exists based on other tools like `apt update`.

How to eliminate wrong answers

Option A is wrong because `kubectl update` is not a valid kubectl command; Kubernetes uses `kubectl edit`, `kubectl patch`, or `kubectl apply` to modify resources, not `update`. Option B is wrong because `kubectl create -f file.yaml` only creates new resources and will fail if the resource already exists, whereas the question asks for creating OR updating. Option D is wrong because `kubectl set -f file.yaml` is not a valid command; `kubectl set` is used to modify specific fields of live resources (e.g., `kubectl set image`), not to apply a full YAML file.

Full explanation →

155

Multi-Selectmedium

Which two of the following are valid ways to expose a set of Pods to external traffic?

Select 2 answers

A.Create a Service of type NodePort

B.Use a ConfigMap to expose the Pods

C.Create an Ingress resource without a Service

D.Create a Service of type LoadBalancer

E.Create a Service of type ClusterIP

AnswersA, D

NodePort opens a static port on every cluster node, forwarding external traffic to the matched Pods via kube-proxy. This satisfies the stem's requirement to expose Pods externally without a cloud load balancer, unlike ClusterIP, which remains reachable only inside the cluster.

Why this answer

Option A (Create a Service of type NodePort) is correct because a NodePort Service allocates a port on every node's IP (default range 30000-32767) and forwards external traffic to the selected Pods, making it a valid way to expose Pods externally. Option D (Create a Service of type LoadBalancer) is correct because it provisions an external load balancer (via the cloud provider) that routes traffic to the Service's endpoints, thereby exposing the Pods to external clients. Option B is incorrect because a ConfigMap stores configuration data, not network routing, and cannot expose Pods.

Option C is incorrect because an Ingress resource requires a backing Service (typically ClusterIP) to route traffic to Pods; without a Service, it has no endpoints to forward to. Option E is incorrect because a ClusterIP Service only exposes Pods on an internal cluster IP, reachable only from within the cluster, not from external traffic.

Exam trap

A common misconception is that an Ingress resource can function without an underlying Service, but Ingress only provides routing and must point to a Service to reach Pods.

Full explanation →

156

MCQhard

In the context of resiliency patterns, which pattern is designed to prevent a cascade of failures by isolating each component so that a failure in one component does not affect others?

A.Retry

B.Circuit breaker

C.Timeout

D.Bulkhead

AnswerD

The Bulkhead pattern partitions components into isolated pools, so resource exhaustion or failure in one partition cannot consume shared capacity and cascade to others. This isolation directly satisfies the requirement to contain failures within individual components.

Why this answer

The bulkhead pattern isolates resources (e.g., thread pools, connections) so that a failure in one part of the system doesn't bring down other parts. Circuit breaker is for handling failures of external calls, not isolation.

Full explanation →

157

MCQhard

A pod uses a ServiceAccount that has a RoleBinding to a Role with 'get', 'list', 'watch' on 'pods'. The pod tries to list pods in the same namespace. Will the request succeed?

A.No, because there is a deny rule for pods

B.Yes, because the Role grants 'list' on pods

C.No, because ServiceAccount cannot list pods

D.Yes, but only if the ServiceAccount also has a ClusterRoleBinding

AnswerB

RoleBinding binds the Role to the ServiceAccount within the same namespace, and the Role explicitly grants 'list' on pods, so the API server authorises the request. The namespace constraint is satisfied because both the Role and the pod reside in the same namespace.

Why this answer

In Kubernetes RBAC, permissions are additive. The Role grants 'list' on pods, so the ServiceAccount can list pods. There is no deny rule; RBAC is deny by default, but the permission is explicitly granted.

Option A is incorrect because there is no deny rule for pods. Option C is incorrect because a ServiceAccount can list pods if it has the appropriate RBAC permissions. Option D is incorrect because a ClusterRoleBinding is not required; a RoleBinding in the same namespace is sufficient.

Full explanation →

158

Multi-Selectmedium

Which TWO statements are true about Kustomize? (Choose 2)

Select 2 answers

A.It supports patching Kubernetes resources via strategic merge patches or JSON patches.

B.It automatically handles canary traffic routing.

C.It relies on Go templating to generate Kubernetes manifests.

D.It uses a base and overlay model to manage environment-specific configurations.

E.It can be used to package and deploy Helm charts.

AnswersA, D

Kustomize's patch transformers apply strategic merge patches, which use Kubernetes merge keys to combine list items by name, or JSON patches, which use RFC 6902 operations for precise edits. This satisfies the stem's requirement for a true statement, as both patch types are core, documented Kustomize features.

Why this answer

Option A is correct because Kustomize natively supports customizing Kubernetes resources through patches, including strategic merge patches (which merge by resource keys) and JSON patches (RFC 6902 operations), applied via the patchesStrategicMerge and patchesJson6902 fields in kustomization.yaml. Option D is correct because Kustomize's core design is a base-and-overlay model, where a base holds common manifests and overlays reference the base to apply environment-specific customizations without duplicating YAML. Option B is not correct because canary traffic routing is handled by service meshes or progressive delivery tools like Argo Rollouts or Flagger, not Kustomize, which only renders manifests.

Option C is not correct because Kustomize deliberately avoids Go templating; it uses declarative YAML overlays and patches, unlike Helm which uses Go templates. Option E is not correct because packaging and deploying Helm charts is the role of Helm itself, not Kustomize, although the two tools can be used together.

Exam trap

The trap here is that candidates might confuse Kustomize with Helm, thinking Kustomize uses Go templating or can package Helm charts, but Kustomize is template-free and focuses on overlays and patches.

Full explanation →

159

MCQeasy

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

A.To store and distribute container images

B.To run unit tests on container images

C.To store application source code

D.To scan images for vulnerabilities

AnswerA

A container registry stores versioned container images and serves them to nodes during deployment, which is precisely the distribution role the CI/CD pipeline requires. Build stages push tagged images; runtime environments pull them by digest or tag, satisfying the stem's demand for a dedicated artefact repository rather than a build or orchestration function.

Why this answer

A container registry is a centralized repository for storing and distributing container images, such as Docker images. In a CI/CD pipeline, after an image is built, it is pushed to a registry (e.g., Docker Hub, Harbor, or a cloud provider's registry) so that it can be pulled and deployed to various environments. This enables versioning, sharing, and consistent deployment of containerized applications.

Exam trap

KCNA often tests the distinction between the roles of different CI/CD components, and a common trap is confusing the registry with tools that perform scanning or testing, leading candidates to select an answer that describes a secondary or integrated feature rather than the primary purpose.

How to eliminate wrong answers

Option B is wrong because running unit tests is typically done by a CI tool (e.g., Jenkins, GitLab CI) or a test runner, not by a container registry; registries only store and serve images. Option C is wrong because storing application source code is the role of a version control system (e.g., Git), not a container registry. Option D is wrong because scanning images for vulnerabilities is a security function often performed by dedicated scanners (e.g., Trivy, Clair) or integrated into registries as an add-on, but it is not the primary purpose of a registry.

Full explanation →

160

MCQmedium

An application is instrumented with OpenTelemetry to export traces to Jaeger. The team notices that some traces are incomplete. What is the most likely cause?

A.Context propagation is not correctly implemented

B.Span attributes are missing

C.Sampling rate is too high

D.Jaeger database is full

AnswerA

Incomplete traces typically arise when trace context is not propagated across service boundaries, so downstream spans are created without the parent trace ID and appear as separate traces rather than linked spans within one trace.

Why this answer

Incomplete traces often occur when context propagation is not implemented correctly, causing spans to be disconnected.

Full explanation →

161

MCQmedium

A user wants to run a one-time batch job that runs to completion. Which Kubernetes resource should they use?

A.Job

B.StatefulSet

C.DaemonSet

D.Deployment

AnswerA

A Job creates pods that run until successful completion, tracking completions and retries — exactly matching the one-time batch requirement. Unlike Deployments, which maintain a desired replica count indefinitely, or CronJobs, which schedule recurring runs, a Job's controller terminates once the specified completions succeed, satisfying the run-to-completion constraint.

Why this answer

A Kubernetes Job is the correct resource for a one-time batch job that runs to completion. Unlike controllers designed for long-running processes, a Job creates one or more Pods and ensures they successfully terminate, making it ideal for finite tasks like data processing or backups.

Exam trap

A common pitfall is assuming that a Deployment can handle batch jobs because it manages Pods, but Deployments enforce a desired replica count and restart policies that keep Pods running indefinitely, making them unsuitable for tasks that must terminate successfully after completing their work.

How to eliminate wrong answers

Option B (StatefulSet) is wrong because it manages stateful applications with persistent identities and stable storage, designed for long-running workloads like databases, not one-time batch jobs. Option C (DaemonSet) is wrong because it ensures a Pod runs on every node in the cluster, intended for cluster-wide services like logging agents, not finite tasks. Option D (Deployment) is wrong because it manages stateless, long-running applications with rolling updates and scaling, aiming for continuous availability, not job completion.

Full explanation →

162

Multi-Selectmedium

Which TWO components are part of the Kubernetes control plane? (Select exactly two.)

Select 2 answers

A.kube-proxy

B.kubelet

C.container runtime

D.kube-apiserver

E.kube-scheduler

AnswersD, E

kube-apiserver is the control plane's central REST front end: it validates and persists every object to etcd and is the only component all others talk to. It satisfies the control-plane criterion because it runs on the control plane, not on worker nodes.

Why this answer

The kube-apiserver (option D) is the central control plane component that exposes the Kubernetes API, validating and processing all REST requests and serving as the front end for the cluster's shared state in etcd. The kube-scheduler (option E) is also a control plane component, responsible for watching for newly created Pods with no assigned node and selecting an appropriate node based on resource requirements, affinity rules, and other constraints. By contrast, kube-proxy (A) runs on each node and maintains network rules for Service traffic, the kubelet (B) is a node agent that ensures containers described in PodSpecs are running, and the container runtime (C) is the software on each node that actually runs containers — all three are node components, not control plane components.

Exam trap

CNCF often tests the distinction between control plane and worker node components, and the trap here is that candidates confuse kube-proxy or kubelet (which run on every node) with control plane components because they are essential for cluster operation, but they are not part of the control plane itself.

Full explanation →

163

MCQhard

A team wants to run a database Pod that must be scheduled onto a node with an SSD and must not be evicted when the node comes under memory pressure. Which combination of fields should be configured in the Pod spec?

A.nodeAffinity with a disk-type match and resource requests equal to limits for memory

B.A taint on the database Pod and a matching toleration on the SSD nodes

C.nodeSelector with a disk-type label and a PriorityClass with a high value

D.A PodDisruptionBudget with minAvailable set to one and an emptyDir volume

AnswerA

nodeAffinity with a requiredDuringSchedulingIgnoredDuringExecution rule pins the Pod to SSD-labeled nodes, and setting memory requests equal to limits makes the Pod Guaranteed QoS. Guaranteed Pods are the last to be evicted when a node exceeds its memory eviction threshold, satisfying both the placement and eviction-resistance requirements.

Why this answer

Node placement is expressed through nodeSelector or nodeAffinity, and protection from kubelet eviction under resource pressure comes from the Pod's QoS class. Setting memory requests equal to limits yields Guaranteed QoS, which is evicted last. Taints, tolerations, PriorityClass, and PodDisruptionBudgets address different concerns and do not provide the required placement plus eviction resistance together.

Exam trap

The trap here is believing a high PriorityClass prevents eviction, when priority affects scheduling and preemption while QoS class determines eviction order under node pressure.

Full explanation →

164

MCQhard

An application is deployed across multiple cloud providers (AWS and GCP) to avoid vendor lock-in. This is an example of which pattern?

A.Public cloud

B.Federated cloud

C.Hybrid cloud

D.Multi-cloud

AnswerD

Multi-cloud means deliberately using two or more distinct public cloud providers, here AWS and GCP, so workloads avoid dependence on one vendor. That directly satisfies the stated vendor lock-in avoidance constraint, distinguishing it from hybrid cloud, which pairs private infrastructure with a single public provider.

Why this answer

Multi-cloud refers to using services from multiple cloud providers simultaneously.

Full explanation →

165

MCQmedium

A Service of type ClusterIP is created. What is the default behavior of this Service?

A.It exposes the Service externally via a cloud load balancer

B.It exposes the Service on a static port on each node

C.It routes traffic to Pods based on external DNS names

D.It exposes the Service on a cluster-internal IP

AnswerD

ClusterIP is the default Service type, allocating a virtual IP reachable only from within the cluster network. It satisfies the scenario's implicit constraint that no external exposure is requested, unlike NodePort or LoadBalancer, which additionally open host ports or provision cloud ingress.

Why this answer

A ClusterIP Service is the default Kubernetes Service type, which assigns a virtual IP address reachable only within the cluster. Traffic sent to this IP is load-balanced across the Pods selected by the Service's label selector, using iptables or IPVS rules. No external access is provided unless an Ingress or other mechanism is explicitly configured.

Exam trap

The trap here is that candidates often confuse the default Service type (ClusterIP) with NodePort or LoadBalancer, assuming a Service must be externally accessible by default, but Kubernetes intentionally isolates ClusterIP Services to internal cluster traffic only.

How to eliminate wrong answers

Option A is wrong because exposing a Service externally via a cloud load balancer is the behavior of a Service of type LoadBalancer, not ClusterIP. Option B is wrong because exposing the Service on a static port on each node is the behavior of a Service of type NodePort, which opens a high-port on every node's IP. Option C is wrong because routing traffic based on external DNS names is not a native Service behavior; DNS-based routing is typically handled by an Ingress controller or external DNS integration, not by a ClusterIP Service.

Full explanation →

166

MCQmedium

What type of Prometheus metric is best suited to count the total number of HTTP requests received by a service?

A.Histogram

B.Gauge

C.Summary

D.Counter

AnswerD

Counters are monotonically increasing values, so each HTTP request increments the total without resetting. This satisfies the stem's requirement to count cumulative requests; the rate() function then derives requests per second from that running total.

Why this answer

A Counter is a cumulative metric that only increases (or resets to zero on restart), making it ideal for tracking the total number of events like HTTP requests. Since the total request count is monotonically increasing, a Counter directly represents this without additional processing. Other metric types like Gauge, Histogram, and Summary serve different purposes: Gauge can go up and down, Histogram and Summary are for distributions (e.g., request durations).

Exam trap

KCNA often tests the distinction between metric types, and a common trap is confusing Counter with Gauge or Histogram, especially when the question mentions 'total number'—candidates might incorrectly think a Gauge can track totals or that a Histogram is needed for counting, but the key is that a Counter is specifically for cumulative counts.

How to eliminate wrong answers

Option A is wrong because a Histogram is used to track the distribution of values (e.g., request durations or sizes) across predefined buckets, not for simple counting. Option B is wrong because a Gauge represents a value that can arbitrarily go up and down, such as current memory usage or temperature, and is not suitable for a cumulative count. Option C is wrong because a Summary, like a Histogram, is designed to capture distributions and calculate quantiles over a sliding time window, not to count total events.

Full explanation →

167

MCQmedium

Which tool is specifically designed for log aggregation and is built by Grafana Labs as a lightweight, cost-effective alternative to traditional log systems?

A.Loki

B.Zipkin

C.Prometheus

D.Jaeger

AnswerA

Loki indexes only metadata labels rather than full log text, storing compressed chunks in object storage, which satisfies the lightweight, cost-effective constraint. Built by Grafana Labs, it aggregates logs alongside Prometheus-style metrics, making it the purpose-built alternative to traditional full-text indexing systems such as Elasticsearch.

Why this answer

Loki is a log aggregation system optimized for Kubernetes, designed to be cost-effective and easy to operate.

Full explanation →

168

MCQmedium

A workload running in a namespace called 'payments' is defined by a Pod spec with restartPolicy: Always. The cluster's kubelet on node 'worker-3' is healthy, the API server is reachable, and the scheduler has placed the Pod on worker-3. After the Pod's only container exits with code 0, a platform engineer observes that the Pod restarts repeatedly even though the application completed its work successfully. Which Kubernetes behavior explains this observation?

A.The ReplicaSet controller recreates the Pod because the Pod's desired replica count is set to one.

B.The kubelet applies the Pod's liveness probe and restarts the container when the probe fails after the process exits.

C.The kubelet restarts the container because restartPolicy: Always restarts containers regardless of the exit code.

D.The scheduler evicts the Pod and reschedules it to another node, which causes the container to start again.

AnswerC

For a Pod with restartPolicy: Always, the kubelet restarts any container that terminates, including a container that exits with code 0. The restart decision is based on the policy, not on whether the application reported success, so a one-shot job-like container will keep restarting under this policy. This matches the observed repeated restarts.

Why this answer

With restartPolicy: Always, the kubelet treats every container termination as a reason to restart, even a successful exit with code 0. That policy is the correct default for long-running services but is wrong for run-to-completion work; such work should use restartPolicy: OnFailure or Never, or be modeled as a Job. The repeated restarts observed on worker-3 are therefore expected kubelet behavior for the Pod's policy.

Exam trap

The trap here is assuming that an exit code of 0 prevents a restart, when restartPolicy: Always restarts the container regardless of exit status.

Full explanation →

169

MCQmedium

Which field in a Deployment YAML specifies the number of pod replicas?

A.spec.replicas

B.spec.template.spec.replicas

C.spec.replicaCount

D.spec.selector.matchLabels

AnswerA

The Deployment's pod template sits under spec.template, but the replica count is a direct child of spec, so spec.replicas declares how many identical pods the controller maintains. Setting it satisfies the stem's requirement for the field specifying pod replica numbers.

Why this answer

In a Kubernetes Deployment YAML, the `spec.replicas` field directly defines the desired number of pod replicas that the Deployment controller should maintain. This is a top-level field under the Deployment spec, not nested under `template.spec`, because the replica count is a property of the Deployment itself, not of the Pod template.

Exam trap

The trap here is that candidates confuse the Deployment's `spec.replicas` with the Pod template's `spec` section, or they misremember the field name as `replicaCount` due to exposure to Helm chart conventions or other orchestration tools.

How to eliminate wrong answers

Option B is wrong because `spec.template.spec.replicas` is not a valid field; the `spec.template` section defines the Pod template, and Pods themselves do not have a `replicas` field — that concept belongs to higher-level controllers like Deployments or ReplicaSets. Option C is wrong because `spec.replicaCount` is not a Kubernetes API field; the correct field name is `replicas`, not `replicaCount`, which is a common naming convention in Helm charts but not in native Kubernetes YAML. Option D is wrong because `spec.selector.matchLabels` is used to define the label selector that the Deployment uses to identify which Pods it manages, not to specify the number of replicas.

Full explanation →

170

Multi-Selectmedium

Which TWO of the following are Prometheus metric types? (Select two.)

Select 2 answers

A.Event

B.Gauge

C.Set

D.Counter

E.Timer

AnswersB, D

Gauge is a Prometheus metric type representing a value that can arbitrarily increase or decrease, such as current memory usage or temperature. It is one of the four core types alongside counter, histogram and summary.

Why this answer

Prometheus defines exactly four core metric types, and Gauge (B) is one of them: it represents a value that can arbitrarily go up or down, such as current temperature or memory usage. Counter (D) is also a core Prometheus metric type: it is a cumulative value that only increases (or resets to zero on restart), used for things like total requests served. The other options are not Prometheus metric types: Event (A) is not a Prometheus concept, Set (C) is a StatsD metric type, and Timer (E) is also a StatsD metric type, so none of them belong to Prometheus's metric model.

Exam trap

KCNA often tests the confusion between Prometheus metric types and general monitoring concepts like timers or events, which belong to other systems such as StatsD.

Full explanation →

171

Multi-Selecthard

A developer is troubleshooting a Pod that is stuck in the Pending state. Which two commands can help identify the reason for the scheduling failure? (Choose two.)

Select 2 answers

A.kubectl exec -it <pod-name> -- /bin/sh

B.kubectl top pod <pod-name>

C.kubectl logs <pod-name>

D.kubectl get events --field-selector involvedObject.name=<pod-name>

E.kubectl describe pod <pod-name>

AnswersD, E

This command filters cluster events related to the specific Pod. Events include scheduler messages such as '0/3 nodes are available: 3 Insufficient cpu', which directly explain why the Pod cannot be scheduled. It is an effective way to isolate relevant scheduling failures.

Why this answer

When a Pod is Pending, the scheduler has not placed it on a node. The describe command and filtered events both surface scheduler events that state the reason, such as insufficient resources or taints. Logs, exec, and top require a running container and are not useful for a Pod that has never started.

Exam trap

The trap here is reaching for logs or exec to debug a Pending Pod, but those require a running container and will not work before scheduling.

Full explanation →

172

Multi-Selecthard

Which TWO of the following are features of a service mesh like Istio or Linkerd? (Select 2)

Select 2 answers

A.Container image building

B.Traffic management (routing, load balancing)

C.Observability (metrics, tracing, logs)

D.Service discovery

E.Auto-scaling of services

AnswersB, C

A service mesh's data plane proxies intercept all pod-to-pod traffic, enabling dynamic routing rules, retries, and load balancing independent of application code. This satisfies the traffic management feature the question asks for, unlike a plain Kubernetes Service which offers only basic round-robin distribution.

Why this answer

Option B is correct because a service mesh like Istio or Linkerd deploys sidecar proxies (Envoy in Istio, linkerd2-proxy in Linkerd) alongside each workload to intercept east-west traffic and provide fine-grained traffic management such as HTTP/gRPC routing, retries, timeouts, circuit breaking, and load balancing. Option C is correct because these sidecars also emit telemetry — request metrics (e.g., Prometheus-scraped latency/error counters), distributed traces (via Zipkin/Jaeger/OpenTelemetry), and access logs — giving uniform observability without changing application code. Option A is not a service mesh feature; container image building is handled by tools like Docker BuildKit, Buildah, or Kaniko in a CI pipeline.

Option D, service discovery, is a related but distinct capability typically provided by the platform (Kubernetes Services/DNS, Consul) that the mesh consumes rather than being a defining feature of the mesh itself. Option E, auto-scaling, is performed by Kubernetes controllers such as the Horizontal Pod Autoscaler or KEDA, not by the service mesh data plane.

Exam trap

KCNA often tests the boundary between mesh features and Kubernetes-native features — service discovery and auto-scaling are Kubernetes capabilities, so candidates who pick them confuse 'things a mesh uses' with 'things a mesh provides'.

Full explanation →

173

MCQeasy

What is the purpose of values.yaml in a Helm chart?

A.To specify the chart metadata

B.To define the Kubernetes resources to create

C.To define the release name

D.To store default configuration values for the chart

AnswerD

Helm reads values.yaml to supply the chart's built-in defaults, which templates reference during rendering. Any value a user omits at install time falls back to these entries, so the file defines the chart's baseline configuration rather than per-release overrides.

Why this answer

values.yaml in a Helm chart is the default configuration file that supplies values to the chart's templates. When you run helm install or helm upgrade, Helm merges these defaults with any user-supplied overrides (via --set, -f, or a parent chart's values) and then renders the templates. This separation of configuration from template logic is what makes charts reusable across environments without editing the templates themselves.

Exam trap

KCNA often tests the confusion between Chart.yaml (metadata) and values.yaml (configuration defaults), so candidates who skim the options may pick 'chart metadata' simply because both files live at the chart root.

How to eliminate wrong answers

Option A is wrong because chart metadata (name, version, apiVersion, description, dependencies) lives in Chart.yaml, not values.yaml. Option B is wrong because the Kubernetes resources are defined in the templates/ directory as Go-templated YAML manifests; values.yaml only supplies the data those templates interpolate. Option C is wrong because the release name is provided at install time (helm install <release-name> <chart>) or auto-generated, not stored in values.yaml.

Full explanation →

174

MCQmedium

In Kustomize, what is the purpose of an overlay?

A.To apply environment-specific customizations on top of a base

B.To merge multiple Kubernetes manifests into one

C.To template variables into YAML files

D.To define the base configuration of an application

AnswerA

An overlay is a Kustomization layered over a base, patching or adding resources so the same base yields environment-specific output such as dev or production variants. This satisfies the requirement to customise a shared base per environment.

Why this answer

In Kustomize, an overlay is a kustomization that references a base and applies environment-specific customizations such as patches, name prefixes, or label changes. This allows you to reuse a common base configuration while tailoring it for different environments like dev, staging, and prod. The overlay does not modify the base itself; it produces a new set of resources with the changes applied.

Exam trap

KCNA often tests the distinction between Kustomize overlays and Helm templating, causing candidates to confuse variable substitution with overlay-based customization.

How to eliminate wrong answers

Option B is wrong because merging multiple Kubernetes manifests into one is not the purpose of an overlay; that is typically done by combining resources in a kustomization or using tools like helm, but overlays are for customization, not merging. Option C is wrong because templating variables into YAML files is a feature of Helm, not Kustomize; Kustomize uses patches and transformers, not variable substitution. Option D is wrong because defining the base configuration is the role of the base, not the overlay; the overlay builds upon the base to apply environment-specific changes.

Full explanation →

175

MCQmedium

A DevOps team wants to implement GitOps for their Kubernetes cluster. Which tool is specifically designed for Kubernetes GitOps and can automatically sync the cluster state with a Git repository?

A.ArgoCD

B.Jenkins

C.Kustomize

D.Helm

AnswerA

ArgoCD is a declarative GitOps continuous delivery controller built specifically for Kubernetes. It continuously reconciles live cluster state against manifests stored in Git, automatically syncing drift back to the declared desired state, which directly satisfies the requirement for automatic cluster-to-repository synchronisation.

Why this answer

ArgoCD is a declarative, GitOps continuous delivery tool designed specifically for Kubernetes. It continuously monitors a Git repository and automatically syncs the cluster state to match the desired state defined in Git, making it the correct choice for Kubernetes GitOps.

Exam trap

KCNA often tests the confusion between GitOps tools (ArgoCD, Flux) and Kubernetes packaging/config tools (Helm, Kustomize) — candidates pick Helm or Kustomize because they are Kubernetes-related but not GitOps reconcilers.

How to eliminate wrong answers

Option B is wrong because Jenkins is a general-purpose CI/CD automation server; while it can be scripted to deploy to Kubernetes, it is not a GitOps tool and does not natively sync cluster state from Git. Option C is wrong because Kustomize is a configuration management tool for customizing Kubernetes manifests (overlays, patches) — it does not perform GitOps syncing or cluster reconciliation. Option D is wrong because Helm is a package manager for Kubernetes that templates and deploys charts; it does not continuously reconcile cluster state with a Git repository.

Full explanation →

176

MCQhard

A site reliability engineer is investigating high latency in a microservices application. They have distributed tracing enabled with OpenTelemetry and traces exported to a backend. They want to correlate a specific slow trace with the logs generated by the involved services. Which practice best enables this correlation?

A.Enable debug logging on all services and increase log verbosity.

B.Configure the OpenTelemetry Collector to sample all traces at 100%.

C.Use a separate logging backend that is different from the tracing backend.

D.Include the trace ID and span ID in the log entries of each service.

AnswerD

Including the trace ID and span ID in log entries allows logs to be directly linked to the corresponding trace. When investigating a slow trace, the engineer can search logs for that trace ID and see all related log lines across services. This is a standard practice in cloud native observability and is supported by OpenTelemetry's logging integration, enabling efficient root cause analysis.

Why this answer

Correlating traces and logs requires a shared identifier. By injecting the trace ID and span ID into log records, each log line can be tied to the exact trace and span that produced it. This allows an engineer to take a slow trace, extract its trace ID, and query logs for that ID to see all related events across services.

Other options do not provide this direct linkage.

Exam trap

The trap here is thinking that increasing log detail or sampling rates enables correlation, when the essential requirement is propagating trace context into logs.

Full explanation →

177

Multi-Selecteasy

Which two of the following are benefits of using Kubernetes for container orchestration? (Select TWO.)

Select 2 answers

A.Integrated continuous integration pipeline

B.Automatic code compilation

C.Self-healing: automatically restarts failed containers

D.Built-in database management

E.Automated rollouts and rollbacks

AnswersC, E

Kubernetes self-healing is performed by the kubelet and ReplicaSet controllers, which detect failed containers and restart or replace them automatically. This satisfies the availability benefit, maintaining the desired replica count without manual intervention when a container crashes.

Why this answer

Option C is correct because Kubernetes provides self-healing through controllers such as ReplicaSets and Deployments: when a container or Pod fails, the kubelet and control-plane reconciliation loop detect the deviation from the desired state and automatically restart or replace the failed container to maintain the declared replica count. Option E is correct because Kubernetes supports automated rollouts and rollbacks via Deployment objects, where changes to the Pod template trigger a rolling update (using maxSurge/maxUnavailable) and `kubectl rollout undo` reverts to a previous ReplicaSet revision. The unmarked options do not belong: A is incorrect because Kubernetes is an orchestration platform, not a CI system (CI is handled by tools like Jenkins, GitLab CI, or Tekton), B is incorrect because Kubernetes does not compile source code—it runs pre-built container images, and D is incorrect because Kubernetes does not provide built-in database management; stateful databases require operators or external services.

Exam trap

A common pitfall is assuming that Kubernetes includes built-in CI/CD, code compilation, or database management features. In reality, these are external tools integrated separately. Kubernetes core features focus on container orchestration, including self-healing (via liveness probes and controllers) and automated rollouts/rollbacks (via Deployments).

Full explanation →

178

MCQeasy

An operator needs a workload that runs exactly one Pod on every node in the cluster, including nodes added later, to collect host-level logs. Which Kubernetes resource should be used?

A.A Job with a high parallelism value

B.A StatefulSet with podManagementPolicy set to Parallel

C.A DaemonSet

D.A Deployment with replicas equal to the node count

AnswerC

A DaemonSet ensures that a copy of a Pod runs on every eligible node and automatically schedules new Pods onto nodes that join the cluster later. That matches the requirement of one log-collector Pod per node, including future nodes, without manual intervention or node-specific manifests.

Why this answer

Per-node agents such as log shippers, node exporters, and CNI components are implemented as DaemonSets. The DaemonSet controller creates one Pod per eligible node and reacts to cluster membership changes by adding Pods on new nodes, which no replica-count-based controller can guarantee. Deployments, StatefulSets, and Jobs lack that node-scoped placement semantics.

Exam trap

The trap here is assuming a Deployment with a replica count matching the number of nodes will spread Pods evenly, when the scheduler actually offers no such per-node guarantee.

Full explanation →

179

MCQhard

Which of the following patterns is used to improve resilience by isolating failures to a subset of components?

A.Timeout

B.Retry

C.Circuit breaker

D.Bulkhead

AnswerD

Bulkhead partitions components into isolated pools so a failure in one pool cannot exhaust shared resources and cascade. This directly satisfies the stem's requirement to isolate failures to a subset, containing the blast radius rather than letting one fault degrade the whole system.

Why this answer

The Bulkhead pattern (D) is correct because it isolates failures by partitioning resources (e.g., thread pools, connections) into separate pools for different components or services. This prevents a failure in one component from exhausting shared resources and cascading to others, directly improving resilience by containing the blast radius.

Exam trap

CNCF often tests the distinction between patterns that prevent cascading failures (Bulkhead) versus patterns that handle transient failures (Retry/Timeout) or protect against repeated failures (Circuit Breaker), leading candidates to confuse the goal of isolation with failure detection or recovery.

How to eliminate wrong answers

Option A is wrong because Timeout is a pattern that limits the wait time for a response, preventing indefinite hangs, but it does not isolate failures to a subset of components—it only terminates slow operations. Option B is wrong because Retry is a pattern that automatically reattempts a failed operation, which can help with transient failures but does not isolate failures; in fact, it can exacerbate resource exhaustion if not combined with other patterns. Option C is wrong because Circuit Breaker is a pattern that monitors for failures and stops requests to a failing service to allow recovery, but it does not isolate failures to a subset of components—it protects callers from a failing dependency, not partition resources across components.

Full explanation →

180

Multi-Selecteasy

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

Select 2 answers

A.Images are always pulled from a private registry

B.Each layer is identified by a unique hash

C.Images can be modified at runtime by writing to the container layer

D.Images are built from a series of read-only layers

E.Images are stored on the host filesystem after being pulled

AnswersB, D

Content-addressed storage means each layer's digest is computed from its contents, so identical layers share one hash across images and registries. This satisfies the stem's requirement for a correct statement about container images: immutability and deduplication follow directly from that unique hash, and any byte change produces a different digest.

Why this answer

Option B is correct because container image layers are content-addressable: each layer is identified by a unique cryptographic digest (hash) of its content, which is how registries and runtimes verify integrity and deduplicate layers. Option D is correct because an image is constructed as a stack of read-only layers, typically defined by Dockerfile instructions, with each layer adding or changing files on top of the previous one. Option A is incorrect because images can be pulled from public registries such as Docker Hub as well as private registries, so 'always' is false.

Option C is incorrect because writing at runtime happens in the writable container layer created on top of the image, not by modifying the image layers themselves. Option E is incorrect because after a pull, image layers are stored in the container runtime's local storage area (for example, /var/lib/docker or /var/lib/containers) rather than simply as arbitrary files on the host filesystem.

Exam trap

CNCF often tests the misconception that images are stored directly on the host filesystem like regular files, when in reality they are stored in a runtime-managed cache (e.g., /var/lib/docker) and are not directly accessible as ordinary files.

Full explanation →

181

MCQmedium

A pod spec includes a liveness probe that runs 'cat /tmp/healthy'. The probe is configured with initialDelaySeconds: 10, periodSeconds: 5. At what point does the kubelet first execute the probe?

A.Immediately after the pod is created

B.Only when the container is unhealthy

C.5 seconds after the container starts

D.10 seconds after the container starts

AnswerD

initialDelaySeconds: 10 tells the kubelet to wait ten seconds after the container starts before running the first liveness probe. periodSeconds: 5 only governs subsequent intervals, so the initial execution occurs at the ten-second mark, not earlier.

Why this answer

The kubelet first executes the liveness probe 10 seconds after the container starts because `initialDelaySeconds: 10` tells the kubelet to wait that long before initiating the first probe. The `periodSeconds: 5` only defines the interval between subsequent probes, not the initial delay. This ensures the container has time to start and create the `/tmp/healthy` file before being checked.

Exam trap

The trap here is confusing `initialDelaySeconds` with `periodSeconds`, leading candidates to think the probe runs after 5 seconds (the period) instead of 10 seconds (the initial delay).

How to eliminate wrong answers

Option A is wrong because the kubelet does not execute probes immediately after pod creation; it waits for the container to start and then applies `initialDelaySeconds`. Option B is wrong because liveness probes are executed periodically regardless of container health, not only when the container is unhealthy; the probe itself determines health. Option C is wrong because `periodSeconds: 5` controls the interval between probes after the first one, not the initial delay; the first probe occurs after `initialDelaySeconds`, which is 10 seconds.

Full explanation →

182

MCQhard

A developer wants to inject environment variables into a pod from a ConfigMap named 'app-config'. Which YAML snippet correctly mounts all key-value pairs from the ConfigMap as environment variables?

A.env: - name: CONFIG value: "$(CONFIGMAP)"

B.envFrom: - configMapRef: name: app-config

C.volumes: - name: config configMap: name: app-config volumeMounts: - name: config mountPath: /etc/config

D.env: - name: CONFIG valueFrom: configMapKeyRef: name: app-config key: config.yaml

AnswerB

Using `envFrom` with `configMapRef` imports every key-value pair from `app-config` as environment variables in one declaration, satisfying the requirement to mount all pairs rather than selecting individual keys. The alternative `valueFrom.configMapKeyRef` maps a single key per variable, so it cannot expose the whole ConfigMap without listing each key explicitly.

Why this answer

`envFrom` with a `configMapRef` injects all key-value pairs from the ConfigMap named 'app-config' as environment variables into the container. This is the standard Kubernetes method for bulk injection of ConfigMap data into environment variables, as opposed to selecting individual keys.

Exam trap

The trap here is that candidates often confuse `envFrom` (bulk injection) with `env` + `configMapKeyRef` (single key injection) or volume mounts (file-based injection), leading them to pick options that inject only one key or mount files instead of environment variables.

How to eliminate wrong answers

Option A is wrong because `env` with `value: "$(CONFIGMAP)"` is not valid syntax; Kubernetes does not support referencing a ConfigMap via a variable expansion like `$(CONFIGMAP)` — it requires explicit `valueFrom` or `envFrom`. Option C is wrong because it mounts the ConfigMap as a volume at `/etc/config`, which injects keys as files, not as environment variables — this does not satisfy the requirement to inject them as environment variables. Option D is wrong because it uses `env` with `configMapKeyRef` to inject only a single key (`config.yaml`) from the ConfigMap, not all key-value pairs.

Full explanation →

183

MCQeasy

Which of the following is considered one of the three pillars of observability?

A.Events

B.Metrics

C.Alerts

D.Profiles

AnswerB

Metrics are numerical measurements aggregated over time, forming one of observability's three pillars alongside logs and traces. They satisfy the stem's requirement by enabling efficient, low-cost monitoring of system health and alerting on thresholds, since pre-aggregated time-series data scales far better than inspecting individual events.

Why this answer

The three pillars of observability in cloud native environments are logs, metrics, and traces.

Full explanation →

184

MCQmedium

A DevOps team notices that a new deployment of a web application is not receiving traffic even though the pods are running. The deployment has a selector matching the pod labels, and a Service of type ClusterIP exists. What is the most likely cause?

A.The Service's targetPort does not match the container's containerPort.

B.The pods do not have a readiness probe defined.

C.The Service type should be NodePort to receive traffic.

D.The Service is not exposed via an Ingress.

AnswerA

The Service routes traffic to the targetPort, which must match the port the container listens on.

Why this answer

The most likely cause is that the Service's targetPort does not match the container's containerPort. In Kubernetes, a Service routes traffic to pods by forwarding packets to the port specified in the Service's `targetPort` field. If this does not match the `containerPort` defined in the pod's container spec, the traffic will be dropped because the kube-proxy will forward packets to a closed port on the pod, resulting in no connectivity even though the pods are running.

Exam trap

The trap here is that candidates often confuse the Service's `port` (the port the Service listens on) with `targetPort` (the port on the pod), assuming they must match, or they incorrectly attribute the issue to missing readiness probes or Ingress resources.

How to eliminate wrong answers

Option B is wrong because a readiness probe controls whether a pod is considered ready to receive traffic, but its absence does not prevent traffic from being sent to the pod; it simply means the pod will always be considered ready. Option C is wrong because a Service of type ClusterIP is perfectly capable of receiving traffic within the cluster; NodePort is only needed for external access from outside the cluster, not for internal traffic. Option D is wrong because an Ingress is an optional API object for HTTP/HTTPS routing and is not required for a ClusterIP Service to receive traffic; the Service itself can be accessed directly via its cluster IP.

Full explanation →

185

MCQeasy

A developer wants to run a one-time batch job that processes a queue and then terminates. Which Kubernetes resource should they use?

A.Job

B.StatefulSet

C.Deployment

D.DaemonSet

AnswerA

A Job creates pods that run to completion and then stops, tracking successful finishes rather than maintaining a persistent replica count. That matches a one-time batch process that drains a queue and terminates, unlike a Deployment, which restarts pods indefinitely.

Why this answer

A Kubernetes Job is designed for finite, batch-oriented tasks that run to completion, such as processing a queue and then terminating. Unlike controllers that maintain a desired state (like Deployments or StatefulSets), a Job creates one or more Pods and ensures they successfully exit, making it the correct choice for a one-time batch job.

Exam trap

The trap here is that candidates confuse a Job with a Deployment, assuming that any workload that 'runs' must be a Deployment, but Deployments are designed for long-running services and will restart terminated Pods, whereas a Job is the correct resource for workloads that should run to completion and then stop.

How to eliminate wrong answers

Option B (StatefulSet) is wrong because it is used for stateful applications that require stable, unique network identities and persistent storage, not for one-time batch jobs. Option C (Deployment) is wrong because it manages a set of Pods intended to run continuously (e.g., web servers) and will restart Pods if they exit, which is the opposite of a terminating batch job. Option D (DaemonSet) is wrong because it ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, typically for long-running system services like log collectors or monitoring agents, not for one-time tasks.

Full explanation →

186

MCQmedium

A Kubernetes cluster has a single control plane node and two worker nodes. The control plane node fails. What is the immediate impact on the workloads running on the worker nodes?

A.All workloads will stop immediately

B.Existing workloads continue running, but no new pods can be scheduled

C.The kubelet on worker nodes will restart all pods

D.Workloads will be automatically migrated to another cluster

AnswerB

Worker nodes run kubelet and their containers independently, so existing pods keep serving traffic. However, the scheduler and controller manager reside on the failed control plane, so no new pods can be placed and failed pods are not replaced, satisfying the immediate-impact constraint.

Why this answer

In Kubernetes, the control plane is responsible for scheduling new pods and maintaining desired state via the API server, controller manager, and scheduler. When the control plane fails, the kubelets on worker nodes continue to run existing pods based on their local state, but the scheduler cannot assign new pods to nodes, and the API server is unavailable for updates or scaling operations.

Exam trap

CNCF often tests the misconception that the control plane is required for all pod operations, leading candidates to assume workloads stop immediately, when in fact the kubelet provides resilience for existing pods.

How to eliminate wrong answers

Option A is wrong because existing workloads are managed by the kubelet on each worker node, which runs pods independently of the control plane; they do not stop immediately. Option C is wrong because the kubelet does not restart all pods upon control plane failure; it only restarts pods that have failed according to its local restart policy, not as a reaction to the control plane being down. Option D is wrong because Kubernetes does not automatically migrate workloads to another cluster; migration requires manual intervention or a multi-cluster management tool like KubeFed or a service mesh.

Full explanation →

187

Multi-Selectmedium

Which TWO resources can be used to store configuration data separately from container images?

Select 2 answers

A.Service

B.PersistentVolume

C.Secret

D.Deployment

E.ConfigMap

AnswersC, E

Secret stores sensitive configuration such as passwords, tokens and TLS certificates as base64-encoded key-value data, mounted into pods or exposed as environment variables. It keeps credentials out of container images, complementing ConfigMap for non-confidential settings.

Why this answer

ConfigMap (E) is correct because it is the Kubernetes API object designed to hold non-confidential configuration data as key-value pairs, which pods can consume via environment variables, command-line arguments, or mounted volumes, keeping that data out of the container image. Secret (C) is correct because it serves the analogous purpose for sensitive configuration data such as passwords, tokens, and certificates, storing them base64-encoded and injecting them into pods separately from the image. Both objects decouple configuration from the image, so the same image can be reused across environments with different settings.

Service (A) is incorrect because it provides stable network access and load balancing to a set of pods, not configuration storage. PersistentVolume (B) is incorrect because it supplies durable block or file storage for application data, not configuration key-value data. Deployment (D) is incorrect because it manages the desired state and rollout of replicated pods, not configuration content.

Exam trap

CNCF often tests the distinction between storage for configuration data (ConfigMaps/Secrets) vs. storage for application data (PersistentVolumes), so candidates mistakenly select PersistentVolume thinking it can store config files, but it is intended for stateful workloads like databases, not for decoupling configuration from images.

Full explanation →

188

MCQmedium

A developer instruments a service using the OpenTelemetry SDK and wants to export traces to a backend. The backend expects data in the OTLP format. Which OpenTelemetry component is responsible for receiving, processing, and exporting telemetry data to the backend?

A.OpenTelemetry Protocol (OTLP)

B.OpenTelemetry SDK

C.OpenTelemetry Collector

D.OpenTelemetry API

AnswerC

The OpenTelemetry Collector is a vendor-neutral agent that receives telemetry in various formats, processes it, and exports it to one or more backends. It supports OTLP natively and can batch, filter, and transform data before export. In this scenario, it acts as the intermediary that takes the SDK's OTLP output and delivers it to the backend, making it the correct component for receiving, processing, and exporting telemetry.

Why this answer

The OpenTelemetry Collector is designed to receive telemetry in OTLP and other formats, apply processors such as batching or filtering, and export to one or more backends. The API and SDK are for instrumenting and generating data inside applications, while OTLP is only the transport protocol. Therefore, the Collector is the component that receives, processes, and exports telemetry in this pipeline.

Exam trap

The trap here is confusing the OTLP protocol with the Collector, treating the transport format as if it were the runtime component that receives and routes telemetry.

Full explanation →

189

MCQmedium

Which Kubernetes command displays the current state of a pod, including its IP address, node, and container statuses?

A.kubectl get pod -o wide

B.kubectl describe pod

C.kubectl logs pod

D.kubectl get pod

AnswerA

The -o wide output flag extends the default pod listing with the pod IP and node name, alongside status and container readiness. Plain kubectl get pod omits those columns, and describe or logs show different detail.

Why this answer

`kubectl get pod -o wide` extends the default output to include additional columns such as the pod's IP address, the node it is scheduled on, and the container statuses (e.g., READY state). This command queries the Kubernetes API server for the pod's current state and formats the response with extra details, making it the most direct way to view the pod's IP and node assignment in a single line.

Exam trap

The trap here is that candidates often assume `kubectl get pod` alone shows all relevant pod details, but Kubernetes tests the specific requirement for the `-o wide` flag to expose the pod IP and node fields, which are hidden in the default output.

How to eliminate wrong answers

Option B is wrong because `kubectl describe pod` provides a detailed, multi-line description of a pod, including its IP address, node, and container statuses, but it is not a single-line display of the current state; it is a verbose output meant for troubleshooting, not a concise summary. Option C is wrong because `kubectl logs pod` retrieves the container logs from the pod's stdout/stderr, not the pod's state, IP address, or node information; it is used for debugging application output, not for inspecting pod metadata. Option D is wrong because `kubectl get pod` (without `-o wide`) displays only the basic columns (NAME, READY, STATUS, RESTARTS, AGE) and omits the pod IP and node fields, which are only added with the `-o wide` output format.

Full explanation →

190

MCQhard

Refer to the exhibit. A pod 'my-pod' shows repeated 'BackOff' events after the container starts. Which is the most likely cause?

A.The image 'myapp:v2' does not exist.

B.The container exceeds its memory limit.

C.The liveness probe is failing.

D.The application crashes shortly after starting.

AnswerD

BackOff means the kubelet is delaying a restart after a container exit, with the delay growing exponentially. Repeated events after startup indicate the process terminates on its own, typically from a crash or failed health check, rather than an image pull or scheduling failure.

Why this answer

The 'BackOff' event in Kubernetes indicates that the container has started but repeatedly crashes, causing the kubelet to increase the restart delay. Option D is correct because an application that crashes shortly after starting will trigger this restart loop, as the container exits with a non-zero exit code, leading to exponential backoff.

Exam trap

The KCNA exam often tests the distinction between 'ImagePullBackOff' (image not found) and 'CrashLoopBackOff' (container crashes after start), so candidates must recognize that 'BackOff' events after the container starts point to a runtime crash, not a pull failure.

How to eliminate wrong answers

Option A is wrong because if the image 'myapp:v2' does not exist, the pod would show 'ErrImagePull' or 'ImagePullBackOff' events, not 'BackOff' after the container starts. Option B is wrong because exceeding the memory limit causes an 'OOMKilled' status and a container restart, but the event would typically be 'OOMKilled' or 'CrashLoopBackOff', not specifically 'BackOff' after a successful start. Option C is wrong because a failing liveness probe results in the container being killed and restarted, but the event would be 'Unhealthy' or 'Liveness probe failed', and the pod would show 'CrashLoopBackOff' rather than 'BackOff' immediately after start.

Full explanation →

191

MCQmedium

Which of the following is a correct YAML structure for a Service of type ClusterIP?

A.apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: myapp ports: - port: 80

B.apiVersion: v1 kind: Pod metadata: name: my-service spec: selector: app: myapp ports: - port: 80

C.apiVersion: apps/v1 kind: Service metadata: name: my-service spec: selector: app: myapp ports: - port: 80

D.apiVersion: v1 kind: Service metadata: name: my-service spec: app: myapp ports: - port: 80

AnswerA

This manifest declares apiVersion v1, kind Service, and a spec containing a label selector plus a ports entry with port 80. Omitting type defaults to ClusterIP, so the structure is a valid ClusterIP Service definition.

Why this answer

It defines a Kubernetes Service of kind Service with apiVersion v1, which is the correct API group for core Service objects. The spec includes a selector to target pods with label app: myapp and a port mapping with port 80, which is the standard structure for a ClusterIP Service (the default type when type is omitted). The selector field is required to route traffic to matching pods, and the ports array correctly specifies the service port.

Exam trap

A common pitfall is confusing the apiVersion for core resources (v1) with that of named API groups (e.g., apps/v1). Candidates often mistakenly use apps/v1 for Services, or confuse the Service spec structure with that of a Pod or Deployment.

How to eliminate wrong answers

Option B is wrong because it uses kind: Pod instead of kind: Service, and Pods do not have a selector or ports field in their spec; these fields are specific to Service objects. Option C is wrong because it uses apiVersion: apps/v1, which is for resources like Deployments and StatefulSets, not Services; Services must use apiVersion: v1. Option D is wrong because it places app: myapp directly under spec instead of using a selector field; the selector is a required subfield of spec for Services to identify target pods, and omitting it means the Service will not route traffic to any pods.

Full explanation →

192

MCQmedium

Which log aggregation tool is designed specifically for Kubernetes and is often used as a lightweight alternative to Fluentd?

A.Logstash

B.Fluent Bit

C.Loki

D.Elasticsearch

AnswerB

Fluent Bit is a CNCF-hosted, C-based log processor and forwarder built for containerised environments, with a far smaller memory and CPU footprint than Fluentd. That lightweight design makes it the common Kubernetes alternative to Fluentd for node-level log collection.

Why this answer

Fluent Bit is a CNCF-graduated, lightweight log processor and forwarder written in C with a small memory footprint, explicitly designed for containerized and Kubernetes environments. It is commonly deployed as a DaemonSet to collect node and pod logs and forward them to backends like Elasticsearch, Loki, or S3. Its low resource usage makes it the standard 'lightweight alternative to Fluentd' in Kubernetes logging stacks.

Exam trap

The trap here is confusing the collector/forwarder role with the storage/backend role; candidates who know Loki or Elasticsearch from dashboards may pick them, forgetting the question asks for a lightweight log shipper designed for Kubernetes.

How to eliminate wrong answers

Option A is wrong because Logstash is a JVM-based, heavyweight log pipeline from the Elastic stack — it is not Kubernetes-specific and consumes far more memory than Fluent Bit, so it is not the lightweight alternative. Option C is wrong because Loki is a log aggregation/storage backend (like Elasticsearch) from Grafana Labs, not a log forwarder/collector — it receives logs rather than being the shipper. Option D is wrong because Elasticsearch is a search and analytics store used as a log backend, not a collector, and it is not lightweight nor Kubernetes-specific.

Full explanation →

193

MCQmedium

A developer wants to deploy a stateless web application that should maintain three running instances at all times. Which Kubernetes resource should they use?

A.Job

B.Deployment

C.StatefulSet

D.DaemonSet

AnswerB

A Deployment manages a ReplicaSet that continuously reconciles the pod count to three, restarting or replacing failed pods automatically. It suits stateless workloads, whereas StatefulSet adds stable identities and storage that this application does not require.

Why this answer

A Deployment is the correct resource because it manages a ReplicaSet to ensure a specified number of Pod replicas (in this case, three) are running at all times. It supports rolling updates and rollbacks, making it ideal for stateless web applications that require high availability and declarative scaling.

Exam trap

In the Kubernetes exam, candidates often confuse Deployment and StatefulSet. A common trap is selecting StatefulSet for any workload needing stable network identities or persistent storage, but for stateless web applications that simply require a fixed number of replicas and rolling updates, Deployment is the correct choice.

How to eliminate wrong answers

Option A is wrong because a Job is designed to run a finite task to completion (e.g., batch processing) and does not maintain a desired number of running instances. Option C is wrong because a StatefulSet is intended for stateful applications that require stable network identities and persistent storage, not for stateless web apps. Option D is wrong because a DaemonSet ensures that one Pod runs on each node (or a subset of nodes) in the cluster, which does not guarantee exactly three running instances regardless of node count.

Full explanation →

194

MCQhard

You create a Pod with a liveness probe that uses an HTTP GET on port 8080, path /healthz. The probe fails after the container starts. What will happen to the Pod?

A.The Pod will be marked as Unhealthy and removed from Service endpoints

B.The container will be restarted automatically

C.The Pod will be evicted from the node

D.The Pod will be deleted and recreated on a different node

AnswerB

A failing liveness probe signals the kubelet that the container is unhealthy. The kubelet kills that container and restarts it according to the pod's restartPolicy, rather than deleting the pod. This mechanism satisfies the stem's scenario of an HTTP GET probe failing after startup.

Why this answer

A liveness probe is designed to determine if a container is still running properly. When an HTTP GET liveness probe fails, kubelet considers the container unhealthy and automatically restarts it according to the Pod's restart policy (defaulting to Always). This ensures the container can recover from transient failures without manual intervention.

Exam trap

The trap here is confusing liveness probes with readiness probes: candidates often think a failing liveness probe removes the Pod from Service endpoints, but that is the job of a readiness probe, while liveness probes only trigger container restarts.

How to eliminate wrong answers

Option A is wrong because removing a Pod from Service endpoints is the behavior of a readiness probe, not a liveness probe; liveness probes only trigger container restarts. Option C is wrong because Pod eviction is caused by node-level issues like resource pressure or node failure, not by a failing liveness probe. Option D is wrong because the Pod is not deleted or recreated on a different node; the container is restarted in place on the same node.

Full explanation →

195

MCQmedium

You have a Deployment that manages 3 replicas of a web application. You want to perform a rolling update with zero downtime. Which kubectl command should you use?

A.kubectl set image deployment/myapp mycontainer=myimage:v2

B.kubectl delete pod myapp-xyz --grace-period=0

C.kubectl patch deployment myapp -p '{"spec":{"replicas":5}}'

D.kubectl rollout undo deployment/myapp

AnswerA

`kubectl set image` triggers the Deployment controller to create a new ReplicaSet and roll pods over incrementally, honouring maxUnavailable and maxSurge so capacity never drops to zero. This satisfies the stem's zero-downtime constraint, unlike editing a bare pod or scaling, which bypass the rolling-update mechanism entirely.

Why this answer

`kubectl set image deployment/myapp mycontainer=myimage:v2` triggers a rolling update on the Deployment, which by default creates a new ReplicaSet and gradually scales it up while scaling down the old ReplicaSet, ensuring zero downtime. The Deployment controller manages the update strategy (default: RollingUpdate) and maintains the desired number of replicas throughout the process.

Exam trap

The trap here is that candidates may confuse a simple pod deletion or scaling operation with a proper rolling update, or think that `rollout undo` is used to apply a new version instead of reverting to a previous one.

How to eliminate wrong answers

Option B is wrong because `kubectl delete pod myapp-xyz --grace-period=0` forcefully deletes a single pod, which does not perform a rolling update and can cause downtime if the pod is not immediately replaced by the ReplicaSet; it also bypasses the Deployment's update strategy. Option C is wrong because `kubectl patch deployment myapp -p '{"spec":{"replicas":5}}'` only scales the Deployment to 5 replicas, which does not update the container image and does not perform a rolling update. Option D is wrong because `kubectl rollout undo deployment/myapp` reverts the Deployment to a previous revision, which is used for rollback, not for performing a new rolling update.

Full explanation →

196

MCQeasy

Refer to the exhibit. How many containers are defined in this Pod?

A.2

B.1

C.3

D.0

AnswerA

The exhibit lists two distinct container specifications within the Pod's spec.containers array, so the Pod defines two containers. Each entry has its own name and image, and Kubernetes schedules them together in the shared network namespace, confirming the count of two.

Why this answer

The exhibit shows a Pod manifest with two container definitions under the `containers` field: one named `nginx` and one named `sidecar`. In Kubernetes, the number of containers in a Pod is determined by counting the entries in the `spec.containers` list, not including init containers or ephemeral containers unless explicitly specified. Therefore, the correct answer is 2.

Exam trap

The trap here is that candidates may miscount containers by including init containers or ephemeral containers, or mistakenly think the number of images referenced equals the number of containers, when the manifest explicitly lists only two containers in the `containers` array.

How to eliminate wrong answers

Option B is wrong because it assumes only one container is defined, but the manifest clearly lists two container entries under `spec.containers`. Option C is wrong because it suggests three containers, which would require a third entry in the `containers` list or additional init containers, neither of which is present. Option D is wrong because a Pod must have at least one container to be valid; the manifest explicitly defines two containers, so zero is incorrect.

Full explanation →

197

Multi-Selecthard

Which TWO of the following are characteristics of serverless computing?

Select 2 answers

A.Manual server provisioning

B.Long-running processes

C.Event-driven execution

D.Auto-scaling to zero when not in use

E.Reserved capacity for predictable workloads

AnswersC, D

Event-driven execution is intrinsic to serverless platforms: functions are invoked only in response to triggers such as HTTP requests, queue messages or object storage events, with no persistent process awaiting work. This satisfies the stem's characteristic requirement, since the platform scales from zero and bills per invocation rather than per allocated server.

Why this answer

Serverless computing is event-driven and auto-scales to zero when idle. Long-running processes are not suitable, and you do not manage the underlying servers. Reserved capacity is a concept for traditional cloud.

Full explanation →

198

Multi-Selecteasy

Which TWO of the following are benefits of using Helm for application delivery?

Select 2 answers

A.Automatic scaling based on CPU usage

B.Ability to roll back to previous releases

C.Automatic canary deployments

D.Simplified packaging and templating of Kubernetes resources

E.Built-in monitoring and alerting

AnswersB, D

Helm tracks each release as a revision, so helm rollback restores the previous manifest and Kubernetes objects. This gives deterministic recovery from a failed upgrade, satisfying the benefit of reverting to an earlier working release without manual reapplication.

Why this answer

Option B is correct because Helm maintains a release history for each chart installation, and the 'helm rollback <release> <revision>' command lets you revert a release to any prior revision, restoring the previously deployed Kubernetes manifests. Option D is correct because Helm packages Kubernetes resources into reusable charts and uses Go templating plus values files to parameterize manifests, which simplifies packaging, sharing, and customizing deployments across environments. Option A is not a Helm feature; automatic CPU-based scaling is provided by the Kubernetes Horizontal Pod Autoscaler, not by Helm itself.

Option C is not built into Helm; canary deployments require additional tooling such as Argo Rollouts, Flagger, or service-mesh traffic splitting. Option E is not provided by Helm; monitoring and alerting come from tools like Prometheus, Grafana, or Alertmanager, while Helm only manages manifest packaging and release lifecycle.

Exam trap

CNCF often tests the distinction between Helm's release management features and Kubernetes-native or third-party operational features, so candidates mistakenly attribute capabilities like autoscaling or canary deployments to Helm because they see Helm used in CI/CD pipelines alongside those tools.

Full explanation →

199

MCQmedium

A pod is stuck in 'Pending' state. You run 'kubectl describe pod mypod' and see the event '0/4 nodes are available: 4 Insufficient cpu'. What is the most likely cause?

A.The pod has exceeded its memory limit

B.The pod's image pull is failing

C.None of the nodes have enough CPU resources to satisfy the pod's request

D.The pod's liveness probe is failing

AnswerC

The scheduler cannot bind the pod because every node's allocatable CPU is below the pod's requested `resources.requests.cpu`. The event "4 Insufficient cpu" confirms all four nodes failed the CPU predicate during filtering, leaving no feasible node. This directly satisfies the stem's constraint: insufficient CPU capacity across the cluster.

Why this answer

The '0/4 nodes are available: 4 Insufficient cpu' event directly indicates that the Kubernetes scheduler attempted to place the pod on each of the four nodes but found that none had enough allocatable CPU capacity to satisfy the pod's CPU request (specified in the container's `resources.requests.cpu`). This causes the pod to remain in 'Pending' state because the scheduler cannot find a feasible node.

Exam trap

A common pitfall is confusing resource 'requests' (used for scheduling) with 'limits' (used for throttling/eviction). Candidates may mistakenly think 'Insufficient cpu' refers to CPU limits being exceeded, rather than the scheduler failing to find a node with enough free CPU to meet the request.

How to eliminate wrong answers

Option A is wrong because exceeding a memory limit causes a pod to be terminated (OOMKilled) or evicted, not stuck in 'Pending' state with an 'Insufficient cpu' event. Option B is wrong because image pull failures generate events like 'Failed to pull image' or 'ErrImagePull', not a node-level scheduling failure. Option D is wrong because liveness probe failures occur after the pod is already running (affecting the 'Running' state), not during scheduling when the pod is still 'Pending'.

Full explanation →

200

MCQhard

When using a Service of type ClusterIP, how do pods reach the service?

A.Via the service's cluster IP and port

B.Via the node's IP address and a high port

C.Via an external load balancer

D.Directly via the pod's IP address

AnswerA

ClusterIP assigns a stable virtual IP; kube-proxy programs iptables or IPVS rules on each node so traffic sent to that IP and port is load-balanced to a backing pod. DNS resolves the service name to this address.

Why this answer

A Service of type ClusterIP exposes a stable virtual IP (the cluster IP) and port within the cluster. Pods reach the Service by sending traffic to this cluster IP and port, which is then load-balanced by kube-proxy (using iptables, IPVS, or eBPF rules) to one of the backing pod endpoints. This is the default and most fundamental Service type in Kubernetes.

Exam trap

CNCF often tests the misconception that ClusterIP Services are only reachable from within the same pod or node, when in fact they are reachable from any pod in the cluster (across nodes) via the cluster IP, thanks to kube-proxy's distributed routing rules.

How to eliminate wrong answers

Option B is wrong because reaching a Service via the node's IP address and a high port is the behavior of a NodePort Service, not ClusterIP. Option C is wrong because an external load balancer is used by a LoadBalancer Service, which is built on top of NodePort and ClusterIP, not by ClusterIP itself. Option D is wrong because pods do not reach the Service directly via a pod's IP address; that would bypass the Service abstraction and load balancing, and the Service's cluster IP is the intended stable endpoint.

Full explanation →

201

MCQmedium

A Deployment is created with `replicas: 3`. After applying the manifest, only 2 pods are running and one is in Pending state. What is the most likely reason?

A.The Service selector does not match

B.The Deployment name is misspelled

C.There are insufficient resources on the nodes

D.The container image is invalid

AnswerC

The scheduler leaves a pod Pending when no node has enough allocatable CPU or memory to satisfy its requests. Insufficient cluster resources prevent the third replica from being placed, while the other two run normally.

Why this answer

When a Pod remains in Pending state, it means the scheduler cannot find a node that satisfies the Pod's resource requirements (CPU, memory, or other constraints). Since two Pods are running successfully, the Deployment configuration (image, name, selector) is valid, and the issue is that the cluster lacks sufficient capacity to schedule the third replica. The scheduler continuously evaluates node resources and will leave the Pod pending until resources become available or the request is adjusted.

Exam trap

CNCF often tests the distinction between Pod lifecycle phases (Pending vs. CrashLoopBackOff vs. ImagePullBackOff) to see if candidates confuse scheduling failures with runtime or image errors.

How to eliminate wrong answers

Option A is wrong because a Service selector mismatch would not cause a Pod to be in Pending state; it would affect traffic routing but not Pod scheduling or creation. Option B is wrong because a misspelled Deployment name would cause the manifest to fail at creation time or create a separate resource, not result in a partially running Deployment with two Pods. Option D is wrong because an invalid container image would cause the Pod to enter ImagePullBackOff or ErrImagePull state, not Pending; Pending occurs before the container runtime attempts to pull the image.

Full explanation →

202

MCQeasy

Which component on a worker node is responsible for enforcing the desired state of pods as defined in the pod specification?

A.kube-scheduler

B.kube-proxy

C.container runtime

D.kubelet

AnswerD

The kubelet runs as an agent on each worker node, watching the API server for PodSpecs bound to its node. It then starts containers via the container runtime and continuously reconciles actual state to the desired state, restarting or stopping pods as needed.

Why this answer

The kubelet is the primary node agent that runs on each worker node and is responsible for ensuring that containers are running in a pod as specified by the pod's manifest (PodSpec). It continuously monitors pod status and takes corrective actions, such as restarting containers or re-creating pods, to match the desired state defined in the Kubernetes API.

Exam trap

The trap here is that candidates often confuse the kubelet's role with the container runtime or kube-scheduler, assuming that running containers automatically enforces the desired state, when in fact the kubelet is the only component that actively reconciles the actual state with the PodSpec.

How to eliminate wrong answers

Option A is wrong because the kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints, but it does not enforce the desired state of pods on a worker node. Option B is wrong because kube-proxy handles network rules and load balancing for services on each node, not pod lifecycle management or state enforcement. Option C is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for pulling images and running containers, but it does not interpret the PodSpec or enforce the desired state; that is the kubelet's job.

Full explanation →

203

MCQhard

A pod is stuck in 'Pending' state. Which of the following is NOT a common cause for a pod to remain Pending?

A.Insufficient CPU or memory resources available in the cluster

B.The node selector in the pod spec does not match any node labels

C.The container runtime is not functioning on the node

D.The pod's PVC is not yet bound to a PV

AnswerC

A non-functioning container runtime produces container creation or start failures on an already-scheduled node, typically surfacing as 'ContainerCreating' or 'CrashLoopBackOff', not 'Pending'. Pending specifically indicates the scheduler cannot bind the pod, driven by insufficient resources, unsatisfied node selectors or affinity, or unbound PersistentVolumeClaims.

Why this answer

A non-functioning container runtime on a node typically results in pod states like CrashLoopBackOff or Error, not prolonged 'Pending' state. Pending state occurs when a pod cannot be scheduled. Insufficient resources (A), node selector mismatch (B), and unbound PVCs (D) are common causes of scheduling failures that keep a pod in Pending.

Container runtime issues affect pod execution after scheduling, not the scheduling process itself. Therefore, C is NOT a common cause for a pod to remain Pending.

Exam trap

Candidates often confuse issues that affect pod scheduling with those that affect pod execution. Container runtime problems cause pods to fail after starting, not to remain in Pending state. The question tests understanding of which conditions prevent scheduling vs. those that impact running pods.

How to eliminate wrong answers

Option A is wrong because insufficient CPU or memory resources in the cluster is a common cause for a pod to remain in 'Pending' state, as the scheduler cannot find a node with enough free resources to place the pod. Option C is wrong because a non-functioning container runtime on a node will cause the pod to stay 'Pending' if the node is the only candidate, as the kubelet cannot start containers; however, this is a less common but valid cause. Option D is wrong because an unbound PVC (PersistentVolumeClaim) is a classic reason for a pod to be stuck in 'Pending', as the scheduler waits for the volume to be bound before proceeding with pod placement.

Full explanation →

204

Multi-Selecthard

Which THREE are valid ways to provide configuration data to a pod in Kubernetes?

Select 3 answers

A.Use an init container to write configuration to a shared volume

B.Mount a ConfigMap as a volume

C.Mount a Secret as a volume

D.Hardcode environment variables in the pod spec that contain sensitive data

E.Use environment variables from a ConfigMap

AnswersB, C, E

ConfigMaps can be mounted as files in a pod.

Why this answer

A ConfigMap is a Kubernetes API object designed to store non-confidential configuration data in key-value pairs. Mounting a ConfigMap as a volume makes its data available as files in the pod's filesystem, allowing applications to read configuration without hardcoding it into the container image or pod spec. This approach decouples configuration from containerized applications, following the principle of immutable infrastructure.

Exam trap

The KCNA exam often tests the misconception that any method of injecting data into a pod is a 'valid' configuration approach, but the KCNA exam expects you to recognize that only native Kubernetes API objects (ConfigMaps and Secrets) are the recommended and valid ways to provide configuration data, rejecting ad-hoc methods like init container scripts or hardcoded values.

Full explanation →

205

MCQeasy

Which Kubernetes primitive is the smallest and simplest unit in the Kubernetes object model that you can create or deploy?

A.ReplicaSet

B.Pod

C.Deployment

D.Container

AnswerB

A Pod is the atomic scheduling unit: one or more containers sharing a network namespace and storage volumes, always co-located on a single node. It is the smallest deployable object, so it satisfies the stem's constraint of being the simplest creatable unit.

Why this answer

B is correct because a Pod is the smallest and simplest unit in the Kubernetes object model. It represents a single instance of a running process in a cluster and can contain one or more containers that share the same network namespace, storage volumes, and lifecycle. You create and deploy Pods directly, while higher-level controllers like ReplicaSets and Deployments manage Pods as their fundamental building block.

Exam trap

The trap here is that candidates often confuse 'Container' as the smallest unit because they think of Docker containers, but Kubernetes abstracts containers into Pods, and you cannot deploy a container directly without a Pod wrapper.

How to eliminate wrong answers

Option A is wrong because a ReplicaSet is a higher-level controller that ensures a specified number of Pod replicas are running at all times; it is not the smallest or simplest unit, as it depends on Pods. Option C is wrong because a Deployment is an even higher-level abstraction that manages ReplicaSets and Pods, providing declarative updates and rollbacks; it is not the smallest deployable unit. Option D is wrong because a Container is not a Kubernetes object; it is a runtime instance of a container image that runs inside a Pod, and Kubernetes does not allow you to create or deploy a Container directly as a standalone object.

Full explanation →

206

Multi-Selecthard

A team is evaluating whether their application qualifies as cloud-native. They want to identify characteristics that are central to cloud-native architecture rather than incidental implementation details. Which TWO of the following are core characteristics of cloud-native architecture? (Choose two.)

Select 2 answers

A.Declarative configuration and automated management

B.Manual, ticket-driven provisioning of production servers

C.Tight coupling between services to reduce network calls

D.Resilience through fault tolerance and graceful degradation

E.Vendor-specific, proprietary APIs for all internal communication

AnswersA, D

Declarative configuration expresses the desired state, and automation continuously reconciles actual state to match it. This is central to cloud-native architecture because it enables reproducible deployments, self-healing, and scalable operations. Kubernetes controllers and GitOps workflows are common examples. This characteristic directly reflects how cloud-native systems are managed rather than an incidental detail.

Why this answer

Declarative configuration with automated management and resilience through fault tolerance and graceful degradation are core cloud-native characteristics. They shape how systems are defined, reconciled, and kept running under failure. Manual provisioning, tight coupling, and exclusive reliance on proprietary APIs work against portability, automation, and independent operation, so they are not central characteristics of cloud-native architecture.

Exam trap

The trap here is selecting operational conveniences or performance optimizations, such as reducing network calls through tight coupling, instead of the architectural principles that define cloud-native systems.

Full explanation →

207

MCQeasy

What is the primary purpose of Prometheus in cloud native observability?

A.Provide distributed tracing

B.Visualize data

C.Collect and store logs

D.Collect and store metrics

AnswerD

Prometheus scrapes time-series metrics from instrumented targets and stores them in its local TSDB, directly fulfilling observability's metrics pillar. This satisfies the stem's requirement for the primary purpose: pulling and retaining numeric measurements for querying and alerting, rather than handling logs or distributed traces.

Why this answer

Prometheus is an open-source monitoring and alerting toolkit designed specifically for collecting and storing time-series metrics. It scrapes metrics from instrumented targets via HTTP endpoints, stores them in a time-series database, and supports powerful querying with PromQL. Its primary purpose in cloud native observability is metrics collection and storage, not tracing, visualization, or log aggregation.

Exam trap

KCNA often tests the distinction between the three pillars of observability — metrics (Prometheus), logs (Loki/Elasticsearch), and traces (Jaeger) — and candidates may confuse Prometheus with visualization tools like Grafana.

How to eliminate wrong answers

Option A is wrong because distributed tracing is handled by tools like Jaeger, Zipkin, or OpenTelemetry, not Prometheus. Option B is wrong because visualization is typically done by Grafana or the Prometheus expression browser, not by Prometheus itself as its primary purpose. Option C is wrong because log collection and storage is the domain of tools like Fluentd, Loki, or Elasticsearch, not Prometheus.

Full explanation →

208

Multi-Selectmedium

Which THREE of the following are true about container lifecycle? (Choose 3)

Select 3 answers

A.A container can be paused and resumed

B.A container can be hibernated to save state to disk

C.A container goes through a 'built' phase before running

D.A container terminates when its main process exits

E.A container can be stopped and later restarted

AnswersA, D, E

Pausing freezes all processes in the container's cgroup via the freezer, and resuming unfreezes them, so state is preserved without a restart. This satisfies the lifecycle claim that a running container can be suspended and later continued.

Why this answer

Option A is correct because container runtimes such as Docker support pausing a running container (e.g., `docker pause`), which freezes all processes via the cgroup freezer, and resuming it later with `docker unpause`. Option D is correct because a container's lifecycle is tied to its main process (PID 1); when that process exits, the container terminates and its writable layer stops. Option E is correct because a stopped container retains its filesystem and configuration, allowing it to be restarted later with `docker start`, resuming the same container instance.

Option B is not correct because containers do not hibernate state to disk the way virtual machines or operating systems do; there is no standard container hibernation mechanism. Option C is not correct because 'built' is a phase of creating an image, not a container lifecycle stage; containers are created and then started, not built.

Exam trap

KCNA often tests the container-vs-VM lifecycle boundary — candidates who transfer VM concepts like hibernation or 'built phase' onto containers pick the wrong options.

Full explanation →

209

Multi-Selectmedium

Which TWO of the following are characteristics of Kustomize?

Select 2 answers

A.Requires a values.yaml file for configuration

B.Uses a templating engine similar to Helm

C.Supports patching resources via patchesStrategicMerge

D.Can manage dependencies between charts

E.Uses overlays to customize base configurations

AnswersC, E

Kustomize applies patchesStrategicMerge to merge partial resource definitions onto base manifests, modifying only the fields specified. This strategic merge behaviour distinguishes it from templating engines, satisfying the requirement for patching existing resources without altering the originals.

Why this answer

Option C is correct because Kustomize natively supports patchesStrategicMerge, a strategic merge patch mechanism that lets you modify specific fields of base Kubernetes resources without rewriting the whole manifest. Option E is correct because Kustomize's core model is bases plus overlays: a base holds common resources, and overlays apply environment-specific customizations on top of it. Option A is wrong because values.yaml is a Helm convention; Kustomize uses kustomization.yaml files instead.

Option B is wrong because Kustomize is explicitly template-free and works by merging and patching YAML rather than rendering Go templates like Helm. Option D is wrong because chart dependency management is a Helm feature, not a Kustomize capability.

Exam trap

KCNA often tests the Helm vs. Kustomize distinction — candidates incorrectly assume Kustomize uses templating or values.yaml because they conflate the two tools.

Full explanation →

210

MCQhard

You are asked to deploy a Kubernetes service that exposes a set of pods internally within the cluster only. The service should not be accessible from outside the cluster. Which Service type should you choose?

A.ClusterIP

B.NodePort

C.ExternalName

D.LoadBalancer

AnswerA

ClusterIP assigns a virtual IP reachable only from within the cluster, satisfying the internal-only constraint. Unlike NodePort or LoadBalancer, it provisions no external listener or cloud load balancer, so pods remain unexposed outside the cluster network.

Why this answer

ClusterIP is the default Kubernetes Service type that exposes the service on a cluster-internal IP address. This makes the service reachable only from within the cluster, which is exactly what is required for internal-only communication between pods. No external traffic can reach a ClusterIP service unless an ingress controller or proxy is explicitly configured.

Exam trap

CNCF often tests the misconception that ClusterIP is only for inter-pod communication within the same namespace, but it actually works across all namespaces within the cluster, and the trap is that candidates confuse it with NodePort when they think 'internal only' means 'no external access' but forget that NodePort inherently opens external access.

How to eliminate wrong answers

Option B is wrong because NodePort exposes the service on a static port on each node's IP address, making it accessible from outside the cluster via <NodeIP>:<NodePort>. Option C is wrong because ExternalName maps a service to a DNS name (via CNAME records) and does not expose pods internally; it is used to provide an alias for an external service. Option D is wrong because LoadBalancer provisions an external load balancer (e.g., from a cloud provider) and assigns a public IP, making the service accessible from outside the cluster.

Full explanation →

211

MCQeasy

What is the primary purpose of the Open Container Initiative (OCI)?

A.To provide a container runtime called Docker

B.To create a container orchestration platform

C.To define the Kubernetes Container Runtime Interface (CRI)

D.To standardize container image and runtime specifications

AnswerD

The OCI publishes the image-spec and runtime-spec, defining a common image format and runtime behaviour so any compliant runtime can run any compliant image. This standardisation prevents vendor lock-in and guarantees portability across container tooling.

Why this answer

The Open Container Initiative (OCI) is an open governance structure that standardizes container image and runtime specifications. It ensures that any OCI-compliant image can run on any OCI-compliant runtime, promoting interoperability across the container ecosystem. This is the core purpose, not to provide a specific runtime or orchestration tool.

Exam trap

The CNCF exam often tests the distinction between a standard (OCI) and an implementation (Docker, containerd), so candidates mistakenly associate the OCI with Docker or Kubernetes rather than its role as a neutral specification body.

How to eliminate wrong answers

Option A is wrong because Docker is a specific container runtime and toolset, not the purpose of the OCI; the OCI standardizes specifications, not a particular implementation. Option B is wrong because container orchestration platforms like Kubernetes are separate projects; the OCI focuses on low-level image and runtime standards, not orchestration. Option C is wrong because the Kubernetes Container Runtime Interface (CRI) is a Kubernetes-specific plugin interface for runtimes, while the OCI defines the broader industry standard for container formats and runtimes.

Full explanation →

212

MCQeasy

Which control plane component is responsible for assigning pods to nodes?

A.etcd

B.kube-apiserver

C.kube-scheduler

D.kube-controller-manager

AnswerC

kube-scheduler watches for newly created pods with no assigned node and selects a suitable node based on resource requests, affinity and taints. This satisfies the assignment responsibility, unlike kubelet, which only runs pods already bound to its node.

Why this answer

The kube-scheduler is the control plane component responsible for assigning pods to nodes. It watches for newly created pods that have no node assignment and selects an optimal node for each pod based on resource requirements, constraints, policies, and data locality. The scheduler does not actually run the pod; it updates the pod's `nodeName` field via the API server, which then triggers the kubelet on the chosen node to launch the pod.

Exam trap

A common misconception is that kube-apiserver handles scheduling because it is the central API gateway, but the scheduler is a distinct component that runs the scheduling algorithm and communicates with the API server to bind pods to nodes.

How to eliminate wrong answers

Option A is wrong because etcd is a distributed key-value store that holds the cluster state, not a component that makes scheduling decisions. Option B is wrong because kube-apiserver is the front-end for the Kubernetes control plane that exposes the API and validates requests, but it does not assign pods to nodes. Option D is wrong because kube-controller-manager runs controller processes like the node controller and replication controller, but it does not handle pod-to-node assignment; that is the sole responsibility of the scheduler.

Full explanation →

213

MCQhard

An SRE team defines an SLO that 99.9% of requests to a service should complete in under 500ms over a 30-day rolling window. If the service receives 10 million requests in a month, what is the maximum number of requests that can exceed the latency threshold while still meeting the SLO?

A.10,000

B.5,000

C.1,000

D.100,000

AnswerA

A 99.9% SLO permits 0.1% of requests to breach the 500ms latency threshold. With 10 million monthly requests, that error budget equals 10,000,000 × 0.001 = 10,000 requests. This satisfies the 30-day rolling window constraint exactly, leaving no headroom beyond the defined tolerance.

Why this answer

An SLO of 99.9% means 0.1% of requests may violate the latency threshold. With 10,000,000 requests, 0.1% equals 10,000 requests. This is the error budget for the 30-day rolling window.

Exam trap

KCNA often tests SLO math — candidates miscalculate the error budget by misplacing the decimal (e.g., treating 99.9% as 0.01% instead of 0.1%).

How to eliminate wrong answers

Option B (5,000) is wrong because it corresponds to 99.95%, not 99.9%. Option C (1,000) is wrong because it corresponds to 99.99%, a stricter SLO. Option D (100,000) is wrong because it corresponds to 99%, a looser SLO.

Only 10,000 matches the 0.1% error budget for 99.9%.

Full explanation →

214

Multi-Selectmedium

Which THREE of the following are valid use cases for Kubernetes Namespaces? (Select 3)

Select 3 answers

A.To enforce resource quotas and limits on the resources within the namespace

B.To create separate environments like development, staging, and production in the same cluster

C.To isolate cluster-wide resources such as Nodes and PersistentVolumes

D.To improve performance by reducing network latency between Pods

E.To separate resources for different teams or projects within a single cluster

AnswersA, B, E

ResourceQuota and LimitRange objects are scoped to a namespace, so quotas and default limits apply only to workloads inside it. This satisfies the need to cap aggregate CPU, memory and object counts per team or environment.

Why this answer

Option A is correct because Namespaces are the scope at which Kubernetes ResourceQuota and LimitRange objects are applied, letting administrators cap aggregate CPU/memory/storage consumption and enforce per-container defaults for all workloads inside that namespace. Option B is correct because a single cluster can host distinct dev, staging, and production environments as separate Namespaces, each with its own objects, RBAC, and quotas, without provisioning additional clusters. Option E is correct because Namespaces provide logical partitioning so multiple teams or projects can share one cluster while keeping their Pods, Services, ConfigMaps, and Secrets scoped and access-controlled independently.

Option C is incorrect because Nodes and PersistentVolumes are cluster-scoped resources that live outside any Namespace and cannot be isolated by one. Option D is incorrect because Namespaces are purely a logical/API-scoping construct and have no effect on the data plane, so they do not reduce network latency between Pods.

Exam trap

A common trap in the Kubernetes exam is that candidates mistakenly think namespaces can isolate cluster-wide resources like Nodes or PersistentVolumes, but these are not namespaced and cannot be scoped to a namespace.

Full explanation →

215

MCQmedium

You have two pods in different namespaces that need to communicate using a stable IP address. Which Kubernetes object provides a stable endpoint for a set of pods?

A.ConfigMap

B.Ingress

C.Service

D.Deployment

AnswerC

A Service provides a stable virtual IP and DNS name that load-balances across selected pods, independent of individual pod IPs. This satisfies cross-namespace communication by giving a consistent endpoint, provided the Service is reachable from the other namespace.

Why this answer

A Kubernetes Service provides a stable IP address and DNS name that remains constant regardless of pod restarts or rescheduling, enabling reliable communication between pods in different namespaces. Unlike pods, which have ephemeral IPs, a Service selects a set of pods via label selectors and load-balances traffic to them, ensuring a stable endpoint across namespace boundaries.

Exam trap

A common misconception is that a Deployment itself provides a stable network endpoint, but a Deployment only manages pod lifecycle; the Service object is required to expose those pods with a fixed IP and DNS name.

How to eliminate wrong answers

Option A is wrong because a ConfigMap is used to store configuration data as key-value pairs, not to provide network endpoints or stable IPs for pod communication. Option B is wrong because an Ingress manages external HTTP/HTTPS traffic routing to Services, but it does not itself provide a stable internal IP; it relies on a Service for that purpose. Option D is wrong because a Deployment manages pod replicas and updates, but it does not expose a stable IP; pods managed by a Deployment have dynamic IPs that change on restart, so a Service is needed for a stable endpoint.

Full explanation →

216

MCQhard

You need to run a stateful application that requires stable network identities and persistent storage per pod. Which Kubernetes resource is BEST suited?

A.DaemonSet

B.StatefulSet

C.Job

D.Deployment

AnswerB

StatefulSet assigns each pod a stable ordinal hostname and its own PersistentVolumeClaim, so replicas keep predictable DNS names and storage across restarts. This directly satisfies the stem's requirement for stable network identities and per-pod persistent storage, which a Deployment's interchangeable pods cannot provide.

Why this answer

StatefulSet is the correct choice because it is specifically designed for stateful applications that require stable, unique network identifiers (e.g., pod names like `web-0`, `web-1`) and persistent storage that persists across pod rescheduling. Each pod in a StatefulSet gets a dedicated PersistentVolumeClaim, and the ordinal index ensures consistent identity, which is critical for databases like Cassandra or MySQL.

Exam trap

A common misconception is that Deployment can handle stateful workloads by using PersistentVolumeClaims, but Deployment pods lack stable identities and ordered startup/shutdown, which are essential for many stateful applications.

How to eliminate wrong answers

Option A is wrong because DaemonSet ensures one pod per node for cluster-wide services (e.g., logging agents), but it does not guarantee stable network identities or per-pod persistent storage. Option C is wrong because Job is intended for batch processing tasks that run to completion, not for long-running stateful applications requiring stable storage and identity. Option D is wrong because Deployment provides stateless, interchangeable pods with random names and shared or ephemeral storage, making it unsuitable for applications that require stable network identities and persistent storage per pod.

Full explanation →

217

Multi-Selectmedium

Which THREE are examples of DORA metrics used to measure DevOps performance? (Choose 3)

Select 3 answers

A.Deployment Frequency

B.Number of developers per team

C.Code coverage percentage

D.Mean Time to Restore (MTTR)

E.Lead Time for Changes

AnswersA, D, E

Deployment Frequency directly measures how often code reaches production, satisfying the stem's requirement for a DORA metric. It belongs to the throughput axis, alongside lead time for changes, distinguishing it from stability metrics such as change failure rate and mean time to restore. Accelerate's research identifies it as a core predictor of DevOps performance.

Why this answer

Deployment Frequency (A) is correct because DORA's Accelerate research defines it as how often an organization successfully releases to production, measuring delivery throughput. Mean Time to Restore (D) is correct because DORA uses it to measure how quickly service is restored after an incident or failed deployment, capturing operational stability. Lead Time for Changes (E) is correct because DORA measures the time from code commit to code successfully running in production, reflecting delivery speed.

The other options do not belong: Number of developers per team (B) is a staffing metric, not a DORA performance measure, and Code coverage percentage (C) is a code-quality/testing metric that DORA does not include among its four key metrics (which are Deployment Frequency, Lead Time for Changes, Change Failure Rate, and MTTR).

Exam trap

KCNA often tests the confusion between DORA metrics and other common DevOps or code quality metrics, so candidates who see 'code coverage' or 'team size' and assume they are DORA metrics pick the wrong answers.

Full explanation →

218

Multi-Selectmedium

Which two of the following are characteristics of container images built using OCI standards? (Choose two.)

Select 2 answers

A.They are portable across different container runtimes

B.They are composed of layers that can be cached and reused

C.They include a full guest operating system

D.They can only be run by Docker

E.They require a hypervisor to run

AnswersA, B

OCI image specifications define a runtime-agnostic manifest and filesystem bundle, so any compliant runtime (Docker, containerd, CRI-O) can pull and execute the same image. This portability satisfies the stem's requirement by decoupling the artefact from a single vendor's engine.

Why this answer

Option A is correct because OCI (Open Container Initiative) image specifications define a runtime-agnostic format, so an image built to OCI standards can be pulled and executed by any OCI-compliant runtime such as containerd, CRI-O, or Docker, not just one vendor's engine. Option B is correct because OCI images are built as a stack of content-addressable layers, each identified by a digest, which allows runtimes and registries to cache and reuse unchanged layers across builds and pulls, reducing storage and transfer overhead. Option C is incorrect because containers share the host kernel and do not bundle a full guest operating system; that characteristic belongs to virtual machines.

Option D is incorrect because OCI compliance explicitly enables portability beyond Docker to other runtimes like containerd and CRI-O. Option E is incorrect because containers run directly on the host kernel via namespaces and cgroups, requiring no hypervisor (except in specialized VM-isolated setups, which are not the norm for OCI images).

Exam trap

KCNA often tests the misconception that containers are 'lightweight VMs' — candidates pick 'full guest OS' or 'requires hypervisor' because they conflate container isolation with virtualization.

Full explanation →

219

Multi-Selectmedium

A team is implementing observability for a cloud native application. They want to adopt OpenTelemetry to instrument their code and collect telemetry data. Which TWO of the following are core components of the OpenTelemetry project? (Choose two.)

Select 2 answers

A.Fluentd

B.OpenTelemetry API

C.Jaeger Backend

D.Prometheus Server

E.OpenTelemetry Collector

AnswersB, E

The OpenTelemetry API provides the interfaces and data types for instrumenting code to generate telemetry. It defines how to create spans, metrics, and logs, and is implemented by SDKs. It is a fundamental building block, as it allows developers to instrument their applications in a vendor-neutral way. Without the API, there would be no standard way to emit telemetry.

Why this answer

OpenTelemetry consists of several core components, including the API, SDK, and Collector. The API defines the instrumentation interfaces, while the SDK provides the implementation. The Collector is a standalone service that receives, processes, and exports telemetry.

Together, these components enable vendor-neutral collection of metrics, logs, and traces. Prometheus, Jaeger, and Fluentd are separate projects that can integrate with OpenTelemetry but are not part of it.

Exam trap

The trap here is assuming that any popular observability tool is part of OpenTelemetry; instead, OpenTelemetry defines its own API, SDK, and Collector, while backends like Jaeger and Prometheus are external.

Full explanation →

220

MCQmedium

A platform team uses Argo CD to manage a Kubernetes cluster. A developer manually edits a Deployment's replica count from 3 to 5 using kubectl, bypassing Git. Argo CD detects the drift and its sync policy is set to automated with self-heal enabled. What happens next?

A.Argo CD marks the application as OutOfSync but takes no action because self-heal is disabled.

B.Argo CD deletes the Deployment and recreates it from the Git manifest.

C.Argo CD reverts the replica count back to the value defined in Git.

D.Argo CD updates the Git repository to match the live cluster state.

AnswerC

With automated sync and self-heal enabled, Argo CD continuously compares the live cluster state to the desired state stored in Git. When it detects that the Deployment's replica count was manually changed to 5, which diverges from the Git-declared value of 3, it automatically applies the Git version, restoring the replica count to 3. This enforces Git as the single source of truth.

Why this answer

When Argo CD's automated sync policy includes self-heal, it automatically reverts any manual changes to the cluster that deviate from the Git repository. In this case, the developer's manual scaling to 5 replicas is undone, and the Deployment is restored to the Git-defined 3 replicas. This ensures Git remains the single source of truth and prevents configuration drift.

Exam trap

The trap here is assuming Argo CD writes changes back to Git; it only reconciles the cluster to match Git.

Full explanation →

221

MCQeasy

You are deploying a stateful application that requires each pod to have a stable, unique network identity and its own persistent storage. Which Kubernetes resource should you use?

A.DaemonSet

B.ReplicaSet

C.Deployment

D.StatefulSet

AnswerD

StatefulSet is designed for stateful applications, providing stable, unique network identifiers (like pod-0, pod-1) and stable persistent storage per pod via volumeClaimTemplates. Each pod gets its own PVC, and the pod's hostname and storage are preserved across rescheduling. This makes StatefulSet ideal for databases, message queues, and other stateful workloads that require stable identity and storage.

Why this answer

StatefulSet is the correct resource for stateful applications because it provides stable network identities and persistent storage per pod. Each pod in a StatefulSet gets a unique ordinal index, a stable hostname, and its own PersistentVolumeClaim. Deployments, DaemonSets, and ReplicaSets are designed for stateless workloads and do not offer these guarantees.

Exam trap

The trap here is assuming that a Deployment can provide per-pod persistent storage, but Deployments share a single PVC across all replicas if specified, which is not suitable for stateful applications.

Full explanation →

222

MCQhard

A Kubernetes cluster has two nodes: control-plane and worker. The worker node runs several pods. The control-plane node becomes unreachable. What is the immediate impact on the pods running on the worker node?

A.All pods are immediately terminated

B.Pods continue running, but new pods cannot be scheduled

C.Pods are rescheduled to the control-plane node

D.The worker node is automatically cordoned

AnswerB

Pods keep running because kubelet on the worker node maintains their containers independently of the control-plane; the API server's absence only prevents scheduling decisions, so no new pods can be placed. This satisfies the stem's immediate-impact constraint: existing workloads survive, while scheduling halts until the control-plane returns.

Why this answer

When the control-plane node becomes unreachable, the kube-controller-manager cannot communicate with the kubelet on the worker node, so it stops performing scheduling and reconciliation. However, the kubelet on the worker node continues to run existing pods based on the last known desired state stored locally, and the pods themselves are managed by the container runtime (e.g., containerd) independently of the control-plane. Therefore, pods continue running normally, but no new pods can be scheduled because the scheduler, which runs on the control-plane, is unavailable.

Exam trap

The trap here is that candidates often assume the control-plane is required for all pod operations, confusing the control-plane's role in scheduling and reconciliation with the kubelet's independent ability to maintain running workloads, leading them to choose immediate termination or automatic rescheduling.

How to eliminate wrong answers

Option A is wrong because pods are not immediately terminated; the kubelet on the worker node continues to maintain running pods even without contact with the control-plane, as the pod lifecycle is managed locally. Option C is wrong because pods cannot be rescheduled to the control-plane node; the control-plane node is typically tainted (e.g., node-role.kubernetes.io/control-plane:NoSchedule) to prevent workload pods from running on it, and the scheduler is unavailable to make such decisions. Option D is wrong because the worker node is not automatically cordoned; cordoning is a manual or scheduler-driven action that marks a node as unschedulable, but the control-plane being unreachable does not trigger an automatic cordon of the worker node.

Full explanation →

223

MCQmedium

You have a Pod that is in 'Pending' state. What is the most likely cause?

A.The node is out of CPU or memory resources.

B.The application inside the container crashed.

C.The container image is missing.

D.The Service does not have any endpoints.

AnswerA

The scheduler cannot place a pod when no node has sufficient allocatable CPU or memory. Unschedulable pods remain Pending rather than being assigned to a node, making resource exhaustion the most common cause of this state.

Why this answer

A Pod in 'Pending' state indicates that the scheduler has not yet assigned it to a node. The most common reason is insufficient resources (CPU or memory) on any available node, causing the scheduler to fail to find a suitable node that meets the Pod's resource requests. This is a core scheduling failure in Kubernetes.

Exam trap

CNCF often tests the distinction between Pod lifecycle states, and the trap here is confusing 'Pending' (pre-scheduling) with post-scheduling failures like image pull errors or container crashes, which have distinct states (e.g., ImagePullBackOff, CrashLoopBackOff).

How to eliminate wrong answers

Option B is wrong because a container crash (e.g., application exit code non-zero) results in a 'CrashLoopBackOff' or 'Error' state, not 'Pending'. Option C is wrong because a missing container image causes the Pod to enter 'ImagePullBackOff' or 'ErrImagePull' state after scheduling, not 'Pending'. Option D is wrong because a Service lacking endpoints does not affect Pod scheduling; it is a networking issue that affects service discovery, not the Pod's lifecycle state.

Full explanation →

224

MCQeasy

Which of the following is a key benefit of container orchestration?

A.Manual scaling of applications

B.Requires manual intervention for pod failures

C.Only supports monolithic applications

D.Automated scaling, self-healing, and declarative management

AnswerD

Orchestrators such as Kubernetes continuously reconcile observed state against declared manifests, automatically restarting failed containers and scaling replicas to match load. This declarative control loop delivers self-healing and elastic scaling, which are the defining operational benefits over manually managed containers.

Why this answer

Container orchestration platforms like Kubernetes provide automated scaling (HPA/VPA/cluster autoscaler), self-healing (restarting failed containers, rescheduling pods, replacing unhealthy nodes), and declarative management (desired-state YAML reconciled by controllers). These three capabilities are the defining value proposition that distinguishes orchestration from manually running `docker run` commands.

Exam trap

KCNA often tests the contrast between orchestration's automated, declarative model and manual/imperative alternatives, so distractors describing manual scaling or manual failure recovery are designed to catch candidates who don't internalize the 'automated + declarative' framing.

How to eliminate wrong answers

Option A is wrong because manual scaling is precisely what orchestration eliminates — orchestration automates scaling via metrics-driven controllers, not manual intervention. Option B is wrong because requiring manual intervention for pod failures is the opposite of orchestration's self-healing behavior; controllers like ReplicaSet and Deployment automatically recreate failed pods. Option C is wrong because orchestration platforms are designed for microservices and support diverse workloads (stateless, stateful, batch, DaemonSets), not just monoliths.

Full explanation →

225

MCQmedium

A service of type ClusterIP is created but pods cannot reach it using the service name. The pods are in the same namespace. What is a likely cause?

A.The service is not exposed externally

B.CoreDNS is not running or misconfigured

C.The service port does not match the container port

D.The selector does not match any pod labels

AnswerB

CoreDNS resolves cluster-internal service names, so if it is not running or is misconfigured, pods cannot translate the ClusterIP service name into its virtual IP. Since the pods share the namespace, the fault lies in DNS resolution rather than NetworkPolicy or selector mismatch.

Why this answer

When a ClusterIP service cannot be reached by its DNS name from pods in the same namespace, the most common cause is that CoreDNS (the cluster DNS resolver) is not running or is misconfigured. Kubernetes relies on CoreDNS to resolve service names to ClusterIP addresses; if CoreDNS is down or its configuration is incorrect, DNS queries for the service name will fail, even though the service itself and its endpoints are healthy.

Exam trap

The exam tests the distinction between DNS resolution failures and connectivity failures, trapping candidates who confuse a selector mismatch or port mismatch with a DNS issue, even though those would still allow the service name to resolve.

How to eliminate wrong answers

Option A is wrong because ClusterIP services are internal by design and do not need external exposure for pods to reach them via the service name; external exposure is irrelevant to internal DNS resolution. Option C is wrong because a port mismatch would cause connection timeouts or resets at the network layer, but the pod would still be able to resolve the service name via DNS and initiate a connection; the symptom described is that pods cannot reach the service using the name, which points to DNS failure, not port mismatch. Option D is wrong because if the selector does not match any pod labels, the service would have no endpoints and traffic would be dropped, but the service name would still resolve to a ClusterIP via DNS; the issue is that pods cannot reach the service using the name, implying DNS resolution itself is failing.

Full explanation →

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 151–225