KCNA Practice Exam 61 — 20 Questions

Question 1

A team manages a multi-service application with Helm. Each service has its own ConfigMap, Deployment, and Service. The manifests for all services are almost identical except for the image tag and service name. They want to create a single reusable Helm chart that deploys all services from one values file, avoiding duplicate YAML. Which Helm feature should they use to loop over a list of services in the chart templates?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use the `range` action in the template to iterate over a list defined in values.yaml, rendering one set of resources per service.. The `range` action in Helm templates allows iteration over a list from values.yaml, rendering a block of resources for each item. This is the standard way to avoid duplicating YAML for near-identical services. By defining a list of services in values.yaml and using `range` in the templates, the chart generates all ConfigMaps, Deployments, and Services dynamically. This keeps the chart DRY and maintainable as services are added.

Answer

Use Helm's `--set` flag during installation to override the service name and image tag for each service.

Answer

Create a separate subchart for each service and include them with the `dependencies` field in Chart.yaml.

Answer

Define each service as a separate named template in `_helpers.tpl` and call them from a single deployment manifest.

Question 2

A developer is investigating a performance issue in a microservices application. They want to trace a single request as it flows through multiple services, including a database call. Which OpenTelemetry concept allows them to correlate all these operations under a single logical unit?

Accepted Answer

Trace. In OpenTelemetry, a trace is the overarching structure that ties together all spans associated with a single request. Each span represents a unit of work, and spans within the same trace share a trace ID, enabling correlation across service boundaries. This allows developers to visualize the entire request flow, including database calls, and identify bottlenecks or failures. Metrics and logs serve different purposes and do not provide this end-to-end request context.

Answer

Span

Answer

Metric

Answer

Log record

Question 3

An administrator runs `kubectl taint nodes node1 dedicated=gpu:NoSchedule` and then creates a Pod with the toleration `key: dedicated, operator: Equal, value: gpu, effect: NoSchedule`. The Pod is scheduled onto node1, but the administrator expected the taint to repel all Pods without a matching toleration. Which statement explains why the Pod was still placed on node1?

Accepted Answer

The toleration matches the taint, so the scheduler is allowed to place the Pod on node1; taints repel only Pods that do not tolerate them.. Taints and tolerations work as a pair: a taint repels Pods that lack a matching toleration, but a Pod that tolerates the taint is allowed onto the node. Because the Pod's toleration matched the taint's key, value, and effect, the scheduler correctly placed it on node1. The administrator's mental model omitted the effect of the toleration, which is the intended escape hatch.

Answer

The taint effect `NoSchedule` only applies to Pods created in the kube-system namespace, so user Pods are unaffected.

Answer

Taints are only enforced during eviction, not during initial scheduling, so any Pod can land on a tainted node.

Answer

The toleration must use `operator: Exists` to match a taint with a value; `operator: Equal` never matches when a value is present.

Question 4

A Kubernetes administrator is troubleshooting a Pod that is stuck in the Pending state. The Pod has a resource request of cpu: 2 and memory: 4Gi. Which two commands are most appropriate to identify why the Pod cannot be scheduled? (Choose two.)

Accepted Answer

kubectl describe pod <pod-name>. The describe command surfaces scheduler events that explain why the Pod is Pending, and querying node allocatable resources shows whether any node has enough CPU and memory. Together they confirm resource shortfalls or constraint mismatches. Logs and exec require a running container, and a rollout restart does not diagnose scheduling failures.

Answer

kubectl logs <pod-name> --previous

Answer

kubectl rollout restart deployment <deployment-name>

Answer

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

Question 5

A cluster administrator is configuring a Pod with a container that requires 2 CPU cores and 4Gi of memory. The administrator sets resource requests to 2 CPU and 4Gi memory, and limits to 4 CPU and 8Gi memory. The Pod is scheduled to a node with 4 CPU and 8Gi memory available. What happens when the container attempts to use 3 CPU and 6Gi memory?

Accepted Answer

The container runs normally because usage is within the limits.. Resource requests are used by the scheduler to place pods, while limits define the maximum resources a container can consume. When usage is between requests and limits, the container continues running without throttling or termination. Only exceeding CPU limits causes throttling, and exceeding memory limits triggers an OOM kill.

Answer

The container is restarted by the kubelet because it exceeded its request.

Answer

The container is throttled to 2 CPU and OOM killed for memory.

Answer

The container is evicted from the node due to resource overcommit.

Question 6

A team is adopting a GitOps workflow with Argo CD to manage Kubernetes applications. They want to ensure that the cluster state always matches the desired state in Git and that changes are automatically applied. Which two Argo CD features should they configure? (Choose two.)

Accepted Answer

Self-heal. To ensure the cluster state always matches Git and changes are automatically applied, the team must enable automated sync policy and self-heal in Argo CD. Automated sync applies Git changes without manual intervention, while self-heal reverts any manual cluster modifications, maintaining the desired state. Manual sync, resource hooks, and sync windows do not provide these automatic reconciliation capabilities.

Answer

Sync windows

Answer

Resource hooks

Answer

Manual sync policy

Question 7

A cluster administrator needs to run a log-forwarding agent on every node, including nodes added later, without manually scheduling a Pod per node. Which workload object should be used?

Accepted Answer

A DaemonSet. Node-wide agents need exactly one instance per node with automatic coverage of newly joined nodes. A DaemonSet is purpose-built for that pattern, scheduling a Pod onto each eligible node as the cluster changes. Deployments, Jobs, and StatefulSets all lack the one-per-node guarantee, so they cannot satisfy the requirement reliably.

Answer

A Deployment with a high replica count

Answer

A Job with parallelism set to the node count

Answer

A StatefulSet with podManagementPolicy set to Parallel

Question 8

An administrator needs to store a database password for a Pod to consume as an environment variable. The password must be stored securely and not exposed in the Pod specification. Which Kubernetes resource should the administrator create?

Accepted Answer

A Secret. Secrets are the Kubernetes resource for storing sensitive data and can be referenced in Pod specs as environment variables or mounted volumes. ConfigMaps are for non-sensitive configuration, PersistentVolumeClaims provide storage, and ServiceAccounts provide API identities. Only a Secret meets the requirement of secure, out-of-manifest password storage.

Answer

A ConfigMap

Answer

A PersistentVolumeClaim

Answer

A ServiceAccount

Question 9

An administrator wants to allow a Pod to consume a ConfigMap named app-config as environment variables, but only the keys DB_HOST and DB_PORT. The ConfigMap contains additional keys. Which Pod spec snippet correctly injects only those two keys as environment variables?

Accepted Answer

env: - name: DB_HOST valueFrom: configMapKeyRef: name: app-config key: DB_HOST - name: DB_PORT valueFrom: configMapKeyRef: name: app-config key: DB_PORT. To inject specific ConfigMap keys as environment variables, each env entry must use valueFrom.configMapKeyRef with the ConfigMap name and key. This maps only the chosen keys. envFrom injects all keys, volume mounts expose keys as files, and the value field sets literal strings. The scenario requires selective environment variable injection.

Answer

env: - name: DB_HOST value: app-config.DB_HOST - name: DB_PORT value: app-config.DB_PORT

Answer

envFrom: - configMapRef: name: app-config

Answer

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

Question 10

A platform team is designing a progressive delivery rollout for a new version of a service running on Kubernetes. They want to send a small percentage of live traffic to the new version, observe metrics, and automatically roll back if error rates rise. Which two components are required to implement this with a service mesh? (Choose two.)

Accepted Answer

A canary or weighted routing rule in the mesh that splits traffic between the stable and new versions.. Progressive delivery with a service mesh requires two capabilities: a routing rule that splits traffic by percentage between stable and canary, and an analysis loop that reads metrics and decides whether to promote or roll back. Together they enable small, safe exposure and automatic recovery from regressions.

Answer

A NodePort Service exposing the canary directly to external users for manual testing.

Answer

A separate Kubernetes cluster dedicated to canary workloads.

Answer

A HorizontalPodAutoscaler configured to scale the canary based on CPU.

Question 11

A platform engineer is troubleshooting a Pod that stays in the Pending phase. Which two conditions can legitimately cause a Pod to remain Pending? (Choose two.)

Accepted Answer

No node in the cluster has sufficient allocatable CPU or memory to satisfy the Pod's resource requests.. Pending means the Pod has been accepted by the API server but not yet scheduled to a node. The two legitimate causes here are scheduling constraints: insufficient allocatable CPU or memory across candidate nodes, and node affinity or nodeSelector rules that match no nodes. Image pull failures, probe failures, and application crashes occur after scheduling and therefore do not produce a Pending phase.

Answer

The Pod's liveness probe is failing repeatedly.

Answer

The container's application process exits with a non-zero exit code.

Answer

The Pod's image tag does not exist in the registry.

Question 12

A platform engineer is configuring an OpenTelemetry Collector pipeline. They want to ensure that sensitive data such as credit card numbers is not exported to the observability backend. Which component of the Collector should they use to modify or drop attributes before export?

Accepted Answer

A processor in the pipeline. Processors are the components in an OpenTelemetry Collector pipeline that transform telemetry data. They can add, remove, or modify attributes, including dropping sensitive information. By placing a processor such as the attributes or filter processor before the exporter, the engineer can ensure that credit card numbers are removed or obfuscated before data is sent to the backend. Receivers, exporters, and connectors do not serve this purpose.

Answer

An exporter in the pipeline

Answer

A receiver in the pipeline

Answer

A connector in the pipeline

Question 13

An administrator is configuring a NetworkPolicy to allow ingress traffic to Pods with label `role=db` only from Pods with label `role=api` on TCP port 6379. The NetworkPolicy is applied in the same namespace as the Pods. Which NetworkPolicy YAML correctly implements this requirement?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api
    ports:
    - protocol: TCP
      port: 6379. The correct NetworkPolicy selects the target Pods (role=db) and defines an ingress rule that allows traffic from Pods labeled role=api on TCP port 6379. It uses a podSelector within the from clause to match the source Pods. Since both sets of Pods are in the same namespace, no namespaceSelector is required. The other options either allow too much traffic, reverse the roles, or add unnecessary egress restrictions that could disrupt other traffic.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - podSelector:
        matchLabels:
          role: api
    ports:
    - protocol: TCP
      port: 6379

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {}
    ports:
    - protocol: TCP
      port: 6379

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
spec:
  podSelector:
    matchLabels:
      role: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: db
    ports:
    - protocol: TCP
      port: 6379

Question 14

An engineering team runs a Kubernetes cluster and wants to ensure that a critical payment service continues to function during a partial network partition between two availability zones. The service currently depends on a single external authentication API in one zone. Which architectural change BEST supports the goal of maintaining payment processing during the partition?

Accepted Answer

Add a circuit breaker and a local authentication cache to the payment service. During a network partition, the external authentication API may become unreachable. A circuit breaker prevents the payment service from repeatedly calling a failing dependency, and a local authentication cache allows recently validated credentials to be used while the dependency is unavailable. These changes directly support continued payment processing. Replica scaling, single-zone placement, or changing the compute platform do not address the dependency failure.

Answer

Deploy the authentication API in the same zone as the payment service only

Answer

Increase the replica count of the payment service to three

Answer

Move the payment service to a serverless platform

Question 15

A startup is building a cloud-native application and wants to ensure that its services can be discovered and communicated with dynamically as they scale up and down. Which CNCF project provides a distributed key-value store that is commonly used for service discovery and configuration management in Kubernetes?

Accepted Answer

etcd. etcd is the correct choice because it is a distributed key-value store designed for reliable data storage, often used for service discovery and configuration management. In Kubernetes, etcd stores the entire cluster state, and many cloud-native applications use it directly for dynamic configuration and service registration. Its strong consistency and watch capabilities make it ideal for these tasks.

Answer

Prometheus

Answer

Jaeger

Answer

Fluentd

Question 16

A developer wants to run a single instance of a stateless web application in a Kubernetes cluster. The application does not need to maintain state or have a stable network identity. Which workload resource is the most appropriate to use?

Accepted Answer

Deployment. A Deployment is the standard Kubernetes resource for managing stateless applications. It provides declarative updates, scaling, and self-healing by managing ReplicaSets. For a stateless web application that does not require stable identities or persistent storage, a Deployment offers the right balance of simplicity and functionality, ensuring the application remains available and can be updated seamlessly.

Answer

StatefulSet

Answer

DaemonSet

Answer

Job

Question 17

A team wants every microservice to ship its logs and metrics to a central backend, and they want to avoid running a separate agent container inside each application Pod. Which cloud native approach BEST fits this requirement while keeping collection decoupled from the application?

Accepted Answer

Run a logging and metrics agent as a DaemonSet so one agent instance runs on every node and collects from all Pods on that node.. Running the collection agent as a DaemonSet places exactly one agent on each node, where it can read container logs and node-local metrics for every Pod on that node. That decouples telemetry from application containers, eliminates per-Pod sidecars, and scales naturally with the cluster. Sidecars, application push, and a single centralized collector all either violate the no-per-Pod-agent requirement or introduce coupling and availability problems.

Answer

Configure each application to push directly to the backend using its own vendor SDK and credentials.

Answer

Create a single centralized collector Deployment with one replica that all Pods send telemetry to.

Answer

Add a sidecar container to every application Pod that forwards logs and metrics to the backend.

Question 18

A developer creates a Pod with two containers. The first container writes logs every 30 seconds to a shared volume. The second container reads those logs. After deployment, the second container fails to start because it cannot find the log file. The Pod spec uses an emptyDir volume mounted at /var/logs in both containers. What is the most likely cause?

Accepted Answer

The second container starts before the first container writes any logs, and it exits because the file does not exist.. Containers within a Pod start simultaneously without guaranteed ordering. When one container depends on a file created by another, the reader may start first and fail. This race condition is best solved by using an init container that waits for the file, or by making the reader container resilient to the file's absence.

Answer

emptyDir volumes are not shared between containers in the same Pod; each container gets its own isolated volume.

Answer

The Pod's restartPolicy is set to Never, so the second container will not restart after failing.

Answer

The second container lacks the necessary permissions to read files written by the first container.

Question 19

A Kubernetes cluster runs a critical application in a pod. The operations team wants to receive an alert if the application's main process stops responding to HTTP requests on port 8080 at path /healthz. They need Kubernetes to automatically restart the pod if the health check fails. Which type of probe should they configure?

Accepted Answer

livenessProbe. A liveness probe is used to determine if a container is alive and healthy. When it fails, the kubelet restarts the container, which helps recover from deadlocks or unresponsive states. Configuring an HTTP liveness probe on port 8080 at /healthz will cause Kubernetes to periodically send HTTP GET requests; if the response is not successful, the container is restarted, meeting the alert and restart requirement.

Answer

startupProbe

Answer

httpProbe

Answer

readinessProbe

Question 20

A release manager asks how a GitOps controller such as Argo CD decides whether an application is in sync. Which statement accurately describes that behavior?

Accepted Answer

It compares the manifests rendered from the Git repository against the live objects in the cluster and reports drift when they differ. GitOps defines the desired state in Git, so a controller determines sync by rendering that desired state and diffing it against the live cluster objects. Divergence produces an OutOfSync status that a human can review or an automated policy can reconcile, keeping the cluster aligned with the repository.

Answer

It watches container image registries and marks the application in sync whenever a newer image tag is published

Answer

It checks whether all Pods report Ready and marks the application in sync once every replica passes its readiness probe

Answer

It queries the Kubernetes API for the latest applied annotation and considers the application in sync when that annotation is present