Kubernetes and Cloud Native Associate KCNA KCNA Questions 901–930 | Page 13/13

901

MCQhard

A user creates a Service of type ClusterIP with a selector matching pods labeled 'app: myapp'. However, a pod named 'myapp-pod' with label 'app: myapp' is not receiving traffic. What is a possible reason?

A.The Service type should be NodePort

B.The pod is in a different namespace

C.The pod's readiness probe is failing

D.The pod's container port is not defined

AnswerC

A failing readiness probe marks the pod NotReady, so the Endpoints controller excludes its IP from the Service's endpoint list. The selector matches correctly, but ClusterIP only forwards to ready endpoints, so traffic never reaches the pod.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

902

Multi-Selectmedium

Which TWO of the following are core principles of cloud native architecture? (Choose two.)

Select 2 answers

A.Manual infrastructure provisioning

B.Monolithic application design

C.Tight coupling between services

D.Containerization

E.Microservices

AnswersD, E

Containers provide lightweight, consistent environments.

Why this answer

Containerization (Option D) is a core principle of cloud native architecture because it packages applications and their dependencies into isolated, lightweight containers, enabling consistent deployment across environments and efficient resource utilization. This aligns with the cloud native goal of portability and scalability, as containers can be orchestrated by platforms like Kubernetes to manage dynamic workloads.

Exam trap

CNCF often tests the misconception that cloud native architecture requires a specific technology like Kubernetes or Docker, but the core principles are about architectural patterns (e.g., microservices, containerization) rather than any single tool, so candidates may incorrectly select options that describe operational practices (like manual provisioning) instead of architectural principles.

Full explanation →

903

MCQmedium

What is the role of kube-scheduler in Kubernetes?

A.To assign pods to nodes

B.To run container health checks

C.To store cluster configuration

D.To provide network rules for services

AnswerA

The scheduler watches for newly created Pods with no assigned node and selects a suitable node based on resource requests, affinity rules, taints and tolerations. It writes that binding to the API server, satisfying the stem's constraint that pods must be placed onto nodes.

Why this answer

The kube-scheduler is responsible for selecting an optimal node for newly created pods that have not yet been assigned to a node. It evaluates constraints such as resource requirements, affinity/anti-affinity rules, and data locality, then binds the pod to the chosen node via the Kubernetes API. This makes option A correct because scheduling is the scheduler's primary and defining function.

Exam trap

A common misconception is that the scheduler also manages pod lifecycle or health checks, leading candidates to confuse the scheduler's static assignment role with the kubelet's dynamic runtime responsibilities.

How to eliminate wrong answers

Option B is wrong because container health checks (liveness, readiness, and startup probes) are executed by the kubelet on the node where the pod is running, not by the kube-scheduler. Option C is wrong because cluster configuration is stored in etcd, a distributed key-value store, and the kube-scheduler does not persist any configuration data. Option D is wrong because network rules for Services (e.g., iptables or IPVS rules) are managed by the kube-proxy component, not the scheduler.

Full explanation →

904

MCQeasy

A Pod has a container that needs to write logs to a file. The administrator wants the logs to persist even if the container restarts. What is the simplest solution?

A.Use a PersistentVolumeClaim for each container.

B.Use a hostPath volume to write logs directly to the node filesystem.

C.Store logs in a ConfigMap.

D.Use an emptyDir volume and mount it at the log path.

AnswerD

An emptyDir volume is created when the Pod is assigned to a node and survives container restarts within that Pod, so log files written to the mounted path persist across a container crash. It satisfies the persistence requirement without the complexity of a PersistentVolume claim.

Why this answer

An emptyDir volume provides a simple, ephemeral storage solution that persists across container restarts within the same Pod. When a container crashes and is restarted by the kubelet, the emptyDir volume's contents remain intact, allowing log files to survive container restarts without requiring external storage or complex configuration.

Exam trap

CNCF often tests the misconception that container restarts always wipe all data, leading candidates to choose persistent storage options like PVCs or hostPath, when in fact emptyDir volumes are specifically designed to survive container restarts within the same Pod.

How to eliminate wrong answers

Option A is wrong because a PersistentVolumeClaim (PVC) is designed for durable, long-term storage that survives Pod deletion and rescheduling, which is overkill for simple log persistence across container restarts and adds unnecessary complexity. Option B is wrong because a hostPath volume ties the Pod to a specific node and poses security risks (e.g., allowing container access to the host filesystem), and it is not the simplest solution for log persistence within a Pod. Option C is wrong because a ConfigMap is intended for storing configuration data (e.g., key-value pairs, small files) and is not designed for dynamic, writable log output; ConfigMaps are read-only when mounted and cannot be written to by containers.

Full explanation →

905

MCQmedium

A developer deploys a pod with the following resource specification: ```yaml resources: requests: memory: "256Mi" limits: memory: "512Mi" ``` The pod is killed with OOMKilled. What is the most likely cause?

A.The container exceeded the memory request of 256Mi

B.The node ran out of memory

C.The CPU limit was too low

D.The container exceeded the memory limit of 512Mi

AnswerD

The kernel OOM killer terminates a container when its memory usage breaches the configured limit of 512Mi. Requests of 256Mi only influence scheduling, not termination. Exceeding the limit is therefore the cause of the OOMKilled status described in the stem.

Why this answer

The OOMKilled exit code indicates the container was terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it attempted to use more memory than its configured limit of 512Mi. Kubernetes enforces memory limits using cgroups; when the container exceeds the limit, the kernel kills the process, resulting in the OOMKilled status.

Exam trap

CNCF often tests the distinction between requests and limits, trapping candidates who think exceeding a request causes termination, when in fact only exceeding the limit triggers OOMKilled.

How to eliminate wrong answers

Option A is wrong because exceeding the memory request of 256Mi does not cause termination; requests are used for scheduling and guaranteed QoS, not enforcement. Option B is wrong because node memory exhaustion would cause the node to evict pods or the OOM killer to target pods, but the pod's explicit memory limit is the direct cause here, not node-level pressure. Option C is wrong because CPU limits do not cause OOMKilled; CPU is a compressible resource, and exceeding CPU limits results in throttling, not termination.

Full explanation →

906

MCQeasy

A Kubernetes operator wants to view real-time CPU and memory usage of pods and nodes in a cluster using kubectl top. Which component must be installed and running in the cluster for this command to work?

A.Prometheus

B.kube-state-metrics

C.metrics-server

D.OpenTelemetry Collector

AnswerC

The metrics-server is a cluster-wide aggregator of resource usage data. It collects metrics from Kubelets and exposes them via the Metrics API, which kubectl top uses to display current CPU and memory usage for pods and nodes. Without metrics-server, kubectl top returns an error indicating that metrics are not available, so it is the required component.

Why this answer

kubectl top retrieves metrics from the Kubernetes Metrics API, which is implemented by the metrics-server. The metrics-server collects resource usage data from Kubelets and makes it available through the API. Other tools like Prometheus or kube-state-metrics serve different purposes and do not power kubectl top, so metrics-server is the correct component to install.

Exam trap

The trap here is confusing general monitoring tools like Prometheus with the specific component that backs the kubectl top command.

Full explanation →

907

MCQeasy

Which Kubernetes control plane component is the primary entry point for all administrative tasks and serves the Kubernetes API?

A.kube-scheduler

B.kube-controller-manager

C.kube-apiserver

D.etcd

AnswerC

kube-apiserver serves the Kubernetes API and is the sole entry point for administrative tasks, validating and persisting every request to etcd. It satisfies the stem's requirement for the primary administrative entry point exposing the Kubernetes API.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane and the sole entry point for all administrative operations. It exposes the Kubernetes REST API, validates and processes requests (including authentication, authorization, and admission control), and updates the corresponding objects in etcd. Without the API server, no kubectl command, automation, or internal component communication can occur.

Exam trap

CNCF often tests the misconception that etcd is the primary entry point because it stores all cluster data, but the trap here is that etcd is a data store, not an API endpoint — all interactions must go through the kube-apiserver, which is the only component that communicates directly with etcd.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible only for assigning newly created pods to nodes based on resource requirements and policies, not for serving the API or handling administrative tasks. Option B is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that watch the desired state via the API server, but it does not expose an API endpoint itself. Option D is wrong because etcd is a distributed key-value store used as Kubernetes' backing store for all cluster data, but it is not the entry point for administrative tasks and does not serve the Kubernetes API.

Full explanation →

908

Multi-Selectmedium

A developer inspects a Pod and sees that it is stuck in the Pending phase. Which two conditions can legitimately cause a Pod to remain Pending? (Choose two.)

Select 2 answers

A.The Pod's container image cannot be pulled from the registry.

B.The Pod requests a PersistentVolumeClaim that is not yet bound and uses a storage class with WaitForFirstConsumer.

C.No node in the cluster satisfies the Pod's resource requests or node affinity rules.

D.The Pod's liveness probe is failing repeatedly.

E.The Pod's ServiceAccount token has expired.

AnswersB, C

With WaitForFirstConsumer binding mode, the volume is provisioned only after a node is chosen, and the scheduler holds the Pod until the claim is satisfiable. Until then the Pod remains Pending, which is expected behavior rather than a failure. This is a legitimate scheduling-related cause of the Pending phase.

Why this answer

A Pod stays Pending whenever the scheduler cannot place it or its volumes are not ready. Unsatisfiable resource requests, affinity rules, or taints block scheduling, and a WaitForFirstConsumer PersistentVolumeClaim deliberately delays binding until a node is chosen. Image pull errors, failed liveness probes, and token expiry all occur after scheduling and therefore do not cause the Pending phase.

Exam trap

The trap here is blaming image pull failures for a Pending Pod, when those failures happen after scheduling and surface as ImagePullBackOff.

Full explanation →

909

MCQmedium

You create a Service of type ClusterIP with the name 'my-service' in the 'default' namespace. What DNS name resolves to the service's cluster IP from a pod in the same namespace?

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

B.my-service.svc.cluster.local

C.my-service.default.cluster.local

D.my-service.cluster.local

AnswerA

Kubernetes DNS resolves Services as <service>.<namespace>.svc.cluster.local. With the Service named my-service in the default namespace, that fully qualified name resolves to its cluster IP, and the shorter form my-service also works from within the same namespace.

Why this answer

Kubernetes DNS resolves a Service's ClusterIP using the fully qualified domain name (FQDN) format `<service>.<namespace>.svc.cluster.local`. Since the Service 'my-service' is in the 'default' namespace, a pod in the same namespace can reach it via `my-service.default.svc.cluster.local`. The DNS query returns the ClusterIP of the Service, allowing pods to communicate with it reliably.

Exam trap

The trap here is that candidates often forget the mandatory 'svc' subdomain in the FQDN, mistakenly thinking the namespace directly precedes 'cluster.local', or they omit the namespace entirely when the Service is in the same namespace as the pod.

How to eliminate wrong answers

Option B is wrong because it omits the namespace component; the correct FQDN must include the namespace (e.g., 'default') before 'svc'. Option C is wrong because it uses 'cluster.local' instead of 'svc.cluster.local'; the 'svc' subdomain is mandatory for Service DNS records. Option D is wrong because it drops both the namespace and the 'svc' subdomain, resulting in an incomplete and unresolvable DNS name.

Full explanation →

910

MCQmedium

A Kubernetes administrator needs to restrict inbound traffic to a set of pods. Only pods with the label 'app: frontend' in the same namespace should be allowed to reach the pods on TCP port 8080. Which resource should be used?

A.Ingress

B.PodSecurityPolicy

C.ServiceAccount

D.NetworkPolicy

AnswerD

NetworkPolicy selects pods via label selectors and defines ingress rules permitting only labelled sources on specified ports. It satisfies the stem's requirement to restrict inbound traffic to TCP 8080 from pods labelled app: frontend within the same namespace.

Why this answer

NetworkPolicy is the correct resource because it is a Kubernetes-native object that defines how groups of pods are allowed to communicate with each other and other network endpoints. By specifying a pod selector matching 'app: frontend' and an ingress rule allowing TCP port 8080, you can restrict inbound traffic to only those pods with that label in the same namespace.

Exam trap

The trap here is that candidates confuse Ingress (external HTTP routing) with NetworkPolicy (internal pod-to-pod traffic control), leading them to choose Ingress when the question explicitly restricts inbound traffic within the same namespace.

How to eliminate wrong answers

Option A is wrong because Ingress is an API object that manages external HTTP/S traffic to services, not pod-to-pod traffic within the cluster. Option B is wrong because PodSecurityPolicy is a cluster-level resource that controls security-sensitive aspects of pod specification (e.g., privilege escalation, host namespaces), not network traffic rules. Option C is wrong because a ServiceAccount provides an identity for processes running in a pod to authenticate to the Kubernetes API server, it does not enforce network-level access controls.

Full explanation →

911

Multi-Selecthard

Which THREE of the following are correct statements about Kubernetes Deployments?

Select 3 answers

A.Deployments support canary deployments natively

B.A Deployment manages ReplicaSets

C.A Deployment directly manages Pods

D.The default update strategy is RollingUpdate

E.Deployment supports rolling back to an earlier revision

AnswersB, D, E

A Deployment owns and manages ReplicaSets, creating a new ReplicaSet for each revision while retaining older ones. This ownership hierarchy is what enables declarative scaling and rollouts, since the Deployment controller reconciles desired replica counts through the ReplicaSet it governs.

Why this answer

Option B is correct because a Deployment does not manage Pods directly; it creates and manages ReplicaSets, which in turn manage the Pods, enabling versioned rollouts. Option D is correct because the default .spec.strategy.type for a Deployment is RollingUpdate, which gradually replaces old Pods with new ones to avoid downtime. Option E is correct because Deployments retain revision history (controlled by .spec.revisionHistoryLimit) and support kubectl rollout undo to roll back to a previous revision.

Option A is not correct because Deployments do not natively support canary deployments; canary releases require additional tooling or manual manipulation of replicas/selectors. Option C is not correct because Deployments manage ReplicaSets, not Pods directly.

Exam trap

The KCNA exam often tests the misconception that Deployments directly manage Pods, when in fact they manage ReplicaSets, and that canary deployments are a built-in feature of Deployments, whereas they require external traffic management.

Full explanation →

912

MCQmedium

Which component in a service mesh is responsible for collecting telemetry data and enforcing traffic policies?

A.Control plane

B.Sidecar proxy (data plane)

C.Certificate authority

D.Service mesh ingress gateway

AnswerB

The sidecar proxy sits alongside each workload in the data plane, intercepting all inbound and outbound traffic. It enforces routing and access policies while emitting metrics, logs and traces to the control plane's telemetry collectors.

Why this answer

In a service mesh, the sidecar proxy (part of the data plane) is the component that actually intercepts service-to-service traffic, enforces traffic policies (routing, retries, timeouts, mTLS), and emits telemetry (metrics, logs, traces) for each request. The control plane configures the sidecars but does not handle live traffic itself.

Exam trap

The trap is confusing the control plane (which configures policy) with the data plane (which enforces it) — candidates often pick 'control plane' because it sounds like the brain of the mesh, but telemetry collection and runtime policy enforcement happen in the sidecar proxy.

How to eliminate wrong answers

Option A is wrong because the control plane (e.g., Istio's istiod, Linkerd's control plane) is responsible for configuration, certificate issuance, and pushing policy to the data plane — it does not sit in the request path and therefore does not collect per-request telemetry or enforce runtime traffic policies. Option C is wrong because the certificate authority is a component that issues and rotates workload certificates for mTLS; it is part of the control plane's security function and does not process traffic or collect telemetry. Option D is wrong because the ingress gateway handles north-south traffic entering the mesh from outside, not the east-west service-to-service traffic where sidecar proxies enforce policy and collect telemetry.

Full explanation →

913

MCQmedium

Which of the following best describes the 12-factor app methodology's approach to configuration?

A.Configuration is hardcoded in the application code

B.Configuration is stored in environment variables

C.Configuration is stored in a database and accessed at runtime

D.Configuration is managed by a configuration server

AnswerB

The 12-factor methodology mandates strict separation of config from code, storing it in environment variables so the same build can be deployed across environments. This satisfies the stem by naming environment variables as the prescribed storage mechanism rather than files or baked-in values.

Why this answer

The 12-factor app methodology's third factor, 'Config,' states that configuration should be stored in environment variables, keeping it strictly separate from code. This allows the same codebase to be deployed across environments without modification. Environment variables are language- and OS-agnostic, making them the recommended mechanism.

Exam trap

The trap is over-engineering the answer by choosing a configuration server or database, which sounds robust but contradicts the 12-factor methodology's explicit preference for environment variables.

How to eliminate wrong answers

Option A is wrong because hardcoding configuration in code violates the factor's core principle and makes the app non-portable across environments. Option C is wrong because storing config in a database and reading it at runtime is not the 12-factor recommendation; it couples config to a runtime dependency and complicates deployment. Option D is wrong because a configuration server, while used in some architectures, is not what the 12-factor methodology prescribes; the factor explicitly calls for environment variables.

Full explanation →

914

MCQmedium

An application Pod in the `web` namespace must read a configuration value stored in a ConfigMap named `app-config` without restarting when the value changes. The value is consumed as a file inside the container. Which approach meets this requirement?

A.Mount the ConfigMap as a volume and let the application re-read the file periodically.

B.Use a subPath volume mount of the ConfigMap key.

C.Set the ConfigMap as an immutable object and mount it as a volume.

D.Reference the ConfigMap with envFrom and rely on automatic environment refresh.

AnswerA

ConfigMaps projected as volumes are updated in place by the kubelet after a short sync delay, so a file-reading application that re-reads on its own sees new values without a Pod restart. This is the standard way to get live configuration updates. The application must still poll or watch the file, because the kubelet does not signal the process.

Why this answer

Volume-mounted ConfigMaps are periodically refreshed by the kubelet, so an application that re-reads its configuration file can pick up new values without a restart. Environment-variable injection and subPath mounts do not update at runtime, and immutable ConfigMaps cannot change at all, so the volume-mount approach is the only one that satisfies the scenario.

Exam trap

The trap here is believing that envFrom variables refresh automatically, when they are fixed at container start and never update.

Full explanation →

915

MCQhard

According to DORA metrics, which metric measures the percentage of deployments that fail in production?

A.Change Failure Rate

B.Mean Time to Restore (MTTR)

C.Deployment Frequency

D.Lead Time for Changes

AnswerA

Change Failure Rate measures the proportion of deployments to production that result in degraded service and require remediation, expressed as a percentage. It directly satisfies the metric definition requested, unlike deployment frequency, lead time for changes or mean time to restore.

Why this answer

Change Failure Rate (CFR) is the DORA metric that directly measures the percentage of deployments that result in a failure in production, such as a service outage or a bug requiring a hotfix. It is calculated as (number of failed deployments / total deployments) * 100. This metric reflects the quality and stability of the software delivery process, complementing speed metrics like Deployment Frequency and Lead Time for Changes.

Exam trap

KCNA often tests the confusion between Change Failure Rate and Mean Time to Restore, as both relate to failures but measure different aspects: CFR measures the frequency of failures, while MTTR measures the duration to recover.

How to eliminate wrong answers

Option B is wrong because Mean Time to Restore (MTTR) measures the average time it takes to recover from a failure, not the percentage of deployments that fail. Option C is wrong because Deployment Frequency measures how often an organization successfully releases to production, not the failure rate. Option D is wrong because Lead Time for Changes measures the time from code commit to code successfully running in production, not the proportion of failed deployments.

Full explanation →

916

Multi-Selecthard

A platform engineer is designing a multi-tenant cluster and must ensure that Pods in different namespaces cannot communicate with each other by default, while allowing specific traffic within each namespace. Which two Kubernetes features are required to achieve this? (Choose two.)

Select 2 answers

A.Service mesh with mTLS enabled

B.ResourceQuota per namespace

C.A CNI plugin that supports NetworkPolicy enforcement

D.PodSecurityPolicy restricted to the namespace

E.NetworkPolicy with a default deny-all ingress rule in each namespace

AnswersC, E

NetworkPolicy resources are only enforced if the cluster's CNI plugin implements them. Plugins like Calico, Cilium, and Weave Net enforce policies, while some basic plugins like Flannel do not. Without a supporting CNI, NetworkPolicy objects are created but have no effect, leaving Pods unrestricted.

Why this answer

To achieve default-deny between namespaces, you need a NetworkPolicy that denies all ingress in each namespace and a CNI plugin that enforces NetworkPolicy. Without the policy, traffic is allowed by default; without a supporting CNI, the policy has no effect. Together they provide the required isolation and allow specific traffic via additional allow policies.

Exam trap

The trap here is assuming that creating a NetworkPolicy is sufficient, when in fact the cluster's CNI plugin must also support and enforce NetworkPolicy for the rules to take effect.

Full explanation →

917

Multi-Selecteasy

Which THREE of the following are benefits of using a service mesh in a cloud native architecture?

Select 3 answers

A.Management of application state across services

B.Traffic management capabilities like canary deployments

C.Reduction of container image sizes

D.Improved security through mutual TLS encryption

E.Enhanced observability with metrics and tracing

AnswersB, D, E

A service mesh provides layer 7 traffic management through sidecar proxies, enabling fine-grained routing rules that split traffic between service versions. This directly supports canary deployments, where a small percentage of requests route to a new version before full rollout, satisfying the stem's requirement for progressive delivery without changing application code.

Why this answer

Option B is correct because a service mesh provides layer-7 traffic management (e.g., weighted routing, header-based routing) that enables canary deployments and blue/green releases without changing application code. Option D is correct because service meshes like Istio and Linkerd automatically provision and rotate mutual TLS (mTLS) certificates between sidecar proxies, giving strong service-to-service authentication and encryption. Option E is correct because sidecar proxies emit uniform telemetry—request metrics, distributed traces, and access logs—across all services, improving observability without per-service instrumentation.

Option A is not a service mesh benefit: application state management is handled by databases, caches, or stateful orchestration, not by the mesh's data plane. Option C is also incorrect because the mesh adds sidecar proxies and control-plane components, which tend to increase rather than reduce container image sizes.

Exam trap

KCNA often tests the core responsibilities of a service mesh; candidates may confuse it with other cloud native tools like container registries or state management solutions, leading them to select options that are not service mesh benefits.

Full explanation →

918

MCQeasy

Which component of the Kubernetes control plane stores the cluster state?

A.etcd

B.kube-controller-manager

C.kube-scheduler

D.kube-apiserver

AnswerA

etcd is the control plane's distributed key-value store, persisting every Kubernetes object and cluster state. The API server is the only component that reads and writes it directly, making etcd the authoritative backing store for the cluster.

Why this answer

etcd is the distributed key-value store that serves as the single source of truth for the entire Kubernetes cluster. It stores all cluster state data, including configuration, secrets, and the desired state of every object (Pods, Deployments, Services, etc.). The kube-apiserver is the only component that directly communicates with etcd, ensuring that all state changes go through a consistent, versioned API.

Exam trap

The trap here is that candidates often confuse the kube-apiserver as the state store because it is the only component that interacts with etcd and serves the Kubernetes API, but the actual persistence layer is etcd itself.

How to eliminate wrong answers

Option B (kube-controller-manager) is wrong because it runs controller processes that reconcile the current cluster state with the desired state stored in etcd; it does not store state itself. Option C (kube-scheduler) is wrong because it assigns Pods to Nodes based on resource availability and constraints, reading state from the API server but never persisting state. Option D (kube-apiserver) is wrong because while it is the front-end that validates and processes all REST requests and acts as the gateway to etcd, it does not store the cluster state—it delegates persistence to etcd.

Full explanation →

919

MCQeasy

Which Kubernetes control plane component is responsible for storing the cluster state and configuration data?

A.kube-controller-manager

B.etcd

C.kube-apiserver

D.kube-scheduler

AnswerB

etcd is the distributed key-value store holding all cluster state, including object definitions, configuration and secrets, and is the only component the API server reads from and writes to. Losing etcd means losing the cluster's authoritative state, making it the control plane's backing store.

Why this answer

etcd is the distributed key-value store that serves as Kubernetes' single source of truth for all cluster state and configuration data. It stores objects like Pods, Services, Deployments, and Secrets, and is the only component that holds persistent state. The kube-apiserver reads from and writes to etcd, but etcd itself is the storage backend.

Exam trap

The exam often tests the misconception that kube-apiserver stores the cluster state because it is the central API endpoint, but the trap is that the API server is stateless and relies entirely on etcd for persistence.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager is a control loop that watches the shared state via the API server and makes changes to move the current state toward the desired state, but it does not store any data itself. Option C is wrong because kube-apiserver is the front-end for the Kubernetes control plane that validates and processes RESTful requests, but it delegates all persistent storage to etcd and does not store cluster state locally. Option D is wrong because kube-scheduler is responsible for assigning Pods to Nodes based on resource availability and constraints, and it has no role in storing cluster configuration or state.

Full explanation →

920

Multi-Selectmedium

Which TWO of the following are responsibilities of the kube-controller-manager?

Select 2 answers

A.Assigning pods to nodes based on resource requirements

B.Ensuring the correct number of pod replicas are running

C.Implementing network rules for Services

D.Monitoring node health and responding to node failures

E.Storing the cluster state

AnswersB, D

The kube-controller-manager runs the ReplicaSet controller, which continuously reconciles the observed replica count against the desired count declared in the ReplicaSet spec, creating or deleting pods to close any gap. This directly satisfies the stem's requirement to maintain the correct number of running pod replicas.

Why this answer

Option B is correct because the kube-controller-manager runs the ReplicationController/ReplicaSet controller, which continuously reconciles the desired replica count in a workload's spec with the actual number of running pods, creating or deleting pods as needed. Option D is correct because the kube-controller-manager includes the node controller, which monitors node heartbeats/status and reacts to node failures by marking nodes NotReady and evicting or rescheduling their pods (subject to tolerations). Option A is not a kube-controller-manager responsibility; pod-to-node assignment is performed by the kube-scheduler.

Option C is not correct because Service network rules are implemented by the kube-proxy component (and/or CNI/iptables/IPVS), not the kube-controller-manager. Option E is not correct because cluster state is stored in etcd, the distributed key-value store, not by the kube-controller-manager.

Exam trap

The trap here is that candidates often confuse the kube-controller-manager's role in node health monitoring with the kube-scheduler's role in pod placement, or they mistakenly think the controller-manager handles network rules, which is actually done by kube-proxy.

Full explanation →

921

Multi-Selectmedium

Which TWO of the following are common characteristics of serverless computing? (Choose two.)

Select 2 answers

A.Auto-scaling to zero when idle

B.Event-driven execution

C.Manual scaling based on predicted load

D.Always-on dedicated servers

E.Long-running stateful processes

AnswersA, B

Auto-scaling to zero when idle is a defining trait of serverless platforms such as AWS Lambda and Azure Functions, where the provider provisions no instances during inactivity. This satisfies the stem's demand for common characteristics, since consumption-based billing and event-driven invocation both depend on capacity dropping to zero rather than idling at a baseline.

Why this answer

Option A (Auto-scaling to zero when idle) is correct because serverless platforms such as AWS Lambda, Azure Functions, and Google Cloud Functions provision no compute instances when there are no invocations, so you pay nothing during idle periods and capacity scales down to zero automatically. Option B (Event-driven execution) is correct because serverless functions are invoked in response to events — HTTP requests via API Gateway, object uploads to S3, messages in SQS, database changes, or scheduled timers — rather than running continuously. Option C is incorrect because manual scaling based on predicted load describes traditional provisioned servers or reserved capacity, not the automatic, demand-based scaling of serverless.

Option D is incorrect because serverless abstracts away servers entirely; there are no always-on dedicated servers allocated to the customer. Option E is incorrect because serverless functions are designed to be short-lived and stateless, with state externalized to services like DynamoDB, S3, or Redis rather than held in long-running processes.

Exam trap

The trap is selecting options that sound 'efficient' (manual scaling, dedicated servers) because they are familiar from traditional infrastructure — candidates must remember that serverless is defined by automatic elasticity to zero and event-driven invocation, not by any form of pre-provisioned capacity.

Full explanation →

922

MCQmedium

A Deployment is configured with 'replicas: 4' and 'strategy.type: RollingUpdate'. You update the container image. What behavior does the Deployment exhibit?

A.The Deployment creates 8 Pods total, 4 old and 4 new

B.All 4 Pods are deleted immediately and then 4 new Pods are created

C.New Pods are created before old ones are terminated, one at a time

D.The update is paused until manually resumed

AnswerC

RollingUpdate replaces Pods incrementally, so the Deployment creates new Pods before terminating old ones, honouring the default maxSurge and maxUnavailable settings. This satisfies the requirement that the update proceeds without downtime, scaling the new ReplicaSet up gradually while the old ReplicaSet scales down, one Pod at a time.

Why this answer

With a RollingUpdate strategy, the Deployment controller replaces old Pods with new ones incrementally to ensure zero downtime. By default, it creates new Pods before terminating old ones (maxSurge=25%, maxUnavailable=25%), so one new Pod is created first, then one old Pod is terminated, repeating until all 4 Pods run the new image.

Exam trap

The trap here is that candidates confuse RollingUpdate with Recreate (Option B) or assume all Pods are replaced simultaneously (Option A), failing to recognize the incremental, surge-based behavior controlled by maxSurge and maxUnavailable defaults.

How to eliminate wrong answers

Option A is wrong because a RollingUpdate does not create 8 Pods simultaneously; it creates at most 1 extra Pod (maxSurge=25% of 4 = 1) beyond the desired 4, so the total is 5, not 8. Option B is wrong because deleting all Pods immediately is a Recreate strategy, not RollingUpdate, which would cause downtime. Option D is wrong because the update is not paused; a paused update requires explicitly setting 'paused: true' in the Deployment spec, which is not mentioned in the question.

Full explanation →

923

MCQhard

A company defines an SLO that 99.9% of requests to a service should complete in under 200ms. Which metric type is used to measure this SLO?

A.Summary

B.Histogram

C.Gauge

D.Counter

AnswerB

Histograms bucket observations into configurable ranges, so the proportion of requests completing under 200ms can be calculated from the relevant bucket counts. This satisfies the SLO's latency threshold, which a gauge or counter cannot express as a distribution.

Why this answer

A histogram is the Prometheus metric type designed to capture the distribution of observations (like request durations) into configurable buckets, and it automatically exposes _bucket, _sum, and _count series. This allows you to compute quantiles (e.g., the 99.9th percentile latency) and ratios such as 'fraction of requests under 200ms' using PromQL, which is exactly what the SLO requires.

Exam trap

The trap is choosing Summary because it also measures latency distributions; the key differentiator is that Summaries cannot be aggregated across instances, which breaks service-wide SLO calculations.

How to eliminate wrong answers

Option A is wrong because a Summary also captures distributions and quantiles, but quantiles are pre-computed client-side and cannot be aggregated across instances — making it unsuitable for a service-level SLO that spans multiple pods. Option C is wrong because a Gauge represents a single instantaneous value that can go up or down (e.g., temperature, queue depth), not a distribution of request durations. Option D is wrong because a Counter is a monotonically increasing value (e.g., total requests), which cannot express '99.9% under 200ms' without a distribution.

Full explanation →

924

MCQmedium

Your application requires persistent storage that must be available across pod restarts and rescheduling. What is the recommended approach?

A.Store data in the container's writable layer

B.Use hostPath volume

C.Use an emptyDir volume

D.Use a PersistentVolumeClaim (PVC) and mount it into the pod

AnswerD

A PersistentVolumeClaim decouples storage lifecycle from the pod, binding to a PersistentVolume that survives restarts and rescheduling. This satisfies the requirement for persistent storage across pod lifecycles, unlike emptyDir or container filesystem storage, which are ephemeral and tied to the pod's lifetime.

Why this answer

PersistentVolumeClaim (PVC) is the recommended approach because it decouples storage provisioning from pod lifecycle, ensuring data persists across pod restarts and rescheduling. PVCs request storage from a PersistentVolume (PV) that is backed by a physical storage system (e.g., NFS, cloud block storage), and the pod mounts this volume, allowing the data to survive even if the pod is deleted and recreated on a different node.

Exam trap

The trap here is that candidates often confuse emptyDir or hostPath as persistent storage because they survive container restarts within the same pod, but they fail to recognize that these volumes do not survive pod deletion or rescheduling to a different node.

How to eliminate wrong answers

Option A is wrong because the container's writable layer is ephemeral and tied to the container's lifecycle; data is lost when the container restarts or the pod is rescheduled. Option B is wrong because hostPath volumes tie storage to a specific node's filesystem, so if the pod is rescheduled to a different node, the data is not accessible, and it also poses security risks by exposing node filesystem. Option C is wrong because emptyDir volumes are created empty when a pod starts and are deleted when the pod is removed; they share data between containers in the same pod but do not persist across pod restarts or rescheduling.

Full explanation →

925

MCQmedium

A DevOps team wants to collect and forward logs from all nodes in a Kubernetes cluster to a centralized logging backend. Which component is specifically designed for lightweight log collection and forwarding?

A.Fluent Bit

B.Prometheus

C.Jaeger

D.Grafana

AnswerA

Fluent Bit is a lightweight, low-memory log processor and forwarder, typically deployed as a DaemonSet so one pod runs per node. This satisfies the stem's requirement for lightweight node-level log collection forwarding to a centralised backend.

Why this answer

Fluent Bit is a lightweight log processor and forwarder, ideal for Kubernetes nodes.

Full explanation →

926

MCQmedium

You want to update a Deployment's container image to v2 and perform a rolling update using the simplest imperative command. Which kubectl command achieves this?

A.kubectl update deployment my-deployment --image=myapp:v2

B.kubectl replace -f updated-deployment.yaml

C.kubectl patch deployment my-deployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"my-container","image":"myapp:v2"}]}}}}'

D.kubectl set image deployment/my-deployment my-container=myapp:v2 --record

AnswerD

`kubectl set image` patches the Deployment's pod template in place, triggering the rolling update strategy already defined on the Deployment. It satisfies the stem's imperative and simplest constraints, updating only the named container's image to v2 without editing YAML. The `--record` flag annotates the revision, aiding rollback history.

Why this answer

The `kubectl set image` command is the standard imperative way to update a container image in a Deployment, and it automatically triggers a rolling update. Option A is invalid; `kubectl update` is not a real command. Option B, `kubectl replace`, requires a full YAML file and is a declarative replacement operation, not a simple image update command.

Option C, `kubectl patch`, can be used but is overly complex and error-prone for a simple image update. The question asks for the simplest imperative command, making D the best answer.

Exam trap

A common pitfall is assuming that `kubectl update` is a valid command (it is not) or that `kubectl patch` is the simplest approach. While `kubectl patch` can update the image, it is not the simplest or most direct imperative command for this task.

How to eliminate wrong answers

Option A is wrong because `kubectl update` is not a valid kubectl command; the correct imperative command for updating a Deployment's image is `kubectl set image`. Option B is wrong because `kubectl replace -f updated-deployment.yaml` performs a full replacement of the Deployment object, which is a declarative approach that does not inherently trigger a rolling update; it replaces the entire resource definition, potentially causing downtime if not managed carefully. Option C is wrong because while `kubectl patch` can update the container image, it requires a complex JSON patch and does not automatically trigger a rolling update unless the patch modifies the pod template spec; however, it is less straightforward and not the recommended imperative command for this specific task.

Full explanation →

927

MCQmedium

A Service of type ClusterIP is created to expose a set of pods. How does the Service achieve load balancing to the pods?

A.The API server routes traffic directly to the pods

B.The kube-proxy component on each node sets up network rules to forward traffic to the pods

C.The kubelet configures the container runtime to route traffic

D.Using a cloud load balancer

AnswerB

Kube-proxy runs on every node and programs iptables or IPVS rules that intercept traffic destined for the ClusterIP, then forwards each connection to one of the backing pod endpoints. This satisfies the stem's load-balancing requirement, distributing traffic across pods without any external load balancer.

Why this answer

Kube-proxy on each node implements load balancing for ClusterIP Services by creating iptables or IPVS rules that distribute traffic from the Service's virtual IP to the backend pods. These rules use a random or round-robin selection (depending on the mode) to forward packets to healthy pods, ensuring no single pod is overwhelmed.

Exam trap

A common trap is confusing the control-plane role of the API server with the data-plane role of kube-proxy. The API server does not handle data-plane traffic for Services.

How to eliminate wrong answers

Option A is wrong because the API server does not handle data-plane traffic; it only manages the control plane and stores Service definitions in etcd, while actual packet forwarding is done by kube-proxy. Option C is wrong because kubelet is responsible for managing pod lifecycle and container runtime configuration, not for setting up network routing rules for Services. Option D is wrong because a cloud load balancer is used for Services of type LoadBalancer, not ClusterIP, which is an internal virtual IP only reachable within the cluster.

Full explanation →

928

MCQeasy

A team is deploying a new microservice that processes sensitive user data. They want to ensure that secrets such as database passwords are not exposed in the container image or environment variables. Which approach should they use?

A.Embed the secret directly in the Docker image and use it via environment variables

B.Store the secret in a ConfigMap and reference it in the pod spec

C.Store the secret in a Kubernetes Secret and mount it as a volume in the pod

D.Use a PersistentVolumeClaim to store the secret and mount it into the pod

AnswerC

Kubernetes Secrets store credentials separately from the image and pod specification, and mounting them as volumes injects the data as files at runtime, so passwords never appear in container layers or environment variables. This satisfies the requirement to avoid exposing sensitive data.

Why this answer

Kubernetes Secrets are designed specifically to store sensitive data like database passwords. Mounting the Secret as a volume ensures the secret data is available to the pod as files, without being exposed in environment variables (which can be leaked via logs or `kubectl describe`) or embedded in the container image. This approach follows security best practices for handling sensitive information in cloud-native applications.

Exam trap

CNCF often tests the misconception that ConfigMaps are suitable for secrets because they can store key-value pairs, but the trap is that ConfigMaps store data in plaintext and are not designed for sensitive information, whereas Secrets provide base64 encoding and optional encryption at rest.

How to eliminate wrong answers

Option A is wrong because embedding secrets directly in a Docker image makes them part of the image layers, which can be inspected by anyone with access to the image registry, violating the principle of least privilege. Option B is wrong because ConfigMaps are intended for non-sensitive configuration data; storing secrets in a ConfigMap leaves them unencrypted and accessible via `kubectl get configmap`, which is a security risk. Option D is wrong because PersistentVolumeClaims are used for persistent storage of application data, not for storing secrets; they lack the encryption and access control features provided by Kubernetes Secrets.

Full explanation →

929

Multi-Selectmedium

Which two of the following are Kubernetes controllers that run inside the kube-controller-manager? (Select TWO)

Select 2 answers

A.kubelet

B.Replication controller

C.etcd

D.Node controller

E.kube-scheduler

AnswersB, D

The replication controller is a legacy control loop bundled inside kube-controller-manager, which maintains the desired pod replica count for its selector. It satisfies the stem's requirement of running within that manager rather than as a standalone control plane component, unlike the scheduler or kubelet.

Why this answer

The Replication controller (B) is correct because it is a built-in controller that runs within the kube-controller-manager process, continuously reconciling the desired number of pod replicas with the actual state by creating or deleting pods. The Node controller (D) is also correct because it is another controller embedded in the kube-controller-manager, responsible for monitoring node health, applying taints like node.kubernetes.io/not-ready, and evicting pods from unreachable nodes. The kubelet (A) is not part of the kube-controller-manager; it is a node-level agent that runs on each worker node and manages pod lifecycle via the container runtime. etcd (C) is the distributed key-value store that persists cluster state, not a controller, and it runs as a separate process.

The kube-scheduler (E) is a separate control-plane component that assigns pods to nodes and runs independently of the kube-controller-manager.

Exam trap

The exam often tests the distinction between control plane components (kube-controller-manager, kube-scheduler, etcd) and node agents (kubelet). Many candidates mistakenly think kubelet is a controller because it manages pods locally, but it runs on each node as a separate binary, not inside the kube-controller-manager.

Full explanation →

930

MCQmedium

A pod is in CrashLoopBackOff. You check the logs and see 'Error: container process not found'. What is the most likely cause?

A.The pod has insufficient memory

B.The liveness probe is misconfigured

C.The container's entrypoint or command is incorrect

D.The container image is missing

AnswerC

An incorrect entrypoint or command means the runtime cannot locate the executable to start, so the container exits immediately and Kubernetes restarts it repeatedly, producing CrashLoopBackOff. The log message 'container process not found' directly indicates the specified binary is missing or misnamed.

Why this answer

The container's entrypoint or command may be misconfigured, causing the container to exit immediately.

Full explanation →

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 901–930