Courseiva

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 676–750

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

Take a mock examExam hub
Page 9

Page 10 of 12

Page 11
676
MCQmedium

A team is implementing a multi-cloud strategy to avoid vendor lock-in. Which Kubernetes feature is most helpful for abstracting the underlying cloud provider?

A.Services
B.ConfigMaps
C.Namespaces
D.Kubernetes API
AnswerD

The API abstracts infrastructure differences.

Why this answer

The Kubernetes API server provides a consistent interface regardless of the underlying infrastructure. Namespaces organize resources, Services provide networking abstractions, and ConfigMaps store configuration.

Full explanation →
677
MCQmedium

A DevOps team wants to adopt a deployment pattern where a new version of an application is gradually rolled out to a small subset of users before full deployment. Which progressive delivery technique should they use?

A.Canary deployment
B.Rolling update
C.Blue-green deployment
D.Recreate deployment
AnswerA

Canary releases a new version to a small subset of users, monitoring before full rollout.

Why this answer

Canary deployment releases the new version to a small percentage of users initially, then gradually increases traffic.

Full explanation →
678
MCQmedium

A team notices that a pod remains in 'CrashLoopBackOff' state after deployment. The application logs show 'Error: unable to bind to port 8080'. What is the most likely cause?

A.The pod's resource limits are too low.
B.An environment variable has a typo in the Deployment spec.
C.The readiness probe is misconfigured.
D.The container's port is already in use on the host node.
AnswerD

Correct; port conflict prevents binding, causing container to exit.

Why this answer

The error 'unable to bind to port 8080' indicates that the container process cannot open port 8080 for listening. The most likely cause is that another process on the host node is already using port 8080, preventing the container from binding to it. This is a classic port conflict scenario, where the host's network namespace has a port already allocated, and the container (even with its own network namespace) may be using host networking or the port is mapped from the host.

Exam trap

The KCNA exam often tests the misconception that a 'CrashLoopBackOff' with a port bind error is caused by resource limits or probe misconfiguration, when in reality it points to a network-level port conflict on the host node.

How to eliminate wrong answers

Option A is wrong because resource limits being too low would cause the pod to be OOMKilled or throttled, not a bind error on a specific port. Option B is wrong because a typo in an environment variable would cause the application to misread configuration, but the error message explicitly states a port binding failure, not a missing or incorrect variable. Option C is wrong because a misconfigured readiness probe would cause the pod to be marked as not ready and removed from service endpoints, but the pod would still start and run; the error here occurs at container startup before any probe can fail.

Full explanation →
679
Multi-Selecthard

Which TWO of the following are best practices for structuring log output in cloud-native applications to maximize observability?

Select 2 answers
A.Include verbose debug-level information in every log line
B.Use multi-line log entries for detailed error information
C.Output logs in structured format such as JSON
D.Include a unique request or correlation ID in each log entry
E.Avoid timestamps to reduce log size
AnswersC, D

Structured logs are machine-parseable and easily ingested by log aggregators.

Why this answer

Structured logging (e.g., JSON) enables automated parsing, filtering, and querying by log aggregation tools like Fluentd, Logstash, or cloud-native observability backends (e.g., Elasticsearch, Loki). This format ensures each log entry has consistent key-value pairs, making it machine-readable and facilitating correlation across distributed services without manual text parsing.

Exam trap

CNCF often tests the misconception that 'more detail is better' (Option A) or that 'human readability' (Option B) is the priority, when in cloud-native observability, machine-parseable, single-line structured logs are the standard for scalability and automation.

Full explanation →
680
MCQeasy

What is the smallest deployable unit in Kubernetes?

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

A Pod is the smallest deployable unit that can be created, scheduled, and managed.

Why this answer

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. While containers are the runtime processes, Kubernetes schedules and manages Pods as atomic units, meaning you cannot deploy a container directly without a Pod wrapper.

Exam trap

The trap here is that candidates confuse 'container' as the smallest unit because Docker popularized container-centric thinking, but Kubernetes abstracts containers into Pods as the fundamental scheduling and deployment boundary.

How to eliminate wrong answers

Option B is wrong because a Node is a worker machine (physical or virtual) that hosts Pods, not a deployable unit itself; you deploy Pods onto Nodes. Option C is wrong because a Container is the runtime process inside a Pod, but Kubernetes does not schedule containers individually—they must be part of a Pod. Option D is wrong because a Deployment is a higher-level controller that manages the desired state of ReplicaSets and Pods, but the smallest unit it directly operates on is still the Pod.

Full explanation →
681
MCQmedium

A retail company runs its e-commerce platform on Kubernetes. During a flash sale, the application experiences high latency. The team notices that the database pods are CPU-bound and the application pods are waiting on database responses. Which architectural change would best address this bottleneck?

A.Change the database service type from ClusterIP to NodePort.
B.Implement read replicas for the database and configure the application to use them for read operations.
C.Increase the number of application pod replicas.
D.Store database configuration in a ConfigMap to improve startup time.
AnswerB

Read replicas distribute the read load, reducing CPU pressure on the primary database.

Why this answer

The bottleneck is caused by the database being CPU-bound, meaning it cannot process requests fast enough. Implementing read replicas offloads read queries from the primary database, reducing its CPU load and allowing it to handle write operations more efficiently. The application can be configured to route read operations to the replicas, which directly addresses the latency caused by waiting on database responses.

Exam trap

CNCF often tests the misconception that scaling application pods (Option C) is a universal fix for performance issues, but here it would amplify the database bottleneck rather than resolve it.

How to eliminate wrong answers

Option A is wrong because changing the service type from ClusterIP to NodePort exposes the database externally but does nothing to reduce its CPU load or improve query processing speed. Option C is wrong because increasing application pod replicas would only increase the number of requests hitting the already CPU-bound database, worsening the bottleneck. Option D is wrong because storing database configuration in a ConfigMap improves manageability and startup time but has no impact on runtime database CPU utilization or query latency.

Full explanation →
682
Matchingmedium

Match each Kubernetes scheduler concept to its description.

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

Concepts
Matches

Constraints that attract pods to nodes based on node labels

Mechanism to repel pods from nodes unless they tolerate the taint

Minimum amount of CPU/memory guaranteed to a container

Maximum amount of CPU/memory a container can use

Indicates importance of a pod relative to others for preemption

Why these pairings

NodeAffinity and NodeSelector both use node labels but differ in expressiveness. PodAffinity schedules relative to other pods. Taints/Tolerations control which pods can be placed on nodes.

Common confusion: swapping NodeAffinity with PodAffinity or Taints/Tolerations.

Full explanation →
683
MCQhard

You need to ensure that a pod runs on a node with SSD storage. How can you achieve this?

A.Use nodeSelector with a label that matches nodes having SSDs
B.Use a taint on nodes without SSDs and a toleration on the pod
C.Use pod anti-affinity to avoid nodes without SSDs
D.Use node affinity with requiredDuringSchedulingIgnoredDuringExecution
AnswerD

Node affinity allows you to specify hard or soft constraints. Using requiredDuringSchedulingIgnoredDuringExecution ensures the pod is only scheduled on nodes with the specified label.

Why this answer

Node affinity with `requiredDuringSchedulingIgnoredDuringExecution` is the correct approach because it allows you to specify a hard constraint that the pod must be scheduled on a node with a specific label (e.g., `disk=ssd`). This ensures the pod runs only on nodes that have SSD storage, as the scheduler enforces this rule during pod placement.

Exam trap

Kubernetes often tests the distinction between node affinity (which attracts pods to nodes with specific labels) and taints/tolerations (which repel pods from nodes), leading candidates to incorrectly choose taints/tolerations when the goal is to ensure a pod runs on a node with a specific feature.

How to eliminate wrong answers

Option A is wrong because `nodeSelector` is a simpler, legacy mechanism that only supports exact match of a single label key-value pair, but it does not provide the flexibility of node affinity (e.g., multiple expressions, `In`, `NotIn` operators) and is less expressive for complex scheduling requirements. Option B is wrong because taints and tolerations are used to repel pods from nodes (unless tolerated), not to attract pods to specific node features; they prevent scheduling on tainted nodes but do not actively ensure a pod lands on a node with SSDs. Option C is wrong because pod anti-affinity is used to avoid co-locating pods with other pods (e.g., spread across nodes), not to select nodes based on hardware characteristics like SSD storage.

Full explanation →
684
MCQeasy

A pod is stuck in 'Pending' state. 'kubectl describe pod' shows '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate.' What is the most likely cause?

A.All nodes have disk pressure.
B.All nodes are unreachable or have been cordoned.
C.The pod has a toleration that matches the taint.
D.The nodes do not have enough CPU or memory.
AnswerB

The taint indicates nodes are unreachable.

Why this answer

The taint `node.kubernetes.io/unreachable` is automatically added by the node controller when a node becomes unreachable (e.g., network failure, kubelet stops heartbeating). The error shows all 4 nodes have this taint and the pod has no matching toleration, meaning the scheduler cannot place the pod. This directly indicates all nodes are unreachable or have been cordoned (which also adds the `node.kubernetes.io/unschedulable` taint, but here the specific taint is `unreachable`).

Exam trap

The KCNA exam often tests the distinction between taint types — candidates confuse `unreachable` with resource-based taints like `disk-pressure` or `insufficient-memory`, or assume a toleration would solve the issue when the problem is that no toleration exists.

How to eliminate wrong answers

Option A is wrong because disk pressure is indicated by the taint `node.kubernetes.io/disk-pressure`, not `node.kubernetes.io/unreachable`. Option C is wrong because if the pod had a toleration matching the taint, it would be scheduled despite the taint, but the error explicitly states the pod didn't tolerate it. Option D is wrong because insufficient CPU or memory would show taints like `node.kubernetes.io/insufficient-cpu` or `node.kubernetes.io/insufficient-memory`, not the `unreachable` taint.

Full explanation →
685
MCQmedium

Which Kubernetes object should you use to store non-sensitive configuration data that can be consumed by Pods as environment variables or mounted files?

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

ConfigMap is used to store non-confidential configuration data in key-value pairs.

Why this answer

ConfigMap is the correct Kubernetes object for storing non-sensitive configuration data, such as key-value pairs or configuration files. It is designed to decouple configuration artifacts from container images, allowing Pods to consume this data as environment variables, command-line arguments, or mounted files in a volume. Unlike Secrets, ConfigMaps do not provide encryption or base64 encoding by default, making them suitable only for non-sensitive information.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming both are interchangeable for configuration, but the KCNA exam tests the distinction that Secrets are for sensitive data and ConfigMaps are for non-sensitive data, and that PersistentVolume is for storage, not configuration.

How to eliminate wrong answers

Option A is wrong because Secret is specifically designed for storing sensitive data (e.g., passwords, tokens, SSH keys) and uses base64 encoding with optional encryption at rest, not for non-sensitive configuration. Option B is wrong because PersistentVolume is an abstraction for storage resources (e.g., NFS, iSCSI) that provides persistent storage volumes to Pods, not for storing configuration data as environment variables or files. Option D is wrong because Service is a networking abstraction that exposes a set of Pods as a network service (e.g., ClusterIP, NodePort), and it cannot store or provide configuration data to Pods.

Full explanation →
686
MCQmedium

A developer wants to view the logs of a specific container named 'sidecar' inside a pod named 'app-pod'. Which command should they use?

A.kubectl log app-pod --container sidecar
B.kubectl logs app-pod sidecar
C.kubectl logs -c sidecar app-pod
D.kubectl logs app-pod -c sidecar
AnswerD

Correct; this uses the proper syntax: kubectl logs <pod-name> -c <container-name>.

Why this answer

The -c flag specifies the container name. The correct command is 'kubectl logs app-pod -c sidecar'.

Full explanation →
687
MCQmedium

A pod is stuck in 'Pending' state. Which of the following is a likely cause?

A.The pod's command returned a non-zero exit code
B.The container image is invalid
C.Insufficient CPU or memory resources on any available node
D.The pod's liveness probe failed
AnswerC

If no node can satisfy the pod's resource requests, the scheduler leaves it Pending.

Why this answer

A pod remains in 'Pending' state when the scheduler cannot find a suitable node to run it. The most common reason is insufficient CPU or memory resources on any available node, as the scheduler checks resource requests against node allocatable resources before binding the pod. If no node meets the pod's resource requirements, the pod stays pending until resources become available.

Exam trap

The KCNA exam often tests the distinction between pod scheduling failures (Pending) and runtime failures (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly associate image or command issues with the Pending state instead of recognizing that Pending is exclusively a scheduling-phase problem.

How to eliminate wrong answers

Option A is wrong because a non-zero exit code from the pod's command causes the container to crash and restart, resulting in a 'CrashLoopBackOff' or 'Error' state, not 'Pending'. Option B is wrong because an invalid container image (e.g., wrong tag or registry) leads to an 'ImagePullBackOff' or 'ErrImagePull' state, as the kubelet fails to pull the image, but the pod is first scheduled to a node before image pull occurs. Option D is wrong because a failed liveness probe causes the kubelet to restart the container, resulting in a 'CrashLoopBackOff' or 'Running' state with restarts, not 'Pending'; liveness probes only affect running containers.

Full explanation →
688
MCQmedium

A Deployment named 'web-app' is configured with replicas: 3. You update the container image. Which Kubernetes object directly manages the pods during the rolling update?

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

Deployment manages ReplicaSets, which in turn manage pods.

Why this answer

When a Deployment is updated (e.g., container image change), it creates a new ReplicaSet to manage the new pods and scales down the old ReplicaSet. The ReplicaSet is the Kubernetes object that directly owns and manages the pods during the rolling update, ensuring the desired number of replicas are running at each step.

Exam trap

The trap here is that candidates often think the Deployment directly manages pods, but Kubernetes uses ReplicaSets as the intermediary to handle pod scaling and updates, making ReplicaSet the correct answer.

How to eliminate wrong answers

Option A is wrong because a StatefulSet is used for stateful applications requiring stable network identities and persistent storage, not for stateless rolling updates managed by a Deployment. Option B is wrong because a DaemonSet ensures a pod runs on every node, and it does not participate in rolling updates triggered by a Deployment. Option C is wrong because a Job is designed for batch processing tasks that run to completion, not for managing long-running pods during a rolling update.

Full explanation →
689
MCQeasy

Which kubectl command is used to see the logs of a container in a pod?

A.kubectl attach <pod-name>
B.kubectl logs <pod-name>
C.kubectl exec <pod-name> -- cat /var/log/app.log
D.kubectl describe pod <pod-name>
AnswerB

Correct command.

Why this answer

`kubectl logs <pod-name>` is the dedicated command to retrieve and display the logs from the default container in a specified pod. This command directly accesses the container's stdout and stderr streams, which are captured by the container runtime (e.g., containerd or CRI-O) and stored by the kubelet, making it the standard and simplest way to view application logs.

Exam trap

The trap here is that candidates may confuse `kubectl logs` with `kubectl exec` for log retrieval, mistakenly thinking that accessing a log file inside the container is the standard approach, when Kubernetes expects logs to be captured from stdout/stderr and accessed via `kubectl logs`.

How to eliminate wrong answers

Option A is wrong because `kubectl attach` attaches to a running container's stdin/stdout/stderr streams, allowing interactive input, but it does not retrieve historical logs; it shows live output and requires the container to be running. Option C is wrong because while `kubectl exec` can run a command inside a container (like `cat /var/log/app.log`), this assumes the application writes logs to a file rather than stdout/stderr, which violates the Kubernetes logging best practice of using stdout/stderr for log aggregation; it also requires the file to exist and be accessible. Option D is wrong because `kubectl describe pod` provides detailed metadata and status information about the pod (e.g., events, conditions, container states), but it does not show container logs.

Full explanation →
690
MCQhard

A developer reports that a Pod cannot reach another Service in the same namespace via its DNS name. The Service name is 'api'. What is the correct DNS query for a Pod to resolve this Service?

A.api.svc.cluster.local
B.api.namespace.svc.cluster.local
C.api
D.api.default.svc.cluster.local
AnswerC

Within the same namespace, the short name works.

Why this answer

When a Pod and a Service are in the same namespace, Kubernetes DNS resolves the Service using just the Service name (e.g., 'api'). The DNS search domain configured in the Pod's resolv.conf (e.g., <namespace>.svc.cluster.local) appends the namespace and cluster suffix automatically, so a short query like 'api' resolves correctly without needing the full FQDN.

Exam trap

The trap here is that candidates often assume the full FQDN (e.g., 'api.svc.cluster.local') is always required, forgetting that DNS search domains in the Pod's resolv.conf enable short-name resolution within the same namespace.

How to eliminate wrong answers

Option A is wrong because 'api.svc.cluster.local' omits the namespace, which is required in the full DNS name; the correct FQDN for a cross-namespace query would be 'api.<namespace>.svc.cluster.local'. Option B is wrong because it includes 'namespace' as a literal string instead of the actual namespace name (e.g., 'default'), making it invalid unless the namespace is literally named 'namespace'. Option D is wrong because it assumes the namespace is 'default', which is not guaranteed; the Pod and Service could be in any namespace, and the short name 'api' works only within the same namespace.

Full explanation →
691
MCQhard

A platform team is designing a monitoring strategy for a multi-tenant Kubernetes cluster. Each tenant runs workloads in separate namespaces. The team needs to ensure tenant isolation while providing aggregated cluster-wide dashboards. Which approach best meets these requirements?

A.Deploy a single Prometheus instance with namespace labels on all metrics
B.Use a global Prometheus with recording rules to aggregate per-namespace metrics
C.Have each tenant deploy their own monitoring stack and view separately
D.Deploy a Prometheus instance per tenant and use Thanos to aggregate metrics globally
AnswerD

Per-tenant Prometheus ensures isolation, and Thanos sidecar allows secure global aggregation with proper RBAC.

Why this answer

Deploying a Prometheus instance per tenant enforces strong tenant isolation by preventing cross-tenant metric access or resource contention, while Thanos provides a global view by aggregating metrics from all tenants via sidecar-based or query-frontend federation. This approach satisfies both isolation and aggregated dashboards without compromising security or scalability.

Exam trap

CNCF often tests the misconception that namespace labels alone provide sufficient isolation, but in practice, labels do not enforce access control or resource boundaries, making a single Prometheus instance a security and reliability risk in multi-tenant clusters.

How to eliminate wrong answers

Option A is wrong because a single Prometheus instance with namespace labels does not enforce tenant isolation; any user with access to Prometheus can query all namespaces, and a misconfigured or malicious tenant could overload the instance, affecting others. Option B is wrong because a global Prometheus with recording rules still runs a single instance, failing to isolate tenant workloads and creating a single point of failure and performance bottleneck. Option C is wrong because having each tenant deploy their own monitoring stack and view separately prevents the team from creating aggregated cluster-wide dashboards, as there is no unified query layer to combine metrics across tenants.

Full explanation →
692
MCQmedium

Which of the following is true about Kubernetes Namespaces?

A.Namespaces can be nested
B.Namespaces are required for all resources
C.Namespaces provide network isolation by default
D.Namespaces are used to logically isolate resources like pods and services
AnswerD

Namespaces provide a scope for names and can be used for resource quotas.

Why this answer

Kubernetes Namespaces provide a mechanism to logically isolate resources such as Pods, Services, and Deployments within a single cluster. They enable multi-tenancy by partitioning cluster resources among multiple users or teams, each operating within their own virtual cluster. This logical isolation does not include network segmentation by default, but it allows for resource quota enforcement and access control via RBAC.

Exam trap

The trap here is that candidates often confuse logical isolation with network isolation, assuming Namespaces automatically restrict traffic between them, when in fact they only provide a scope for naming and resource management without any built-in network segmentation.

How to eliminate wrong answers

Option A is wrong because Kubernetes Namespaces cannot be nested; they are flat organizational units within a cluster, and resources belong to exactly one namespace. Option B is wrong because not all Kubernetes resources are namespaced; cluster-scoped resources like Nodes, PersistentVolumes, and ClusterRoles exist outside any namespace. Option C is wrong because Namespaces do not provide network isolation by default; network policies are required to enforce traffic rules between pods in different namespaces, and without them, pods in different namespaces can communicate freely.

Full explanation →
693
MCQhard

Refer to the exhibit. The nginx Pod is created, but the Pod never becomes Ready. The container starts and runs. What is the most likely reason?

A.The nginx:latest image does not exist.
B.The containerPort is not matching the actual port nginx listens on.
C.The liveness probe is failing because /healthz endpoint does not exist, causing the container to restart.
D.The readiness probe is failing because the root path is not returning 200.
AnswerC

The liveness probe expects /healthz to return 200, but nginx does not serve that path by default, so the probe fails and the container is restarted. This prevents the readiness probe from ever succeeding.

Why this answer

The liveness probe is configured to check the /healthz endpoint, but the default nginx container does not serve a /healthz endpoint. This causes the liveness probe to fail, and Kubernetes restarts the container according to the probe's failure threshold. Since the container keeps restarting, it never reaches the Ready state, even though the container starts and runs initially.

Exam trap

The KCNA exam often tests the distinction between liveness and readiness probes, and the trap here is that candidates assume a failing liveness probe only affects health checks, not the Pod's Ready status, when in fact repeated restarts prevent the Pod from ever becoming Ready.

How to eliminate wrong answers

Option A is wrong because if the nginx:latest image did not exist, the Pod would fail to pull the image and remain in ImagePullBackOff or ErrImagePull state, not start and run. Option B is wrong because the containerPort is a declaration for documentation and network policy; nginx listens on port 80 by default, and even if the port mismatched, the container would still start and become Ready as long as the probes pass. Option D is wrong because the readiness probe is checking the root path (/) which nginx serves by default with a 200 status, so it would pass; the issue is the liveness probe hitting a non-existent /healthz endpoint.

Full explanation →
694
MCQmedium

A development team wants to deploy a serverless function that scales to zero when not in use. Which CNCF project or platform is BEST suited for this requirement?

A.Kubeless
B.AWS Lambda
C.Knative
D.OpenFaaS
AnswerC

Knative is a Kubernetes-based platform for building, deploying, and managing serverless workloads that can scale to zero, and it is a CNCF project.

Why this answer

Knative is a Kubernetes-based platform to build, deploy, and manage serverless workloads that can scale to zero. AWS Lambda is a proprietary offering, not CNCF. OpenFaaS and Kubeless are also serverless frameworks but Knative is the most prominent CNCF serverless project.

Full explanation →
695
Multi-Selecteasy

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

Select 2 answers
A.Terraform
B.kubectl
C.Pulumi
D.Helm
E.Docker Compose
AnswersA, C

Why this answer

Terraform and Pulumi are popular IaC tools that allow infrastructure provisioning via code.

Full explanation →
696
MCQeasy

Which of the following is used to logically isolate resources within a Kubernetes cluster?

A.Annotations
B.Selectors
C.Namespaces
D.Labels
AnswerC

Namespaces partition resources within a cluster.

Why this answer

Namespaces provide logical isolation for resources. Option C is correct.

Full explanation →
697
MCQmedium

A team wants to deploy a serverless function using Knative. Which core primitive does Knative rely on to run serverless workloads on Kubernetes?

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

Knative Service is the top-level resource.

Why this answer

Knative Serving uses the 'Service' resource to manage serverless workloads. 'Deployment' is a lower-level resource, 'Function' is not a Kubernetes resource, and 'Pod' is too granular.

Full explanation →
698
MCQmedium

You want to deploy a stateless web application that should maintain 5 running instances at all times. You need to support rolling updates and rollbacks. Which Kubernetes resource is most appropriate?

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

Deployments manage ReplicaSets and provide rolling updates, rollbacks, and declarative updates for stateless applications.

Why this answer

A Deployment is the correct choice because it is designed to manage stateless applications with a desired replica count (5 instances), supports rolling updates to update pods gradually without downtime, and enables rollbacks to a previous revision if an update fails. Deployments internally create ReplicaSets to manage pod scaling and versioning, making them ideal for stateless workloads requiring high availability and update flexibility.

Exam trap

The trap here is that candidates often pick ReplicaSet because it maintains replica counts, but they overlook that Deployments are the required resource for rolling updates and rollbacks, as ReplicaSets alone do not provide these higher-level lifecycle management features.

How to eliminate wrong answers

Option A (DaemonSet) is wrong because DaemonSets ensure one pod runs on each node, not a fixed number of replicas across the cluster, and they do not support rolling updates or rollbacks in the same controlled manner as Deployments. Option C (ReplicaSet) is wrong because while it can maintain a desired replica count, it lacks built-in support for rolling updates and rollbacks; Deployments are the higher-level abstraction that manages ReplicaSets for these features. Option D (StatefulSet) is wrong because StatefulSets are designed for stateful applications requiring stable network identities and persistent storage, not for stateless web apps, and they have different update strategies that are not as straightforward for simple rolling updates.

Full explanation →
699
Multi-Selecthard

Which TWO statements about Namespaces are correct?

Select 2 answers
A.Resource names must be unique within a namespace
B.Namespaces provide network isolation by default
C.All Kubernetes resources are namespaced
D.Namespaces provide a way to divide cluster resources between multiple users
E.You can delete a namespace without affecting the resources inside it
AnswersA, D

Uniqueness is enforced within a namespace.

Why this answer

Kubernetes enforces that resource names must be unique within a namespace. This is a fundamental constraint: within a given namespace, you cannot have two resources of the same type (e.g., two Pods) with the same name. This uniqueness allows the API server to resolve resource references unambiguously when using namespaced resources.

Exam trap

The KCNA exam often tests the misconception that namespaces provide automatic network isolation, when in fact they only provide logical grouping and resource quota boundaries, not network segmentation.

Full explanation →
700
Multi-Selecthard

Which TWO of the following statements about Kubernetes Deployments are correct? (Select 2)

Select 2 answers
A.Deployments support rolling updates and rollbacks
B.Deployments ensure that a copy of a Pod runs on each node in the cluster
C.Deployments are used for batch processing jobs that run to completion
D.Deployments manage the lifecycle of ReplicaSets
E.Deployments provide stable network identities for Pods
AnswersA, D

Deployments provide a declarative update strategy that supports rolling updates and rollbacks.

Why this answer

A is correct because Deployments provide a declarative update mechanism that supports rolling updates, where Pods are gradually replaced with new ones, and rollbacks, which revert the Deployment to a previous revision. This is achieved through the Deployment controller managing ReplicaSets, allowing seamless transitions between versions without downtime.

Exam trap

The CNCF exam often tests the distinction between Deployments and other controllers like DaemonSets, StatefulSets, and Jobs, so the trap here is confusing the purpose of Deployments (stateless, scalable apps) with controllers that handle per-node scheduling, stateful identities, or batch workloads.

Full explanation →
701
Multi-Selectmedium

Which TWO are valid reasons to use a Namespace in Kubernetes?

Select 2 answers
A.To enforce network policies that restrict traffic between Pods in different Namespaces.
B.To reduce the number of API calls to the control plane.
C.To isolate resources and prevent naming collisions between different teams.
D.To improve application performance by reducing latency.
E.To store environment variables for containers.
AnswersA, C

NetworkPolicies can be scoped to Namespaces to control traffic flow.

Why this answer

Kubernetes NetworkPolicies are namespace-scoped resources that can restrict ingress and egress traffic between Pods in different Namespaces. By default, all Pods can communicate across Namespaces, but applying a NetworkPolicy with a podSelector and namespaceSelector allows you to enforce isolation. Option C is correct because Namespaces provide a logical boundary for resource names, preventing naming collisions when multiple teams or projects deploy objects with the same name within the same cluster.

Exam trap

CNCF often tests the misconception that Namespaces provide performance benefits or reduce API load, when in reality they are purely a logical isolation and naming boundary with no direct impact on network speed or control plane traffic.

Full explanation →
702
MCQmedium

Which command correctly creates a Deployment named 'web-app' with the image 'nginx:1.21' and 3 replicas?

A.kubectl apply deployment web-app --image=nginx:1.21 --replicas=3
B.kubectl run web-app --image=nginx:1.21 --replicas=3
C.kubectl create deployment web-app --image=nginx:1.21 --replicas=3
D.kubectl create deployement web-app --image=nginx:1.21 --replicas=3
AnswerC

This is the correct syntax to create a Deployment with the given name, image, and replica count.

Why this answer

`kubectl create deployment` is the imperative command specifically designed to create a Deployment resource in Kubernetes. The `--image` flag specifies the container image, and `--replicas=3` sets the desired number of pod replicas, which matches the requirement exactly.

Exam trap

CNCF often tests the distinction between `kubectl run` (which creates a Pod, not a Deployment) and `kubectl create deployment` (which creates a Deployment with replica management), leading candidates to mistakenly choose `kubectl run` when replicas are required.

How to eliminate wrong answers

Option A is wrong because `kubectl apply` requires a manifest file or stdin input; it does not accept `--image` or `--replicas` flags directly, and the syntax `apply deployment` is invalid. Option B is wrong because `kubectl run` creates a Pod (or a Deployment only in older versions with certain flags), but it does not support the `--replicas` flag; it is used for ad-hoc pods, not multi-replica Deployments. Option D is wrong because `deployement` is a misspelling of `deployment`, which causes a command syntax error; Kubernetes CLI commands are case-sensitive and must match the exact resource name.

Full explanation →
703
MCQmedium

A team wants to deploy a serverless function that scales to zero when not in use. Which CNCF project is specifically designed for this purpose?

A.Helm
B.Prometheus
C.Envoy
D.Knative
AnswerD

Knative provides serverless containers with scale-to-zero.

Why this answer

Knative is the correct answer because it is a CNCF project built on Kubernetes that provides a serverless platform specifically designed to scale workloads to zero when not in use. It achieves this through its Serving component, which automatically scales pods down to zero replicas based on traffic, and scales up from zero on the first request, enabling true serverless behavior.

Exam trap

CNCF often tests the distinction between infrastructure tools (Helm, Prometheus, Envoy) and serverless platforms (Knative), trapping candidates who confuse package management, monitoring, or proxy functions with serverless scaling capabilities.

How to eliminate wrong answers

Option A is wrong because Helm is a package manager for Kubernetes that deploys applications using charts, but it does not provide any serverless scaling or scale-to-zero functionality. Option B is wrong because Prometheus is a monitoring and alerting toolkit that collects metrics, not a serverless platform; it cannot scale functions to zero. Option C is wrong because Envoy is a high-performance sidecar proxy used for service mesh communication (e.g., in Istio), not a serverless framework for scaling functions to zero.

Full explanation →
704
Multi-Selectmedium

A DevOps team uses Helm to manage Kubernetes applications. They want to ensure that sensitive data (e.g., database passwords) is not stored in plaintext in the Helm chart or in the cluster's ConfigMaps/Secrets. Which TWO practices should they adopt? (Choose two.)

Select 2 answers
A.Use an external secrets operator (e.g., AWS Secrets Manager, HashiCorp Vault) to inject secrets at runtime
B.Store secrets in a separate Git repository with restricted access
C.Use a tool like sealed-secrets to encrypt the secrets before committing them to the chart
D.Store secrets as Kubernetes Secrets and reference them in the chart values
E.Use Helm's built-in encryption for values files
AnswersA, C

External secrets operators fetch secrets from external stores and create Kubernetes Secrets without exposing them in the chart.

Why this answer

Using an external secrets operator (e.g., AWS Secrets Manager, HashiCorp Vault) allows secrets to be injected directly into Pods at runtime without ever storing them in the Helm chart or as Kubernetes Secrets in plaintext. This approach leverages the Kubernetes CSI (Container Storage Interface) or a sidecar pattern to mount secrets from an external store, ensuring sensitive data never resides in the cluster's etcd or version control.

Exam trap

CNCF often tests the misconception that base64 encoding in Kubernetes Secrets is equivalent to encryption, leading candidates to incorrectly select Option D as secure, when in fact base64 is merely an encoding and provides no confidentiality.

Full explanation →
705
MCQeasy

Which of the following describes the Open Container Initiative (OCI) image specification?

A.A standard for container images and runtimes
B.A specification for container orchestration
C.A specification for container storage
D.A specification for container networking
AnswerA

OCI defines both image spec and runtime spec.

Why this answer

The Open Container Initiative (OCI) image specification defines a standard format for container images, ensuring that any OCI-compliant image can be run by any OCI-compliant runtime (e.g., runc, crun). This specification covers the image manifest, filesystem layers, and configuration, enabling interoperability across different container platforms like Docker, Podman, and containerd. Option A is correct because the OCI specifically standardizes both the image format and the runtime behavior, not higher-level orchestration or infrastructure concerns.

Exam trap

CNCF often tests the distinction between OCI (image/runtime) and CNI/CSI (networking/storage), so the trap here is that candidates confuse the OCI specification with other container ecosystem standards like CNI or CSI due to similar acronyms and overlapping container contexts.

How to eliminate wrong answers

Option B is wrong because container orchestration is the domain of tools like Kubernetes, Docker Swarm, and Nomad, which manage scheduling, scaling, and service discovery—not the OCI image specification. Option C is wrong because container storage is addressed by separate standards like the Container Storage Interface (CSI), which defines how storage systems are exposed to containerized workloads, not by the OCI image spec. Option D is wrong because container networking is governed by the Container Network Interface (CNI), which specifies how network plugins configure network interfaces for containers, whereas the OCI image spec focuses solely on image and runtime standards.

Full explanation →
706
MCQhard

A pod named 'db' in the 'default' namespace cannot connect to another pod named 'cache' in the 'prod' namespace via DNS. The service 'cache-svc' exists in the 'prod' namespace. What DNS name should the 'db' pod use to reach the 'cache-svc' service?

A.cache-svc.default
B.cache-svc.prod
C.cache-svc.prod.svc.cluster.local
D.cache-svc.default.svc.cluster.local
AnswerC

The correct DNS format for a service in another namespace is <svc>.<ns>.svc.cluster.local.

Why this answer

Kubernetes DNS resolves services across namespaces using the format <service>.<namespace>.svc.cluster.local. Since the 'cache-svc' service is in the 'prod' namespace, the 'db' pod in the 'default' namespace must use 'cache-svc.prod.svc.cluster.local' to reach it. The default cluster domain is 'cluster.local', and the 'svc' subdomain is part of the standard DNS schema for services.

Exam trap

CNCF often tests the misconception that the namespace alone (e.g., 'cache-svc.prod') is sufficient for cross-namespace DNS resolution, but the full 'svc.cluster.local' suffix is mandatory for the cluster DNS to resolve the service correctly.

How to eliminate wrong answers

Option A is wrong because 'cache-svc.default' implies the service is in the 'default' namespace, but the service is actually in 'prod', and it omits the required 'svc.cluster.local' suffix. Option B is wrong because 'cache-svc.prod' is incomplete—it lacks the 'svc.cluster.local' suffix, so it would not be resolved by the cluster DNS server (CoreDNS/kube-dns). Option D is wrong because it places the service in the 'default' namespace (using 'default' instead of 'prod'), which does not match the actual namespace of the service.

Full explanation →
707
MCQmedium

You need to create a ConfigMap from a file named 'app.properties'. Which kubectl command should you use?

A.kubectl create configmap my-config --from-literal=app.properties
B.kubectl create configmap my-config --file=app.properties
C.kubectl create configmap my-config --from-env-file=app.properties
D.kubectl create configmap my-config --from-file=app.properties
AnswerD

This creates a ConfigMap with the file contents.

Why this answer

`kubectl create configmap` with the `--from-file` flag creates a ConfigMap from a file, using the filename as the key and its content as the value. This is the standard way to import a properties file into a ConfigMap in Kubernetes.

Exam trap

The most common mistake is confusing --from-file with --from-env-file. --from-file creates a ConfigMap entry with the filename as the key and file content as value. --from-env-file parses the file line by line as key=value pairs.

How to eliminate wrong answers

Option A is wrong because `--from-literal` expects a key=value pair directly in the command, not a filename; it would treat 'app.properties' as a literal string key with no value. Option B is wrong because `--file` is not a valid flag for `kubectl create configmap`; the correct flag is `--from-file`. Option C is wrong because `--from-env-file` imports a file line-by-line as environment variables, but it expects each line to be in KEY=VALUE format and does not preserve the filename as a key; it is used for importing environment files, not for creating a ConfigMap with the file content as a single key-value pair.

Full explanation →
708
Multi-Selectmedium

Which TWO of the following are principles of the 12-factor app? (Choose two.)

Select 2 answers
A.Monolithic deployment
B.Stateful sessions
C.Config
D.Disposability
E.Manual provisioning
AnswersC, D

Config is a 12-factor principle.

Why this answer

Config is a core principle of the 12-factor app methodology, which mandates strict separation of configuration from code. Configuration (such as database URLs, credentials, or hostnames) must be stored in environment variables, not hardcoded in the application source. This allows the same codebase to be deployed across different environments (development, staging, production) without modification, adhering to the principle of config-driven behavior.

Exam trap

CNCF often tests the 12-factor app principles by pairing a correct principle like 'Config' with a plausible-sounding but incorrect option like 'Stateful sessions', exploiting the common misconception that statefulness is acceptable in cloud-native apps when in fact it must be externalized.

Full explanation →
709
MCQeasy

What is the primary purpose of Kubernetes?

A.To orchestrate containers across a cluster of machines
B.To provide a graphical user interface for managing containers
C.To replace Docker as a container runtime
D.To provide a virtual machine management platform
AnswerA

Kubernetes automates container deployment, scaling, and operations.

Why this answer

Kubernetes is a container orchestration platform designed to automate the deployment, scaling, and management of containerized applications across a cluster of machines. Its primary purpose is to abstract the underlying infrastructure and provide declarative management of container workloads, ensuring desired state convergence through controllers like the ReplicaSet and Deployment.

Exam trap

A common misconception is that Kubernetes is a container runtime or a GUI tool, but its primary purpose is container orchestration across a cluster of machines.

How to eliminate wrong answers

Option B is wrong because Kubernetes does not provide a graphical user interface as its primary purpose; while dashboards like the Kubernetes Dashboard exist, they are optional add-ons, not the core function. Option C is wrong because Kubernetes is not a container runtime replacement; it uses container runtimes like containerd or CRI-O via the Container Runtime Interface (CRI) and does not replace Docker or any specific runtime. Option D is wrong because Kubernetes manages containers, not virtual machines; although it can run on VMs, it does not provide a VM management platform like VMware vSphere or OpenStack.

Full explanation →
710
MCQhard

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

A.It stores events and enables asynchronous communication between producers and consumers
B.It executes business logic in response to events
C.It provides a user interface to view events
D.It converts events into HTTP requests
AnswerA

The broker persists events and routes them to interested consumers.

Why this answer

An event broker acts as a central intermediary that receives events from producers, stores them durably (often in a log or queue), and delivers them to consumers asynchronously. This decouples producers and consumers, allowing them to operate independently without blocking or direct knowledge of each other. Technologies like Apache Kafka, RabbitMQ, or AWS Kinesis exemplify this role by persisting events and enabling replay, fan-out, and load-leveling.

Exam trap

CNCF often tests the distinction between the broker's role (storage and routing) and the consumer's role (processing logic), so candidates mistakenly pick B when they conflate event handling with event brokering.

How to eliminate wrong answers

Option B is wrong because executing business logic in response to events is the role of an event consumer or a serverless function (e.g., AWS Lambda), not the broker itself — the broker only routes and stores events. Option C is wrong because providing a user interface to view events is a monitoring or management tool (e.g., Kafka UI or Confluent Control Center), not a core function of the event broker. Option D is wrong because converting events into HTTP requests is a protocol translation task typically performed by an adapter or gateway (e.g., Kafka REST Proxy), not the event broker's native role — brokers use their own protocols (e.g., Kafka protocol, AMQP) for communication.

Full explanation →
711
MCQhard

An administrator notices that a pod in a Deployment is stuck in CrashLoopBackOff. The pod logs show 'Error: failed to start container: exec: "app": executable file not found in $PATH'. What is the most likely cause?

A.The image registry credentials are missing
B.The liveness probe is misconfigured and killing the container
C.The container is running as a non-root user without proper permissions
D.The container image does not contain the binary specified in the pod's command field
AnswerD

The exec error shows the binary is missing, likely due to a typo or wrong image.

Why this answer

The error 'exec: "app": executable file not found in $PATH' indicates that the container image does not contain the binary or script specified in the pod's command field (e.g., `command: ["app"]`). This typically happens when the image is built without the expected executable, the command path is incorrect, or the image tag points to a different version. The container fails to start because the runtime cannot locate the entrypoint.

Exam trap

CNCF often tests the distinction between image pull errors (ImagePullBackOff) and container execution errors (CrashLoopBackOff), so candidates may confuse missing credentials with a missing executable in the image.

How to eliminate wrong answers

Option A is wrong because missing registry credentials would cause an ImagePullBackOff, not a CrashLoopBackOff with an exec error in logs. Option B is wrong because a misconfigured liveness probe would cause the container to be restarted after it starts, but the exec error occurs before the container can run, so the probe never executes. Option C is wrong because running as a non-root user without permissions would produce a 'permission denied' error, not an 'executable file not found' error.

Full explanation →
712
Multi-Selectmedium

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

Select 2 answers
A.Serving the Kubernetes API
B.Implementing network rules for Services
C.Scheduling pods to nodes
D.Running the node controller to monitor node health
E.Managing ReplicaSets to ensure the desired number of pods are running
AnswersD, E

The node controller periodically checks node status and responds to node failures.

Why this answer

The kube-controller-manager is a core control plane component that runs controller processes, including the node controller, which monitors node health by checking the NodeStatus and NodeLease objects. If a node becomes unreachable (e.g., the node controller fails to receive a heartbeat within the --node-monitor-grace-period, default 40 seconds), it marks the node as Unhealthy and eventually taints it to trigger pod eviction. This makes option D correct because the node controller is a built-in controller within the kube-controller-manager.

Exam trap

CNCF often tests the distinction between control plane components by listing overlapping responsibilities, so the trap here is confusing the kube-controller-manager's role in managing controllers (like the node controller and ReplicaSet controller) with the kube-scheduler's scheduling function or kube-proxy's network rule implementation.

Full explanation →
713
Multi-Selectmedium

Which TWO of the following are benefits of using a service mesh? (Choose two.)

Select 2 answers
A.Improved observability of service-to-service communication
B.Direct management of virtual machines
C.Automated container image building
D.Replacing the need for a container runtime
E.Traffic management capabilities such as canary deployments
AnswersA, E

Service mesh captures metrics, traces, and logs for inter-service traffic.

Why this answer

Service mesh provides improved observability and enables traffic management features like canary deployments.

Full explanation →
714
MCQmedium

An organization wants to manage infrastructure using code to ensure consistent and repeatable deployments across multiple cloud providers. Which tool is MOST suitable for this multi-cloud Infrastructure as Code approach?

A.Terraform
B.Kuberntes manifests
C.AWS CloudFormation
D.Azure Resource Manager Templates
AnswerA

Terraform supports many providers including AWS, Azure, GCP, and others.

Why this answer

Terraform is a cloud-agnostic IaC tool that supports multiple providers, enabling consistent management across clouds.

Full explanation →
715
Multi-Selecthard

A user reports that a web application is not accessible via its Service. The Service is of type ClusterIP. Which TWO steps should be taken to troubleshoot?

Select 2 answers
A.Verify that the kube-proxy is running on the node
B.Check that the container runtime is working
C.Check the kube-apiserver status
D.Check if the Service has any endpoints using 'kubectl get endpoints'
E.Restart all nodes in the cluster
AnswersA, D

kube-proxy is responsible for implementing the Service abstraction via iptables or IPVS.

Why this answer

Kube-proxy is the component responsible for implementing the ClusterIP Service abstraction by managing iptables or IPVS rules on each node. If kube-proxy is not running, traffic destined for the Service's ClusterIP will not be forwarded to the backend pods, making the Service unreachable from within the cluster.

Exam trap

The trap here is that candidates often assume a Service is always reachable if the pods are running, forgetting that kube-proxy must be healthy and that the Service must have endpoints for traffic to be forwarded.

Full explanation →
716
MCQmedium

You have a Namespace 'team-a' and you want to see all Pods in that namespace, including those that are not ready. Which command should you use?

A.kubectl get pods -n team-a
B.kubectl get pods -n team-a -l app=myapp
C.kubectl get pods --namespace=team-a --field-selector=status.phase!=Running
D.kubectl get pods --all-namespaces
AnswerA

This command lists all pods in the specified namespace.

Why this answer

`kubectl get pods -n team-a` retrieves all Pods in the specified namespace, regardless of their readiness or status. By default, `kubectl get pods` shows all Pods, including those that are not ready, and the `-n` flag targets the namespace. No additional filters are needed to include non-ready Pods.

Exam trap

A common misconception is that `kubectl get pods` only shows ready Pods, or that you need a special flag to see non-ready Pods, when in fact the default output includes all Pods regardless of readiness.

How to eliminate wrong answers

Option B is wrong because the `-l app=myapp` label selector filters Pods to only those with the label `app=myapp`, which may exclude Pods that are not ready if they lack that label, and it does not show all Pods in the namespace. Option C is wrong because `--field-selector=status.phase!=Running` explicitly excludes Pods in the Running phase, so it would only show Pods that are not ready (e.g., Pending, Succeeded, Failed), not all Pods including those that are ready. Option D is wrong because `--all-namespaces` shows Pods across all namespaces, not just the `team-a` namespace, and it does not filter by readiness.

Full explanation →
717
MCQmedium

A team deploys a microservice that requires sticky sessions. The service runs on Kubernetes with multiple replicas. Which Kubernetes resource should be used to ensure requests from a client are consistently routed to the same pod?

A.Headless Service
B.Service with sessionAffinity: ClientIP
C.Ingress with default settings
D.Deployment with hostNetwork: true
AnswerB

This configuration ensures requests from the same client IP go to the same pod.

Why this answer

Setting `sessionAffinity: ClientIP` on a Kubernetes Service ensures that all requests from the same client IP are routed to the same Pod. This is the standard Kubernetes mechanism for implementing sticky sessions without requiring changes to the application or ingress layer.

Exam trap

CNCF often tests the misconception that Ingress or Headless Services can handle session affinity by default, but only a Service with `sessionAffinity: ClientIP` provides this at the Kubernetes networking layer without additional configuration.

How to eliminate wrong answers

Option A is wrong because a Headless Service does not provide load balancing or session affinity; it returns the IPs of all Pods directly, requiring the client to handle routing. Option C is wrong because an Ingress with default settings does not maintain session affinity; it typically passes traffic to a Service without any stickiness, and Ingress controllers like NGINX require additional annotations (e.g., `nginx.ingress.kubernetes.io/affinity`) to enable sticky sessions. Option D is wrong because `hostNetwork: true` binds the Pod directly to the node's network stack, bypassing Kubernetes service networking entirely, and does not provide any session affinity mechanism.

Full explanation →
718
MCQhard

You create a Deployment with replicas: 3. You then scale the Deployment to 5 replicas. What is the order of operations that the Deployment controller follows?

A.It creates a new ReplicaSet with 5 replicas and deletes the old one
B.It directly creates 2 new pods without using a ReplicaSet
C.It updates the existing ReplicaSet's replica count to 5, and the ReplicaSet creates the new pods
D.It creates 2 new pods immediately without modifying the existing ReplicaSet
AnswerC

The Deployment controller updates the ReplicaSet's .spec.replicas, and the ReplicaSet controller creates the pods.

Why this answer

When you scale a Deployment, the Deployment controller updates the replica count on the existing ReplicaSet that matches the pod template. The ReplicaSet controller then observes the desired count and creates the additional pods to reach the new target. This ensures that the Deployment's rollout history and rollback capabilities remain intact.

Exam trap

The trap here is that candidates often confuse scaling with a rolling update, assuming a new ReplicaSet is created, when in fact scaling only modifies the existing ReplicaSet's replica count without changing the pod template.

How to eliminate wrong answers

Option A is wrong because the Deployment does not create a new ReplicaSet when scaling; it reuses the existing one, and deleting the old ReplicaSet would lose the rollout history. Option B is wrong because the Deployment controller never creates pods directly; it always delegates pod creation to a ReplicaSet to maintain declarative state and ownership. Option D is wrong because the Deployment controller modifies the ReplicaSet's replica count, and the ReplicaSet creates the pods; it does not create pods independently of the ReplicaSet.

Full explanation →
719
MCQeasy

Which Kubernetes control plane component acts as the entry point for all administrative tasks and provides the REST API?

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

The API server exposes the Kubernetes API and handles all administrative requests.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane, exposing the Kubernetes REST API. All administrative tasks, such as creating pods, scaling deployments, and querying cluster state, are performed by sending HTTP requests to this component. It validates and processes these requests before storing the resulting state in etcd.

Exam trap

CNCF often tests the misconception that etcd is the entry point because it stores cluster data, but the trap is that etcd is a backend datastore with no direct REST API for administrative tasks—the kube-apiserver is the sole gateway for all client interactions.

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 handling administrative API requests. Option B is wrong because etcd is a distributed key-value store used for cluster state persistence, not an API entry point; it is accessed internally by the API server. Option C is wrong because kube-controller-manager runs controller processes (e.g., ReplicaSet controller, Node controller) that watch the API server for desired state changes, but it does not serve as the REST API endpoint.

Full explanation →
720
MCQmedium

You need to provide configuration data as environment variables to a pod, but the data is not sensitive. Which object should you use?

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

ConfigMap is correct for non-sensitive configuration data.

Why this answer

A ConfigMap is the correct Kubernetes object for providing non-sensitive configuration data as environment variables to a pod. ConfigMaps are designed to decouple configuration artifacts from image content to keep containers portable, and they support injection via environment variables, command-line arguments, or volume mounts. Unlike Secrets, ConfigMaps store data in plaintext (base64-encoded only for transport) and are intended for data that does not require encryption at rest or in transit.

Exam trap

The trap here is that candidates often confuse ConfigMap with Secret, assuming that any data passed as environment variables must be sensitive, or they overlook that ServiceAccounts are for identity, not configuration data.

How to eliminate wrong answers

Option B (Secret) is wrong because Secrets are specifically designed for sensitive data such as passwords, tokens, or keys, and they support additional features like encryption at rest and integration with external key management systems; using a Secret for non-sensitive data is unnecessary and violates the principle of least privilege. Option C (ServiceAccount) is wrong because a ServiceAccount is an identity object used to control pod-level authentication and authorization to the Kubernetes API, not a mechanism for storing or injecting configuration data. Option D (PersistentVolume) is wrong because a PersistentVolume is a storage abstraction for persistent data that survives pod restarts, not a means to provide ephemeral configuration data as environment variables.

Full explanation →
721
MCQmedium

Which command creates a Deployment named 'nginx-deployment' from the image 'nginx:1.25' and exposes it on port 80?

A.kubectl create deployment nginx-deployment --image=nginx:1.25 --port=80
B.kubectl run nginx-deployment --image=nginx:1.25 --port=80
C.kubectl apply -f nginx-deployment.yaml
D.kubectl expose deployment nginx-deployment --type=ClusterIP
AnswerA

This creates a Deployment with the specified image and port exposure.

Why this answer

The `kubectl create deployment` command is the standard way to create a Deployment resource in Kubernetes. The `--image=nginx:1.25` flag specifies the container image, and the `--port=80` flag sets the container port in the pod template spec, which allows the Deployment to expose the container on port 80.

Exam trap

The trap here is that candidates confuse `kubectl run` with `kubectl create deployment`, as `kubectl run` can create a pod but not a Deployment in modern Kubernetes, and they may think the `--port` flag works with `kubectl run` when it does not.

How to eliminate wrong answers

Option B is wrong because `kubectl run` creates a Pod (or a Deployment only in older versions with specific flags), not a Deployment; it does not create a Deployment resource by default, and the `--port` flag is not a standard flag for `kubectl run` in current Kubernetes versions. Option C is wrong because `kubectl apply -f nginx-deployment.yaml` assumes a YAML manifest file already exists, but the question asks to create the Deployment from the image directly, not from a file. Option D is wrong because `kubectl expose deployment` creates a Service to expose an existing Deployment, but it does not create the Deployment itself; the Deployment must already exist.

Full explanation →
722
Multi-Selecthard

Which THREE statements about Kubernetes Services are correct?

Select 3 answers
A.A Service provides a stable IP address and DNS name for a set of Pods.
B.Services use label selectors to identify the target Pods.
C.A Service of type LoadBalancer can be used to expose an application externally.
D.A Service can only route traffic to Pods within the same namespace.
E.The default Service type is NodePort.
AnswersA, B, C

Services provide stable endpoints that decouple clients from individual Pod IPs.

Why this answer

A is correct because a Kubernetes Service provides a stable virtual IP address and a DNS name (via CoreDNS) that remains constant even as the underlying Pods are created, destroyed, or scaled. This decouples clients from the ephemeral nature of Pod IPs, ensuring reliable connectivity.

Exam trap

A common mistake is to assume that a Service can select Pods from any namespace, but in Kubernetes, a Service's label selector only matches Pods within the same namespace. Additionally, the default Service type is ClusterIP, not NodePort.

Full explanation →
723
MCQeasy

What is the purpose of a Service in Kubernetes?

A.To provide persistent storage volumes
B.To manage rolling updates of pods
C.To expose a set of pods as a network service with a stable endpoint
D.To store configuration data as key-value pairs
AnswerC

This is the primary purpose of a Service.

Why this answer

A Service in Kubernetes provides a stable network endpoint (IP address and DNS name) to access a set of Pods, which are ephemeral and can be created or destroyed dynamically. It decouples the client from the Pods' IPs by using label selectors to route traffic, enabling reliable communication within the cluster or externally. This is defined in the Kubernetes API as a Service resource, with types like ClusterIP, NodePort, and LoadBalancer.

Exam trap

The trap here is that candidates confuse the Service's role of exposing Pods with the Deployment's role of managing Pod lifecycles, leading them to pick Option B, but a Service does not handle updates or scaling—it only provides a stable network endpoint.

How to eliminate wrong answers

Option A is wrong because persistent storage volumes are provided by PersistentVolume (PV) and PersistentVolumeClaim (PVC) resources, not by a Service. Option B is wrong because managing rolling updates of Pods is the responsibility of a Deployment controller, which handles update strategies like RollingUpdate or Recreate. Option D is wrong because storing configuration data as key-value pairs is the role of ConfigMaps and Secrets, not a Service.

Full explanation →
724
MCQeasy

A development team is designing a new microservices application to run on a Kubernetes cluster. They want to ensure that each microservice can be developed, deployed, and scaled independently. Which cloud native architecture principle are they primarily applying?

A.Loose coupling
B.Immutable infrastructure
C.Statelessness
D.Service discovery
AnswerA

Loose coupling allows services to be developed, deployed, and scaled independently.

Why this answer

The principle of loose coupling ensures that each microservice can be developed, deployed, and scaled independently by minimizing dependencies between services. In Kubernetes, this is achieved through well-defined APIs and service boundaries, allowing teams to update or scale one service without affecting others. This directly supports the team's goal of independent lifecycle management for each microservice.

Exam trap

The trap here is that candidates often confuse 'statelessness' with 'loose coupling' because both enable scaling, but statelessness is about session data management, not the architectural independence of service development and deployment.

How to eliminate wrong answers

Option B (Immutable infrastructure) is wrong because it focuses on replacing rather than modifying infrastructure components, which supports consistency and reliability but does not directly address independent development and scaling of microservices. Option C (Statelessness) is wrong because it refers to services not storing session state locally, which aids scalability but is not the primary principle for independent development and deployment; stateful services can also be loosely coupled. Option D (Service discovery) is wrong because it is a mechanism for services to find each other dynamically, which enables loose coupling but is not the principle itself; it is an implementation detail that supports the broader goal of loose coupling.

Full explanation →
725
MCQmedium

You have a Kubernetes cluster with multiple nodes. You need to ensure that a pod runs on a node that has an SSD. How should you achieve this?

A.Manually edit kube-scheduler configuration
B.Use a DaemonSet to run the pod on all nodes
C.Use a nodeSelector with the label 'disktype: ssd'
D.Use a toleration for the node
AnswerC

nodeSelector is a simple field that matches node labels, making it the easiest way to schedule pods on nodes with SSDs.

Why this answer

NodeSelector is the simplest and most direct way to constrain a Pod to run only on nodes that have a specific label, such as 'disktype=ssd'. When you add a nodeSelector field to the Pod spec, the kube-scheduler filters nodes that do not have the matching label, ensuring the Pod lands on a node with an SSD.

Exam trap

The trap here is confusing tolerations (which allow scheduling onto tainted nodes) with node selection mechanisms like nodeSelector or nodeAffinity, leading candidates to pick D when they need a label-based constraint.

How to eliminate wrong answers

Option A is wrong because manually editing the kube-scheduler configuration is unnecessary and overly complex; node scheduling constraints are handled via Pod spec fields like nodeSelector, nodeAffinity, or taints/tolerations, not by modifying the scheduler itself. Option B is wrong because a DaemonSet runs a copy of the Pod on every node (or a subset defined by nodeSelector), but the question asks to ensure the Pod runs on a node with an SSD, not on all nodes. Option D is wrong because tolerations are used to allow Pods to schedule onto nodes with matching taints, not to select nodes based on labels like 'disktype=ssd'; tolerations alone do not guarantee placement on a specific node type.

Full explanation →
726
Matchingmedium

Match each Kubernetes resource to its primary purpose.

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

Concepts
Matches

Smallest deployable unit containing one or more containers

Stable network endpoint to access a set of Pods

Stores non-sensitive configuration data as key-value pairs

Cluster-wide storage resource provisioned by an administrator

Manages external access to services, typically HTTP

Why these pairings

Pods are the smallest deployable units; Services provide stable networking to Pods; Deployments manage Pod lifecycle. Common confusions involve swapping Pod with Service, Service with ConfigMap, and Deployment with storage resources.

Full explanation →
727
Multi-Selecthard

Which THREE are key characteristics of event-driven architecture? (Choose three.)

Select 3 answers
A.Event processing can trigger multiple downstream actions
B.Requires a central database for state
C.Synchronous communication between components
D.Components communicate by emitting and reacting to events
E.Loose coupling between event producers and consumers
AnswersA, D, E

Events can fan out to multiple consumers.

Why this answer

Event-driven architecture is based on producing, detecting, and reacting to events, with loose coupling between components and asynchronous communication.

Full explanation →
728
MCQhard

A team wants to implement GitOps for their Kubernetes workloads using Argo CD. They have multiple environments (dev, staging, prod) in separate clusters. What is the best practice for structuring the Git repository?

A.A single branch with all environment manifests in the same folder
B.Separate repositories per environment
C.Store all manifests in a single file with environment labels
D.A monorepo with a directory per environment and overlays for differences
AnswerD

Standard GitOps pattern; clear separation with shared base and overlays.

Why this answer

A monorepo with a directory per environment and overlays (e.g., using Kustomize or Helm) allows you to manage environment-specific differences declaratively while keeping a single source of truth. Argo CD can sync each environment's directory to its respective cluster, and overlays minimize duplication by applying only the necessary patches (e.g., replica counts, ingress hosts) on top of a common base. This approach aligns with GitOps best practices for multi-environment deployments.

Exam trap

The trap here is that candidates often choose Option B (separate repos) thinking it provides the best isolation, but the KCNA exam emphasizes that a monorepo with overlays is the recommended pattern for GitOps because it reduces duplication and simplifies cross-environment consistency.

How to eliminate wrong answers

Option A is wrong because storing all environment manifests in the same folder on a single branch makes it impossible to isolate environment-specific changes, leading to accidental cross-environment deployments and no clear promotion path. Option B is wrong because separate repositories per environment introduce fragmentation, making it harder to maintain consistency across environments and requiring duplicate base configurations, which violates the DRY principle. Option C is wrong because storing all manifests in a single file with environment labels (e.g., using YAML anchors or labels) is not supported by Argo CD's native sync mechanism—Argo CD syncs entire manifests, not filtered by labels, and this approach would cause all environments to be deployed simultaneously, breaking environment isolation.

Full explanation →
729
Multi-Selectmedium

Which TWO of the following correctly describe the difference between Docker Compose and Kubernetes? (Choose 2)

Select 2 answers
A.Docker Compose can manage containers across multiple hosts
B.Docker Compose is suitable for production-grade deployments
C.Kubernetes provides built-in auto-scaling and self-healing
D.Kubernetes supports rolling updates and rollbacks
E.Both Docker Compose and Kubernetes use the same YAML format
AnswersC, D

Kubernetes offers features like HorizontalPodAutoscaler and ReplicaSet controllers for auto-scaling and self-healing.

Why this answer

Docker Compose is designed for single-host container orchestration with a simple YAML file, while Kubernetes is a multi-host container orchestration platform with advanced features like auto-scaling and self-healing.

Full explanation →
730
MCQmedium

The exhibit shows a Deployment manifest for a frontend service. After deployment, the pods are running but the service reports that no endpoints are available. What is the most likely cause?

A.The readiness probe periodSeconds is too short, causing the probe to overload the container.
B.The readiness probe is checking /ready which is not returning a 200 OK response.
C.The container image nginx:1.21 does not have the /healthz endpoint.
D.The liveness probe is failing, causing the pod to be restarted.
AnswerB

If the readiness probe fails, the pod is not considered ready and is removed from service endpoints.

Why this answer

The service reports no endpoints because the readiness probe is failing. A readiness probe determines whether a pod should receive traffic; if it does not return a 200 OK on the configured path (/ready), the pod is removed from the service’s endpoint list. Since the pods are running (liveness probe passes), the most likely cause is that the /ready endpoint is not serving a successful response.

Exam trap

CNCF often tests the distinction between readiness and liveness probes: candidates confuse a failing liveness probe (which restarts pods) with a failing readiness probe (which removes traffic but keeps the pod running).

How to eliminate wrong answers

Option A is wrong because a short periodSeconds does not cause the probe to overload the container; it merely increases the frequency of checks, and the symptom would be high CPU usage, not missing endpoints. Option C is wrong because the readiness probe is checking /ready, not /healthz; the absence of /healthz is irrelevant unless that path is configured. Option D is wrong because a failing liveness probe would restart the pod, but the pods are running, so the liveness probe is passing.

Full explanation →
731
Multi-Selecthard

Which THREE of the following are true about the Container Runtime Interface (CRI)? (Choose 3)

Select 3 answers
A.Docker natively implements the CRI
B.CRI is part of the Open Container Initiative (OCI)
C.CRI allows kubelet to communicate with different container runtimes
D.containerd implements the CRI
E.CRI-O is a lightweight runtime designed for Kubernetes
AnswersC, D, E

CRI defines the API between kubelet and container runtime.

Why this answer

CRI is a plugin interface that enables kubelet to use different container runtimes without recompiling. containerd and CRI-O are CRI-compliant runtimes. Docker was deprecated as a Kubernetes runtime and is not CRI-native; it uses dockershim.

Full explanation →
732
Multi-Selectmedium

Which two statements correctly describe etcd in a Kubernetes cluster?

Select 2 answers
A.It is a key-value store that holds cluster configuration and state
B.It runs on every worker node
C.It manages network rules for Services
D.It implements the Kubernetes API
E.It is a critical component that must be backed up regularly
AnswersA, E

Correct.

Why this answer

etcd is a distributed, consistent key-value store used by Kubernetes to persist all cluster data, including configuration, state, and metadata. It is the single source of truth for the cluster, and the API server reads from and writes to it exclusively. Without etcd, the cluster cannot recover or maintain its desired state, making it a critical component.

Exam trap

A common misconception is that etcd runs on all nodes or that it directly handles networking, when in fact it is a control-plane-only store that does not participate in data-plane operations.

Full explanation →
733
MCQmedium

Which Kubernetes resource is best suited for running a batch processing job that must complete successfully exactly once?

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

Job is designed for batch processing that runs to completion.

Why this answer

A Kubernetes Job is designed specifically for batch processing tasks that need to run to completion exactly once. It creates one or more Pods and ensures that a specified number of them successfully terminate, making it ideal for workloads like data processing or backups that must finish without retries or restarts.

Exam trap

CNCF often tests the distinction between one-time batch processing (Job) and recurring scheduled tasks (CronJob), so candidates mistakenly choose CronJob when the question specifies 'exactly once' rather than 'on a schedule'.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, which is used for continuous background services like logging or monitoring, not for one-time batch jobs. Option B is wrong because a Deployment manages a set of Pods to maintain a desired number of replicas running indefinitely, with rolling updates and self-healing, which is unsuitable for a job that must complete and not restart. Option C is wrong because a CronJob is used for scheduling recurring tasks on a time-based schedule, not for a one-time batch job that must run exactly once.

Full explanation →
734
MCQhard

You have a web application that needs to read configuration from a file and also access a database password. Which combination of resources should you use to manage these configurations securely?

A.Use ConfigMap for configuration file and Secret for database password
B.Use ConfigMap for both
C.Use PersistentVolume for configuration and environment variables for the password
D.Use Secret for both
AnswerA

Separating concerns: ConfigMap for non-sensitive, Secret for sensitive.

Why this answer

ConfigMap is designed for storing non-confidential configuration data like configuration files, while Secret is specifically for sensitive data such as database passwords. Secrets are base64-encoded and can be encrypted at rest using etcd encryption or KMS, providing a security boundary that ConfigMaps lack. This combination follows Kubernetes best practices for separating configuration from secrets.

Exam trap

The CNCF often tests the misconception that Secrets are inherently secure because they are base64-encoded, leading candidates to think Secrets are safe for all data, when in fact base64 is not encryption and Secrets require additional encryption-at-rest configuration for true security.

How to eliminate wrong answers

Option B is wrong because using ConfigMap for both stores the database password in plaintext (or base64 without encryption), exposing sensitive data to anyone with access to the ConfigMap API. Option C is wrong because PersistentVolume is for persistent storage of large data, not for managing configuration or secrets, and environment variables for the password would expose it in plaintext in the pod spec and process list. Option D is wrong because Secrets are not intended for non-sensitive configuration files; using Secrets for everything adds unnecessary complexity and defeats the purpose of having separate resource types for different security levels.

Full explanation →
735
MCQeasy

Which of the following is the smallest deployable unit in Kubernetes?

A.Service
B.Container
C.Pod
D.Node
AnswerC

A pod is the smallest deployable unit.

Why this answer

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 schedules and manages Pods as atomic units, making the Pod the fundamental building block of deployment.

Exam trap

The trap here is that candidates often think a Container is the smallest unit because Docker popularized containers as atomic units, but Kubernetes abstracts one level higher — the Pod — to manage shared resources and scheduling, making the Pod the smallest deployable object.

How to eliminate wrong answers

Option A is wrong because a Service is an abstraction that defines a logical set of Pods and a policy to access them, not a deployable unit — Pods are deployed, and Services provide stable networking to those Pods. Option B is wrong because a Container is the runtime instance of an image, but Kubernetes never deploys a container directly; it always wraps containers inside a Pod to manage shared resources and scheduling. Option D is wrong because a Node is a worker machine (physical or virtual) in the cluster, not a deployable unit — Pods are deployed onto Nodes, but the Node itself is infrastructure, not a unit of deployment.

Full explanation →
736
MCQmedium

Which API version is correct for a Deployment in modern Kubernetes (v1.29+)?

A.apiVersion: extensions/v1beta1
B.apiVersion: v1
C.apiVersion: apps/v1
D.apiVersion: apps/v1beta2
AnswerC

apps/v1 is the correct stable API version for Deployment.

Why this answer

In modern Kubernetes (v1.29+), the `apps/v1` API version is the stable and recommended version for the Deployment resource. The `apps/v1` API has been the default since Kubernetes 1.9, and all older beta versions (e.g., `apps/v1beta2`, `extensions/v1beta1`) have been removed as of Kubernetes 1.16. Using `apps/v1` ensures compatibility with current cluster features and avoids deprecation warnings.

Exam trap

The exam often tests the misconception that `v1` is the default API version for all resources, but candidates must remember that Deployments specifically require the `apps/v1` group, not the core `v1` group.

How to eliminate wrong answers

Option A is wrong because `extensions/v1beta1` was deprecated in Kubernetes 1.8 and removed entirely in Kubernetes 1.16; it is no longer available in v1.29+. Option B is wrong because `v1` is the core API version used for resources like Pods, Services, and ConfigMaps, but Deployments are not part of the core API group—they belong to the `apps` group. Option D is wrong because `apps/v1beta2` was a beta version of the Deployment API that was deprecated in Kubernetes 1.9 and removed in Kubernetes 1.16; it is not valid in modern clusters.

Full explanation →
737
MCQmedium

Which component of an API gateway pattern is responsible for routing requests to the appropriate microservice based on the request path?

A.API Gateway
B.Load balancer
C.Service registry
D.Sidecar proxy
AnswerA

The API gateway routes, enforces policies, and aggregates responses.

Why this answer

The API gateway acts as a reverse proxy and routes requests to the correct backend service.

Full explanation →
738
Multi-Selectmedium

Which TWO of the following are principles of the 12-factor app methodology? (Choose two.)

Select 2 answers
A.Perform manual deployment to avoid automation errors
B.Maximize robustness through stateful sessions
C.Ensure fast startup and graceful shutdown (disposability)
D.Build monolithic applications for simplicity
E.Store configuration in environment variables
AnswersC, E

This is the 'Disposability' factor.

Why this answer

The 12-factor app includes 'Config' (store config in environment variables) and 'Disposability' (start fast and shut down gracefully). 'Monolithic architecture' is not a principle; 12-factor encourages microservices. 'Stateful sessions' are discouraged; apps should be stateless. 'Manual deployment' is not a principle; CI/CD is recommended.

Full explanation →
739
MCQmedium

An administrator runs 'kubectl get pods' and sees that a pod is in 'Pending' state. 'kubectl describe pod' shows the event: '0/4 nodes are available: 1 node had taints that the pod didn't tolerate, 3 nodes had insufficient memory'. What is the most likely issue?

A.The node with the taint has a toleration mismatch.
B.The pod's image pull is failing.
C.The pod's resource requests exceed available memory on three nodes.
D.The pod was evicted due to resource pressure.
AnswerC

Correct; insufficient memory prevents scheduling.

Why this answer

The scheduler event explicitly states '3 nodes had insufficient memory', which directly indicates that the pod's resource requests (specifically memory) exceed the available allocatable memory on those three nodes. The fourth node is unavailable due to taints, leaving zero schedulable nodes, hence the 'Pending' state.

Exam trap

The KCNA exam often tests the distinction between taint/toleration and resource constraints — candidates mistakenly think the taint is the primary issue, but the event clearly shows only one node is tainted while three have insufficient memory, making resource exhaustion the dominant cause.

How to eliminate wrong answers

Option A is wrong because the event says '1 node had taints that the pod didn't tolerate', which is a taint/toleration mismatch, not a toleration mismatch on the node — the pod lacks the required toleration, not the node. Option B is wrong because image pull failures would appear as 'ErrImagePull' or 'ImagePullBackOff' events in 'kubectl describe pod', not as node availability issues. Option D is wrong because eviction due to resource pressure would result in a 'Terminating' or 'Evicted' status, not 'Pending', and the event would reference eviction, not node availability.

Full explanation →
740
MCQeasy

What is the primary purpose of the `kubectl apply` command?

A.To create or update resources from a manifest
B.To view resource details
C.To delete resources
D.To execute commands inside a container
AnswerA

`kubectl apply` creates or updates resources declaratively.

Why this answer

The `kubectl apply` command uses a declarative approach to manage Kubernetes resources. It sends a PATCH request to the API server, which compares the desired state in the provided manifest (YAML/JSON) with the current state of the resource in the cluster. If the resource does not exist, it creates it; if it does exist, it updates only the fields specified in the manifest, preserving any fields not mentioned.

Exam trap

CNCF often tests the confusion between imperative commands (like `kubectl create` or `kubectl run`) and declarative commands (`kubectl apply`), leading candidates to mistakenly think `apply` only creates resources or only updates them, rather than understanding it handles both idempotently.

How to eliminate wrong answers

Option B is wrong because viewing resource details is the purpose of `kubectl get` (to list resources) or `kubectl describe` (to show detailed state), not `kubectl apply`. Option C is wrong because deleting resources is done with `kubectl delete`, which sends a DELETE request to the API server, whereas `apply` never removes resources. Option D is wrong because executing commands inside a container is the function of `kubectl exec`, which uses the container runtime's exec API (e.g., via CRI or Docker), not the Kubernetes API for resource management.

Full explanation →
741
MCQhard

Which of the following is a key difference between a service mesh and an API gateway?

A.Service mesh is only used in multi-cloud environments, while API gateway is for single-cloud
B.Service mesh manages east-west traffic between services, while API gateway manages north-south traffic from external clients
C.Service mesh provides authentication and authorization, while API gateway does not
D.Service mesh handles north-south traffic, while API gateway handles east-west traffic
AnswerB

This correctly describes the primary traffic direction each handles.

Why this answer

Service mesh focuses on internal service-to-service communication within the cluster, while API gateway handles external traffic entering the cluster (north-south traffic). Both can perform traffic management, but their scopes differ.

Full explanation →
742
MCQhard

You have a Pod that is running but not receiving traffic. You suspect the associated Service's selector does not match the Pod labels. Which kubectl command would you use to check the Service's selector?

A.kubectl get endpoints <service-name>
B.kubectl describe service <service-name>
C.kubectl get service <service-name> -o yaml
D.kubectl logs <pod-name>
AnswerB

This shows detailed information including the selector field.

Why this answer

`kubectl describe service <service-name>` displays the service's selector field under the 'Selector' section, allowing you to directly compare it with the Pod's labels. This is the most straightforward way to verify if the selector matches the Pod labels, which is essential for traffic routing.

Exam trap

CNCF often tests the distinction between checking the selector definition versus checking the resulting endpoints, so candidates may mistakenly choose `kubectl get endpoints` because it shows the current routing status, but it does not reveal the selector itself.

How to eliminate wrong answers

Option A is wrong because `kubectl get endpoints <service-name>` shows the current endpoints (Pod IPs) that the service is routing to, but it does not show the service's selector; it only reveals the result of the selector matching, not the selector itself. Option C is wrong because `kubectl get service <service-name> -o yaml` outputs the full service definition including the selector, but it is more verbose and less direct than `kubectl describe` for quickly checking the selector; however, it is not incorrect per se, but the question asks for the command to check the selector, and `describe` is the standard, concise method. Option D is wrong because `kubectl logs <pod-name>` retrieves the logs from the Pod's containers, which provides application-level output but no information about the service's selector or label matching.

Full explanation →
743
MCQhard

You are asked to schedule a pod on a node that has SSD storage. Which mechanism should you use to achieve this?

A.Use a resource request for SSD storage capacity
B.Set an annotation on the pod specifying the disk type
C.Add a nodeSelector with a label matching the node, e.g., disktype: ssd
D.Add a toleration for a taint on SSD nodes
AnswerC

nodeSelector ensures the pod is scheduled on nodes with the matching label.

Why this answer

NodeSelector is the built-in Kubernetes mechanism for constraining a pod to nodes with specific labels. By labeling a node with disktype=ssd and adding that same label selector to the pod spec, the scheduler will only place the pod on nodes that have that label, ensuring it lands on SSD-equipped nodes.

Exam trap

The trap here is that candidates confuse tolerations (which only allow scheduling on tainted nodes) with node selectors (which actively target nodes), leading them to pick D instead of C.

How to eliminate wrong answers

Option A is wrong because resource requests specify minimum CPU/memory capacity, not storage type or node attributes; they cannot select nodes based on disk type. Option B is wrong because annotations are metadata for non-identifying information and are not used by the scheduler for node selection; they have no effect on pod placement. Option D is wrong because tolerations allow pods to be scheduled on tainted nodes but do not actively select nodes; they only permit scheduling on nodes that would otherwise repel the pod, without guaranteeing the node has SSD storage.

Full explanation →
744
MCQeasy

Which of the following is an example of immutable infrastructure?

A.SSH into a server to apply patches
B.Manually installing packages on a running container
C.Using configuration management tools to update software on running servers
D.Rebuilding a server from a pre-baked image and replacing the old one
AnswerD

This is the essence of immutable infrastructure.

Why this answer

Immutable infrastructure means that once a server or container is deployed, it is never modified in place. Instead, any change requires building a new image and redeploying. Option D describes exactly this: rebuilding from a pre-baked image and replacing the old server, which is the core pattern of immutability in container orchestration (e.g., Kubernetes rolling updates or Recreate deployments).

Exam trap

CNCF often tests the misconception that configuration management tools (like Ansible or Puppet) are inherently immutable, but they are actually used for mutable infrastructure because they apply changes to running systems rather than replacing them entirely.

How to eliminate wrong answers

Option A is wrong because SSHing into a server to apply patches is a classic mutable infrastructure pattern — it modifies a running system in place, which breaks the immutability principle. Option B is wrong because manually installing packages on a running container directly alters its filesystem and state, making it mutable and unreproducible from the original image. Option C is wrong because using configuration management tools (like Ansible or Chef) to update software on running servers still mutates the live environment, which is the opposite of the immutable approach where changes are made only at the image build stage.

Full explanation →
745
MCQmedium

A developer wants to deploy a function that reacts to image upload events in a cloud storage bucket. The function should scale to zero when idle. Which architecture best fits this use case?

A.Use a long-running virtual machine to process events
B.Deploy a container on Kubernetes with HorizontalPodAutoscaler set to minReplicas 0
C.Implement a serverless function using a FaaS platform like AWS Lambda
D.Use a Kubernetes Job triggered by a CronJob
AnswerC

FaaS platforms are event-driven and automatically scale to zero when idle.

Why this answer

FaaS (Function-as-a-Service) platforms like AWS Lambda are event-driven and can scale to zero when idle, making them ideal for sporadic event-triggered workloads.

Full explanation →
746
Multi-Selecteasy

Which TWO of the following are responsibilities of the kube-controller-manager? (Select 2)

Select 2 answers
A.Ensuring the desired number of pod replicas are running
B.Implementing service networking rules
C.Storing the cluster state
D.Detecting node failures and reacting
E.Scheduling pods onto nodes
AnswersA, D

The Replication Controller ensures the correct replica count.

Why this answer

The kube-controller-manager is responsible for running controller processes that regulate the state of the cluster. Option A is correct because the ReplicaSet controller, which runs inside the kube-controller-manager, continuously monitors the number of running pods and ensures it matches the desired replica count defined in the ReplicaSet or Deployment object. If a pod fails or is deleted, the controller creates a replacement to maintain the desired state.

Exam trap

The trap here is that candidates often confuse the kube-controller-manager with the kube-scheduler or kube-proxy, because all three are control plane components that manage different aspects of cluster operations, but only the controller-manager handles state regulation and failure detection.

Full explanation →
747
MCQmedium

A pod is in the 'Pending' state. Which of the following is a likely cause?

A.The liveness probe is failing
B.The container image is not found in the registry
C.No node has sufficient resources to run the pod
D.The container exited with OOMKilled
AnswerC

Insufficient resources cause the scheduler to keep the pod Pending.

Why this answer

A pod enters the 'Pending' state when it has been accepted by the API server but cannot be scheduled onto a node. The most common cause is insufficient cluster resources (CPU, memory, or ephemeral storage) on any available node to satisfy the pod's resource requests. The Kubernetes scheduler continuously evaluates node resource availability and will leave the pod in Pending until a suitable node is found or the request times out.

Exam trap

CNCF often tests the distinction between pod scheduling failures (Pending) and runtime failures (CrashLoopBackOff, OOMKilled, ImagePullBackOff), tempting candidates to confuse post-scheduling errors with pre-scheduling conditions.

How to eliminate wrong answers

Option A is wrong because a failing liveness probe causes the pod to be restarted (CrashLoopBackOff) or marked as Unhealthy, but does not prevent the pod from being scheduled; the pod must first be Running for probes to execute. Option B is wrong because an image not found in the registry results in an ImagePullBackOff or ErrImagePull error, which occurs after the pod is scheduled to a node, not while it is still in Pending. Option D is wrong because OOMKilled (exit code 137) is a container termination reason that occurs after the pod is Running, not during the scheduling phase; it would be visible in the pod status as CrashLoopBackOff or Terminated.

Full explanation →
748
MCQeasy

Which of the following is a benefit of using a service mesh?

A.It eliminates the need for Kubernetes
B.It provides persistent storage for stateful applications
C.It provides observability and traffic management
D.It reduces the number of microservices needed
AnswerC

These are primary benefits.

Why this answer

A service mesh provides observability, traffic management, and security (mTLS) without changing application code. It does not reduce the number of microservices, replace Kubernetes, or provide storage.

Full explanation →
749
MCQmedium

A development team wants to implement GitOps for their Kubernetes deployments using ArgoCD. Which ArgoCD component is responsible for monitoring the Git repository for changes and syncing the desired state to the cluster?

A.Repo Server
B.API Server
C.Application Controller
D.Redis Server
AnswerC

The Application Controller is the core component that monitors Git repositories and syncs applications to match the desired state.

Why this answer

The Application Controller in ArgoCD is the component that continuously monitors the Git repository and compares the desired state (in Git) with the live state (in the cluster). It triggers sync operations when differences are detected.

Full explanation →
750
MCQmedium

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

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

Secrets store sensitive data like passwords, tokens, and keys.

Why this answer

Secrets are designed to store sensitive data, such as passwords, and can be exposed to Pods via environment variables or volumes.

Full explanation →
Page 9

Page 10 of 12

Page 11

All pages

123456789101112

Practice KCNA by domain

Target a specific domain to shore up weak areas.

Kubernetes FundamentalsContainer OrchestrationCloud Native ArchitectureCloud Native ObservabilityCloud Native Application Delivery
See all domains with question counts →