Kubernetes Fundamentals

A cluster administrator needs a log-collection agent to run on every node, including any new node that later joins the cluster, with exactly one copy of the agent per node. Which Kubernetes workload object is purpose-built to guarantee one Pod on each node automatically?

• AA Deployment, because it keeps a fixed number of identical Pod replicas running across the cluster
• BA StatefulSet, because it gives each Pod a stable network identity tied to a specific node
• CA Job, because it runs one Pod per node until each completes its task
• DA DaemonSet, because it schedules one copy of the Pod onto every eligible node and onto new nodes as they joincheck_circle Correct

Why A is wrong: A Deployment maintains a chosen replica count and lets the scheduler place those Pods anywhere, so it is tempting for any 'run this everywhere' need, but it cannot guarantee one Pod per node and will not react to new nodes joining.

Why B is wrong: A StatefulSet provides ordered, stably named Pods for stateful apps, which sounds node-related, but its replica count is fixed and its Pods are not placed one-per-node, so it does not track node membership.

Why C is wrong: A Job runs Pods to completion for batch work, which can feel like a per-node task, but it targets a completion count rather than node coverage and does not maintain a long-running agent on every node.

Why D is correct: A DaemonSet ensures each eligible node runs exactly one copy of the Pod, and it automatically adds a Pod to any node that later joins, which is precisely the node-agent pattern described.

A newly created Pod is accepted by the cluster but sits with no node assigned to it. Which control plane component is responsible for watching for such unscheduled Pods and choosing a suitable node for each one?

• Akube-controller-manager, which runs controllers that create replica Pods but does not select the node those Pods land on
• Bkube-scheduler, which watches for Pods that have no assigned node and binds each to a feasible node using resource requests and constraintscheck_circle Correct
• Ckubelet, which starts a Pod's containers only after a node has already been chosen for that Pod
• Dkube-apiserver, which validates the Pod object and stores it but leaves node selection to another component

Why A is wrong: Tempting because this component does drive Pod creation through controllers such as the ReplicaSet controller, but it delegates placement entirely and never binds a Pod to a node.

Why B is correct: Correct because the scheduler's sole job is to watch for unscheduled Pods and select a node that satisfies resource requests, affinity, and other constraints, then record the binding.

Why C is wrong: Tempting because the kubelet is what actually runs the Pod, but it acts on Pods already bound to its own node and plays no part in choosing the node.

Why D is wrong: Tempting because every Pod passes through the API server first, but it only persists the object and serves the API; it does not decide placement.

A cluster administrator wants a group of nodes to refuse ordinary Pods and accept only Pods that have been explicitly marked as permitted, so the nodes stay reserved for one special workload. Which mechanism is designed to let nodes repel Pods that do not carry a matching marker?

• AA nodeSelector added to every ordinary Pod in the cluster
• BPod anti-affinity declared between the special and ordinary workloads
• CTaints applied to the nodes, with matching tolerations on the permitted Podscheck_circle Correct
• DResource limits set on the containers running on the reserved nodes

Why A is wrong: A nodeSelector attracts a Pod to labelled nodes, so it is easily confused with placement control, but it acts from the Pod side and cannot make a node reject Pods that do not opt out, leaving the nodes unprotected from unmarked Pods.

Why B is wrong: Anti-affinity spreads Pods away from each other based on Pod labels, which sounds like repelling, but it governs Pod-to-Pod placement rather than reserving nodes, so ordinary Pods could still land on the nodes when the special Pods are absent.

Why C is correct: A taint on a node repels any Pod that lacks a matching toleration, so only Pods carrying the toleration are allowed to schedule there, which reserves the nodes for the intended workload.

Why D is wrong: Resource limits cap how much CPU and memory a container may use at runtime, which feels related to node control, but they neither influence which node is chosen nor stop other Pods from scheduling onto the nodes.

A platform team wants to swap the container runtime their kubelet talks to without changing kubelet code, choosing between containerd and CRI-O. Which standard defines the API the kubelet uses to manage Pods and containers on a node, making runtimes interchangeable?

• AThe Container Runtime Interface (CRI), a gRPC API the kubelet calls to run and manage Pods and containerscheck_circle Correct
• BThe Container Network Interface (CNI), which standardises how runtimes attach Pods to a network
• CThe Container Storage Interface (CSI), which standardises how runtimes mount volumes into containers
• DThe OCI runtime specification, which the kubelet calls directly to create each container process

Why A is correct: CRI is the gRPC contract the kubelet speaks, so any runtime that implements it (containerd, CRI-O) is interchangeable behind the kubelet without kubelet changes.

Why B is wrong: CNI is a real, kubelet-adjacent standard that is easy to confuse with CRI by name, but it governs network attachment for Pods, not the API the kubelet uses to create and manage containers.

Why C is wrong: CSI is a genuine Kubernetes interface and shares the same 'C-I' naming pattern, but it standardises storage volume provisioning and mounting, not the kubelet-to-runtime container lifecycle API.

Why D is wrong: The OCI runtime spec is real and sits below the runtime, but the kubelet does not call it directly; it calls CRI, and the runtime in turn uses an OCI runtime such as runc.

A team keeps their Kubernetes resource definitions as YAML files in version control and wants one command that creates the resources if they are absent and updates them to match the files if they already exist, without deleting and recreating them. Which kubectl command follows this declarative approach?

• Akubectl create
• Bkubectl replace
• Ckubectl applycheck_circle Correct
• Dkubectl edit

Why A is wrong: Tempting because it also builds resources from a file, but create is imperative and fails when the object already exists, so it cannot update resources to match the files.

Why B is wrong: Tempting because it updates existing objects, but replace requires the resource to already exist and overwrites the whole object rather than merging, so it is not the declarative create-or-update command.

Why C is correct: Correct: apply reconciles live objects toward the state described in the files, creating what is missing and merging changes into what exists, which is the declarative workflow.

Why D is wrong: Tempting because it modifies existing objects, but edit opens a live in-place editor for one object at a time rather than reconciling files stored in version control.