KCNA Container Orchestration Practice Test 12 — 15 Questions

Question 1

A team wants to deploy a batch job that runs once to process a large dataset. The job should run to completion and then terminate. Which Kubernetes resource should be used?

Accepted Answer

Job. A Job resource is designed for batch processing tasks that run to completion and then terminate. It creates one or more Pods and ensures they successfully finish their work, making it the correct choice for a one-time data processing job.

Answer

DaemonSet

Answer

CronJob

Answer

Deployment

Question 2

A Kubernetes administrator needs to restrict inbound traffic to a set of pods. Only pods with the label 'app: frontend' in the same namespace should be allowed to reach the pods on TCP port 8080. Which resource should be used?

Accepted Answer

NetworkPolicy. NetworkPolicy is the correct resource because it is a Kubernetes-native object that defines how groups of pods are allowed to communicate with each other and other network endpoints. By specifying a pod selector matching 'app: frontend' and an ingress rule allowing TCP port 8080, you can restrict inbound traffic to only those pods with that label in the same namespace.

Answer

Ingress

Answer

PodSecurityPolicy

Answer

ServiceAccount

Question 3

A pod has resource requests of 512Mi memory and 500m CPU, and limits of 1Gi memory and 1 CPU. The node has 4Gi memory and 2 CPU cores. If the pod tries to use 700m CPU, what will happen?

Accepted Answer

The pod will be allowed to use 700m CPU. The pod's CPU request is 500m, and its CPU limit is 1 CPU (1000m). When the pod attempts to use 700m CPU, it is below the limit of 1000m, so it is allowed to burst up to that amount. Kubernetes uses the CPU request for scheduling and the limit for throttling; since 700m is within the limit, no throttling occurs. The pod is not evicted or terminated because it has not exceeded its memory limit or violated any resource constraints.

Answer

The pod will be throttled to 500m CPU

Answer

The pod will be evicted from the node

Answer

The pod will be terminated for exceeding the limit

Question 4

A pod uses a ServiceAccount that has a RoleBinding to a Role with 'get', 'list', 'watch' on 'pods'. The pod tries to list pods in the same namespace. Will the request succeed?

Accepted Answer

Yes, because the Role grants 'list' on pods. In Kubernetes RBAC, permissions are additive. The Role grants 'list' on pods, so the ServiceAccount can list pods. There is no deny rule; RBAC is deny by default, but the permission is explicitly granted. Option A is incorrect because there is no deny rule for pods. Option C is incorrect because a ServiceAccount can list pods if it has the appropriate RBAC permissions. Option D is incorrect because a ClusterRoleBinding is not required; a RoleBinding in the same namespace is sufficient.

Answer

No, because there is a deny rule for pods

Answer

No, because ServiceAccount cannot list pods

Answer

Yes, but only if the ServiceAccount also has a ClusterRoleBinding

Question 5

Which TWO statements about containers compared to virtual machines are correct? (Select 2)

Accepted Answer

Containers have lower overhead than virtual machines. Options A and B are correct. Containers have lower overhead than virtual machines because they do not require a separate guest OS per instance, making them more lightweight. Containers share the host OS kernel, which allows them to be efficient and portable. In contrast, each virtual machine includes a full guest OS running on top of a hypervisor, leading to higher resource usage. Option C is false because virtual machines have their own kernel, not shared with the host. Option D is false because containers share the host kernel and do not run their own OS kernel. Option E is false because virtual machines provide stronger isolation due to hardware virtualization.

Answer

Virtual machines share the host OS kernel

Answer

Each container runs its own operating system kernel

Answer

Virtual machines provide weaker isolation than containers

Question 6

Which THREE are benefits of using a container orchestration platform? (Select 3)

Accepted Answer

Declarative configuration management. Options B, C, and E are correct. Declarative configuration management (B) allows you to define the desired state and the platform ensures it. Automated scaling based on demand (C) adjusts resources automatically. High availability through automatic failover (E) ensures minimal downtime. Option A is incorrect—orchestration does not guarantee zero downtime. Option D is incorrect—orchestration does not eliminate the need for infrastructure.

Answer

Guarantees zero downtime during deployments

Answer

Eliminates the need for cloud infrastructure

Question 7

Which TWO statements about the Container Runtime Interface (CRI) are correct? (Select 2)

Accepted Answer

CRI allows Kubernetes to use different container runtimes. The Container Runtime Interface (CRI) is a plugin interface that enables kubelet to use a variety of container runtimes without needing to recompile Kubernetes. It defines the API between kubelet and the container runtime, allowing runtimes like containerd and CRI-O to be swapped in seamlessly. This abstraction decouples Kubernetes from any single runtime, enabling flexibility and vendor neutrality.

Answer

Docker is the primary CRI implementation

Answer

CRI is responsible for pulling container images

Answer

CRI is an OCI specification

Question 8

What is a primary benefit of using containers over virtual machines?

Accepted Answer

Containers are lightweight and share the host OS kernel. Containers virtualize at the operating system level, sharing the host OS kernel while running in isolated user-space instances. This eliminates the need for a full guest OS per workload, making containers significantly more lightweight in terms of memory, disk usage, and startup time compared to virtual machines, which each require a separate kernel and hypervisor.

Answer

Containers provide stronger isolation than VMs

Answer

Containers can run any operating system kernel

Answer

Containers require a hypervisor to run

Question 9

Which Kubernetes component is responsible for maintaining the desired state of the cluster?

Accepted Answer

Deployment controller. The Deployment controller is a core Kubernetes controller that runs as part of the kube-controller-manager. It continuously watches the cluster's current state via the API server and reconciles it with the desired state defined in Deployment objects, ensuring the correct number of Pod replicas are running, updated, and available. This makes it the primary component responsible for maintaining the desired state of the cluster for stateless workloads.

Answer

kube-proxy

Answer

kubelet

Answer

etcd

Question 10

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

Accepted Answer

To allow kubelet to communicate with different container runtimes. The Container Runtime Interface (CRI) is a plugin interface that enables the kubelet to use a variety of container runtimes without needing to recompile the Kubernetes components. It defines the API for creating, starting, stopping, and deleting containers, allowing the kubelet to communicate with runtimes like containerd, CRI-O, or Docker (via dockershim, now deprecated). Option D is correct because the CRI's primary purpose is to abstract the runtime implementation from the kubelet, enabling interoperability.

Answer

To manage container networking

Answer

To define a standard for container images

Answer

To orchestrate multi-container pods

Question 11

A Pod is stuck in 'Pending' state. Which command is most helpful to diagnose the issue?

Accepted Answer

kubectl describe pod my-pod. 'kubectl describe pod my-pod' provides detailed information about the pod's current state, including events, conditions, and resource constraints. When a pod is stuck in 'Pending', it typically means the scheduler cannot place it on a node due to issues like insufficient CPU/memory, persistent volume claims not being bound, or node selector mismatches. The 'describe' command surfaces these specific reasons in the 'Events' section and 'Conditions' field, making it the most direct diagnostic tool.

Answer

kubectl logs my-pod

Answer

kubectl get events

Answer

kubectl top pod my-pod

Question 12

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

Accepted Answer

Job. A Job is the correct Kubernetes resource for running a batch process that executes a finite task (e.g., processing a queue) and then terminates. Unlike controllers that maintain a desired state indefinitely, a Job creates one or more Pods and ensures they run to successful completion, after which the Job itself completes and no further Pods are created.

Answer

Deployment

Answer

DaemonSet

Answer

StatefulSet

Question 13

What is the difference between a liveness probe and a readiness probe?

Accepted Answer

Liveness probe indicates if the container is alive; if it fails, the container is restarted. A liveness probe determines if a container is still running (alive). If the liveness probe fails, Kubernetes restarts the container based on the `restartPolicy`. This is distinct from a readiness probe, which checks if a container is ready to accept traffic and removes it from Service endpoints if it fails.

Answer

Liveness probe checks if the container is ready to serve traffic

Answer

Readiness probe indicates if the container is healthy; liveness indicates if it should be restarted

Answer

Both probes serve the same purpose but with different endpoints

Question 14

You want to ensure that a Pod runs on every Node in the cluster. Which resource should you use?

Accepted Answer

DaemonSet. A DaemonSet ensures that a copy of a Pod runs on every Node in the cluster, including when new Nodes are added. This is the correct resource for cluster-wide services like log collectors, monitoring agents, or kube-proxy, as it automatically schedules a Pod on each Node and respects node taints and tolerations.

Answer

Deployment

Answer

ReplicaSet

Answer

StatefulSet

Question 15

A Service of type ClusterIP is created for a Deployment, but Pods in other namespaces cannot reach it. What is the most likely cause?

Accepted Answer

The Pods in other namespaces are using the short Service name without the namespace suffix. The most likely cause is that Pods in other namespaces are using the short Service name (e.g., `my-service`) without appending the namespace suffix (e.g., `my-service.other-namespace.svc.cluster.local`). Kubernetes DNS resolves short names only within the same namespace; cross-namespace resolution requires the fully qualified domain name (FQDN) or at least the `..svc` form. Without this, the DNS lookup fails, making the Service unreachable from other namespaces.

Answer

NetworkPolicies are blocking cross-namespace traffic

Answer

The Service is not publishing the correct port

Answer

The Service selector does not match the Pod labels