Courseiva

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 751825

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

Page 10

Page 11 of 12

Page 12
751
MCQeasy

Which kubectl command would you use to view detailed information about a pod named 'web-pod' in the 'default' namespace?

A.kubectl describe pod web-pod
B.kubectl get pod web-pod
C.kubectl logs web-pod
D.kubectl exec web-pod -- env
AnswerA

This provides detailed status, events, and configuration.

Why this answer

The `kubectl describe pod web-pod` command retrieves detailed information about the specified pod, including its current status, events, container details, resource limits, and labels. This is the correct command for viewing comprehensive metadata and state information beyond the basic summary provided by `kubectl get`.

Exam trap

The trap here is that candidates confuse `kubectl get` with `kubectl describe`, assuming that `get` provides all details, when in fact `get` only shows a terse summary and `describe` is required for the full object dump and event history.

How to eliminate wrong answers

Option B is wrong because `kubectl get pod web-pod` only returns a concise summary of the pod's name, status, restarts, and age, not the detailed information requested. Option C is wrong because `kubectl logs web-pod` fetches the container's stdout/stderr logs, not the pod's configuration or status details. Option D is wrong because `kubectl exec web-pod -- env` runs the `env` command inside the pod's container to list environment variables, which is unrelated to viewing the pod's detailed metadata.

752
MCQhard

Which of the following best describes the GitOps pattern?

A.Imperative commands applied to the cluster and tracked in Git
B.Using Git as a backup for Kubernetes manifests
C.Using Git hooks to trigger CI/CD pipelines
D.Declarative configuration stored in Git, with automated deployment via a controller
AnswerD

GitOps relies on a Git repository and an operator like ArgoCD.

Why this answer

GitOps is a pattern where the entire system's desired state is declared in a Git repository, and an automated controller (such as Argo CD or Flux) continuously reconciles the live cluster state with that declarative configuration. This ensures that Git is the single source of truth, and any drift from the declared state is automatically corrected without manual intervention.

Exam trap

CNCF often tests the misconception that GitOps is simply about storing YAML files in Git or using Git as a trigger for CI/CD, when the defining characteristic is the automated reconciliation loop that enforces the desired state from Git.

How to eliminate wrong answers

Option A is wrong because GitOps relies on declarative configuration, not imperative commands; imperative commands (like kubectl run) are applied directly and are not idempotent or easily reconciled, violating the core GitOps principle of desired state stored in Git. Option B is wrong because Git is not used merely as a backup; it is the single source of truth for the desired state, and the controller actively enforces that state, not just stores copies. Option C is wrong because Git hooks are external triggers for CI/CD pipelines, but GitOps uses a pull-based model where the controller inside the cluster watches the Git repository for changes, not a push-based pipeline triggered by hooks.

753
Multi-Selecteasy

Which TWO of the following are benefits of using a multi-cloud strategy? (Select TWO.)

Select 2 answers
A.Reduced network latency
B.Improved resilience and disaster recovery
C.Avoiding vendor lock-in
D.Simplified compliance
E.Increased vendor lock-in
AnswersB, C

If one cloud fails, workloads can run on another.

Why this answer

A multi-cloud strategy distributes workloads across multiple cloud providers, so if one provider experiences an outage, applications can failover to another provider, improving overall resilience and disaster recovery. Option C is correct because using multiple cloud providers prevents dependency on a single vendor's proprietary services, avoiding vendor lock-in and giving you leverage for pricing and feature negotiations.

Exam trap

The trap here is that candidates confuse multi-cloud with hybrid cloud, assuming multi-cloud automatically improves latency or simplifies compliance, when in fact multi-cloud often increases complexity in both areas.

754
MCQmedium

A pod is stuck in Pending state. Which of the following is the MOST likely reason?

A.There are insufficient resources on any available node
B.The pod is still being initialized
C.The container image is missing
D.The pod has crashed and is restarting
AnswerA

The scheduler cannot find a node with enough CPU/memory/ports.

Why this answer

Pending means the pod has not been scheduled to a node, often due to insufficient resources or node constraints.

755
MCQmedium

A company is running a microservices application on a Kubernetes cluster. They have noticed that one of the services, 'payment-api', is experiencing intermittent high latency. The team wants to identify the root cause without modifying the application code. Which approach should they take?

A.Monitor CPU and memory metrics from kube-state-metrics and correlate with latency.
B.Increase log verbosity for all services and search for error messages.
C.Implement distributed tracing using tools like Jaeger or Zipkin to trace requests across services.
D.Check node-level metrics using Prometheus Node Exporter.
AnswerC

Distributed tracing tracks request flow and identifies slow components.

Why this answer

Distributed tracing with tools like Jaeger or Zipkin allows you to follow a single request as it traverses multiple microservices, identifying exactly which service or call introduces latency. This approach does not require code changes (if the service mesh or sidecar proxy handles instrumentation) and is specifically designed to pinpoint performance bottlenecks in distributed systems, unlike CPU/memory metrics or log analysis which cannot trace a request's end-to-end path.

Exam trap

CNCF often tests the distinction between observability tools that provide request-level context (distributed tracing) versus aggregate resource metrics (kube-state-metrics, Node Exporter) or unstructured logs, leading candidates to mistakenly choose CPU/memory correlation or log analysis for pinpointing intermittent latency in a microservices architecture.

How to eliminate wrong answers

Option A is wrong because kube-state-metrics provides resource utilization data (CPU, memory) per pod or container, but high latency in a microservice is often caused by network delays, database contention, or upstream service failures—not necessarily correlated with local resource usage; correlation does not imply causation and cannot trace the request path. Option B is wrong because increasing log verbosity for all services generates massive volumes of unstructured data and relies on error messages that may not appear during intermittent latency spikes; logs lack the context of a specific request's journey across services, making root cause identification inefficient and often impossible. Option D is wrong because node-level metrics from Prometheus Node Exporter only show host-level resource usage (e.g., disk I/O, network bandwidth) and cannot reveal which microservice or request is causing latency within the cluster; they are useful for infrastructure troubleshooting but not for application-level distributed tracing.

756
MCQhard

A company runs a Kubernetes cluster with 50 worker nodes, each hosting multiple microservices. They use Prometheus for metrics collection and Grafana for dashboards. Recently, the Prometheus server has been experiencing out-of-memory (OOM) kills during peak hours, causing gaps in metric collection. The cluster has a dedicated monitoring namespace. The team has already increased the Prometheus pod's memory limits to 8GB, but OOMs still occur. The metrics retention is set to 15 days. The cardinality of certain metrics (e.g., HTTP request labels with user IDs) is very high. The team needs to resolve the OOM issue without losing critical alerting capability for at least the last 7 days of data. Which action should they take first?

A.Implement recording rules to pre-aggregate high-cardinality metrics at a lower granularity
B.Drop high-cardinality metrics like HTTP request labels using relabel_configs
C.Reduce metrics retention to 7 days to free memory
D.Enable vertical pod autoscaler for the Prometheus pod
AnswerA

Recording rules reduce cardinality by aggregating metrics, lowering memory usage while preserving aggregated data for alerting.

Why this answer

Recording rules allow Prometheus to pre-aggregate high-cardinality metrics (e.g., HTTP request labels with user IDs) at a lower granularity, reducing the number of unique time series stored in memory. This directly addresses the OOM issue caused by cardinality explosion without discarding raw data entirely, preserving the ability to query aggregated metrics for alerting over the required 7-day window.

Exam trap

The trap here is confusing memory pressure (caused by cardinality) with storage pressure (caused by retention), leading candidates to incorrectly choose reducing retention (Option C) instead of addressing the root cause of high cardinality via recording rules.

How to eliminate wrong answers

Option B is wrong because dropping high-cardinality metrics entirely using relabel_configs would remove critical data needed for alerting and debugging, violating the requirement to retain alerting capability for at least 7 days. Option C is wrong because reducing retention to 7 days frees disk space, not memory; Prometheus OOMs are caused by in-memory time series cardinality, not storage volume. Option D is wrong because enabling vertical pod autoscaler would only adjust CPU/memory limits dynamically, but the fundamental issue is cardinality—more memory without reducing cardinality will still lead to OOM kills.

757
MCQeasy

Which Kubernetes control plane component is responsible for maintaining the desired state of the cluster by running controllers?

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

Why this answer

The kube-controller-manager is the control plane component that runs controller processes, which are control loops that watch the shared state of the cluster through the kube-apiserver and make changes to bring the current state closer to the desired state. It bundles together multiple controllers (e.g., Node Controller, Replication Controller, Endpoint Controller, Service Account Controller) that each handle a specific aspect of cluster management, ensuring the cluster's actual state matches the user-defined desired state.

Exam trap

A common misconception is that etcd is responsible for maintaining the desired state because it stores the desired state. However, etcd is only a passive data store, while the kube-controller-manager is the active component that performs the actual reconciliation to enforce that state.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning newly created pods to nodes based on resource availability, policies, and constraints, not for maintaining the desired state via controllers. Option B is wrong because etcd is a distributed key-value store that serves as the cluster's backing store for all cluster data, but it does not run controllers or actively reconcile state; it only stores and retrieves the desired and current state. Option D is wrong because kube-apiserver is the front-end for the Kubernetes control plane that exposes the Kubernetes API, handles authentication, authorization, and validation of API requests, but it does not run the controller loops that enforce desired state.

758
MCQeasy

Which of the following is a key difference between containers and virtual machines?

A.Containers share the host OS kernel; VMs run a separate guest OS
B.Both containers and VMs share the host kernel
C.Containers have a full guest OS, VMs share the host kernel
D.Containers require a hypervisor, VMs do not
AnswerA

Containers are lightweight because they share the kernel.

Why this answer

The key difference is that containers virtualize at the operating system level, sharing the host OS kernel via namespaces and cgroups, while each virtual machine runs a full, separate guest OS on top of a hypervisor. This architectural distinction means containers are more lightweight and start faster, but VMs provide stronger isolation because they do not share the host kernel.

Exam trap

CNCF often tests the misconception that containers and VMs are fundamentally similar in kernel sharing, leading candidates to choose Option B, which incorrectly claims both share the host kernel.

How to eliminate wrong answers

Option B is wrong because it states both containers and VMs share the host kernel; in reality, VMs run a separate guest OS with its own kernel and do not share the host kernel. Option C is wrong because it reverses the relationship: containers do not have a full guest OS—they share the host kernel—while VMs run a full guest OS. Option D is wrong because it claims containers require a hypervisor and VMs do not; in fact, VMs require a hypervisor (Type 1 or Type 2) to manage guest OSes, while containers run directly on the host OS without a hypervisor.

759
MCQmedium

A Kubernetes cluster has a Deployment running three replicas of an application. You need to update the container image to a new version with zero downtime. Which approach is most appropriate?

A.Use 'kubectl set image deployment/<name> <container>=<new-image>' to trigger a rolling update
B.Manually delete each pod and rely on the ReplicaSet to recreate them with the new image
C.Delete the Deployment and recreate it with the new image
D.Scale the Deployment to zero and then scale back up with the new image
AnswerA

This command updates the image and initiates a rolling update, ensuring zero downtime.

Why this answer

`kubectl set image deployment/<name> <container>=<new-image>` triggers a rolling update, which is the default update strategy for Deployments. This gradually replaces old pods with new ones, ensuring that the desired number of replicas is always available, thus achieving zero downtime.

Exam trap

CNCF often tests the misconception that manually deleting pods or scaling to zero is a valid zero-downtime strategy, but these actions cause service disruption because they do not maintain the desired number of available replicas during the update.

How to eliminate wrong answers

Option B is wrong because manually deleting pods does not update the Deployment's pod template; the ReplicaSet will recreate pods using the old image, not the new one. Option C is wrong because deleting the Deployment causes a period of unavailability until the new Deployment is created and pods are scheduled, violating zero downtime. Option D is wrong because scaling to zero removes all pods, causing downtime, and scaling back up with a new image requires a separate update step, which is not a zero-downtime approach.

760
MCQmedium

A team uses Flux to manage GitOps. Which Flux component is responsible for reconciling the cluster state with the desired state defined in a Git repository?

A.Kustomize Controller
B.Source Controller
C.Helm Controller
D.Notification Controller
AnswerA

Why this answer

In Flux, the Kustomize Controller (option A) is responsible for reconciling the cluster state with the desired state defined in a Git repository. It applies Kubernetes manifests, including Kustomize overlays, to the cluster to ensure the actual state matches the desired state. The Source Controller (option B) fetches source artifacts from Git or other sources, but does not perform reconciliation.

The Helm Controller (option C) manages Helm releases, and the Notification Controller (option D) handles event notifications. Therefore, the correct answer is the Kustomize Controller.

761
MCQmedium

Which of the following is a way to provide configuration data to a pod without baking it into the container image?

A.Using a ConfigMap
B.Using an annotation
C.Using a Secret
D.Using a PersistentVolume
AnswerA

ConfigMaps store configuration data that can be consumed by pods as environment variables or files.

Why this answer

A ConfigMap is a Kubernetes API object used to decouple configuration artifacts from container images, allowing you to inject configuration data (e.g., environment variables, command-line arguments, or configuration files) into pods without rebuilding the image. This is the standard way to provide non-sensitive configuration data to pods at runtime, as defined in the Kubernetes documentation.

Exam trap

Candidates often select Secret because they think all configuration data should be secure, but ConfigMap is intended for non-sensitive data.

How to eliminate wrong answers

Option B is wrong because an annotation is metadata attached to a Kubernetes object (like a pod) for non-identifying information, such as tooling hints or build details; it is not designed to be consumed as configuration data by the pod's containers. Option C is wrong because while a Secret can provide configuration data (e.g., passwords, tokens), it is specifically intended for sensitive information and is not the general-purpose mechanism for non-sensitive configuration; the question asks for a way to provide configuration data without baking it into the image, and both ConfigMap and Secret can do that, but ConfigMap is the correct answer for non-sensitive data. Option D is wrong because a PersistentVolume is a storage resource that provides persistent storage to pods via a PersistentVolumeClaim, not a mechanism for injecting configuration data like environment variables or files.

762
Multi-Selecthard

Which THREE of the following are components of the OpenTelemetry project? (Select three)

Select 3 answers
A.OpenTelemetry Agent
B.OpenTelemetry API
C.OpenTelemetry SDK
D.OpenTelemetry Collector
E.OpenTelemetry Exporter
AnswersB, C, D

The API defines data types and interfaces.

Why this answer

The OpenTelemetry project includes the API, SDK, and Collector. The Agent (as a separate component) and Exporter are part of the SDK/Collector, not standalone components.

763
MCQeasy

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

A.To manage container networking
B.To define a standard for container images
C.To orchestrate multi-container pods
D.To allow kubelet to communicate with different container runtimes
AnswerD

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

Why this answer

The Container Runtime Interface (CRI) is a plugin interface that enables the kubelet to use a variety of container runtimes without needing to recompile the Kubernetes components. It defines the API for creating, starting, stopping, and deleting containers, allowing the kubelet to communicate with runtimes like containerd, CRI-O, or Docker (via dockershim, now deprecated). Option D is correct because the CRI's primary purpose is to abstract the runtime implementation from the kubelet, enabling interoperability.

Exam trap

The trap here is that candidates confuse the CRI with the CNI or OCI, assuming the CRI manages networking or image standards, when in fact it strictly defines the runtime API for container lifecycle operations.

How to eliminate wrong answers

Option A is wrong because container networking is managed by the Container Network Interface (CNI), not the CRI. Option B is wrong because container image standards are defined by the Open Container Initiative (OCI) image spec, not the CRI. Option C is wrong because orchestrating multi-container pods is a core function of the kubelet and the Kubernetes control plane, not the CRI; the CRI only handles the low-level runtime operations for individual containers within a pod.

764
MCQhard

A user reports that they cannot connect to a Service from within the cluster. The Service is of type ClusterIP. Running 'kubectl get endpoints service-name' shows no endpoints. What is the most likely cause?

A.The Service is not associated with a namespace
B.The Service is exposed on the wrong port
C.The kube-proxy is not running on the node
D.The Service's pod selector does not match any running pods
AnswerD

Endpoints are created by matching pods with the selector; if none match, endpoints are empty.

Why this answer

If endpoints are empty, the Service selector does not match any pods, or the pods are not ready.

765
Multi-Selecthard

Which TWO of the following are examples of context propagation mechanisms used in distributed tracing?

Select 2 answers
A.HTTP headers
B.Environment variables
C.Database queries
D.Shared filesystem
E.gRPC metadata
AnswersA, E

Headers like traceparent are used to propagate trace context across HTTP calls.

Why this answer

HTTP headers, such as the `traceparent` and `tracestate` headers defined in the W3C Trace Context specification, are the standard mechanism for propagating trace context across service boundaries in distributed tracing. When a service receives an incoming HTTP request, it extracts the trace ID and span ID from these headers to continue the same trace. This allows trace data to be correlated across multiple microservices as the request flows through the system.

Exam trap

CNCF often tests the distinction between static configuration mechanisms (like environment variables or shared filesystems) and dynamic, in-band propagation mechanisms (like HTTP headers and gRPC metadata) that travel with each request.

766
Multi-Selectmedium

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

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

Counter is a Prometheus metric type.

Why this answer

Prometheus has four metric types: Counter, Gauge, Histogram, and Summary. Counter and Gauge are two of them.

767
MCQmedium

You need to store a database password securely and expose it to a Pod as an environment variable. Which Kubernetes resource should you use?

A.Service
B.PersistentVolumeClaim
C.Secret
D.ConfigMap
AnswerC

Secrets store sensitive data, such as passwords, and can be injected into Pods as environment variables or volumes.

Why this answer

A Secret is the correct Kubernetes resource for storing sensitive data like database passwords because it encodes the value in base64 and can be injected into a Pod as an environment variable. Unlike ConfigMaps, Secrets are designed for confidential information and support optional encryption at rest when etcd is configured accordingly.

Exam trap

Many candidates mistakenly assume that ConfigMaps are suitable for all configuration data, including passwords. However, Secrets are specifically designed for sensitive information and support optional encryption at rest, whereas ConfigMaps store data in plain text.

How to eliminate wrong answers

Option A is wrong because a Service is a network abstraction that exposes a set of Pods as a stable endpoint, not a storage mechanism for sensitive data. Option B is wrong because a PersistentVolumeClaim is used to request persistent storage volumes for Pods, not for storing small secret values like passwords. Option D is wrong because a ConfigMap stores non-sensitive configuration data in plain text and is not intended for secrets; using it for a password would expose the value in clear text.

768
MCQmedium

A developer needs to deploy a stateless application with three replicas and ensure that updates are rolled out with zero downtime. Which Kubernetes resource is most appropriate?

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

Deployment manages ReplicaSets and supports rolling updates.

Why this answer

A Deployment is the correct resource because it manages a ReplicaSet to ensure the desired number of pod replicas (three) are running, and it supports rolling updates with configurable strategies (e.g., maxSurge and maxUnavailable) to achieve zero-downtime updates. Stateless applications are ideal for Deployments since pods are interchangeable and can be replaced without data loss.

Exam trap

The trap here is that candidates might choose StatefulSet because they associate 'replicas' with stateful workloads, but the question explicitly states 'stateless application,' making Deployment the correct choice for rolling updates with zero downtime.

How to eliminate wrong answers

Option B is wrong because StatefulSet is designed for stateful applications requiring stable, unique network identities and persistent storage, not for stateless apps, and its rolling update behavior is more conservative (e.g., pod ordinal ordering) but still can achieve zero downtime; however, it is not the most appropriate for a stateless app. Option C is wrong because a Job is intended for batch or one-time tasks that run to completion, not for continuously running stateless applications with multiple replicas or rolling updates. Option D is wrong because a DaemonSet ensures one pod per node (or a subset) for cluster-wide services like logging or monitoring, not for deploying a specific number of replicas (three) across the cluster.

769
MCQeasy

Which kubectl command would you use to view the detailed state of a pod named 'web-pod' in the 'default' namespace?

A.kubectl logs web-pod
B.kubectl get pod web-pod
C.kubectl describe pod web-pod
D.kubectl exec web-pod -- /bin/sh
AnswerC

Correct. 'kubectl describe' gives detailed information including events.

Why this answer

`kubectl describe pod web-pod` retrieves a detailed, multi-section view of the pod's current state, including events, conditions, container statuses, and resource usage. This command is specifically designed for deep inspection of a Kubernetes resource, unlike `kubectl get` which shows a summary, or `kubectl logs` which shows container output.

Exam trap

The trap here is that candidates confuse `kubectl get` (which shows a summary) with `kubectl describe` (which shows detailed state), especially when the question asks for 'detailed state' — CNCF often tests this distinction by making the summary command look plausible at first glance.

How to eliminate wrong answers

Option A is wrong because `kubectl logs web-pod` fetches the stdout/stderr logs from the pod's containers, not the pod's detailed state or configuration. Option B is wrong because `kubectl get pod web-pod` outputs a concise, one-line summary of the pod (name, ready status, restarts, age) without the detailed events, conditions, or container-level information. Option D is wrong because `kubectl exec web-pod -- /bin/sh` opens an interactive shell inside the pod's primary container, which is used for debugging or running commands inside the container, not for viewing the pod's state.

770
MCQeasy

A developer creates a pod that needs to securely access a database password stored in the cluster. Which Kubernetes resource should be used to inject the password as an environment variable?

A.Secret
B.ServiceAccount
C.ConfigMap
D.PersistentVolumeClaim
AnswerA

Correct; Secrets store sensitive data like passwords.

Why this answer

A Secret is the correct Kubernetes resource for injecting sensitive data like a database password into a Pod as an environment variable. Secrets store base64-encoded data and are designed specifically for confidential information, unlike ConfigMaps which store non-sensitive configuration. When mounted as environment variables, Secrets ensure the password is not exposed in plaintext in the Pod specification or image layers.

Exam trap

CNCF often tests the distinction between ConfigMaps and Secrets, trapping candidates who assume ConfigMaps can handle sensitive data because both resources can inject environment variables, but Secrets are the only secure choice for passwords.

How to eliminate wrong answers

Option B (ServiceAccount) is wrong because a ServiceAccount provides an identity for Pods to authenticate to the Kubernetes API server, not a mechanism to store or inject sensitive data like passwords. Option C (ConfigMap) is wrong because ConfigMaps are intended for non-sensitive configuration data; storing a password in a ConfigMap would violate security best practices and expose the secret in plaintext. Option D (PersistentVolumeClaim) is wrong because a PVC is used to request storage resources from a PersistentVolume, not to inject environment variables or store secrets.

771
MCQhard

Which Kubernetes resource can be used to define network policies that control traffic between pods?

A.Service
B.PodSecurityPolicy
C.NetworkPolicy
D.Ingress
AnswerC

Correct. NetworkPolicy defines rules for pod-to-pod communication.

Why this answer

NetworkPolicy is a Kubernetes resource that defines how groups of pods are allowed to communicate with each other and other network endpoints. It works by specifying ingress and egress rules using pod selectors, namespace selectors, and IP blocks, and is enforced by a network plugin (CNI) that supports it, such as Calico or Cilium.

Exam trap

CNCF often tests the misconception that Ingress or Service can restrict pod-to-pod traffic, but Ingress only handles external HTTP/HTTPS traffic and Service only provides connectivity, not policy enforcement.

How to eliminate wrong answers

Option A is wrong because a Service is an abstraction that exposes a set of pods as a network service, but it does not control traffic between pods via rules; it only provides stable endpoints and load balancing. Option B is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) controls security-sensitive aspects of pod specification (e.g., privilege escalation, host namespaces), not network traffic between pods. Option D is wrong because an Ingress manages external HTTP/HTTPS traffic to services inside the cluster, not east-west traffic between pods.

772
MCQmedium

You have a Deployment named 'web-app' with 3 replicas. You need to scale it to 5 replicas. Which kubectl command should you use?

A.kubectl create deployment web-app --replicas=5
B.kubectl scale deployment web-app --replicas=5
C.kubectl edit deployment web-app --replicas=5
D.kubectl describe deployment web-app
AnswerB

The scale command changes the replica count of the deployment.

Why this answer

The `kubectl scale` command is the correct way to adjust the replica count of an existing Deployment. It directly modifies the `spec.replicas` field in the Deployment's desired state, instructing the ReplicaSet controller to create or delete Pods to match the new count. Option B uses the correct syntax `kubectl scale deployment web-app --replicas=5` to achieve this.

Exam trap

The trap here is that candidates confuse `kubectl create` with `kubectl scale`, thinking they can reuse the create command with a different replica count to update an existing Deployment, when in fact `create` is only for initial creation and will fail or overwrite the resource.

How to eliminate wrong answers

Option A is wrong because `kubectl create deployment` creates a new Deployment from scratch, not scaling an existing one; using `--replicas=5` would create a new Deployment named 'web-app' (or fail if it already exists), overwriting the original configuration and ignoring the existing 3 replicas. Option C is wrong because `kubectl edit deployment` opens an interactive editor for manual YAML/JSON modification, not a direct scaling command; the `--replicas` flag is not valid with `edit`, and the user would need to manually change the `spec.replicas` field, which is inefficient and error-prone. Option D is wrong because `kubectl describe deployment` only displays the current state and details of the Deployment, including its replica count, but does not perform any scaling action.

773
MCQeasy

Which tool is used to manage infrastructure as code and can provision resources across multiple cloud providers?

A.Helm
B.Terraform
C.Ansible
D.AWS CloudFormation
AnswerB

Terraform supports multiple providers.

Why this answer

Terraform is the correct tool because it is an open-source infrastructure as code (IaC) software tool by HashiCorp that uses declarative configuration files (HCL) to provision and manage resources across multiple cloud providers (AWS, Azure, GCP, etc.) via provider plugins. Unlike single-cloud tools, Terraform's provider architecture allows it to manage heterogeneous environments consistently, making it the standard multi-cloud IaC solution.

Exam trap

CNCF often tests the distinction between configuration management tools (Ansible) and infrastructure provisioning tools (Terraform), leading candidates to pick Ansible because they associate 'automation' with infrastructure, but Ansible lacks native multi-cloud resource lifecycle management and state tracking.

How to eliminate wrong answers

Option A is wrong because Helm is a package manager for Kubernetes that deploys and manages applications on Kubernetes clusters using charts, not a tool for provisioning infrastructure across multiple cloud providers. Option C is wrong because Ansible is primarily a configuration management and automation tool that uses procedural playbooks (YAML) and agentless SSH/PowerShell connections, but it is not designed as a declarative IaC tool for multi-cloud resource provisioning; it focuses on state enforcement on existing servers rather than resource lifecycle management. Option D is wrong because AWS CloudFormation is a native AWS service that provisions resources only within the AWS ecosystem using JSON/YAML templates, and it cannot manage resources across other cloud providers like Azure or GCP.

774
MCQmedium

A company is adopting a multi-cloud strategy to avoid vendor lock-in. Which pattern BEST supports deploying applications across different cloud providers with minimal changes?

A.Use a hybrid cloud approach with a single cloud for all workloads
B.Deploy applications using Kubernetes on each cloud
C.Use each cloud provider's native services directly
D.Write application code that checks the cloud provider and adapts
AnswerB

Kubernetes provides a portable platform that abstracts underlying infrastructure differences.

Why this answer

Using Kubernetes as a consistent abstraction layer allows applications to run across different cloud providers with minimal modifications since it uses a common API and container orchestration. Cloud-specific APIs would lock you in, and hybrid cloud typically refers to mixing public and private cloud, not necessarily multi-cloud.

775
MCQhard

Your application consists of a frontend and a backend. The frontend needs to communicate with the backend using a stable DNS name. The backend is deployed as a Deployment with 3 replicas. Which Kubernetes resource should you create to provide a stable DNS name for the backend?

A.EndpointSlice
B.Service of type NodePort
C.Ingress
D.Service of type ClusterIP
AnswerD

A ClusterIP Service provides a stable internal IP and DNS name for pod-to-pod communication within the cluster.

Why this answer

A Service of type ClusterIP provides a stable virtual IP and DNS name (e.g., my-service.namespace.svc.cluster.local) that load-balances traffic across the backend Pods. This is the correct resource because the frontend only needs a stable DNS name for internal cluster communication, and ClusterIP is the default Service type that fulfills this requirement without exposing the backend externally.

Exam trap

CNCF often tests the misconception that a Service of type NodePort is required for any DNS-based communication, but the trap here is that ClusterIP is the correct choice for internal cluster DNS stability, while NodePort is only needed for external access.

How to eliminate wrong answers

Option A is wrong because EndpointSlice is a resource that tracks network endpoints (IPs and ports) for a Service, but it does not provide a DNS name or stable endpoint itself. Option B is wrong because a Service of type NodePort exposes the backend on a static port on every Node's IP, which is intended for external access and introduces unnecessary exposure and complexity for internal-only communication. Option C is wrong because Ingress is an API object that manages external HTTP/HTTPS routing to Services, not a resource that provides a stable DNS name for internal cluster communication.

776
MCQhard

A team notices that a ReplicaSet is not creating the desired number of pods. The ReplicaSet YAML is correctly configured with replicas: 3. The cluster has sufficient resources. What is the most likely cause?

A.The ReplicaSet is paused
B.The pod template references an invalid image pull secret
C.The nodeSelector does not match any node
D.A ResourceQuota in the namespace limits the number of pods
AnswerB

Invalid image pull secret would cause pods to fail with ImagePullBackOff, reducing the ready count.

Why this answer

An invalid image pull secret in the pod template prevents the kubelet from authenticating with the container registry, causing the pod creation to fail. The ReplicaSet controller attempts to create pods, but the scheduler cannot pull the image, so the pods remain in a pending or ImagePullBackOff state, never reaching the desired count of 3.

Exam trap

The trap here is that candidates often assume a nodeSelector mismatch or ResourceQuota is the issue, but the question specifies 'not creating the desired number of pods' — a nodeSelector mismatch still creates the pod object, while an invalid image pull secret prevents the pod from becoming Ready, causing the ReplicaSet to appear to not create pods when in fact it creates them but they fail to run.

How to eliminate wrong answers

Option A is wrong because ReplicaSets do not have a 'paused' field; only Deployments have a paused status, which suspends rollout but does not affect ReplicaSet pod creation directly. Option C is wrong because if the nodeSelector does not match any node, the scheduler cannot place the pod, but the ReplicaSet would still create the pod object (it would remain in Pending state), not fail to create it entirely. Option D is wrong because a ResourceQuota limits the total number of pods in a namespace, but the question states the cluster has sufficient resources, and a quota would cause pod creation to fail with a specific error, not silently prevent creation; the ReplicaSet would still attempt to create pods and report the quota violation.

777
Multi-Selectmedium

Which THREE of the following are DORA metrics?

Select 3 answers
A.Mean time to restore (MTTR)
B.Lead time for changes
C.Deployment frequency
D.Code coverage
E.Number of deployments per developer
AnswersA, B, C

It measures the time to recover from a failure.

Why this answer

Mean time to restore (MTTR) is one of the four key DORA metrics defined by the DevOps Research and Assessment (DORA) team. It measures the average time it takes to recover from a failure in a production environment, directly reflecting the resilience and incident response capability of a cloud-native system. In Kubernetes, this often involves automated rollback strategies, pod rescheduling, or canary deployments to minimize downtime.

Exam trap

CNCF often tests candidates by including plausible but non-DORA metrics like code coverage or deployment counts, exploiting the misconception that any useful DevOps metric qualifies as a DORA metric, when in fact only the four specific metrics (deployment frequency, lead time for changes, mean time to restore, and change failure rate) are officially defined.

778
MCQhard

A Pod is in 'CrashLoopBackOff' state. You run 'kubectl logs <pod>' and see an error that the application cannot bind to port 8080 because the port is already in use. What is the most likely cause?

A.The container's health check is misconfigured
B.The container runtime is not installed
C.The Pod's resource limits are too low
D.Another process inside the container is already using port 8080
AnswerD

If the application or another process occupies the port, the app cannot bind.

Why this answer

The 'CrashLoopBackOff' state indicates the container repeatedly starts, fails, and is restarted by the kubelet. The error message 'port is already in use' means the application inside the container cannot bind to port 8080 because another process within the same container's network namespace is already listening on that port. This is a classic application-level conflict, not a Kubernetes configuration issue.

Exam trap

The trap here is that candidates may confuse a container-level port conflict with a Kubernetes-level port conflict (e.g., hostPort or NodePort collision), but the error originates from inside the container's own network namespace, not from the host or cluster networking layer.

How to eliminate wrong answers

Option A is wrong because a misconfigured health check (e.g., liveness or readiness probe) would cause the Pod to be restarted due to probe failures, but the specific error 'port is already in use' is not a probe-related message; it is a bind system call failure. Option B is wrong because if the container runtime were not installed, the Pod would never reach the 'Running' state, let alone 'CrashLoopBackOff'; the kubelet would fail to start the container entirely. Option C is wrong because insufficient resource limits (CPU/memory) would cause the container to be OOMKilled or throttled, resulting in 'OOMKilled' or 'CrashLoopBackOff' with resource-related errors, not a 'port already in use' bind error.

779
MCQmedium

You have a pod that needs to securely access a database password. Which Kubernetes resource should you use to store the password?

A.ServiceAccount
B.Secret
C.ConfigMap
D.PersistentVolume
AnswerB

Secrets store sensitive data and are base64 encoded.

Why this answer

A Kubernetes Secret is specifically designed to store sensitive data, such as database passwords, in a base64-encoded format. Secrets can be mounted as volumes or exposed as environment variables in a pod, ensuring the password is not stored in plaintext in the pod specification or container image.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming both can store sensitive data, but ConfigMaps store data in plaintext and lack the security features of Secrets, such as encryption at rest and RBAC controls.

How to eliminate wrong answers

Option A is wrong because a ServiceAccount is an identity for processes running in a pod, used for authentication to the Kubernetes API server, not for storing sensitive data like passwords. Option C is wrong because a ConfigMap is intended for non-confidential configuration data, such as environment variables or configuration files, and does not provide encryption or security for sensitive values. Option D is wrong because a PersistentVolume is a storage resource for persistent data in a cluster, not a mechanism for storing secrets or passwords.

780
Multi-Selecthard

Which three of the following are true about etcd in Kubernetes?

Select 3 answers
A.etcd stores all cluster state, including Pods, ConfigMaps, and Secrets
B.etcd is a relational database
C.etcd is a distributed, consistent key-value store
D.etcd can be used as a message queue
E.etcd supports watches to monitor changes to keys
AnswersA, C, E

etcd is the backing store for all cluster data.

Why this answer

Etcd is the primary datastore for Kubernetes, storing all cluster state including objects like Pods, ConfigMaps, and Secrets. This ensures that the Kubernetes API server has a consistent, authoritative source of truth for the entire cluster.

Exam trap

The trap here is that candidates may confuse etcd's watch functionality with message queuing, or incorrectly assume that any database with key-value storage is relational, leading them to select options B or D.

781
MCQmedium

What is the difference between a liveness probe and a readiness probe?

A.Liveness probe checks if the container is ready to serve traffic
B.Readiness probe indicates if the container is healthy; liveness indicates if it should be restarted
C.Liveness probe indicates if the container is alive; if it fails, the container is restarted
D.Both probes serve the same purpose but with different endpoints
AnswerC

Liveness probes restart unhealthy containers; readiness probes control traffic routing.

Why this answer

A liveness probe determines if a container is still running (alive). If the liveness probe fails, Kubernetes restarts the container based on the `restartPolicy`. This is distinct from a readiness probe, which checks if a container is ready to accept traffic and removes it from Service endpoints if it fails.

Exam trap

The trap here is that candidates confuse the purpose of liveness and readiness probes, often thinking liveness controls traffic routing or that readiness triggers restarts, when in fact liveness governs restarts and readiness governs traffic inclusion.

How to eliminate wrong answers

Option A is wrong because it describes the function of a readiness probe, not a liveness probe; a liveness probe checks if the container is alive, not if it is ready to serve traffic. Option B is wrong because it reverses the roles: a readiness probe indicates if the container is ready to serve traffic, while a liveness probe indicates if it is healthy (alive) and should be restarted on failure. Option D is wrong because the two probes serve different purposes—liveness for restarting unhealthy containers, readiness for traffic routing—and they can use different endpoints (e.g., `/healthz` vs `/ready`).

782
Multi-Selectmedium

Which TWO statements about Kubernetes Services are correct?

Select 2 answers
A.A Service can expose only one container port
B.A Service can only route traffic to pods on the same node as the Service
C.The default Service type is ClusterIP
D.A Service provides a stable IP address and DNS name for a set of pods
E.A Service of type NodePort exposes the service only on the node where the pod is running
AnswersC, D

If no type is specified, ClusterIP is used.

Why this answer

The default Service type in Kubernetes is ClusterIP, which exposes the Service on a cluster-internal IP address. This means the Service is only reachable from within the cluster, providing a stable internal endpoint for pod-to-pod communication without external exposure.

Exam trap

The KCNA exam often tests the misconception that a Service can only expose one port or that NodePort is node-specific, when in fact multiple ports are supported and NodePort opens the port on every node in the cluster.

783
MCQmedium

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

A.It ensures the desired number of pods are running
B.It runs the container runtime
C.It reports node status to the control plane
D.It implements part of the Kubernetes Service concept by managing network rules
AnswerD

kube-proxy handles IP tables/IPVS rules for service load balancing.

Why this answer

kube-proxy runs on each worker node and is responsible for implementing the Kubernetes Service abstraction by managing network rules (e.g., iptables, IPVS, or userspace mode). It watches the API server for Service and EndpointSlice changes and configures local packet filtering or forwarding rules to route traffic to the correct backend pods, enabling load balancing and service discovery.

Exam trap

A common misconception is that kube-proxy handles pod lifecycle or node health reporting, when in fact those are kubelet responsibilities. Candidates often confuse the 'proxy' name with general node management.

How to eliminate wrong answers

Option A is wrong because ensuring the desired number of pods are running is the function of the ReplicaSet controller and the kubelet, not kube-proxy. Option B is wrong because running the container runtime (e.g., containerd, CRI-O) is the responsibility of the kubelet, which interacts with the CRI, while kube-proxy handles network proxying. Option C is wrong because reporting node status to the control plane is a core function of the kubelet, which sends NodeStatus updates via the Kubernetes API, not kube-proxy.

784
Multi-Selectmedium

Which TWO statements about containers compared to virtual machines are correct? (Select 2)

Select 2 answers
A.Containers have lower overhead than virtual machines
B.Containers are lightweight and share the host OS kernel
C.Virtual machines share the host OS kernel
D.Each container runs its own operating system kernel
E.Virtual machines provide weaker isolation than containers
AnswersA, B

Containers do not need a full guest OS, so they have lower overhead.

Why this answer

Options A and B are correct. Containers have lower overhead than virtual machines because they do not require a separate guest OS per instance, making them more lightweight. Containers share the host OS kernel, which allows them to be efficient and portable.

In contrast, each virtual machine includes a full guest OS running on top of a hypervisor, leading to higher resource usage. Option C is false because virtual machines have their own kernel, not shared with the host. Option D is false because containers share the host kernel and do not run their own OS kernel.

Option E is false because virtual machines provide stronger isolation due to hardware virtualization.

785
MCQmedium

A DevOps engineer notices that after a Helm upgrade, the new pods are crash looping with 'ImagePullBackOff'. What is the most likely cause?

A.The pod's liveness probe is misconfigured
B.The Helm chart has a wrong image tag
C.The service account lacks permissions
D.The deployment's resource requests exceed node capacity
AnswerB

A mistyped or non-existent tag leads to pull failures.

Why this answer

The 'ImagePullBackOff' error indicates that Kubernetes is unable to pull the container image from the registry. The most common cause during a Helm upgrade is a misconfigured or incorrect image tag in the Helm chart's values or templates, which causes the kubelet to fail when attempting to pull the specified image. This is distinct from runtime issues like probe failures or resource constraints, which would manifest as different error states.

Exam trap

CNCF often tests the distinction between pre-start errors (ImagePullBackOff, ErrImagePull) and runtime errors (CrashLoopBackOff, probe failures), so candidates mistakenly associate any pod failure with liveness probes or resource constraints rather than image availability.

How to eliminate wrong answers

Option A is wrong because a misconfigured liveness probe would cause the pod to be restarted or killed after starting (e.g., 'CrashLoopBackOff' with a running container), not an 'ImagePullBackOff' which occurs before the container can even start. Option C is wrong because service account permissions affect API access (e.g., for listing secrets or interacting with the Kubernetes API), not the ability to pull container images from a registry; image pull failures are governed by image pull secrets and registry authentication, not RBAC on the cluster. Option D is wrong because resource requests exceeding node capacity would result in a 'Pending' or 'Unschedulable' pod status, not 'ImagePullBackOff', which is a pull-time error unrelated to scheduling.

786
MCQmedium

Which component of the metrics-server provides resource metrics like CPU and memory usage?

A.kube-apiserver
B.metrics-server
C.kubelet
D.Prometheus
AnswerB

The metrics-server is the component that collects and serves resource metrics.

Why this answer

The metrics-server collects resource metrics from kubelets and exposes them via the Metrics API.

787
MCQhard

You have a microservices application where Service A needs to discover the IP of Service B. Both services run in the same Kubernetes cluster. Which approach is the most Kubernetes-native way for Service A to reach Service B?

A.Use the Kubernetes DNS service to resolve the Service name 'service-b'
B.Use an external service registry like Consul or etcd
C.Hardcode the cluster IP of Service B in the configuration of Service A
D.Use environment variables injected by the Kubernetes API into each pod
AnswerA

Kubernetes DNS automatically creates DNS records for Services, making this the standard approach for service discovery.

Why this answer

Kubernetes has a built-in DNS service (typically CoreDNS) that automatically creates DNS records for Services. When Service A resolves the name 'service-b' (or 'service-b.<namespace>.svc.cluster.local'), the DNS returns the cluster IP of Service B's Service object, which then load-balances traffic to the healthy Pods. This is the most Kubernetes-native approach because it leverages the platform's own service discovery mechanism without external dependencies.

Exam trap

The trap here is that candidates may think environment variables (Option D) are the primary Kubernetes-native method, but the exam emphasizes DNS as the modern, recommended approach, while environment variables are a legacy fallback with limitations.

How to eliminate wrong answers

Option B is wrong because using an external service registry like Consul or etcd adds unnecessary complexity and is not Kubernetes-native; Kubernetes already provides DNS-based service discovery. Option C is wrong because hardcoding the cluster IP of Service B is fragile — cluster IPs can change if the Service is recreated, and this approach does not handle scaling or Pod restarts. Option D is wrong because while Kubernetes does inject environment variables (e.g., SERVICE_B_SERVICE_HOST) for Services created before the Pod, this method is deprecated, less reliable (depends on Pod creation order), and does not update dynamically if the Service IP changes.

788
MCQhard

A CI pipeline scans container images for vulnerabilities. The scan report shows a critical vulnerability in a base image layer. What is the most efficient way to remediate this issue?

A.Update the base image to a patched version and rebuild the application image
B.Use a runtime security tool to block exploitation
C.Apply a security patch directly to the running container
D.Ignore the vulnerability if the application code is not affected
AnswerA

Updating the base image and rebuilding ensures the vulnerability is removed from all layers.

Why this answer

Rebuilding the image with an updated base image that includes the security fix is the standard approach to address base image vulnerabilities.

789
MCQhard

A pod has resource requests set to 'cpu: 500m' and 'memory: 256Mi'. The node has 2 CPU cores and 4Gi memory. How many pods with the same resource requests can be scheduled on that node, assuming no other pods?

A.2
B.4
C.8
D.16
AnswerB

CPU is the bottleneck; 2000m / 500m = 4.

Why this answer

Each pod requests 0.5 CPU cores (500m) and 256 MiB of memory. The node has 2 CPU cores, so the CPU limit allows 2 / 0.5 = 4 pods. The node has 4 GiB of memory (4096 MiB), so the memory limit allows 4096 / 256 = 16 pods.

The tighter constraint is CPU, which permits exactly 4 pods. Option B is correct.

Exam trap

Candidates often mistakenly calculate the maximum number of pods based on memory (16) instead of CPU (4), since memory appears less restrictive. However, CPU is the tighter constraint in this scenario.

How to eliminate wrong answers

Option A is wrong because it assumes only 2 pods can fit, likely confusing the 2 CPU cores with the number of pods without dividing by the per-pod request of 500m. Option C is wrong because 8 pods would require 8 * 500m = 4 CPU cores, which exceeds the node's 2 cores. Option D is wrong because 16 pods would require 16 * 500m = 8 CPU cores, far beyond the node's capacity, even though memory alone could support 16 pods.

790
MCQmedium

You need to securely store a database password for use by a Pod. Which Kubernetes resource should you use?

A.Secret
B.PersistentVolumeClaim
C.ServiceAccount
D.ConfigMap
AnswerA

Secrets are intended for sensitive information.

Why this answer

A Secret is the correct Kubernetes resource for storing sensitive data like database passwords because it encodes the value in base64 and can be mounted as a volume or injected as an environment variable into a Pod. Unlike ConfigMaps, Secrets are designed for confidential information and support optional encryption at rest when enabled in the cluster. This ensures the password is not stored in plaintext in the Pod specification or version control.

Exam trap

CNCF often tests the misconception that ConfigMaps are suitable for all configuration data, including sensitive values, but the KCNA exam expects you to know that Secrets are the dedicated resource for confidential information like passwords and API keys.

How to eliminate wrong answers

Option B (PersistentVolumeClaim) is wrong because it is used to request storage volumes for Pods, not to store sensitive configuration data like passwords. Option C (ServiceAccount) is wrong because it provides an identity for Pods to authenticate with the Kubernetes API server, not a mechanism for storing secrets. Option D (ConfigMap) is wrong because it is intended for non-sensitive configuration data; storing a password in a ConfigMap would expose it in plaintext and violate security best practices.

791
Multi-Selecthard

Which THREE of the following are core components of Flux?

Select 3 answers
A.Source controller
B.Notification controller
C.GitOps controller
D.Kustomize controller
E.Helm controller
AnswersA, D, E

Manages sources like Git repositories and OCI artifacts.

Why this answer

Flux has a source-controller that manages artifact sources (e.g., Git repositories), a kustomize-controller that applies Kustomize overlays, and a helm-controller for Helm releases. The gitops-controller is not a specific Flux component (it's a generic term), and the notification-controller is not a core component (it's a separate controller for events).

792
Multi-Selectmedium

Which TWO of the following are characteristics of a Namespace in Kubernetes?

Select 2 answers
A.Namespaces are required for all Kubernetes objects
B.Namespaces provide network isolation by default
C.Resource names must be unique within a namespace, but can be reused across namespaces
D.Namespaces allow multiple virtual clusters within a physical cluster
E.Deleting a namespace deletes all objects inside it
AnswersC, D

Correct. Kubernetes enforces unique names only within the same namespace. This allows names like 'my-app' to be reused across different namespaces (e.g., dev and prod), providing naming flexibility without collisions.

Why this answer

Namespaces in Kubernetes provide a mechanism for logical grouping and scoping of resources. Two key characteristics are: (1) resource names must be unique within a namespace but can be reused across different namespaces (option C), and (2) namespaces allow multiple virtual clusters (logical clusters) within a single physical cluster (option D). While deleting a namespace does delete all its contained objects (option E), this is a consequence of namespace lifecycle management rather than a defining characteristic of what a namespace is.

Network isolation is not provided by default; it requires explicit NetworkPolicy resources.

Exam trap

CNCF often tests the misconception that Namespaces provide built-in network isolation, but in reality, they only offer logical grouping; network segmentation requires explicit NetworkPolicy resources.

793
MCQhard

A team wants to deploy a workload that must run on every node in a Kubernetes cluster, including new nodes added later. Which resource type should they use?

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

DaemonSet runs a pod on every node in the cluster.

Why this answer

A DaemonSet ensures that a copy of the pod runs on every node, and automatically runs on new nodes when they are added.

794
MCQhard

A team is building a serverless application using Knative. They want the application to scale to zero when idle. Which Knative resource type should they use?

A.Knative Serving
B.Knative Trigger
C.Knative Build
D.Knative Eventing
AnswerA

Serving provides scale-to-zero capability.

Why this answer

Knative Serving manages serverless workloads and supports automatic scaling to zero when no requests are incoming.

795
MCQhard

A pod in the 'default' namespace has the following YAML snippet: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 What is the effect of the fsGroup field?

A.It restricts the pod to run only on nodes with that group ID.
B.It sets the group ID for any volumes mounted into the pod.
C.It defines the group ID for the pod's service account.
D.It sets the group ID for the container's main process.
AnswerB

fsGroup changes the group ownership of volumes and any files created in them.

Why this answer

The `fsGroup` field in a Pod's security context sets the group ID (GID) that will be used for ownership of any volumes mounted into the pod. When a volume is mounted, Kubernetes recursively changes the group ownership of the volume's files to the specified GID (2000 in this case) and makes them readable and writable by that group. This ensures that processes running in the container, which may have a different primary group (3000 from `runAsGroup`), can still access the volume files if they are members of the fsGroup.

Exam trap

A common trap is confusing the role of `runAsGroup` (which sets the primary GID of the container process) with `fsGroup` (which sets the group ownership of mounted volumes), leading candidates to incorrectly select option D.

How to eliminate wrong answers

Option A is wrong because `fsGroup` does not restrict pod scheduling to nodes with a specific group ID; node affinity or taints/tolerations control node selection. Option C is wrong because the pod's service account group ID is unrelated to `fsGroup`; service accounts are managed via Kubernetes RBAC and do not have a group ID field in the security context. Option D is wrong because the group ID for the container's main process is set by `runAsGroup`, not `fsGroup`; `fsGroup` only affects volume file ownership, not the process's GID.

796
MCQeasy

Which of the following is a primary goal of the Cloud Native Computing Foundation (CNCF)?

A.To develop the Kubernetes container orchestration platform
B.To host proprietary cloud-native solutions
C.To foster and sustain the cloud-native ecosystem of open source projects
D.To provide commercial support for Kubernetes
AnswerC

This aligns with CNCF's mission statement.

Why this answer

The CNCF's mission is to make cloud-native computing ubiquitous by fostering and sustaining an ecosystem of open source projects. Options A and B are incorrect because CNCF does not provide commercial support or host proprietary solutions. Option D describes a specific project goal, not the foundation's overarching purpose.

797
MCQmedium

Which tool is specifically designed for distributed tracing and was originally developed by Uber?

A.Prometheus
B.Loki
C.Grafana
D.Jaeger
AnswerD

Jaeger is a distributed tracing system originally built by Uber.

Why this answer

Jaeger was originally developed by Uber for distributed tracing.

798
MCQhard

In a GitOps workflow, a team uses ArgoCD. A developer manually changes a Deployment's replica count in the cluster via kubectl. ArgoCD has self-healing enabled. What will happen?

A.ArgoCD creates a new Deployment with the manual change
B.ArgoCD updates the Git repository to reflect the manual change
C.ArgoCD ignores the change because it was made manually
D.ArgoCD reverts the replica count to the value in Git
AnswerD

Self-healing ensures the cluster state matches Git, so it undoes the manual change.

Why this answer

With self-healing enabled, ArgoCD continuously monitors the cluster for drift. When a manual change is made via kubectl, ArgoCD detects that the live state no longer matches the desired state defined in Git. It then automatically reverts the change to bring the cluster back into sync with the Git repository.

799
MCQmedium

You are designing a microservices application that requires each service to be independently deployable and scalable. The services communicate over HTTP and need service discovery. Which orchestration feature BEST addresses the need for service discovery?

A.Kubernetes Service
B.Horizontal Pod Autoscaler
C.ConfigMap
D.PersistentVolume
AnswerA

A Service provides a stable endpoint (IP and DNS name) for a set of pods, enabling service discovery.

Why this answer

Kubernetes Service is the correct choice because it provides a stable network endpoint (IP address and DNS name) for a set of pods, enabling service discovery via DNS or environment variables. This allows microservices to locate and communicate with each other over HTTP without hardcoding IP addresses, which is essential for independent deployability and scalability.

Exam trap

A common trap in CNCF exams is confusing the Horizontal Pod Autoscaler (HPA), which scales pods, with the Kubernetes Service, which provides stable network endpoints for service discovery. Remember: HPA handles scaling, Service handles discovery.

How to eliminate wrong answers

Option B (Horizontal Pod Autoscaler) is wrong because it only adjusts the number of pod replicas based on CPU/memory metrics, not service discovery. Option C (ConfigMap) is wrong because it is used for injecting configuration data (e.g., environment variables) into pods, not for network endpoint resolution. Option D (PersistentVolume) is wrong because it provides storage abstraction for stateful workloads, not network-level service location.

800
Matchingmedium

Match each Kubernetes networking concept to its description.

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

Concepts
Matches

Default service type; exposes service on a cluster-internal IP

Exposes service on each node's IP at a static port

Exposes service externally using a cloud provider's load balancer

Service without a cluster IP; used for direct pod-to-pod communication

Implements traffic routing rules defined by Ingress resources

Why these pairings

Common confusions arise between ClusterIP (internal-only) and NodePort (node-level external access), and between LoadBalancer (cloud-integrated external LB) and Ingress (HTTP routing with rules).

801
Multi-Selectmedium

Which TWO of the following are valid ways to assign a pod to a specific node?

Select 2 answers
A.nodeSelector
B.affinity: nodeAntiAffinity
C.tolerations
D.nodeName
E.podSelector
AnswersA, D

Node selector uses labels to match nodes.

Why this answer

`nodeSelector` is a simple, built-in field in the Pod spec that matches the pod to nodes with specific labels. When you add a `nodeSelector` with a key-value pair, the scheduler only places the pod on nodes that have that exact label. This is the most straightforward way to constrain a pod to a subset of nodes.

Exam trap

CNCF often tests the distinction between mechanisms that *constrain* scheduling (like nodeSelector and nodeAffinity) versus mechanisms that *permit* scheduling (like tolerations), and candidates mistakenly think tolerations can force a pod to a specific node when they only allow it to be scheduled on tainted nodes.

802
Multi-Selectmedium

Which two of the following are true about ConfigMaps? (Select TWO.)

Select 2 answers
A.ConfigMaps are automatically encrypted at rest
B.ConfigMaps are namespace-scoped
C.ConfigMaps can hold binary data
D.ConfigMaps can be mounted as volumes or exposed as environment variables
E.ConfigMaps are used to store sensitive configuration data
AnswersB, D

Correct. ConfigMaps are namespace-scoped, meaning they exist within a specific namespace and are only accessible to pods in that namespace.

Why this answer

ConfigMaps are namespace-scoped objects (B) and can be mounted as volumes or exposed as environment variables (D).

Exam trap

CNCF often tests the distinction between ConfigMaps and Secrets, specifically that ConfigMaps are for non-sensitive, plaintext data and are not encrypted by default, while Secrets are intended for sensitive data and have optional encryption at rest.

803
MCQmedium

What is the primary role of the OpenTelemetry Collector?

A.To replace Prometheus for metric collection
B.To receive, process, and export telemetry data
C.To store traces and metrics long-term
D.To generate traces for applications
AnswerB

The collector acts as a pipeline to handle telemetry data from multiple sources and send to one or more backends.

Why this answer

The OpenTelemetry Collector receives, processes, and exports telemetry data to various backends.

804
MCQeasy

What is the purpose of container image scanning in a CI/CD pipeline?

A.To ensure the image is stored in a registry
B.To measure the image size and optimize it
C.To verify the image tag follows naming conventions
D.To identify security vulnerabilities in the image
AnswerD

Why this answer

Container image scanning checks for known security vulnerabilities (e.g., CVEs) in the image layers and dependencies. This helps prevent deploying vulnerable containers into production. Option A is incorrect because storing in a registry is unrelated; scanning can occur before or after pushing.

Option B is incorrect because image size and optimization are separate concerns, often handled by multi-stage builds or other tools. Option C is incorrect because naming conventions are typically enforced via policies or linting, not scanning. Option D correctly identifies the purpose of scanning: identifying security vulnerabilities.

805
MCQhard

You run 'kubectl logs my-pod' and see: "Error from server (BadRequest): container "my-container" in pod "my-pod" is waiting to start: PodInitializing". What does this mean?

A.The container is running but producing no output
B.The container runtime is failing to start the container
C.The container has crashed and is restarting
D.The Pod is in the process of initializing and logs are not yet available
AnswerD

PodInitializing means the container hasn't started yet.

Why this answer

The error 'PodInitializing' indicates that the pod's init containers are still running or the main container is waiting for init containers to complete. During this phase, the container has not started, so logs are not yet available. Option D correctly identifies that the pod is initializing and logs cannot be retrieved until the container enters the 'Running' state.

Exam trap

The trap here is that candidates confuse 'PodInitializing' with a container runtime failure or crash loop, when in fact it is a normal waiting state caused by init containers or pod initialization, not an error condition.

How to eliminate wrong answers

Option A is wrong because 'PodInitializing' means the container has not started, so it cannot be running or producing output. Option B is wrong because the error does not indicate a runtime failure; it simply means the container is waiting to start, which is a normal part of the pod lifecycle when init containers are executing. Option C is wrong because a crash loop would show 'CrashLoopBackOff' or 'Error' status, not 'PodInitializing', which is a transient state before the container starts.

806
MCQmedium

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

A.Delete the namespace and redeploy all workloads
B.Increase the memory limit in the pod's container resource specification
C.Increase the CPU request for the container
D.Delete and recreate the pod to clear the crash loop
AnswerB

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

Why this answer

The pod is in CrashLoopBackOff with an OOMKilled message, which means the container was terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it exceeded its memory limit. Increasing the memory limit in the container's resource specification allows the container to use more memory before being killed, directly addressing the root cause.

Exam trap

Candidates often confuse resource requests and limits in Kubernetes. They may mistakenly increase the CPU request instead of the memory limit, or think that simply restarting the pod will resolve an OOMKilled error. However, the root cause is an exceeded memory limit, so the correct fix is to increase the memory limit in the container's resource specification.

How to eliminate wrong answers

Option A is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not fix the underlying memory constraint; the same OOMKilled error would recur. Option C is wrong because increasing the CPU request does not affect memory allocation; the OOM killer is triggered by memory usage, not CPU. Option D is wrong because deleting and recreating the pod only restarts the container with the same memory limit, so it will be OOMKilled again once memory usage spikes.

807
MCQmedium

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

A.Increase the memory limit in the pod's container resource specification
B.Increase the CPU request for the container
C.Delete the namespace and redeploy all workloads
D.Delete and recreate the pod to clear the crash loop
AnswerA

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

Why this answer

The 'OOMKilled' status indicates the pod's container was terminated by the Linux kernel Out-of-Memory (OOM) killer because it exceeded its configured memory limit. Since the pod ran successfully for days, this suggests a gradual memory leak or increased workload demand. Increasing the memory limit in the pod's container resource specification allows the container to use more memory before being killed, directly addressing the root cause.

Exam trap

The trap here is that candidates may confuse 'OOMKilled' with a general crash and choose to delete/recreate the pod, not realizing the memory limit must be adjusted to prevent recurrence.

How to eliminate wrong answers

Option B is wrong because increasing the CPU request does not affect memory consumption or prevent OOM kills; CPU and memory are independent resources in Kubernetes. Option C is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not fix the underlying memory limit issue and would cause unnecessary downtime. Option D is wrong because deleting and recreating the pod only restarts the container with the same memory limit, so it will likely be OOMKilled again when memory usage spikes.

808
MCQmedium

Which of the following is NOT a responsibility of the kubelet on a worker node?

A.Performing liveness and readiness probes
B.Starting and stopping containers based on PodSpecs
C.Implementing network rules for Services
D.Reporting node and pod status to the control plane
AnswerC

Network rules and service load balancing are handled by kube-proxy, not kubelet.

Why this answer

The kubelet is the primary node agent that runs on each worker node, responsible for ensuring containers are running in a Pod as specified by the PodSpec. It performs liveness and readiness probes, starts and stops containers, and reports node and pod status to the control plane. Implementing network rules for Services, such as iptables or IPVS rules, is the responsibility of the kube-proxy, not the kubelet.

Exam trap

The trap here is that candidates often confuse the kubelet's role with kube-proxy's role, assuming the kubelet handles all networking on the node, including Service traffic routing.

How to eliminate wrong answers

Option A is wrong because the kubelet is responsible for executing liveness and readiness probes against containers and taking action based on their results (e.g., restarting containers). Option B is wrong because the kubelet directly manages container lifecycle by communicating with the container runtime (e.g., containerd, CRI-O) to start and stop containers as defined in the PodSpec. Option D is wrong because the kubelet periodically reports the node's condition and the status of each Pod to the API server via the NodeStatus and PodStatus updates.

809
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

Services only forward traffic to pods that pass readiness probes.

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.

810
Multi-Selecteasy

Which TWO components are part of a Kubernetes worker node?

Select 2 answers
A.kubelet
B.kube-scheduler
C.container runtime
D.kube-proxy
E.etcd
AnswersA, D

kubelet runs on each node and ensures containers are running as specified.

Why this answer

The kubelet is the primary node agent that runs on every worker node. It registers the node with the cluster, receives Pod specifications from the API server, and ensures that the containers described in those Pods are running and healthy. Without the kubelet, a node cannot participate in the cluster as a worker.

Exam trap

CNCF often tests the distinction between control plane and worker node components, and the trap here is that candidates mistakenly include the container runtime as a 'Kubernetes component' when it is actually a third-party dependency, or they confuse kube-scheduler as a worker node component because it deals with Pod placement.

811
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.

812
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

emptyDir volumes share the Pod's lifetime and persist across container restarts within the same Pod.

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.

813
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

OOMKilled indicates the container exceeded its memory limit.

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.

814
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

The API server exposes the Kubernetes API and is the primary management entry point.

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.

815
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

This is the fully qualified domain name, but from the same namespace, just 'my-service' also works. However, this is a correct FQDN.

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.

816
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 defines network access rules between pods.

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.

817
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

Deployment creates and manages ReplicaSets to ensure the desired state.

Why this answer

A Deployment manages ReplicaSets, which in turn manage Pods. This is the core abstraction: the Deployment controller creates and updates ReplicaSets to achieve the desired state, and each ReplicaSet ensures a specified number of Pod replicas are running. This layered architecture enables features like rolling updates and rollbacks without the Deployment directly interacting with individual Pods.

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.

818
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 is part of the data plane and performs these functions.

Why this answer

The sidecar proxy (often Envoy) intercepts all traffic and collects metrics, traces, and logs, and also enforces traffic management rules.

819
MCQeasy

Which of the following is a core principle of cloud native architecture as defined by the CNCF?

A.Monolithic design
B.Microservices
C.Single point of failure
D.Manual scaling
AnswerB

Why this answer

Microservices are one of the key architectural principles of cloud native applications.

820
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

12-factor apps store config in environment variables for ease of change across deployments.

Why this answer

The 12-factor app methodology states that configuration should be stored in environment variables to separate config from code.

821
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

Service mesh enables advanced traffic routing and canary releases.

Why this answer

Options B, D, and E are correct. A service mesh provides traffic management capabilities (e.g., canary deployments, routing, load balancing), security features like mutual TLS encryption (mTLS), and enhanced observability through metrics and tracing. Option A (management of application state across services) is not a function of a service mesh; state management is handled by other tools like databases or stateful frameworks.

Option C (reduction of container image sizes) is unrelated to service mesh; image size is affected by base images and application dependencies.

822
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 Replication Controller ensures the desired number of replicas.

Why this answer

The kube-controller-manager runs controller processes that regulate the state of the cluster. The ReplicaSet controller, which runs inside the kube-controller-manager, is responsible for ensuring that the desired number of pod replicas are running at all times, creating or deleting pods as necessary to match the specified replica count.

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.

823
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

Idle functions consume no resources.

Why this answer

Event-driven execution and auto-scaling to zero are key serverless characteristics.

824
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.

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.

825
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 allow calculating quantiles like p99 latency.

Why this answer

The SLO is based on latency, which is typically measured using a histogram to track request durations.

Page 10

Page 11 of 12

Page 12