KCNA Container Orchestration Practice Test 9 — 15 Questions

Question 1

A Kubernetes cluster has a Deployment running three replicas of an application. You need to update the container image to a new version with zero downtime. Which approach is most appropriate?

Accepted Answer

Use 'kubectl set image deployment/ =' to trigger a rolling update. `kubectl set image deployment/ =` triggers a rolling update, which is the default update strategy for Deployments. This gradually replaces old pods with new ones, ensuring that the desired number of replicas is always available, thus achieving zero downtime.

Answer

Manually delete each pod and rely on the ReplicaSet to recreate them with the new image

Answer

Delete the Deployment and recreate it with the new image

Answer

Scale the Deployment to zero and then scale back up with the new image

Question 2

You have a microservices application where Service A needs to discover the IP of Service B. Both services run in the same Kubernetes cluster. Which approach is the most Kubernetes-native way for Service A to reach Service B?

Accepted Answer

Use the Kubernetes DNS service to resolve the Service name 'service-b'. Kubernetes has a built-in DNS service (typically CoreDNS) that automatically creates DNS records for Services. When Service A resolves the name 'service-b' (or 'service-b.<namespace>.svc.cluster.local'), the DNS returns the cluster IP of Service B's Service object, which then load-balances traffic to the healthy Pods. This is the most Kubernetes-native approach because it leverages the platform's own service discovery mechanism without external dependencies.

Answer

Use an external service registry like Consul or etcd

Answer

Hardcode the cluster IP of Service B in the configuration of Service A

Answer

Use environment variables injected by the Kubernetes API into each pod

Question 3

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

Accepted Answer

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

Answer

kube-controller-manager

Answer

kube-proxy

Answer

kube-apiserver

Question 4

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

Accepted Answer

To allow kubelet to use different container runtimes without modifying its code. The Container Runtime Interface (CRI) is a plugin interface that enables the kubelet to use a wide variety of container runtimes without requiring changes to the core Kubernetes code. By defining a standard set of gRPC APIs for runtime operations (like pod and container lifecycle management), CRI decouples the kubelet from any specific runtime implementation, allowing runtimes like containerd, CRI-O, and Docker (via dockershim, now deprecated) to be used interchangeably.

Answer

To replace Docker as the only supported runtime

Answer

To define the format of container images

Answer

To provide a standard API for managing containers across different orchestration platforms

Question 5

Which of the following is a benefit of using an orchestrator like Kubernetes?

Accepted Answer

Automatic scaling based on CPU utilization. Kubernetes, as a container orchestrator, provides built-in Horizontal Pod Autoscaling (HPA) that automatically adjusts the number of pod replicas based on observed CPU utilization (or custom metrics). This is a core benefit because it allows applications to handle varying load without manual intervention, improving resource efficiency and availability.

Answer

Direct access to the host kernel for performance tuning

Answer

Guaranteed zero downtime for all updates

Answer

Manual scaling based on traffic spikes

Question 6

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?

Accepted Answer

Use a nodeSelector with the label 'disktype: ssd'. 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.

Answer

Manually edit kube-scheduler configuration

Answer

Use a DaemonSet to run the pod on all nodes

Answer

Use a toleration for the node

Question 7

Your application consists of a frontend and a backend. The frontend needs to communicate with the backend using a stable DNS name. The backend is deployed as a Deployment with 3 replicas. Which Kubernetes resource should you create to provide a stable DNS name for the backend?

Accepted Answer

Service of type ClusterIP. A Service of type ClusterIP provides a stable virtual IP and DNS name (e.g., my-service.namespace.svc.cluster.local) that load-balances traffic across the backend Pods. This is the correct resource because the frontend only needs a stable DNS name for internal cluster communication, and ClusterIP is the default Service type that fulfills this requirement without exposing the backend externally.

Answer

EndpointSlice

Answer

Service of type NodePort

Answer

Ingress

Question 8

What is the OCI (Open Container Initiative) responsible for?

Accepted Answer

Defining standards for container images and runtimes. The Open Container Initiative (OCI) is a Linux Foundation project that defines open industry standards for container image formats and container runtimes. Its two main specifications are the OCI Image Spec (which standardizes the container image layout, including layers and manifests) and the OCI Runtime Spec (which defines the lifecycle and configuration for running containers). This ensures interoperability between different container tools and platforms, such as Docker, Podman, and containerd.

Answer

Hosting public container images

Answer

Providing a default container runtime for Kubernetes

Answer

Managing container orchestration

Question 9

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

Accepted Answer

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

Answer

Configuration changes can be applied via SSH into the container

Answer

Containers are updated in place by executing commands inside running containers

Answer

Stateful applications require mutable infrastructure

Question 10

Which TWO statements correctly describe how Kubernetes handles self-healing? (Select two.)

Accepted Answer

If a node fails, the ReplicaSet controller automatically recreates the pods on healthy nodes. The ReplicaSet controller monitors the cluster for node failures and, when a node becomes unhealthy, it creates replacement pods on other healthy nodes to maintain the desired replica count. This is a core self-healing mechanism in Kubernetes that operates at the controller level, independent of the kubelet.

Answer

Kubernetes automatically fixes application-level bugs by rolling back to a previous version

Answer

Kubernetes can automatically resolve OOMKilled errors by increasing memory limits

Answer

Kubernetes can automatically resolve OOMKilled errors by increasing memory limits

Question 11

Which of the following is a key benefit of container orchestration compared to running containers manually?

Accepted Answer

Automatic scaling and self-healing. Container orchestration platforms like Kubernetes provide automatic scaling and self-healing capabilities that are not available when running containers manually. Self-healing automatically restarts failed containers, reschedules them when nodes fail, and replaces containers that fail health checks, while scaling adjusts the number of replicas based on CPU/memory metrics or custom metrics. Manual container management requires operators to monitor and intervene for each failure or load change, making orchestration essential for production-grade reliability and elasticity.

Answer

Containers use less memory

Answer

Orchestration eliminates the need for container images

Answer

Containers run faster when orchestrated

Question 12

A developer wants to deploy a stateful application that requires stable network identities and persistent storage. Which Kubernetes resource is best suited for this workload?

Accepted Answer

StatefulSet. StatefulSet is the correct choice because it is designed specifically for stateful applications that require stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage (via PersistentVolumeClaims that are retained across Pod rescheduling). Unlike Deployments, StatefulSets guarantee ordered deployment, scaling, and termination, which is essential for databases or message queues.

Answer

Deployment

Answer

DaemonSet

Answer

Job

Question 13

A Kubernetes cluster has a single control plane node and two worker nodes. The control plane node fails. What is the immediate impact on the workloads running on the worker nodes?

Accepted Answer

Existing workloads continue running, but no new pods can be scheduled. In Kubernetes, the control plane is responsible for scheduling new pods and maintaining desired state via the API server, controller manager, and scheduler. When the control plane fails, the kubelets on worker nodes continue to run existing pods based on their local state, but the scheduler cannot assign new pods to nodes, and the API server is unavailable for updates or scaling operations.

Answer

All workloads will stop immediately

Answer

The kubelet on worker nodes will restart all pods

Answer

Workloads will be automatically migrated to another cluster

Question 14

Which statement accurately describes a key difference between containers and virtual machines?

Accepted Answer

Containers share the host OS kernel, while virtual machines include a full guest OS. Containers virtualize at the OS level, sharing the host kernel, while virtual machines (VMs) include a full guest OS with its own kernel, running on a hypervisor. This fundamental architectural difference means containers are lighter and start faster, but VMs provide stronger isolation since each VM has its own kernel and OS instance.

Answer

Virtual machines share the host kernel, while containers have their own kernel

Answer

Both containers and virtual machines require a hypervisor

Answer

Containers include a full guest operating system

Question 15

A pod spec includes a liveness probe that runs 'cat /tmp/healthy'. The probe is configured with initialDelaySeconds: 10, periodSeconds: 5. At what point does the kubelet first execute the probe?

Accepted Answer

10 seconds after the container starts. The kubelet first executes the liveness probe 10 seconds after the container starts because `initialDelaySeconds: 10` tells the kubelet to wait that long before initiating the first probe. The `periodSeconds: 5` only defines the interval between subsequent probes, not the initial delay. This ensures the container has time to start and create the `/tmp/healthy` file before being checked.

Answer

Immediately after the pod is created

Answer

Only when the container is unhealthy

Answer

5 seconds after the container starts