KCNA Hard Questions — 25 Difficult Questions

Question 1

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

Accepted Answer

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

Answer

Service

Answer

PodSecurityPolicy

Answer

Ingress

Question 2

A developer creates a Pod with a single container that writes data to /data. The Pod spec includes a volume of type hostPath with path /mnt/data. After the Pod is deleted, the developer notices that the data persists on the node. What is the primary reason for this behavior?

Accepted Answer

hostPath volumes are not deleted when the Pod is deleted; they persist on the node's filesystem.. hostPath volumes directly mount a node's filesystem path into a Pod. Data written to that path is stored on the node and remains there even after the Pod is deleted. This is why the data persists, as the node's directory is not automatically cleaned up by Kubernetes.

Answer

The Pod's restartPolicy is set to Always, which causes the volume to be recreated after deletion.

Answer

The volume is backed by a PersistentVolume that retains data even after the Pod is deleted.

Answer

The kubelet caches volume data in memory and writes it back to the hostPath after Pod deletion.

Question 3

Which TWO of the following are recommended practices for achieving observability in a Kubernetes cluster?

Accepted Answer

Include correlation IDs in structured logs to enable tracing across services.. Including correlation IDs in structured logs is a key observability practice that enables distributed tracing across microservices. In Kubernetes, where requests often traverse multiple pods and services, correlation IDs allow you to link logs from different components into a single transaction flow, which is essential for debugging and understanding system behavior.

Answer

Use a single centralized logging solution to aggregate logs from all components.

Answer

Store all debug logs for a minimum of 90 days for compliance.

Answer

Disable leader election for monitoring components to reduce complexity.

Question 4

A team wants to use feature flags to control the rollout of a new feature in a Kubernetes-deployed microservice. Which tool is specifically designed for managing feature flags in cloud-native applications?

Accepted Answer

LaunchDarkly. LaunchDarkly is a feature management platform specifically designed for managing feature flags in cloud-native applications. It allows for controlled rollouts and A/B testing. Argo Rollouts focuses on progressive delivery (canary, blue-green deployments), not feature flags. Helm is a package manager for Kubernetes. Kustomize is for configuration management. Therefore, option B (LaunchDarkly) is correct.

Answer

Helm

Answer

Kustomize

Answer

Argo Rollouts

Question 5

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

Accepted Answer

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

Answer

The container is running but producing no output

Answer

The container runtime is failing to start the container

Answer

The container has crashed and is restarting

Question 6

A company wants to implement a serverless function that processes events from an object storage bucket. The function should scale to zero when idle and only incur costs during execution. Which technology is BEST suited for this requirement?

Accepted Answer

A Functions-as-a-Service (FaaS) platform. A Functions-as-a-Service (FaaS) platform is a serverless compute service that scales to zero when idle and is event-driven, making it ideal for processing events from an object storage bucket with cost efficiency. Option A (Knative) is serverless but runs on Kubernetes, requiring cluster management and not scaling to zero as cleanly. Option B (Apache Kafka) is a streaming platform, not a serverless function service. Option D (Kubernetes CronJob) is for scheduled jobs, not event-driven, and does not scale to zero automatically.

Answer

Knative

Answer

Apache Kafka

Answer

Kubernetes CronJob

Question 7

A team is designing a cloud-native system that must maintain high availability across multiple cloud regions. The application uses Kubernetes clusters in each region. Which approach best ensures that the system can tolerate a full region failure while minimizing complexity?

Accepted Answer

Use a global load balancer with active-passive regional failover. A global load balancer with active-passive regional failover provides a straightforward way to route traffic to a healthy secondary region when the primary fails, without the complexity of multi-region Kubernetes control planes or synchronous replication. This approach leverages DNS-based or anycast routing to detect region failure and redirect traffic, ensuring high availability while keeping the operational overhead low.

Answer

Deploy a single Kubernetes cluster spanning all regions

Answer

Run active-active in all regions with synchronous data replication

Answer

Implement manual failover procedures documented in runbooks

Question 8

Refer to the exhibit. A pod 'my-pod' shows repeated 'BackOff' events after the container starts. Which is the most likely cause?

Accepted Answer

The application crashes shortly after starting.. The 'BackOff' event in Kubernetes indicates that the container has started but repeatedly crashes, causing the kubelet to increase the restart delay. Option D is correct because an application that crashes shortly after starting will trigger this restart loop, as the container exits with a non-zero exit code, leading to exponential backoff.

Answer

The image 'myapp:v2' does not exist.

Answer

The container exceeds its memory limit.

Answer

The liveness probe is failing.

Question 9

A Kubernetes cluster has two nodes: control-plane and worker. The worker node runs several pods. The control-plane node becomes unreachable. What is the immediate impact on the pods running on the worker node?

Accepted Answer

Pods continue running, but new pods cannot be scheduled. When the control-plane node becomes unreachable, the kube-controller-manager cannot communicate with the kubelet on the worker node, so it stops performing scheduling and reconciliation. However, the kubelet on the worker node continues to run existing pods based on the last known desired state stored locally, and the pods themselves are managed by the container runtime (e.g., containerd) independently of the control-plane. Therefore, pods continue running normally, but no new pods can be scheduled because the scheduler, which runs on the control-plane, is unavailable.

Answer

All pods are immediately terminated

Answer

Pods are rescheduled to the control-plane node

Answer

The worker node is automatically cordoned

Question 10

Which THREE of the following are key characteristics of microservices architecture?

Accepted Answer

Independent deployment of services. Microservices architecture mandates that each service can be independently deployed, updated, and scaled without affecting other services. This is achieved through separate deployment pipelines, containerization (e.g., Docker), and orchestration platforms like Kubernetes that manage service lifecycles independently. Independent deployment enables continuous delivery and reduces the blast radius of changes.

Answer

Single monolithic codebase

Answer

Shared database schema across services

Question 11

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

Accepted Answer

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

Answer

Store the API key in a ConfigMap and reference it in the Pod spec.

Answer

Embed the API key directly in the container image.

Answer

Store the API key in a Pod annotation and read it with kubectl.

Question 12

According to DORA metrics, which metric measures the percentage of deployments that fail in production?

Accepted Answer

Change Failure Rate. Change Failure Rate (CFR) is the DORA metric that directly measures the percentage of deployments that result in a failure in production, such as a service outage or a bug requiring a hotfix. It is calculated as (number of failed deployments / total deployments) * 100. This metric reflects the quality and stability of the software delivery process, complementing speed metrics like Deployment Frequency and Lead Time for Changes.

Answer

Mean Time to Restore (MTTR)

Answer

Deployment Frequency

Answer

Lead Time for Changes

Question 13

A pod is stuck in the Pending state. Running 'kubectl describe pod <pod-name>' shows the event: '0/3 nodes are available: 1 node had taint {node.kubernetes.io/disk-pressure: }, 2 nodes had taint {node.kubernetes.io/memory-pressure: }'. What is the most likely cause?

Accepted Answer

All nodes have taints that the pod does not have tolerations for. The pod is stuck in Pending because the scheduler cannot find a node that satisfies its scheduling constraints. The events show that all three nodes have taints (disk-pressure and memory-pressure), and the pod does not have corresponding tolerations to allow it to be scheduled on those nodes. Without tolerations, the pod is not permitted to run on any of the available nodes, leaving it in the Pending state.

Answer

The container image is not found in the registry

Answer

The pod has a resource request that exceeds available capacity on all nodes

Answer

The pod's liveness probe is failing

Question 14

Which TWO are characteristics of the microservices architecture that are supported by container orchestration?

Accepted Answer

Independent deployment of each service. Option B is correct because container orchestration platforms such as Kubernetes let each microservice be built, versioned, and rolled out on its own schedule, so a change to one service does not force redeployment of the others. Option C is correct because microservices architecture decomposes an application into small, independently runnable services, and orchestration supports this by scheduling, scaling, and networking each service as a separate workload. Options A, D, and E are not characteristics of microservices supported by orchestration: tight coupling, a monolithic codebase with centralized deployment, and a single shared database all describe monolithic or tightly integrated designs that contradict the independence and loose coupling that orchestration enables.

Answer

Tight coupling between services to ensure performance

Answer

Monolithic codebase with centralized deployment

Answer

Use of a single, shared database for all services

Question 15

A user runs 'kubectl exec -it pod1 -- /bin/sh' and gets the error: 'error: unable to upgrade connection: container not found ("app")'. The pod has one container named 'app'. What is the most likely cause?

Accepted Answer

The pod is in a CrashLoopBackOff state. The error 'unable to upgrade connection: container not found ("app")' indicates that kubectl cannot find a running container named 'app' to attach to. When a pod is in CrashLoopBackOff state, the container repeatedly crashes and restarts, but during the backoff period the container is not running, so kubectl exec cannot locate it. This is the most likely cause because the error specifically mentions the container name, and a CrashLoopBackOff means the container is not in a running state.

Answer

The pod is running on a different node

Answer

The container image does not have /bin/sh

Answer

The container name is misspelled

Question 16

You apply the following YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.21

But the Deployment never creates any Pods. Which field is missing or incorrect?

Accepted Answer

The field 'spec.selector' is missing, which is required for Deployment. The provided YAML is valid. The 'spec.selector' field is present and correctly matches the template labels. The 'replicas' is set to 3, not 0. 'containers' is spelled correctly, and 'apiVersion: apps/v1' is correct for Deployment. Therefore, none of the listed options describe a real issue, and the Deployment should create Pods as expected.

Answer

The 'replicas' field is set to 0

Answer

The 'containers' field is misspelled as 'container'

Answer

The 'apiVersion' should be 'v1'

Question 17

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 18

A microservice application is experiencing high latency during traffic spikes. The team identifies that the database connection pool is exhausted. They want to implement a pattern that helps decouple the microservice from direct database connections and smooth out traffic bursts. Which design pattern should they apply?

Accepted Answer

Queue-based Load Leveling pattern. The Queue-based Load Leveling pattern uses a message queue (e.g., RabbitMQ, Amazon SQS) as a buffer between the microservice and the database. When traffic spikes occur, requests are queued and processed at a manageable rate, preventing the database connection pool from being exhausted. This decouples the service from direct database connections and smooths out bursts, directly addressing the latency issue.

Answer

Bulkhead pattern

Answer

Circuit Breaker pattern

Answer

Retry pattern

Question 19

You want to run a batch job that processes a queue and then terminates. Which Kubernetes resource should you use?

Accepted Answer

Job. A Kubernetes Job is designed for batch processing tasks that run to completion and then terminate. It creates one or more Pods and ensures they successfully finish executing a specific workload, making it the correct choice for processing a queue and then exiting.

Answer

Deployment

Answer

CronJob

Answer

DaemonSet

Question 20

You have a Deployment with 3 replicas. You need to perform a rolling update with 2 extra pods during the update and ensure that only 1 pod is unavailable at any time. Which update strategy configuration achieves this?

Accepted Answer

maxSurge: 2, maxUnavailable: 1. It sets maxSurge to 2 (allowing up to 2 extra pods above the desired 3, for a total of 5 pods during the update) and maxUnavailable to 1 (ensuring at most 1 pod is unavailable at any time). This satisfies the requirement of having 2 extra pods during the update while keeping only 1 pod unavailable.

Answer

maxSurge: 1, maxUnavailable: 2

Answer

maxSurge: 0, maxUnavailable: 2

Answer

maxSurge: 3, maxUnavailable: 0