Courseiva

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

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

Page 8

Page 9 of 12

Page 10
601
MCQmedium

A developer deploys a pod that continuously restarts. 'kubectl describe pod' shows the container exits with code 137. What is the most likely cause?

A.The container is exceeding its memory limit and being OOM-killed.
B.The liveness probe is failing and restarting the container.
C.The init container is failing and blocking the main container.
D.The pod is hitting a resource quota limit at the namespace level.
AnswerA

Exit code 137 indicates SIGKILL, often from OOM.

Why this answer

Exit code 137 (128 + 9) indicates the container was killed by SIGKILL. In Kubernetes, this most commonly occurs when the container exceeds its memory limit, triggering the OOM (Out-Of-Memory) killer. The kubelet enforces the resource limits specified in the pod spec, and when memory usage surpasses the limit, the kernel terminates the process with SIGKILL, resulting in exit code 137.

Exam trap

The KCNA exam often tests the distinction between exit codes and probe failures; the trap here is that candidates confuse exit code 137 with a liveness probe failure, but exit code 137 specifically points to a SIGKILL, not a probe timeout or command failure.

How to eliminate wrong answers

Option B is wrong because a failing liveness probe causes a container restart with exit code 137 only if the probe failure leads to a SIGKILL (which is not typical; liveness probe failures result in exit code 0 or 1 depending on the probe command, not 137). Option C is wrong because init container failures block the main container from starting, but they do not cause the main container to exit with code 137; the main container would never run. Option D is wrong because a namespace-level resource quota limit prevents pod creation or scheduling, not causing a running container to exit with code 137; quota enforcement happens at admission time, not during runtime.

602
MCQeasy

Which component of the Kubernetes control plane is responsible for storing the cluster state?

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

etcd is the cluster state store.

Why this answer

etcd is the distributed key-value store that serves as Kubernetes' primary data store, persisting all cluster state including configuration, secrets, and resource specifications. The kube-apiserver is the only component that interacts directly with etcd, ensuring consistency and providing a RESTful interface for all other components and users.

Exam trap

A common trap is to think that kube-apiserver stores the cluster state because it acts as the central API gateway. However, the API server is stateless and delegates all persistence to etcd.

How to eliminate wrong answers

Option A is wrong because kube-apiserver is the front-end for the Kubernetes control plane that validates and processes API requests, but it does not store state—it reads from and writes to etcd. Option C is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for storing cluster state. Option D is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that watch the shared state via the API server and make changes to bring the current state to the desired state, but it does not persist state itself.

603
MCQmedium

Which tool can be used to implement feature flags in a Kubernetes-native progressive delivery setup?

A.Argo Rollouts
B.Kustomize
C.Helm
D.Flux
AnswerA

Argo Rollouts provides canary deployments and integrates with feature flag systems like Flagd.

Why this answer

Argo Rollouts supports progressive delivery with features like canary, blue-green, and integration with service mesh for traffic shifting, and can be combined with feature flag systems.

604
MCQmedium

Which DORA metric measures how quickly code changes are deployed to production?

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

This metric tracks the speed from commit to production.

Why this answer

Lead time for changes measures the time from code commit to running in production.

605
MCQmedium

A Pod is stuck in Pending state. Which of the following is the MOST likely cause?

A.The Pod's container is crashing
B.The container image has a typo
C.No node has enough resources to run the Pod
D.The Pod's liveness probe is failing
AnswerC

Scheduler cannot place the Pod, so it remains Pending.

Why this answer

A Pod stuck in Pending state means the scheduler cannot place it on a node. The most common reason is insufficient resources (CPU, memory, or ephemeral storage) on any available node, causing the scheduler to leave the Pod unscheduled. This is indicated by the Pod's status remaining Pending and typically confirmed via `kubectl describe pod` showing events like '0/1 nodes are available: 1 Insufficient cpu'.

Exam trap

This question tests the distinction between scheduling failures (Pending) and runtime failures (CrashLoopBackOff, ImagePullBackOff, probe failures), so the trap is confusing post-scheduling container issues with pre-scheduling resource constraints.

How to eliminate wrong answers

Option A is wrong because a container crashing (e.g., CrashLoopBackOff) occurs after the Pod is scheduled and running, not while it is still in Pending state. Option B is wrong because a container image typo (e.g., ImagePullBackOff) prevents the container from starting but does not block scheduling; the Pod would be scheduled first, then fail to pull the image. Option D is wrong because a failing liveness probe causes the container to be restarted or the Pod to be marked as Unhealthy, but this happens only after the Pod is running, not during the Pending phase.

606
MCQeasy

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

A.To store container images in a registry
B.To define the format of container images
C.To manage container network interfaces
D.To provide a standard interface between the kubelet and container runtimes
AnswerD

CRI is a plugin interface that enables the kubelet to use different container runtimes.

Why this answer

The Container Runtime Interface (CRI) is a plugin protocol that enables the kubelet to use any OCI-compliant container runtime (e.g., containerd, CRI-O) without needing to recompile Kubernetes. It defines gRPC APIs for runtime and image service operations, abstracting the runtime implementation from the kubelet's pod lifecycle management.

Exam trap

CNCF often tests the distinction between CRI (runtime abstraction) and CNI (network abstraction), so the trap here is confusing container runtime management with container networking, leading candidates to pick Option C.

How to eliminate wrong answers

Option A is wrong because storing container images in a registry is the function of a container registry (e.g., Docker Hub, Amazon ECR), not the CRI; the CRI's image service pulls images from registries but does not store them. Option B is wrong because defining the format of container images is the responsibility of the OCI Image Specification, not the CRI; the CRI consumes images in that format but does not define it. Option C is wrong because managing container network interfaces is the role of the Container Network Interface (CNI), not the CRI; the CRI focuses on runtime and image operations, while CNI handles network attachment.

607
Multi-Selecteasy

Which TWO of the following are benefits of implementing progressive delivery techniques (e.g., canary releases)?

Select 2 answers
A.Replaces the need for a CI/CD pipeline
B.Allows testing new features with a subset of users
C.Eliminates the need for monitoring and alerting
D.Guarantees zero downtime
E.Reduces the risk of deploying a bad version to all users
AnswersB, E

Canary releases target a small percentage of users for validation.

Why this answer

Progressive delivery reduces risk by gradual rollout and provides the ability to test new versions with a subset of users. It does not eliminate the need for monitoring nor does it replace CI/CD pipelines.

608
MCQhard

A company uses OpenTelemetry to instrument their microservices. They want to ensure that traces from one service can be correlated with those from another service across network calls. Which OpenTelemetry concept enables this correlation?

A.Exporter configuration
B.Span attributes
C.Context propagation
D.Sampling
AnswerC

Context propagation carries trace IDs and other context across service boundaries.

Why this answer

Context propagation allows trace context to be passed between services, enabling distributed tracing correlation.

609
MCQmedium

Which component is responsible for ensuring that containers are running as specified in a Pod's specification on a node?

A.Container runtime
B.kubelet
C.kube-proxy
D.kube-scheduler
AnswerB

The kubelet ensures that containers in a Pod are running according to the PodSpec.

Why this answer

The kubelet is the primary node agent that runs on each node in a Kubernetes cluster. It is responsible for ensuring that containers described in Pod specifications (PodSpecs) are running and healthy. The kubelet watches for Pod assignments from the API server, creates or terminates containers via the container runtime, and continuously reports the node and Pod status back to the control plane.

Exam trap

A common pitfall is confusing the kubelet, which ensures containers are running according to the Pod spec, with the container runtime, which actually executes containers. Candidates often choose 'container runtime' because they associate 'running containers' with the container runtime, but the kubelet is the agent that manages Pod lifecycle on the node.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for actually pulling images and running containers, but it does not interpret Pod specifications or enforce desired state — it only executes commands from the kubelet via the CRI (Container Runtime Interface). Option C is wrong because kube-proxy is a network proxy that runs on each node, handling IPVS/iptables rules for Service traffic and network policies, not container lifecycle management. Option D is wrong because kube-scheduler is a control plane component that selects which node a Pod should run on based on resource availability and constraints, but it does not run on the node or manage running containers.

610
MCQeasy

What does the 'kubectl logs' command retrieve?

A.Audit logs
B.Cluster events
C.Container logs
D.Node logs
AnswerC

kubectl logs shows the logs of a single container.

Why this answer

kubectl logs fetches the standard output and standard error logs from a container in a pod.

611
MCQmedium

A company is adopting a GitOps workflow for their Kubernetes deployments. They want to ensure that the cluster state always matches the desired state defined in a Git repository. Which tool is specifically designed for this purpose?

A.Helm
B.Argo CD
C.Kustomize
D.Prometheus
AnswerB

Argo CD is a GitOps tool that syncs cluster state with a Git repository.

Why this answer

Argo CD is a declarative, GitOps continuous delivery tool specifically designed for Kubernetes that automatically synchronizes the live cluster state with the desired state defined in a Git repository. It continuously monitors the cluster and Git, applying any drift to ensure the cluster matches the repository, which is the core requirement of a GitOps workflow.

Exam trap

The trap here is that candidates often confuse Helm or Kustomize as GitOps tools because they are used in GitOps pipelines, but they lack the continuous reconciliation and drift detection that a dedicated GitOps operator like Argo CD provides.

How to eliminate wrong answers

Option A is wrong because Helm is a package manager for Kubernetes that uses charts to define, install, and upgrade applications, but it does not provide continuous synchronization or drift detection from a Git repository; it is a deployment tool, not a GitOps operator. Option C is wrong because Kustomize is a configuration management tool that allows customizing Kubernetes manifests without templates, but it is a CLI tool or a kubectl plugin, not a controller that continuously reconciles cluster state with a Git repository. Option D is wrong because Prometheus is a monitoring and alerting toolkit for metrics collection and alerting, not a deployment or GitOps tool; it has no mechanism to enforce desired state from Git.

612
MCQmedium

A user runs 'kubectl create deployment my-deploy --image=nginx' and then wants to scale the deployment to 5 replicas. Which command should they use?

A.kubectl apply -f deployment.yaml with replicas: 5
B.kubectl edit deployment my-deploy and change replicas to 5
C.kubectl patch deployment my-deploy -p '{"spec":{"replicas":5}}'
D.kubectl scale deployment my-deploy --replicas=5
AnswerD

Correct command.

Why this answer

`kubectl scale` is the dedicated imperative command to change the replica count of a deployment. It directly updates the `spec.replicas` field in the deployment's desired state, and the deployment controller then adjusts the ReplicaSet and Pods accordingly. This is the simplest and most direct way to scale a deployment without modifying a YAML file or using an editor.

Exam trap

The trap is that candidates may think `kubectl edit` or `kubectl patch` are the only ways to change replicas, but the KCNA exam expects knowledge of the dedicated imperative `kubectl scale` command for direct scaling operations.

How to eliminate wrong answers

Option A is wrong because `kubectl apply` requires a YAML file with the desired state; the user did not create a deployment.yaml file, and the command as written would fail or create a new resource. Option B is wrong because `kubectl edit` opens an interactive editor, which is not a single command and can be error-prone in scripts or automated workflows; it works but is not the recommended imperative approach. Option C is wrong because `kubectl patch` uses a JSON patch to modify the deployment, which is valid but more complex and less intuitive than the dedicated `kubectl scale` command; it also requires correct JSON syntax and is prone to typos.

613
Multi-Selectmedium

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

Select 2 answers
A.Container images include a full operating system kernel
B.Container images can be stored in a registry like Docker Hub
C.Container images are built from a series of layers
D.Container images are immutable once built
E.Container images can only be built on Linux
AnswersB, C

Registries store and distribute images.

Why this answer

Container images are built in layers and can be stored in registries. They are not immutable once built (they can be overwritten), and they include only the application and dependencies, not a full OS kernel.

614
MCQeasy

Which component in Kubernetes is responsible for maintaining the desired state of the cluster?

A.kube-scheduler
B.kube-proxy
C.kube-controller-manager
D.kubelet
AnswerC

The controller manager runs controllers that enforce the desired state.

Why this answer

The kube-controller-manager is the component that runs controller processes, which are control loops that watch the shared state of the cluster through the API server and make changes to move the current state toward the desired state. It is responsible for ensuring that the cluster's actual state matches the desired state defined in Kubernetes objects such as Deployments, ReplicaSets, and StatefulSets.

Exam trap

CNCF often tests the distinction between the kube-controller-manager and the kubelet, where candidates mistakenly think the kubelet maintains the cluster's desired state because it manages containers on a node, but the kubelet only ensures the pod's containers are healthy on its local node, not the cluster-wide desired state.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and scheduling policies, not for maintaining the desired state of the cluster. Option B is wrong because kube-proxy is a network proxy that runs on each node and implements part of the Kubernetes Service concept by maintaining network rules, not for maintaining desired state. Option D is wrong because kubelet is an agent that runs on each node and ensures containers are running in a pod as expected, but it only manages the state on its specific node and does not maintain the overall desired state of the cluster.

615
MCQhard

A pod in a ReplicaSet is failing with 'CrashLoopBackOff'. 'kubectl logs pod' shows 'Error: listen tcp :8080: bind: address already in use'. What is the most likely cause?

A.The readiness probe is misconfigured.
B.The container image is missing the application binary.
C.The container's process is not terminating quickly enough on SIGTERM, causing a port conflict on restart.
D.The pod is using hostPort and two pods on the same node conflict.
AnswerC

Old process still holds the port.

Why this answer

The error 'address already in use' on port 8080 indicates that when the container restarts, the previous process is still holding the port. This typically happens when the application does not handle SIGTERM properly and does not shut down within the terminationGracePeriodSeconds (default 30s), so the old process lingers while the new one tries to bind to the same port, causing a CrashLoopBackOff.

Exam trap

CNCF often tests the distinction between pod startup failures caused by resource constraints or probe misconfiguration versus application-level port conflicts that arise from improper signal handling during restarts.

How to eliminate wrong answers

Option A is wrong because a misconfigured readiness probe would cause the pod to be marked as not ready, but it would not produce a 'bind: address already in use' error in the logs. Option B is wrong because if the container image were missing the application binary, the error would be something like 'executable file not found' or 'no such file or directory', not a port binding error. Option D is wrong because hostPort is used for port mapping to the node, but the error is about a port conflict inside the same container on restart, not between two different pods on the same node.

616
Multi-Selecthard

Which of the following are core components of the Flux GitOps toolkit?

Select 3 answers
A.Helm Controller
B.Helm
C.Source Controller
D.ArgoCD Application Controller
E.Kustomize Controller
AnswersA, C, E

Helm Controller is a core component of Flux, responsible for managing Helm releases.

Why this answer

The core components of the Flux GitOps toolkit include Source Controller, Helm Controller, and Kustomize Controller. These controllers manage sources, Helm releases, and Kustomize overlays respectively. Helm (option B) is a standalone tool, and ArgoCD (option D) is a different GitOps tool.

617
MCQeasy

What is the primary purpose of a Kubernetes Service object?

A.To store configuration data that can be consumed by Pods
B.To manage rolling updates and rollbacks for Pods
C.To provide a stable IP address and DNS name for a set of Pods
D.To persist data beyond the lifecycle of a Pod
AnswerC

Services create a durable endpoint that abstracts the underlying Pod IPs, supporting load balancing and service discovery.

Why this answer

The primary purpose of a Kubernetes Service object is to provide a stable network endpoint (a fixed IP address and DNS name) that abstracts and load-balances traffic across a dynamic set of Pods. Pods are ephemeral and can be rescheduled with new IP addresses, so the Service ensures clients can reliably reach the application without needing to track individual Pod IPs.

Exam trap

The trap here is that candidates often confuse the Service's role with that of a Deployment or ConfigMap, mistakenly thinking a Service manages Pod lifecycles or stores configuration, when its core function is purely about stable network abstraction and load balancing.

How to eliminate wrong answers

Option A is wrong because storing configuration data that can be consumed by Pods is the role of a ConfigMap (or Secret for sensitive data), not a Service. Option B is wrong because managing rolling updates and rollbacks for Pods is the responsibility of a Deployment controller, which handles replica sets and update strategies. Option D is wrong because persisting data beyond the lifecycle of a Pod is achieved through PersistentVolume (PV) and PersistentVolumeClaim (PVC) objects, not a Service.

618
Multi-Selectmedium

Which TWO of the following are Kubernetes control plane components?

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

The API server is a core control plane component.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane, exposing the Kubernetes API. It validates and processes RESTful requests (using JSON/YAML over HTTP/HTTPS) that create, update, or delete cluster resources, and it is the only component that communicates directly with etcd. Without the API server, no control plane operations can be performed.

Exam trap

CNCF often tests the distinction between control plane and worker node components, expecting candidates to mistakenly include kubelet or kube-proxy as control plane components because they are essential for cluster operation but run on nodes, not the control plane.

619
MCQeasy

Which tool is commonly used for log aggregation in Kubernetes and is designed to be lightweight?

A.Fluent Bit
B.Jaeger
C.Prometheus
D.Grafana
AnswerA

Fluent Bit is a lightweight log processor for log aggregation.

Why this answer

Fluent Bit is a lightweight log processor and forwarder, often used as a DaemonSet to collect logs.

620
MCQhard

In the context of the 12-factor app methodology, which factor requires that an app's configuration be stored in environment variables?

A.Config
B.Dependencies
C.Codebase
D.Backing services
AnswerA

Why this answer

Factor III (Config) states that configuration should be stored in environment variables to decouple it from code.

621
MCQhard

A pod is stuck in Terminating state for several minutes. What is the most likely cause?

A.The node is unreachable or the kubelet is not responding
B.The deployment is configured with a grace period
C.The pod has a liveness probe that is failing
D.The pod's container runtime is paused
AnswerA

If the kubelet cannot be contacted, the pod cannot be terminated.

Why this answer

When a pod is stuck in Terminating state, the most likely cause is that the node where the pod was running is unreachable or the kubelet is not responding. The kubelet is responsible for executing the pod's termination lifecycle, including sending SIGTERM and, after the grace period, SIGKILL. If the kubelet cannot communicate with the API server (e.g., due to node failure, network partition, or kubelet crash), the pod's finalizer cannot be removed, leaving it stuck in Terminating.

Exam trap

CNCF often tests the misconception that a failing liveness probe or a misconfigured grace period causes a pod to be stuck in Terminating, when in fact the root cause is almost always a node or kubelet communication issue.

How to eliminate wrong answers

Option B is wrong because a deployment configured with a grace period (terminationGracePeriodSeconds) is normal and does not cause a pod to be stuck; the pod will be forcefully terminated after the grace period expires. Option C is wrong because a failing liveness probe causes the pod to be restarted or recreated, not stuck in Terminating; liveness probes affect running pods, not termination. Option D is wrong because a paused container runtime would prevent the pod from starting or running, but it does not prevent the kubelet from completing the termination process; the kubelet can still force-kill the container.

622
MCQhard

Which of the following best describes immutable infrastructure?

A.Servers that are updated in-place with configuration management tools
B.Infrastructure that is version-controlled and deployed using blue/green deployments
C.Infrastructure components that are replaced rather than changed after deployment
D.Infrastructure that uses only read-only file systems
AnswerC

Immutable infrastructure replaces components instead of modifying them.

Why this answer

Immutable infrastructure is a pattern where components (servers, containers, etc.) are never modified after deployment. Instead, any change requires building a new instance from a golden image or template and replacing the old one. This eliminates configuration drift and ensures consistency, which is a core principle in container orchestration with tools like Kubernetes, where Pods are replaced rather than patched in place.

Exam trap

The trap here is that candidates confuse immutable infrastructure with specific deployment patterns (blue/green) or security features (read-only filesystems), rather than recognizing the core principle of replacement over modification.

How to eliminate wrong answers

Option A is wrong because it describes mutable infrastructure, where configuration management tools (e.g., Ansible, Chef) apply updates in-place, directly contradicting the immutable principle of replacement. Option B is wrong because while version-controlled infrastructure and blue/green deployments are often used with immutable infrastructure, they are deployment strategies, not the defining characteristic of immutability itself. Option D is wrong because read-only file systems are a security hardening technique that can be part of an immutable design, but they are not the core definition; immutable infrastructure focuses on the lifecycle of the entire component, not just the filesystem state.

623
MCQhard

You are an SRE managing a Kubernetes cluster with 200 nodes and 10,000 pods. The cluster runs a critical payment processing application. Users report that transactions are occasionally failing with a 'timeout' error. You have Prometheus and Grafana set up for monitoring, and you use Fluentd with Elasticsearch for logging. You notice that during peak hours, the CPU usage of the payment service pods spikes to 90%, but memory usage remains stable. The pod restart count is low. You also see that the response time of the payment service increases significantly during these spikes. You need to identify the root cause and propose a fix. Which course of action is most appropriate?

A.Add more replicas of the payment service to distribute the load
B.Increase the memory limits for the payment service pods to improve caching
C.Implement a circuit breaker pattern to fail fast and avoid timeouts
D.Increase the CPU limits for the payment service pods to allow more CPU resources during spikes
AnswerD

This directly addresses the CPU bottleneck, reducing response time.

Why this answer

The CPU usage spikes to 90% during peak hours, indicating that the payment service pods are CPU-bound. Increasing CPU limits allows the pods to burst and utilize more CPU resources, reducing response times and preventing timeouts. This directly addresses the bottleneck without adding unnecessary replicas or changing memory settings.

Exam trap

CNCF often tests the misconception that scaling replicas always solves performance issues, but here the bottleneck is per-pod CPU limits, not overall load distribution.

How to eliminate wrong answers

Option A is wrong because adding more replicas does not solve the root cause of CPU starvation; it may spread the load but each pod still faces the same CPU limit, and the issue is per-pod CPU saturation, not overall cluster capacity. Option B is wrong because memory usage is stable, so increasing memory limits does not address the CPU bottleneck and could waste resources. Option C is wrong because a circuit breaker pattern handles failures gracefully but does not fix the underlying performance issue; it would only mask the timeouts by failing fast, not reduce the actual response time.

624
Multi-Selectmedium

Which TWO statements about Namespaces are correct?

Select 2 answers
A.Namespaces provide a way to divide cluster resources among multiple users
B.Namespaces act as a strong security boundary by default
C.Namespaces help organize objects in a cluster
D.Every resource must be created in a namespace
E.Resources in different namespaces cannot communicate with each other
AnswersA, C

Namespaces enable resource quotas and access control scoping.

Why this answer

Namespaces in Kubernetes provide a mechanism for partitioning a single cluster into multiple virtual clusters, enabling resource quota management and access control for different users or teams. This allows administrators to divide cluster resources (like CPU, memory, and storage) among multiple users via ResourceQuotas and LimitRanges, without requiring separate physical clusters.

Exam trap

CNCF often tests the misconception that Namespaces provide strong security isolation by default, when in reality they only offer logical separation and require explicit NetworkPolicies and RBAC for security.

625
MCQeasy

What is the primary purpose of the CNCF (Cloud Native Computing Foundation)?

A.To certify individuals in cloud-native technologies
B.To develop and maintain the Kubernetes project exclusively
C.To host and nurture open-source cloud-native projects and drive adoption
D.To provide commercial support for cloud-native software
AnswerC

CNCF's mission is to make cloud-native computing ubiquitous by hosting projects and fostering community.

Why this answer

The CNCF fosters the adoption of cloud-native technologies by hosting and nurturing open-source projects like Kubernetes, Prometheus, and Envoy.

626
MCQmedium

A CI/CD pipeline includes image scanning. What is the primary security benefit of scanning container images in the CI phase?

A.It reduces the time it takes to build images
B.It automatically fixes vulnerabilities
C.It prevents vulnerable images from being deployed to production
D.It ensures that the image is built only once
AnswerC

Scanning early in the pipeline allows teams to fix vulnerabilities before deployment.

Why this answer

Scanning images in CI catches vulnerabilities before the image is deployed, preventing vulnerable images from reaching production.

627
MCQhard

You are a platform engineer at a fast-growing startup. The company runs a Kubernetes cluster with 50 worker nodes for its production microservices. Recently, the operations team has been struggling with manual configuration drift: developers SSH into nodes to install debugging tools, and some nodes have different kernel parameters or installed packages. This has caused intermittent outages when a pod is scheduled onto a non-standard node. The CTO wants a solution that ensures each node is identical, immutable, and reproducible. The cluster uses kubeadm for bootstrapping and runs on AWS EC2. Which approach best achieves the goal of immutable nodes?

A.Use a configuration management tool like Ansible to enforce desired state on each node via periodic runs.
B.Apply Kubernetes node labels and taints to categorize nodes and prevent workloads from running on non-standard nodes.
C.Create a golden AMI using Packer with all required configurations, then use Auto Scaling groups with a launch template that references the AMI and enable instance refresh for updates.
D.Deploy a DaemonSet that runs a privileged container to enforce node configuration and remove debugging tools.
AnswerC

A golden AMI provides an identical, immutable base. Instance refresh replaces nodes rather than modifying them.

Why this answer

It uses a golden AMI built with Packer to create identical, immutable nodes that are reproducible via Auto Scaling groups and launch templates. This approach ensures that every EC2 instance launched has the exact same kernel parameters, packages, and configuration, eliminating configuration drift. Instance refresh allows rolling updates to the AMI without manual intervention, aligning with the goal of immutable infrastructure.

Exam trap

The trap here is that candidates often confuse configuration management (Option A) with immutability, not realizing that periodic enforcement still allows drift and does not guarantee identical nodes at all times.

How to eliminate wrong answers

Option A is wrong because configuration management tools like Ansible enforce desired state via periodic runs, which still allows drift between runs and does not achieve true immutability; nodes remain mutable and can deviate. Option B is wrong because node labels and taints only control workload scheduling, they do not enforce node configuration or prevent nodes from being modified via SSH. Option D is wrong because a DaemonSet running a privileged container can attempt to enforce configuration but cannot prevent manual SSH changes or guarantee identical state across nodes, and it introduces security risks without solving the root cause of drift.

628
MCQhard

Which Kubernetes resource is commonly used to implement the sidecar pattern for injecting a service mesh proxy?

A.NetworkPolicy
B.Service
C.MutatingAdmissionWebhook
D.ConfigMap
AnswerC

Service meshes like Istio use a mutating webhook to automatically inject the Envoy sidecar proxy.

Why this answer

A MutatingAdmissionWebhook intercepts Pod creation requests and automatically injects a sidecar container (e.g., Envoy or Linkerd-proxy) into the Pod spec. This is the standard mechanism used by service mesh control planes like Istio and Linkerd to transparently add the proxy without modifying application manifests.

Exam trap

CNCF often tests the misconception that a Service or NetworkPolicy is responsible for sidecar injection, when in fact only a mutating admission webhook can automatically modify Pod specs at creation time.

How to eliminate wrong answers

Option A is wrong because NetworkPolicy controls ingress/egress traffic at the network layer using labels and CIDR rules, not container injection. Option B is wrong because a Service provides a stable IP and DNS name for Pod discovery and load balancing, not sidecar injection. Option D is wrong because a ConfigMap stores non-sensitive configuration data as key-value pairs or files, but cannot mutate Pod specs at creation time.

629
MCQhard

A Service of type ClusterIP is created for a Deployment, but Pods in other namespaces cannot reach it. What is the most likely cause?

A.NetworkPolicies are blocking cross-namespace traffic
B.The Pods in other namespaces are using the short Service name without the namespace suffix
C.The Service is not publishing the correct port
D.The Service selector does not match the Pod labels
AnswerB

Cross-namespace access requires the full DNS name including the namespace.

Why this answer

The most likely cause is that Pods in other namespaces are using the short Service name (e.g., `my-service`) without appending the namespace suffix (e.g., `my-service.other-namespace.svc.cluster.local`). Kubernetes DNS resolves short names only within the same namespace; cross-namespace resolution requires the fully qualified domain name (FQDN) or at least the `<service>.<namespace>.svc` form. Without this, the DNS lookup fails, making the Service unreachable from other namespaces.

Exam trap

The trap here is that candidates often assume DNS works globally across namespaces with short names, but Kubernetes DNS only resolves short names within the same namespace by default, requiring the namespace suffix for cross-namespace access.

How to eliminate wrong answers

Option A is wrong because NetworkPolicies are not enabled by default and would require explicit configuration to block cross-namespace traffic; the question states Pods 'cannot reach it' without mentioning any NetworkPolicy, so this is not the most likely cause. Option C is wrong because if the Service were not publishing the correct port, it would affect all clients, not just those in other namespaces, and the question specifically isolates the issue to cross-namespace access. Option D is wrong because if the Service selector did not match the Pod labels, the Service would have no endpoints at all, making it unreachable from any namespace, not just from other namespaces.

630
MCQeasy

What is the primary purpose of a Kubernetes Service?

A.To manage container image versions
B.To store configuration data as key-value pairs
C.To provide a stable endpoint for accessing a set of pods
D.To schedule pods onto nodes
AnswerC

A Service exposes a logical set of pods with a stable IP and DNS name, enabling reliable communication.

Why this answer

A Kubernetes Service provides a stable, virtual IP address and DNS name that acts as a consistent endpoint for accessing a set of pods, regardless of pod IP changes due to scaling, restarts, or scheduling. It decouples frontend clients from backend pods by using label selectors to route traffic, ensuring high availability and load balancing across the pod group.

Exam trap

The trap here is that candidates confuse a Service with a Deployment or ReplicaSet, thinking its purpose is to manage pod lifecycle or scaling, rather than understanding it is purely a networking abstraction for stable pod access.

How to eliminate wrong answers

Option A is wrong because managing container image versions is the responsibility of container registries and image tags, not a Service; this is handled by tools like Docker Hub or Kubernetes image pull policies. Option B is wrong because storing configuration data as key-value pairs is the purpose of a ConfigMap or Secret, not a Service; Services handle network abstraction, not configuration storage. Option D is wrong because scheduling pods onto nodes is the job of the Kubernetes Scheduler, which uses resource requests and constraints, not a Service; a Service only routes traffic to already-scheduled pods.

631
Multi-Selecteasy

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

Select 2 answers
A.Managing replication and ensuring the desired number of pods are running
B.Storing cluster state
C.Exposing the Kubernetes API
D.Monitoring node health and responding to node failures
E.Assigning pods to nodes
AnswersA, D

The replication controller ensures the correct number of pod replicas.

Why this answer

The kube-controller-manager runs controller processes that regulate the state of the cluster. The replication controller (part of the controller manager) ensures that the actual number of pod replicas matches the desired count specified in a ReplicaSet or ReplicationController, automatically creating or terminating pods as needed. Additionally, the node controller within the kube-controller-manager periodically checks node health via the Node Lifecycle Controller, which monitors heartbeats (NodeStatus updates) and responds to node failures by tainting the node and evicting pods after a configurable timeout (default 5 minutes).

Exam trap

CNCF often tests the distinction between the kube-controller-manager and the kube-scheduler, so the trap here is that candidates mistakenly think pod-to-node assignment is a controller function, when it is exclusively handled by the scheduler.

632
MCQmedium

A pod is in 'Pending' state for a long time. What is the most likely cause?

A.The pod's container has crashed
B.The pod's service endpoint is misconfigured
C.The scheduler cannot find a node that satisfies the pod's resource requests or constraints
D.The container image is invalid
AnswerC

If no node meets the pod's requirements, the pod remains unscheduled.

Why this answer

A pod remains in 'Pending' state when it has been accepted by the API server but cannot be scheduled onto a node. The most common cause is that the scheduler cannot find a node that meets the pod's resource requests (CPU/memory) or constraints (node selectors, affinity rules, taints/tolerations). Until a suitable node is found, the pod stays in Pending, waiting for scheduling.

Exam trap

CNCF often tests the distinction between scheduling failures (Pending) and runtime failures (CrashLoopBackOff, ImagePullBackOff), so the trap here is confusing a pod that cannot be placed on a node with a pod that fails after it starts running.

How to eliminate wrong answers

Option A is wrong because a container crash (e.g., CrashLoopBackOff) occurs after the pod is scheduled and running, not while it is still in Pending. Option B is wrong because a misconfigured service endpoint (e.g., wrong selector or port) affects network connectivity to the pod, not the pod's scheduling state; the pod would still be scheduled and running. Option D is wrong because an invalid container image (e.g., wrong tag or registry path) causes the pod to fail during container creation after scheduling, resulting in ImagePullBackOff or ErrImagePull, not a prolonged Pending state.

633
MCQhard

In event-driven architecture, which component is responsible for decoupling event producers from consumers?

A.Event broker
B.Event consumer
C.Event producer
D.API gateway
AnswerA

Why this answer

The event broker (e.g., Apache Kafka, RabbitMQ, or AWS EventBridge) acts as an intermediary that receives events from producers and forwards them to consumers. By decoupling the two, the producer does not need to know the consumer's location or status, and the consumer does not need to be actively listening when the event is published. This enables asynchronous, scalable, and fault-tolerant communication in event-driven architectures.

Exam trap

CNCF often tests the distinction between synchronous and asynchronous communication patterns, and the trap here is that candidates mistakenly think an API gateway (which handles synchronous requests) can decouple producers and consumers in an event-driven architecture, when in fact it only routes requests without persistent event storage or asynchronous delivery.

How to eliminate wrong answers

Option B (Event consumer) is wrong because the consumer is the recipient of events, not the component that decouples producers from consumers; it relies on the broker for decoupling. Option C (Event producer) is wrong because the producer generates events but has no built-in mechanism to decouple itself from consumers without an intermediary. Option D (API gateway) is wrong because an API gateway is designed for synchronous request-response patterns (e.g., REST APIs) and does not provide the persistent, asynchronous event buffering and routing that decouples producers from consumers.

634
MCQmedium

An application running in a Kubernetes pod needs to access a database that is deployed on a VM outside the cluster. The database IP is stable. Which is the best way to expose the database to the pod?

A.Expose the database via Ingress
B.Create a Service of type ExternalName pointing to the database hostname
C.Use a Headless Service
D.Create an EndpointSlice manually with the pod IP
AnswerB

ExternalName service provides a DNS alias to an external resource.

Why this answer

A Service of type ExternalName provides a DNS-based abstraction for external resources, mapping a Kubernetes service name to an external DNS name (the database hostname). This allows the pod to access the database via a stable in-cluster DNS name without needing to manage IP changes or network policies for external endpoints. It is the simplest and most Kubernetes-native way to expose a stable external IP to a pod.

Exam trap

The KCNA exam often tests the misconception that Ingress can handle any external service, but Ingress is strictly for HTTP/HTTPS traffic and cannot expose raw TCP services like databases.

How to eliminate wrong answers

Option A is wrong because Ingress is designed for HTTP/HTTPS traffic routing to internal services, not for exposing external databases (which typically use non-HTTP protocols like TCP). Option C is wrong because a Headless Service is used for stateful applications or service discovery of pod IPs within the cluster, not for pointing to an external resource. Option D is wrong because manually creating an EndpointSlice with the pod IP would require the database to be running as a pod inside the cluster, which contradicts the scenario where the database is on an external VM.

635
Multi-Selecthard

Which THREE are common features of progressive delivery?

Select 3 answers
A.Feature flags to enable/disable features
B.Gradual traffic shifting
C.Automated analysis and rollback
D.All-at-once deployment
E.Manual verification for every change
AnswersA, B, C

Feature flags allow toggling functionality without redeployment.

Why this answer

Progressive delivery uses gradual rollout, feature flags, and analysis to reduce risk.

636
Multi-Selectmedium

Which TWO statements accurately describe the concept of immutable infrastructure in the context of container orchestration? (Select two.)

Select 2 answers
A.Configuration changes can be applied via SSH into the container
B.Container images are versioned and promoted through environments without modification
C.When an update is needed, a new container image is built and deployed, and old containers are destroyed
D.Containers are updated in place by executing commands inside running containers
E.Stateful applications require mutable infrastructure
AnswersB, C

Immutable infrastructure promotes the same image through development, staging, and production without changes, ensuring consistency.

Why this answer

Immutable infrastructure treats container images as immutable artifacts that are versioned and promoted through environments (e.g., dev, staging, prod) without modification. This ensures consistency and reproducibility, as the same image is deployed across all stages without patching or altering it in place.

Exam trap

CNCF often tests the distinction between mutable and immutable patterns by presenting options that describe in-place updates (like SSH or exec commands) as valid, which candidates mistakenly accept if they confuse operational debugging with infrastructure management.

637
MCQeasy

What is the smallest deployable unit in Kubernetes that can be created and managed?

A.Container
B.Pod
C.Service
D.Deployment
AnswerB

Why this answer

The Pod is the smallest and simplest unit in the Kubernetes object model that you can create and manage. It represents a single instance of a running process in the cluster and encapsulates one or more containers, shared storage, and a unique cluster IP. While containers are the runtime units, Kubernetes does not manage containers directly; it manages Pods, which are the atomic scheduling unit.

Exam trap

The trap here is that candidates confuse containers (the runtime process) with Pods (the Kubernetes API object), leading them to pick 'Container' because they think of Docker-style units, but Kubernetes always wraps containers inside Pods as the smallest deployable and manageable entity.

How to eliminate wrong answers

Option A is wrong because a container is not a Kubernetes API object; it is a runtime abstraction managed by the container runtime (e.g., containerd), and Kubernetes schedules and manages Pods, not individual containers. Option C is wrong because a Service is an abstraction that defines a logical set of Pods and a policy to access them; it is not a deployable unit but a networking resource that sits above Pods. Option D is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods, providing declarative updates and scaling; it is not the smallest unit but a management layer over Pods.

638
MCQmedium

You want to run a batch job that processes data and then terminates. Which Kubernetes resource is best suited for this workload?

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

Why this answer

A Kubernetes Job is designed for batch processing workloads that run to completion and then terminate. Unlike controllers that maintain a desired number of running Pods (like Deployments or StatefulSets), a Job creates one or more Pods and ensures they successfully exit. Once the specified number of successful completions is reached, the Job stops, making it the ideal choice for a one-time data processing task.

Exam trap

CNCF often tests the distinction between controllers that maintain 'desired state' (Deployments, StatefulSets) versus controllers that manage 'completion' (Jobs), and the trap here is that candidates mistakenly choose Deployment for any workload that 'processes data' without recognizing the terminating nature of the task.

How to eliminate wrong answers

Option A is wrong because a StatefulSet is used for stateful applications that require stable, unique network identities and persistent storage (e.g., databases), not for terminating batch jobs. Option B is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, typically for cluster-level services like logging or monitoring, not for one-off tasks. Option D is wrong because a Deployment manages a set of identical Pods with a desired replica count and supports rolling updates, but it is designed for long-running services, not for workloads that should terminate after completion.

639
MCQeasy

What is a primary benefit of using containers over virtual machines?

A.Containers provide stronger isolation than VMs
B.Containers can run any operating system kernel
C.Containers are lightweight and share the host OS kernel
D.Containers require a hypervisor to run
AnswerC

Containers share the host kernel and have minimal overhead, making them lightweight.

Why this answer

Containers virtualize at the operating system level, sharing the host OS kernel while running in isolated user-space instances. This eliminates the need for a full guest OS per workload, making containers significantly more lightweight in terms of memory, disk usage, and startup time compared to virtual machines, which each require a separate kernel and hypervisor.

Exam trap

CNCF often tests the misconception that containers provide stronger isolation than VMs, when in fact VMs offer hardware-enforced isolation via the hypervisor, and containers rely on software-enforced kernel isolation, which is weaker.

How to eliminate wrong answers

Option A is wrong because containers provide weaker isolation than VMs; VMs use a hypervisor to enforce hardware-level isolation between guest kernels, while containers rely on kernel features like namespaces and cgroups, which share the host kernel and have a larger attack surface. Option B is wrong because containers cannot run any operating system kernel; they must use the same kernel as the host OS (e.g., Linux containers on a Linux host), and running a different kernel (e.g., Windows containers on Linux) requires a VM layer. Option D is wrong because containers do not require a hypervisor to run; they run directly on the host OS using container runtime engines like Docker or containerd, whereas VMs require a hypervisor (Type 1 or Type 2) to manage guest operating systems.

640
Multi-Selecthard

Which TWO of the following statements about Kubernetes namespaces are true?

Select 2 answers
A.Services in different namespaces cannot communicate with each other
B.Every Kubernetes object must be created in a namespace
C.Deleting a namespace will delete all objects in it
D.Namespaces can be used to implement resource quotas
E.Namespaces provide a way to divide cluster resources between multiple users
AnswersC, D

Correct. Deleting a namespace deletes all objects inside it.

Why this answer

Deleting a namespace triggers cascading deletion of all objects within it. Option D is correct because resource quotas can be applied per namespace to limit aggregate resource consumption. Option E is not entirely accurate: namespaces provide logical isolation, but dividing cluster resources among multiple users requires additional mechanisms like RBAC and resource quotas.

Without those, namespaces alone do not enforce resource division.

Exam trap

The trap is that many candidates think namespaces provide network isolation by default, but in reality, Kubernetes does not enforce inter-namespace network restrictions unless NetworkPolicies are explicitly applied.

641
MCQhard

Which of the following kubectl commands would you use to apply a manifest file and also save it for later updates?

A.kubectl create -f manifest.yaml
B.kubectl patch -f manifest.yaml
C.kubectl replace -f manifest.yaml
D.kubectl apply -f manifest.yaml
AnswerD

Apply is the recommended declarative approach.

Why this answer

`kubectl apply` uses a declarative approach: it creates the resource if it doesn't exist and updates it if it does, while also storing the last-applied configuration as an annotation (`kubectl.kubernetes.io/last-applied-configuration`). This allows future `apply` calls to perform a three-way merge diff (current live state, last-applied config, and new manifest) to intelligently update the resource, making it the standard for managing manifests that need ongoing updates.

Exam trap

The trap here is that candidates confuse `kubectl create` (which works for initial creation but fails on re-apply) with `kubectl apply` (which is idempotent and designed for ongoing updates), or they mistakenly think `kubectl replace` is equivalent to `apply` when it actually performs a full replacement without merge logic.

How to eliminate wrong answers

Option A is wrong because `kubectl create` is imperative and will fail with an error if the resource already exists, so it cannot be used for later updates. Option B is wrong because `kubectl patch` applies partial modifications directly to a live resource without saving the manifest state for future reconciliation; it does not store a last-applied configuration. Option C is wrong because `kubectl replace` is a destructive imperative command that replaces the entire resource definition, but it does not track the manifest for later updates and can cause drift if the resource was modified outside the manifest.

642
MCQmedium

A company wants to manage its Kubernetes resources using Git as the single source of truth, with automated synchronization. Which approach should they use?

A.Using Helm charts without version control
B.Infrastructure as Code with Terraform
C.Using kubectl apply -f with a CI/CD pipeline
D.GitOps with ArgoCD or Flux
AnswerD

GitOps uses Git as the source of truth and automatically syncs the cluster state to the desired state in Git.

Why this answer

GitOps is a practice where the entire system state is described declaratively in Git, and automated tools synchronize the cluster to match. ArgoCD and Flux are popular GitOps tools.

643
Multi-Selectmedium

Which TWO are pillars of observability? (Select two.)

Select 2 answers
A.SLIs
B.Alerting
C.Logs
D.Metrics
E.Dashboards
AnswersC, D

Why this answer

Logs and Metrics are two of the three pillars of observability (alongside Traces). Logs provide immutable, timestamped records of discrete events, while Metrics are numeric aggregations of data over time (e.g., Prometheus counters, histograms). Together they form the foundation for understanding system behavior in cloud-native environments.

Exam trap

CNCF often tests the distinction between the pillars of observability (Logs, Metrics, Traces) and the tools or outputs derived from them (e.g., SLIs, Alerting, Dashboards), leading candidates to confuse operational practices with foundational data types.

644
MCQmedium

A team wants to implement a canary deployment strategy for their Kubernetes application. Which tool is specifically designed for progressive delivery and can be used to automate canary rollouts?

A.Argo Rollouts
B.Flux
C.Kustomize
D.Helm
AnswerA

Argo Rollouts is purpose-built for progressive delivery with canary and blue-green deployments.

Why this answer

Argo Rollouts is a Kubernetes controller and set of CRDs that provides advanced deployment capabilities such as blue-green and canary deployments with automated promotion and rollback.

645
MCQmedium

A Deployment named 'nginx' is failing to update. You run 'kubectl rollout status deployment nginx' and see 'Waiting for deployment "nginx" rollout to finish: 0 out of 3 new replicas have been updated...'. The pod template has an image that does not exist. What is the most likely cause?

A.The cluster is out of memory
B.The deployment has exceeded the revision history limit
C.The deployment is paused
D.The new image tag is incorrect or does not exist in the registry
AnswerD

Non-existent image leads to ImagePullBackOff, preventing new replicas from becoming ready.

Why this answer

The rollout status shows that no new replicas have been created, which is a classic symptom of a container image pull failure. When the image tag specified in the pod template does not exist in the registry, the kubelet cannot pull the image, so the ReplicaSet controller cannot start new pods. This prevents the rollout from progressing past 0 out of 3 new replicas.

Exam trap

The trap here is that candidates may confuse a stuck rollout with resource constraints (memory/CPU) or assume the deployment is paused, but the specific status message '0 out of 3 new replicas have been updated' directly points to an image pull failure, not a scheduling or pause issue.

How to eliminate wrong answers

Option A is wrong because a cluster out-of-memory condition would typically cause pods to be in a Pending state with 'Insufficient memory' events, not a stuck rollout with 0 new replicas; the scheduler would fail to place pods, but the image pull issue is unrelated to memory. Option B is wrong because exceeding the revision history limit (default 10) only affects the number of old ReplicaSets retained, not the ability to create new replicas; the rollout would still proceed and create new pods. Option C is wrong because a paused deployment would show a different status message, such as 'deployment "nginx" paused', and the rollout status command would not report 'Waiting for deployment... rollout to finish'; paused deployments do not attempt to create new replicas at all.

646
MCQmedium

You create a Pod with the following YAML. What will happen when you apply it?

A.The Pod will fail to create because memory and CPU are in the wrong unit
B.The Pod will be created with memory limit of 128Mi and CPU limit of 500m
C.The Pod will be created without resource limits because the syntax is incorrect
D.The Pod will be created but requests and limits will be ignored because they are not valid for Pods
AnswerB

The YAML correctly specifies limits and requests.

Why this answer

The YAML defines resource limits and requests using standard Kubernetes units: '128Mi' for memory (mebibytes) and '500m' for CPU (millicores). These are valid and will be applied to the container, creating the Pod with the specified limits.

Exam trap

CNCF often tests the misconception that resource units like '128Mi' or '500m' are invalid or that resource limits are not applicable to Pods, when in fact they are standard and correctly applied to containers.

How to eliminate wrong answers

Option A is wrong because '128Mi' and '500m' are correct Kubernetes resource units (Mi = mebibytes, m = millicores), not invalid. Option C is wrong because the syntax is correct; resource limits are defined under 'resources.limits' and will be applied. Option D is wrong because resource limits and requests are valid for containers within a Pod, and they are not ignored; they are enforced by the kubelet.

647
MCQmedium

A developer wants to deploy a stateful application that requires stable network identities and persistent storage per pod instance. Which Kubernetes resource is most appropriate?

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

StatefulSets provide ordered, unique pod names and persistent storage per replica.

Why this answer

StatefulSet is the correct choice because it is specifically designed for stateful applications that require stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage per pod instance (via PersistentVolumeClaims that are not shared across replicas). Unlike Deployments, StatefulSet maintains a sticky identity for each pod, ensuring that on rescheduling, the pod retains its name, network identity, and bound storage.

Exam trap

CNCF often tests the misconception that a Deployment with PersistentVolumeClaims is sufficient for stateful workloads, but the trap is that Deployments do not guarantee stable network identities or ordered pod naming, which are critical for applications like databases that rely on hostname-based clustering.

How to eliminate wrong answers

Option A (DaemonSet) is wrong because it ensures exactly one pod runs on each node, which is ideal for node-level agents (e.g., log collectors, monitoring daemons), not for stateful applications needing stable identities and per-instance storage. Option B (Job) is wrong because it is designed for batch or one-off tasks that run to completion, not for long-running stateful services that require persistent storage and stable network identities. Option C (Deployment) is wrong because it treats pods as ephemeral and interchangeable; while it supports persistent storage via PersistentVolumeClaims, it does not guarantee stable network identities or ordered pod naming, so a rescheduled pod gets a new name and IP, breaking stateful expectations.

648
MCQmedium

What is the primary purpose of a service mesh in a cloud-native architecture?

A.To compile application code
B.To provide a dedicated infrastructure layer for handling service-to-service communication
C.To replace container orchestration
D.To store application configuration
AnswerB

The service mesh adds a layer of proxies to manage communication securely and reliably.

Why this answer

A service mesh provides observability, traffic management, and security for microservices communication, offloading these concerns from application code.

649
MCQmedium

A user wants to ensure that a pod is automatically restarted if its main process crashes. Which Kubernetes controller should they use?

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

Deployments maintain desired pod count and restart failed pods via ReplicaSet.

Why this answer

A Deployment is the correct controller because it manages a ReplicaSet, which ensures a specified number of pod replicas are running at all times. If the main process in a pod crashes, the ReplicaSet detects the pod failure (via the kubelet's liveness probe or the pod's phase becoming 'Failed') and automatically creates a new pod to replace it, thereby restarting the application. This self-healing behavior is a core feature of Deployments, making them ideal for stateless applications that need continuous availability.

Exam trap

CNCF often tests the misconception that a 'restart' means the same pod is reused, but in Kubernetes, a Deployment (via ReplicaSet) creates a completely new pod, while the 'restartPolicy' field only controls container restarts within the same pod — the trap is confusing pod-level restart (ReplicaSet replacement) with container-level restart (kubelet action).

How to eliminate wrong answers

Option B (Job) is wrong because a Job is designed to run a finite task to completion; it does not automatically restart pods if the main process crashes — instead, it may create a new pod only if the Job's restart policy is set to 'OnFailure', but the Job itself is not intended for long-running, always-on services. Option C (DaemonSet) is wrong because it ensures that a copy of a pod runs on every node (or a subset of nodes), but its primary purpose is node-level services (e.g., logging, monitoring), not automatic restart of a crashed main process in a general-purpose application; while DaemonSets do use a controller that recreates pods on failure, the question asks for a controller that ensures restart for a single application, and DaemonSet is node-scoped, not workload-scoped. Option D (CronJob) is wrong because it runs Jobs on a scheduled basis; it does not provide continuous pod restart — it only creates Jobs at specified times, and the underlying Job's behavior applies, but the CronJob itself does not monitor or restart crashed pods between scheduled runs.

650
MCQhard

You have a multi-container pod with containers 'app' and 'sidecar'. You need to execute a shell command inside the 'sidecar' container. Which kubectl command should you use?

A.kubectl exec -it mypod -- /bin/sh
B.kubectl exec -it sidecar --container mypod -- /bin/sh
C.kubectl exec -it mypod --container sidecar -- /bin/sh
D.kubectl exec -it mypod -c sidecar -- /bin/sh
AnswerD

The -c flag specifies the container to exec into.

Why this answer

`kubectl exec` uses the `-c` flag (or `--container`) to specify a target container within a multi-container pod. The syntax `kubectl exec -it mypod -c sidecar -- /bin/sh` opens an interactive shell in the 'sidecar' container of the pod named 'mypod'. Without the `-c` flag, the command defaults to the first container in the pod's spec, which would be 'app'.

Exam trap

CNCF often tests the misconception that `kubectl exec` defaults to the first container or that the container flag is optional, leading candidates to pick option A, which would execute in the wrong container.

How to eliminate wrong answers

Option A is wrong because it omits the `-c` flag, so the shell executes in the first container (typically 'app') rather than 'sidecar'. Option B is wrong because it incorrectly places `--container mypod` as a value for the container flag; the flag expects a container name, not a pod name, and the pod name should follow `exec`. Option C is wrong because it uses `--container sidecar` after the pod name, which is syntactically valid but not the standard short form; however, the primary issue is that the order of arguments is non-standard and could cause confusion, but the real trap is that `--container` is a valid alternative to `-c`, so this option is actually correct in function but not the preferred or most common syntax; however, for the KCNA exam, the `-c` flag is the standard and expected answer, and option C uses the long form `--container` which is also acceptable but less concise.

The question asks 'Which kubectl command should you use?' and D is the most direct and standard form.

651
MCQeasy

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

A.Deployment
B.ConfigMap
C.Service
D.Pod
AnswerC

A Kubernetes Service provides a stable virtual IP and DNS name that persists independently of pod lifecycles, satisfying the stem’s requirement for stable network endpoints. It uses label selectors to identify target pods and distributes incoming traffic across them via kube-proxy’s iptables or IPVS rules, fulfilling the load-balancing constraint without relying on individual pod IPs that change on rescheduling.

Why this answer

A Kubernetes Service provides a stable virtual IP (ClusterIP) and DNS name that remains constant even as Pods are created or destroyed. It uses label selectors to identify target Pods and performs TCP/UDP load balancing across them, ensuring reliable network access without requiring clients to track ephemeral Pod IPs.

Exam trap

The trap here is that candidates often confuse a Deployment’s ability to manage Pod replicas with providing a stable network endpoint, forgetting that Pod IPs are ephemeral and only a Service offers a fixed virtual IP and load balancing.

How to eliminate wrong answers

Option A is wrong because a Deployment manages Pod replicas and their rollout strategy, but it does not provide a stable network endpoint or load balancing; Pod IPs change on restart. Option B is wrong because a ConfigMap is used to inject configuration data (key-value pairs) into Pods, not to expose network endpoints. Option D is wrong because a Pod is an ephemeral unit with a non-static IP address; it cannot guarantee stable network access or load balancing across multiple Pods.

652
Multi-Selecteasy

Which TWO of the following are examples of Infrastructure as Code (IaC) tools? (Choose two.)

Select 2 answers
A.Docker
B.Terraform
C.Kubernetes
D.Prometheus
E.Pulumi
AnswersB, E

Terraform is an IaC tool by HashiCorp.

Why this answer

Terraform (B) is an Infrastructure as Code (IaC) tool that uses declarative configuration files (HashiCorp Configuration Language, HCL) to define and provision cloud and on-premises resources. It manages the full lifecycle of infrastructure through a state file and provider plugins, enabling version-controlled, repeatable deployments.

Exam trap

CNCF often tests the distinction between containerization/orchestration tools (Docker, Kubernetes) and actual IaC tools, leading candidates to confuse tools that manage applications with those that provision infrastructure.

653
MCQeasy

What is the Container Runtime Interface (CRI)?

A.A plugin interface that allows kubelet to use a variety of container runtimes
B.A specification for container images
C.A registry for storing container images
D.A command-line tool for managing containers
AnswerA

CRI enables kubelet to communicate with runtimes.

Why this answer

The Container Runtime Interface (CRI) is a plugin interface that enables the kubelet to communicate with different container runtimes (e.g., containerd, CRI-O) without needing to know their internal implementation details. It defines a gRPC-based protocol for managing container lifecycles, image operations, and pod sandboxes, allowing Kubernetes to remain runtime-agnostic.

Exam trap

CNCF often tests whether candidates confuse CRI with the OCI runtime spec or with container image formats, so the trap is assuming CRI defines image structure rather than the runtime-kubelet interface.

How to eliminate wrong answers

Option B is wrong because container images are defined by the OCI Image Specification, not by CRI. Option C is wrong because registries (like Docker Hub or Harbor) are storage systems for images, not an interface for runtime integration. Option D is wrong because command-line tools (e.g., crictl) may use CRI under the hood, but CRI itself is an API, not a CLI tool.

654
MCQmedium

A developer runs 'helm upgrade --install myapp ./mychart' and sees the release status is 'failed'. What is the most likely cause?

A.The chart contains invalid Kubernetes manifests
B.The Tiller pod is not running
C.The Helm binary is outdated
D.The namespace does not exist
AnswerA

Invalid manifests cause the API server to reject them, failing the release.

Why this answer

A failed Helm upgrade usually means the Kubernetes API rejected the manifests (e.g., invalid YAML, resource conflict).

655
Multi-Selecthard

Which THREE of the following are valid reasons to use a StatefulSet instead of a Deployment? (Select 3)

Select 3 answers
A.You only need a single instance of the application
B.You need stable, unique network identifiers (e.g., pod hostnames) that persist across reschedules
C.You need each pod to have its own persistent storage that is not shared
D.You need to deploy a stateless web application with multiple replicas
E.You need ordered, graceful deployment and scaling (e.g., pod-0 starts before pod-1)
AnswersB, C, E

StatefulSets provide stable network identities (e.g., pod-0, pod-1) that are maintained across rescheduling.

Why this answer

StatefulSets provide stable, unique network identifiers (e.g., pod hostnames) that persist across reschedules because each pod gets a fixed ordinal index (e.g., pod-0, pod-1) and a corresponding DNS name (e.g., pod-0.statefulset.namespace.svc.cluster.local). This is essential for applications like databases (e.g., Cassandra, ZooKeeper) that rely on consistent peer discovery and identity, which Deployments cannot guarantee since they assign random pod names and IPs.

Exam trap

CNCF often tests the misconception that StatefulSets are only for persistent storage, but the trap here is that candidates overlook the requirement for stable network identities and ordered operations, which are equally critical and distinct from storage needs.

656
MCQmedium

Which open-source project provides a unified standard for collecting and exporting telemetry data (metrics, logs, and traces) from applications?

A.Prometheus
B.OpenTelemetry
C.Jaeger
D.Fluentd
AnswerB

Correct. OpenTelemetry is a unified standard for metrics, logs, and traces.

Why this answer

OpenTelemetry (OTel) is the industry standard for observability data collection and export, providing vendor-agnostic instrumentation.

657
MCQeasy

What is the smallest deployable unit in Kubernetes?

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

A Pod is the smallest deployable unit in Kubernetes because it encapsulates one or more containers that share the same network namespace, storage volumes, and lifecycle. This satisfies the constraint of atomic scheduling: a Pod is the indivisible object that the scheduler places onto a single node, and it cannot be split across nodes. Containers alone are not directly scheduled; they must be wrapped inside a Pod to run.

Why this answer

The Pod is the smallest deployable unit in Kubernetes because it represents a single instance of a running process in the cluster and encapsulates one or more containers with shared storage and network resources. While containers are the runtime units, Kubernetes schedules and manages Pods, not individual containers, making the Pod the atomic building block for deployment.

Exam trap

CNCF often tests the misconception that a container is the smallest deployable unit because containers are the runtime entities, but Kubernetes abstracts them into Pods for scheduling and resource sharing, so candidates who confuse 'runtime unit' with 'deployable unit' will incorrectly select Container.

How to eliminate wrong answers

Option A is wrong because a Deployment is a higher-level abstraction that manages ReplicaSets and Pods, not the smallest deployable unit itself. Option C is wrong because a Container is the runtime process inside a Pod, but Kubernetes cannot schedule or manage a container directly without a Pod wrapper. Option D is wrong because a Node is a worker machine in the cluster that hosts Pods, not a deployable unit — you deploy Pods onto Nodes, not Nodes themselves.

658
MCQeasy

Which command is used to create a Deployment that runs an nginx container with 3 replicas?

A.kubectl create pod nginx --image=nginx --replicas=3
B.kubectl run nginx --image=nginx --replicas=3
C.kubectl create deployment nginx --image=nginx --replicas=3
D.kubectl scale deployment nginx --replicas=3
AnswerC

This command creates a Deployment named nginx with the specified image and replicas.

Why this answer

`kubectl create deployment` is the standard Kubernetes command to create a Deployment resource, and the `--replicas=3` flag directly sets the desired replica count to 3. This command creates a Deployment that manages a ReplicaSet to ensure three nginx pods are running and maintained.

Exam trap

The trap here is that candidates confuse `kubectl run` (which creates a pod, not a deployment with replicas) with `kubectl create deployment`, or they mistakenly think `kubectl scale` can create a deployment, when it only modifies an existing one.

How to eliminate wrong answers

Option A is wrong because `kubectl create pod` does not exist; pods are created imperatively with `kubectl run` or declaratively via a manifest, and `--replicas` is not a valid flag for pod creation. Option B is wrong because `kubectl run` creates a single pod (or a deployment in older versions, but not with `--replicas`); the `--replicas` flag is not supported by `kubectl run` in current Kubernetes versions. Option D is wrong because `kubectl scale deployment` modifies an existing Deployment's replica count, but it does not create a new Deployment; the question asks for creating a Deployment, not scaling an existing one.

659
MCQmedium

A team wants to minimize downtime during a Deployment rollout. Which strategy ensures that new pods are created before old pods are terminated?

A.Set strategy type to 'Recreate'.
B.Set strategy type to 'RollingUpdate' with maxSurge=0, maxUnavailable=1.
C.Set strategy type to 'RollingUpdate' with maxSurge=1, maxUnavailable=0.
D.Set strategy type to 'RollingUpdate' with maxSurge=1, maxUnavailable=1.
AnswerC

New pods are created first, ensuring zero downtime.

Why this answer

Setting `maxSurge=1` and `maxUnavailable=0` in a RollingUpdate strategy ensures that one additional pod is created above the desired replica count before any existing pod is terminated. This guarantees zero downtime by maintaining full capacity during the rollout, as new pods become ready before old ones are removed.

Exam trap

The trap here is that candidates often confuse `maxSurge` and `maxUnavailable` values, mistakenly thinking that allowing both a surge and an unavailable pod (option D) is safer, when in fact it can still cause a temporary capacity drop if the new pod is not ready before the old one is terminated.

How to eliminate wrong answers

Option A is wrong because the 'Recreate' strategy terminates all old pods before creating new ones, causing downtime. Option B is wrong because `maxSurge=0, maxUnavailable=1` terminates one old pod before creating a new one, which can cause a temporary capacity deficit and potential downtime. Option D is wrong because `maxSurge=1, maxUnavailable=1` allows both a new pod to be created and an old pod to be terminated simultaneously, which may still result in a brief capacity drop if the new pod is not ready before the old one is removed.

660
Multi-Selectmedium

Which THREE of the following are valid use cases for distributed tracing in a microservices architecture?

Select 3 answers
A.Monitoring CPU and memory usage of each service instance
B.Understanding the dependency graph between microservices
C.Pinpointing the root cause of an error in a distributed transaction
D.Identifying which service contributes the most latency to an end-user request
E.Capturing detailed error messages and stack traces
AnswersB, C, D

Traces reveal service call relationships.

Why this answer

Distributed tracing is designed to track the flow of a single request across multiple microservices, recording timing and causality. Option B is correct because tracing systems like Jaeger or Zipkin automatically build a dependency graph by analyzing the parent-child relationships between spans, which reveals how services interact. This is a core use case for understanding service topology and identifying bottlenecks in a distributed system.

Exam trap

The KCNA exam often tests the distinction between observability pillars (metrics, logs, traces) and expects candidates to recognize that distributed tracing is not a catch-all for monitoring or logging tasks, so the trap is confusing request-level tracing with infrastructure metrics or detailed error logging.

661
MCQeasy

What is a key benefit of using containers over virtual machines for application deployment?

A.Containers can only run on Linux
B.Containers require a hypervisor to run
C.Containers provide stronger isolation than VMs
D.Containers are more lightweight and start faster than VMs
AnswerD

Containers share the host OS kernel and do not need to boot a guest OS, leading to faster startup times and lower overhead.

Why this answer

Containers share the host OS kernel and run as isolated processes, requiring no separate guest OS per instance. This makes them significantly more lightweight and faster to start than VMs, which must boot a full guest OS. For application deployment, this translates to higher density, lower resource overhead, and near-instant startup times.

Exam trap

The trap here is that candidates often confuse 'stronger isolation' with 'better security' and pick Option C, not realizing that VMs actually provide stronger isolation due to separate kernels and hardware virtualization, while containers are designed for lightweight efficiency, not maximum isolation.

How to eliminate wrong answers

Option A is wrong because containers are not limited to Linux; Windows containers run on Windows Server and Docker Desktop supports both Linux and Windows containers via appropriate runtimes. Option B is wrong because containers do not require a hypervisor; they run directly on the host OS using kernel features like cgroups and namespaces, whereas VMs require a hypervisor to virtualize hardware. Option C is wrong because VMs provide stronger isolation than containers; each VM has its own separate kernel and hardware virtualization, while containers share the host kernel, making isolation weaker by design.

662
MCQmedium

Which command retrieves logs from a specific container named 'sidecar' in a multi-container pod?

A.kubectl logs pod-name sidecar
B.kubectl logs pod-name --container sidecar
C.kubectl logs pod-name -c sidecar
D.kubectl logs sidecar pod-name
AnswerC

Correct syntax for specifying a container.

Why this answer

The -c flag specifies the container name.

663
Multi-Selectmedium

Which three of the following are valid methods to create or update resources in Kubernetes? (Choose three.)

Select 3 answers
A.kubectl apply -f manifest.yaml
B.kubectl update -f manifest.yaml
C.kubectl replace -f manifest.yaml
D.kubectl create -f manifest.yaml
E.Using the Kubernetes REST API directly
AnswersA, D, E

`kubectl apply -f manifest.yaml` is a declarative command that creates or updates resources, making it a valid method.

Why this answer

`kubectl apply -f manifest.yaml` is correct because it uses a declarative approach to create or update resources by applying a configuration file, performing a three-way merge between the local file, the current live object, and the last-applied annotation. `kubectl create -f manifest.yaml` is also correct because it creates resources from a file or stdin, though it will fail if the resource already exists. Using the Kubernetes REST API directly (via HTTP requests like POST for create and PUT for update) is another valid method. `kubectl update` is not a valid kubectl command; the correct imperative commands for updates are `kubectl edit` or `kubectl patch`. `kubectl replace -f manifest.yaml` is an imperative command that will fail if the resource does not exist and is not recommended for general resource management.

Exam trap

The trap here is that candidates often confuse `kubectl replace` as a valid update method because it sounds similar to 'update', but it is an imperative command that fails on non-existent resources and does not support declarative management like `apply`.

664
Multi-Selecthard

Which THREE of the following are resiliency patterns commonly used in cloud native applications? (Choose three.)

Select 3 answers
A.Retry
B.Timeout
C.Singleton pattern
D.Circuit breaker
E.Round-robin load balancing
AnswersA, B, D

Retrying failed operations can handle transient failures.

Why this answer

The Retry pattern is a fundamental resiliency mechanism in cloud-native applications. When a transient failure occurs (e.g., a network timeout or a temporary database unavailability), the application automatically reattempts the failed operation. This pattern is often implemented with exponential backoff and jitter to avoid overwhelming the downstream service, as seen in libraries like Netflix Hystrix or Kubernetes client-go retry logic.

Exam trap

CNCF often tests the distinction between design patterns (like Singleton) and cloud-native resiliency patterns (like Retry, Timeout, Circuit Breaker), so candidates mistakenly select Singleton because it is a well-known pattern, but it does not address fault tolerance or failure recovery.

665
MCQeasy

Which component is responsible for running containers on a Kubernetes node?

A.kube-controller-manager
B.kube-proxy
C.kube-apiserver
D.kubelet
AnswerD

The kubelet runs on each node and manages pod lifecycles, including starting containers via the container runtime.

Why this answer

The kubelet is the primary node agent that runs on each Kubernetes node. It is responsible for ensuring that containers are running in a Pod as expected, by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers based on PodSpecs received from the API server.

Exam trap

The trap here is that candidates often confuse kubelet with kube-controller-manager, thinking the controller manager handles node-level container operations, but the kubelet is the only component that directly manages containers on the node.

How to eliminate wrong answers

Option A is wrong because the kube-controller-manager runs controller processes (like Node Controller, Replication Controller) at the control plane level, not on worker nodes, and does not directly manage containers. Option B is wrong because kube-proxy is a network proxy that handles network rules and service load balancing on each node, but it does not run or manage containers. Option C is wrong because kube-apiserver is the front-end of the Kubernetes control plane that exposes the Kubernetes API; it validates and processes RESTful requests but does not execute container lifecycle operations on nodes.

666
MCQhard

In a serverless architecture using Knative, what happens to a service that has not received traffic for an extended period?

A.It throws an error and must be redeployed
B.It continues running with one replica to reduce cold start latency
C.It scales down to zero replicas and is reactivated on the next request
D.It is automatically deleted
AnswerC

Knative supports auto-scaling to zero for idle services.

Why this answer

Knative scales to zero when idle, meaning no pods are running, thus no cost incurred.

667
MCQmedium

You are writing a Deployment YAML (apps/v1) for a stateless web application. The application should have 3 replicas and use rolling updates with maxSurge=1 and maxUnavailable=0. Which field should you set under spec.strategy?

A.type: Recreate
B.type: Canary
C.type: OnDelete
D.type: RollingUpdate with rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }
AnswerD

This matches the requirement.

Why this answer

The Deployment's `spec.strategy.type` must be set to `RollingUpdate` to enable a controlled, incremental update of pods. The `rollingUpdate` field then allows you to specify `maxSurge: 1` (one extra pod above the desired count during update) and `maxUnavailable: 0` (ensure all existing pods remain available during the update), which is the exact configuration for a zero-downtime rolling update with a single surge pod.

Exam trap

CNCF often tests the misconception that `maxSurge` and `maxUnavailable` are top-level fields under `spec.strategy`, when in fact they must be nested inside `rollingUpdate` and the `type` must explicitly be set to `RollingUpdate`.

How to eliminate wrong answers

Option A is wrong because `type: Recreate` terminates all existing pods before creating new ones, which violates the requirement for a rolling update with `maxSurge` and `maxUnavailable` settings. Option B is wrong because `Canary` is not a valid Deployment strategy type in the `apps/v1` API; it is a separate deployment pattern often implemented via service mesh or progressive delivery tools, not a native Kubernetes Deployment field. Option C is wrong because `OnDelete` is a strategy type used by StatefulSets (not Deployments) and only triggers pod replacement when a pod is manually deleted, which does not support automated rolling updates or the specified surge/unavailable parameters.

668
MCQeasy

What does SLA stand for in the context of service reliability?

A.Service Level Agreement
B.Service Level Indicator
C.Service Level Availability
D.Service Level Objective
AnswerA

Correct.

Why this answer

SLA stands for Service Level Agreement, a contract specifying expected service level.

669
MCQhard

An application running in a Kubernetes cluster needs to securely access a third-party API. The API key must be stored in the cluster and mounted into the Pod as an environment variable. Which is the best practice?

A.Create a Secret with the API key and use envFrom or valueFrom in the Pod spec.
B.Store the API key in a ConfigMap and reference it in the Pod spec.
C.Embed the API key directly in the container image.
D.Store the API key in a Pod annotation and read it with kubectl.
AnswerA

Secrets are designed for confidential data and can be injected as environment variables.

Why this answer

Kubernetes Secrets are specifically designed to store sensitive data like API keys, and using `envFrom` or `valueFrom` in the Pod spec injects the Secret value as an environment variable without exposing it in the Pod definition. This approach follows the principle of least privilege and avoids hardcoding secrets in images or plaintext ConfigMaps.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming both are equally secure for sensitive data, but Kubernetes tests the understanding that ConfigMaps store data in plaintext and are not encrypted, making them unsuitable for secrets like API keys.

How to eliminate wrong answers

Option B is wrong because ConfigMaps store data in plaintext and are intended for non-sensitive configuration, not secrets; using a ConfigMap for an API key would expose it in etcd and logs. Option C is wrong because embedding the API key directly in the container image violates security best practices, as the key would be baked into the image layers and accessible to anyone with image pull access. Option D is wrong because Pod annotations are metadata fields not designed for secret storage, and reading them with kubectl would expose the key in the API server and command output.

670
Multi-Selecthard

Which THREE of the following are true about Kubernetes labels and selectors?

Select 3 answers
A.Labels are encrypted at rest by default
B.Set-based selectors support operators like 'In' and 'NotIn'
C.Selectors can be used by Services to identify which pods to route traffic to
D.Labels are immutable after creation
E.Labels can be used to organize and select subsets of objects
AnswersB, C, E

Set-based selectors support 'In', 'NotIn', 'Exists', and 'DoesNotExist'.

Why this answer

Kubernetes set-based selectors support operators like 'In', 'NotIn', 'Exists', and 'DoesNotExist', allowing more flexible matching than equality-based selectors. This is defined in the Kubernetes API specification for label selectors, enabling complex filtering of resources.

Exam trap

CNCF often tests the misconception that labels are immutable like certain other Kubernetes fields, but labels are explicitly designed to be mutable for dynamic resource management.

671
Multi-Selecthard

Which THREE of the following are features typically provided by a service mesh? (Choose three.)

Select 3 answers
A.Observability through metrics and tracing
B.Auto-scaling of pods based on CPU
C.Traffic management between services
D.Security with mutual TLS (mTLS)
E.Service discovery
AnswersA, C, D

Service mesh collects telemetry data for monitoring.

Why this answer

Service mesh provides traffic management (routing, canary releases), observability (metrics, tracing), and security (mTLS, authorization). Auto-scaling is handled by Horizontal Pod Autoscaler or custom metrics, not by the service mesh. Service discovery is often built into Kubernetes itself, though service mesh can enhance it, but it's not a core feature.

672
MCQhard

An administrator needs to ensure that Pods from two different Deployments cannot communicate with each other. Which Kubernetes resource should be used?

A.NetworkPolicy
B.RBAC Role
C.PodSecurityPolicy
D.ResourceQuota
AnswerA

NetworkPolicy defines ingress/egress rules for pod communication.

Why this answer

NetworkPolicy is the correct resource because it acts as a firewall for Kubernetes Pods, controlling ingress and egress traffic at the IP address and port level using layer 3/4 rules. By applying a NetworkPolicy that denies all traffic between the Pods of the two Deployments (e.g., using podSelector and ingress/egress rules with an empty `from` or `to` block), the administrator can enforce network isolation. This is the native Kubernetes mechanism for restricting Pod-to-Pod communication within a cluster.

Exam trap

The trap here is that candidates confuse NetworkPolicy with RBAC or PodSecurityPolicy, mistakenly thinking that authorization or security contexts can control network traffic, when in fact only NetworkPolicy (with a compatible CNI) provides layer 3/4 isolation.

How to eliminate wrong answers

Option B (RBAC Role) is wrong because RBAC controls authorization for Kubernetes API operations (e.g., creating Pods, reading Secrets) and does not manage network traffic between Pods. Option C (PodSecurityPolicy) is wrong because it defines security constraints on Pods (e.g., privileged containers, host namespaces) but has no effect on network communication between Pods. Option D (ResourceQuota) is wrong because it limits aggregate resource consumption (CPU, memory, storage) per namespace and cannot restrict network connectivity between Pods.

673
MCQmedium

Which Kubernetes object provides a stable IP address and DNS name to access a set of pods, and can perform load balancing?

A.Service
B.Ingress
C.Deployment
D.Pod
AnswerA

Services provide stable IP and DNS, and load balance traffic to selected pods.

Why this answer

A Service is the correct Kubernetes object because it provides a stable virtual IP (ClusterIP) and a DNS name (via CoreDNS) that remains constant even as pods are created or destroyed. It performs layer 4 (TCP/UDP) load balancing across the set of pods selected by its label selector, using iptables or IPVS rules to distribute traffic.

Exam trap

A common misconception is that Ingress itself performs load balancing, but Ingress is only a routing rule set; the actual load balancing is done by the Service or the Ingress controller's underlying proxy.

How to eliminate wrong answers

Option B (Ingress) is wrong because Ingress is not a load balancer itself; it is an API object that manages external HTTP/HTTPS access to Services, typically relying on a controller (e.g., NGINX) to route traffic, and it does not provide a stable IP or DNS name directly to pods. Option C (Deployment) is wrong because a Deployment manages the desired state of replica sets and pod rollouts, but it does not expose a network endpoint or perform load balancing. Option D (Pod) is wrong because a Pod has a dynamic IP address that changes on restart, and it cannot provide stable DNS or load balancing across multiple pods.

674
Multi-Selectmedium

Which TWO of the following are valid ways to expose a set of pods as a network service in Kubernetes?

Select 2 answers
A.Service of type NodePort
B.NetworkPolicy
C.Service of type ClusterIP
D.Ingress resource
E.Deployment with replicas
AnswersA, C

NodePort exposes the service on each node's IP at a static port.

Why this answer

A Service of type NodePort exposes a set of pods on a static port on each node's IP address, making the service accessible from outside the cluster. This is a valid Kubernetes resource for exposing pods as a network service, as it creates a mapping from a node port to the ClusterIP and then to the target pods.

Exam trap

The KCNA exam often tests the misconception that Ingress or NetworkPolicy can directly expose pods as a network service, but Ingress requires a Service backend and NetworkPolicy only controls traffic, not exposure.

675
MCQeasy

What is the smallest deployable unit in Kubernetes?

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

A Pod is the atomic unit of scheduling in Kubernetes.

Why this answer

The Pod is the smallest deployable unit in Kubernetes because it encapsulates one or more containers that share the same network namespace, storage volumes, and lifecycle. Containers are not directly scheduled onto nodes; instead, Kubernetes always wraps them into Pods, which are the atomic unit of scheduling and execution. This design ensures that co-located containers (e.g., a sidecar and its main app) can communicate via localhost and share resources without additional orchestration.

Exam trap

A common misconception is that a Container is the smallest unit because it is the runtime entity, but Kubernetes abstracts containers into Pods to enforce co-location and shared networking, making the Pod the fundamental scheduling and deployment atom.

How to eliminate wrong answers

Option A is wrong because a Node is a worker machine (physical or virtual) that hosts Pods, but it is not the smallest deployable unit; nodes are infrastructure components that run Pods. Option B is wrong because a Container is the runtime instance of an image, but Kubernetes does not deploy containers directly—containers are always placed inside a Pod, which provides the execution environment and resource boundaries. Option C is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods, providing declarative updates and scaling; it is not the smallest unit of deployment but rather a management abstraction over Pods.

Page 8

Page 9 of 12

Page 10