KCNA Practice Test 33 — 15 Questions

Question 1

A developer creates the Pod manifest shown. When the Pod runs, the liveness probe fails and the container is restarted repeatedly. What is the most likely cause?

Accepted Answer

The liveness probe port (8080) does not match the container port (80).. The liveness probe is configured to check TCP on port 8080, but the container exposes port 80 for Nginx. Since the probe will never successfully connect to port 8080, it always fails, causing the container to be restarted repeatedly. The probe must target the same port that the application is listening on.

Answer

The initialDelaySeconds of 3 is too short for Nginx to start.

Answer

The periodSeconds of 5 causes too frequent probing.

Answer

The image nginx:latest does not have a /healthz endpoint.

Question 2

A pod has resource requests: cpu: 250m, memory: 512Mi and limits: cpu: 500m, memory: 1Gi. If the container tries to use 600m CPU and 700Mi memory, what will happen?

Accepted Answer

The container will be throttled for CPU, but will not be killed because memory is within limits. CPU is a compressible resource: exceeding the CPU limit (500m) causes throttling, not termination. Memory is a non-compressible resource, and since the container's memory usage (700Mi) is below its limit (1Gi), it will not be killed. The container will be CPU-throttled but allowed to continue running.

Answer

The container will be allowed to use the extra resources because limits are only soft constraints

Answer

The container will be throttled for CPU and may be terminated if it continues to exceed the limit

Answer

The container will be killed immediately because it exceeded its CPU limit

Question 3

A DevOps engineer wants to ensure that a critical application pod is rescheduled on a different node if its current node fails. The pod should be scheduled with a preference for nodes in a specific availability zone but can run elsewhere if needed. Which scheduling mechanism should be used?

Accepted Answer

Use a Deployment with a preferred nodeAffinity rule.. A Deployment with a preferred nodeAffinity rule is correct because it allows the pod to be rescheduled on a different node if the current node fails, while expressing a preference for nodes in a specific availability zone. The 'preferred' (soft) rule ensures scheduling flexibility—the pod can run elsewhere if no zone-matching nodes are available—which aligns with the requirement for high availability without strict zone constraints.

Answer

Use a StatefulSet with podAntiAffinity.

Answer

Run a static pod defined in the kubelet configuration.

Answer

Create a DaemonSet with a nodeSelector for the zone.

Question 4

Which command is used to view detailed information about a specific pod, including events and conditions?

Accepted Answer

kubectl describe pod. The `kubectl describe pod` command retrieves detailed information about a specific pod, including its current state, metadata, labels, annotations, container details, resource limits, and a chronological list of events and conditions (e.g., PodScheduled, Initialized, Ready, ContainersReady). This makes it the correct tool for viewing comprehensive pod status and lifecycle events.

Answer

kubectl logs pod

Answer

kubectl exec pod

Answer

kubectl get pod

Question 5

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

Accepted Answer

The Service's pod selector does not match any running pods. If endpoints are empty, the Service selector does not match any pods, or the pods are not ready.

Answer

The Service is not associated with a namespace

Answer

The Service is exposed on the wrong port

Answer

The kube-proxy is not running on the node

Question 6

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

Accepted Answer

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

Answer

Singleton pattern

Answer

Round-robin load balancing

Question 7

You have a ConfigMap named 'app-config' with key 'database.url'. Which environment variable reference in a Pod spec injects this value correctly?

Accepted Answer

env:
  - name: DATABASE_URL
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: database.url. It uses the `configMapKeyRef` field under `valueFrom` to reference a specific key (`database.url`) from the ConfigMap named `app-config`. This is the standard Kubernetes syntax for injecting a single key from a ConfigMap as an environment variable into a Pod.

Answer

env:
  - name: DATABASE_URL
    value: "$(APP_CONFIG_DATABASE_URL)"

Answer

env:
  - name: DATABASE_URL
    valueFrom:
      secretKeyRef:
        name: app-config
        key: database.url

Answer

env:
  - name: DATABASE_URL
    valueFrom:
      configMapRef:
        name: app-config
        key: database.url

Question 8

You have a Deployment with the following rollout strategy: rollingUpdate: maxSurge: 1, maxUnavailable: 0. What behavior does this configuration enforce?

Accepted Answer

The rollout will create one additional pod before terminating the old pod, ensuring zero downtime. The rolling update strategy `maxSurge: 1, maxUnavailable: 0` ensures that during the rollout, one additional pod is created above the desired replica count before any existing pod is terminated. This guarantees that the total number of available pods never drops below the desired count, achieving zero downtime. The `maxUnavailable: 0` setting prevents any pod from being taken down until a new one is ready, while `maxSurge: 1` allows one extra pod to be created temporarily.

Answer

The rollout will terminate all old pods at once and then create new ones

Answer

The rollout will create all new pods first, then delete all old pods

Answer

The rollout will terminate one old pod before creating a new one

Question 9

In the 12-factor app methodology, which factor describes the practice of storing configuration in environment variables?

Accepted Answer

Config. The Config factor (Factor III) of the 12-factor app methodology mandates that configuration—such as database URLs, credentials, or feature flags—be stored in environment variables. This decouples configuration from code, allowing the same build to be deployed across different environments without code changes, and prevents accidental commits of secrets to version control.

Answer

Backing services

Answer

Processes

Answer

Build, release, run

Question 10

Which TWO of the following are valid components of the Alertmanager configuration? (Select two.)

Accepted Answer

route. Alertmanager configuration includes 'route' for routing alerts and 'receivers' for notification channels. 'prometheus_rules' is part of Prometheus configuration, not Alertmanager. 'alert' and 'group_by' are not top-level Alertmanager config keys.

Answer

group_by

Answer

prometheus_rules

Answer

alert

Question 11

When using OpenTelemetry, what is the role of the 'Collector'?

Accepted Answer

To receive, process, and export telemetry data in a vendor-neutral way. The OpenTelemetry Collector is a vendor-agnostic proxy that receives telemetry data (traces, metrics, logs) from instrumented applications, processes it (e.g., batching, filtering, enrichment), and exports it to one or more backends (e.g., Jaeger, Prometheus, or any OTLP-compatible system). It decouples data generation from data storage, enabling flexible, scalable observability pipelines without vendor lock-in.

Answer

To alert on abnormal metrics

Answer

To store traces for long-term retention

Answer

To instrument application code manually

Question 12

Which component runs on every node and is responsible for ensuring that containers are running as specified in Pod manifests?

Accepted Answer

kubelet. The kubelet is the primary node agent that runs on every node in a Kubernetes cluster. It is responsible for ensuring that containers described in Pod manifests (typically provided via the API server) are running and healthy. The kubelet does not manage containers directly; instead, it interacts with the container runtime (e.g., containerd, CRI-O) to create, start, and stop containers as specified.

Answer

kube-proxy

Answer

container runtime

Answer

kube-controller-manager

Question 13

You need to expose a set of pods running in the 'dev' namespace internally within the cluster on a stable IP. All pods have the label 'app: web'. Which kubectl command should you use?

Accepted Answer

kubectl expose deployment web --port=80 --target-port=8080 --name=web-service -n dev. It exposes the existing deployment named 'web' (which manages pods with label 'app: web') as a ClusterIP service, providing a stable internal IP and DNS name within the cluster. The `--port=80` sets the service port, and `--target-port=8080` maps to the container port, ensuring traffic reaches the pods correctly in the 'dev' namespace.

Answer

kubectl create service clusterip web --tcp=80:8080 -n dev

Answer

kubectl run web --image=nginx --port=80 -n dev

Answer

kubectl expose pod web --port=80 --target-port=8080 --name=web-service -n dev

Question 14

A pod is stuck in Pending state. Which THREE of the following are possible causes?

Accepted Answer

The pod specifies a nodeSelector that does not match any node. A pod enters a Pending state when it cannot be scheduled onto a node. A `nodeSelector` constraint requires the node to have specific labels; if no node matches, the scheduler cannot place the pod, leaving it Pending. This is a common scheduling failure cause.

Answer

The container image does not exist

Answer

The pod has a liveness probe that is failing

Question 15

You need to run a stateless web application with three replicas, and you want to ensure that if a pod fails, it is automatically replaced. Which Kubernetes resource should you use?

Accepted Answer

Deployment. A Deployment is the correct resource because it manages a ReplicaSet to ensure the desired number of pod replicas (three) are running at all times. If a pod fails, the Deployment's controller automatically creates a replacement pod, maintaining the stateless application's availability.

Answer

DaemonSet

Answer

Job

Answer

StatefulSet