Kubernetes and Cloud Native Associate KCNA Practice Test 21
Question 200
In the situation "A controller needs one consistent entry point for creating and watching cluster objects", the team applies "Use the Kubernetes API server rather than editing etcd or node files directly". Which outcome is the strongest verification?
- Scheduler events identify a feasible node and the pending Pod becomes assigned
- Two teams can use the same Deployment name without colliding across namespaces
- Restoring the kubelet creates the intended containers on that worker
- A create request is accepted through the API and appears in resource listings
Explanation
Correct Answer
D:A create request is accepted through the API and appears in resource listings. This is stronger than observing a saved configuration because it tests the actual outcome of use the Kubernetes API server rather than editing etcd or node files directly. The underlying principle is that the API server validates requests and exposes the supported declarative control interface. The original risk was that writing cluster state through an unsupported path bypasses expected API safeguards.
Incorrect Answers
A:The scheduler assigns unscheduled Pods to feasible nodes based on constraints. The observation “Scheduler events identify a feasible node and the pending Pod becomes assigned” would validate that property, rather than the required “A create request is accepted through the API and appears in resource listings”. The API server validates requests and exposes the supported declarative control interface.
B:Namespaces partition names and policy scope for namespaced Kubernetes resources. The observation “Two teams can use the same Deployment name without colliding across namespaces” would validate that property, rather than the required “A create request is accepted through the API and appears in resource listings”. The API server validates requests and exposes the supported declarative control interface.
C:The kubelet ensures assigned Pod specifications are carried out by node runtimes. The observation “Restoring the kubelet creates the intended containers on that worker” would validate that property, rather than the required “A create request is accepted through the API and appears in resource listings”. The API server validates requests and exposes the supported declarative control interface.
Question 201
For this Kubernetes condition, A database's three replicas must avoid sharing the same physical worker. The proposed approach is: Apply required Pod anti-affinity using a node topology key. Which technical principle BEST supports that choice?
- Pod anti-affinity can keep matching Pods on separate topology domains
- Admission quota checks operate independently from node scheduling capacity
- Unsatisfied hard node affinity prevents scheduler placement despite free resources
- Preemption cannot create a sufficiently large node from several small nodes
Explanation
Correct Answer
A:Pod anti-affinity can keep matching Pods on separate topology domains. That principle directly explains the selected remediation, apply required Pod anti-affinity using a node topology key, for this case. Without the distinction, placing every replica on one node creates a single-node outage risk. The expected confirmation is that the replicas land on distinct nodes and survive failure of one worker.
Incorrect Answers
B:Admission quota checks operate independently from node scheduling capacity. The operation “Admission quota checks operate independently from node scheduling capacity” does not address the particular Kubernetes requirement “Pod anti-affinity can keep matching Pods on separate topology domains”.
C:Unsatisfied hard node affinity prevents scheduler placement despite free resources. The operation “Unsatisfied hard node affinity prevents scheduler placement despite free resources” does not address the particular Kubernetes requirement “Pod anti-affinity can keep matching Pods on separate topology domains”.
D:Preemption cannot create a sufficiently large node from several small nodes. The operation “Preemption cannot create a sufficiently large node from several small nodes” does not address the particular Kubernetes requirement “Pod anti-affinity can keep matching Pods on separate topology domains”.
Question 202
The platform team applies this control: Add a suitable liveness probe with safe thresholds for recovery. The original issue is: A process becomes stuck after initial startup yet Kubernetes never restarts it. Which observation BEST validates the result?
- A valid tagged digest pulls and the container enters Running state
- A controlled deadlock causes the kubelet to restart the container
- The claim becomes Bound and the workload mounts the intended volume
- The app finishes startup before normal liveness and readiness checks begin
Explanation
Correct Answer
B:A controlled deadlock causes the kubelet to restart the container. This is stronger than observing a saved configuration because it tests the actual outcome of add a suitable liveness probe with safe thresholds for recovery. The underlying principle is that liveness probes detect a running container that requires restart. The original risk was that a readiness probe alone only changes traffic eligibility and will not restart it.
Incorrect Answers
A:ImagePullBackOff often follows failed pulls or invalid registry authentication. The observation “A valid tagged digest pulls and the container enters Running state” would validate that property, rather than the required “A controlled deadlock causes the kubelet to restart the container”. Liveness probes detect a running container that requires restart.
C:Unbound storage claims or topology conflicts can block workload readiness. The observation “The claim becomes Bound and the workload mounts the intended volume” would validate that property, rather than the required “A controlled deadlock causes the kubelet to restart the container”. Liveness probes detect a running container that requires restart.
D:Startup probes protect slow initialization from premature liveness restarts. The observation “The app finishes startup before normal liveness and readiness checks begin” would validate that property, rather than the required “A controlled deadlock causes the kubelet to restart the container”. Liveness probes detect a running container that requires restart.
Question 203
Given the requirement "A critical service is intermittent only when traffic reaches one specific node", the proposed fix is "Compare node conditions, CNI health, DNS, and packet paths across workers". Which principle explains why it works?
- Version-aware troubleshooting isolates failures introduced by specific changes
- Ephemeral troubleshooting separates observation tooling from the release artifact
- Node-local dataplane or runtime problems can affect only a subset of replicas
- Name-resolution caching can outlive endpoint or service changes in some clients
Explanation
Correct Answer
C:Node-local dataplane or runtime problems can affect only a subset of replicas. That principle directly explains the selected remediation, compare node conditions, CNI health, DNS, and packet paths across workers, for this case. Without the distinction, changing the global image tag may obscure a node-specific infrastructure issue. The expected confirmation is that tests isolate one affected worker and service recovers after node remediation.
Incorrect Answers
A:Version-aware troubleshooting isolates failures introduced by specific changes. The operation “Version-aware troubleshooting isolates failures introduced by specific changes” does not address the particular Kubernetes requirement “Node-local dataplane or runtime problems can affect only a subset of replicas”.
B:Ephemeral troubleshooting separates observation tooling from the release artifact. The operation “Ephemeral troubleshooting separates observation tooling from the release artifact” does not address the particular Kubernetes requirement “Node-local dataplane or runtime problems can affect only a subset of replicas”.
D:Name-resolution caching can outlive endpoint or service changes in some clients. The operation “Name-resolution caching can outlive endpoint or service changes in some clients” does not address the particular Kubernetes requirement “Node-local dataplane or runtime problems can affect only a subset of replicas”.
Question 204
A team implemented the proposed remedy for this problem: A platform team wants a neutral venue for collaboration across competing cloud providers. Which evidence BEST shows it works?
- The change proposal is discussed in the correct SIG and receives documented review
- Compatibility tests pass against the scheduled release using documented migration guidance
- The evaluation records the actual current maturity and independent suitability evidence
- Multiple stakeholders participate through documented open community channels
Explanation
Correct Answer
D:Multiple stakeholders participate through documented open community channels. This is stronger than observing a saved configuration because it tests the actual outcome of evaluate CNCF community structures and Linux Foundation open governance principles. The underlying principle is that vendor-neutral communities can coordinate shared cloud-native standards and adoption. The original risk was that relying solely on one provider's private roadmap may increase dependency risk.
Incorrect Answers
A:Kubernetes development is organized through open governance and special interest groups. The observation “The change proposal is discussed in the correct SIG and receives documented review” would validate that property, rather than the required “Multiple stakeholders participate through documented open community channels”. Vendor-neutral communities can coordinate shared cloud-native standards and adoption.
B:Community release processes communicate API evolution and deprecation timelines. The observation “Compatibility tests pass against the scheduled release using documented migration guidance” would validate that property, rather than the required “Multiple stakeholders participate through documented open community channels”. Vendor-neutral communities can coordinate shared cloud-native standards and adoption.
C:CNCF maturity stages such as Sandbox, Incubating, and Graduated have distinct meanings. The observation “The evaluation records the actual current maturity and independent suitability evidence” would validate that property, rather than the required “Multiple stakeholders participate through documented open community channels”. Vendor-neutral communities can coordinate shared cloud-native standards and adoption.
Question 205
A cloud-native operations team faces this condition: A newly deployed app cannot attach a PersistentVolumeClaim and stays Pending. Which response is MOST appropriate?
- Inspect PVC binding status, StorageClass, and volume topology events
- Add a startup probe so liveness is deferred until startup completes
- Use a scoped kubectl port-forward session and terminate it after testing
- Use kubectl debug or a suitable ephemeral debug container where permitted
Explanation
Correct Answer
A:Inspect PVC binding status, StorageClass, and volume topology events. This is appropriate for the described asset and control gap because unbound storage claims or topology conflicts can block workload readiness. If the issue is left untreated, changing the container command will not provision an unavailable volume. An assessor can verify remediation when the claim becomes Bound and the workload mounts the intended volume.
Incorrect Answers
B:Add a startup probe so liveness is deferred until startup completes. The operation “Add a startup probe so liveness is deferred until startup completes” does not address the particular Kubernetes requirement “Inspect PVC binding status, StorageClass, and volume topology events”.
C:Use a scoped kubectl port-forward session and terminate it after testing. The operation “Use a scoped kubectl port-forward session and terminate it after testing” does not address the particular Kubernetes requirement “Inspect PVC binding status, StorageClass, and volume topology events”.
D:Use kubectl debug or a suitable ephemeral debug container where permitted. The operation “Use kubectl debug or a suitable ephemeral debug container where permitted” does not address the particular Kubernetes requirement “Inspect PVC binding status, StorageClass, and volume topology events”.
Question 206
Consider this Kubernetes scenario: A CPU-heavy Pod stays Pending even though a node shows low instantaneous usage. What is the BEST next action?
- Give the approved agent a matching toleration and restrict other workloads
- Inspect requested CPU and node allocatable resources before changing placement
- Check ResourceQuota usage and the Pod's requested resources
- Apply preferred node affinity with a documented scheduling weight
Explanation
Correct Answer
B:Inspect requested CPU and node allocatable resources before changing placement. This is appropriate for the described asset and control gap because the scheduler tests resource requests against node allocatable capacity. If the issue is left untreated, live CPU graphs alone cannot establish whether requested capacity fits. An assessor can verify remediation when scheduling events identify insufficient requested CPU and placement succeeds after adjustment.
Incorrect Answers
A:Give the approved agent a matching toleration and restrict other workloads. The operation “Give the approved agent a matching toleration and restrict other workloads” does not address the particular Kubernetes requirement “Inspect requested CPU and node allocatable resources before changing placement”.
C:Check ResourceQuota usage and the Pod's requested resources. The operation “Check ResourceQuota usage and the Pod's requested resources” does not address the particular Kubernetes requirement “Inspect requested CPU and node allocatable resources before changing placement”.
D:Apply preferred node affinity with a documented scheduling weight. The operation “Apply preferred node affinity with a documented scheduling weight” does not address the particular Kubernetes requirement “Inspect requested CPU and node allocatable resources before changing placement”.
Question 207
A Kubernetes platform team observes this situation: An application needs a changeable feature flag without rebuilding its container image. Which action BEST addresses the requirement?
- Reference a Kubernetes Secret with least-privilege access and encryption-at-rest policy
- Use a StatefulSet with stable identity and persistent storage design
- Supply nonsecret configuration through a ConfigMap and suitable Pod reference
- Inspect CoreDNS and the namespace-aware Service DNS naming rules
Explanation
Correct Answer
C:Supply nonsecret configuration through a ConfigMap and suitable Pod reference. This is appropriate for the described asset and control gap because configMaps separate ordinary configuration data from immutable image content. If the issue is left untreated, baking every environment setting into images creates configuration and release drift. An assessor can verify remediation when a deployment uses the configured flag after an appropriate Pod or mount update.
Incorrect Answers
A:Reference a Kubernetes Secret with least-privilege access and encryption-at-rest policy. The operation “Reference a Kubernetes Secret with least-privilege access and encryption-at-rest policy” does not address the particular Kubernetes requirement “Supply nonsecret configuration through a ConfigMap and suitable Pod reference”.
B:Use a StatefulSet with stable identity and persistent storage design. The operation “Use a StatefulSet with stable identity and persistent storage design” does not address the particular Kubernetes requirement “Supply nonsecret configuration through a ConfigMap and suitable Pod reference”.
D:Inspect CoreDNS and the namespace-aware Service DNS naming rules. The operation “Inspect CoreDNS and the namespace-aware Service DNS naming rules” does not address the particular Kubernetes requirement “Supply nonsecret configuration through a ConfigMap and suitable Pod reference”.
Question 208
The platform team applies this control: Use portable OCI images and standard Kubernetes APIs where practical. The original issue is: A platform team wants the same app to operate across compliant container runtimes and clusters. Which observation BEST validates the result?
- A clean environment rebuild recreates intended controls from approved versioned inputs
- A load test scales replicas within limits and meets performance targets
- An injected dependency outage produces bounded latency and graceful degradation
- The workload runs on two compliant environments using the same core manifest
Explanation
Correct Answer
D:The workload runs on two compliant environments using the same core manifest. This is stronger than observing a saved configuration because it tests the actual outcome of use portable OCI images and standard Kubernetes APIs where practical. The underlying principle is that open standards reduce unnecessary vendor coupling across cloud-native infrastructure. The original risk was that dependence on an undocumented provider-specific API can make migration difficult.
Incorrect Answers
A:Infrastructure as code and desired-state convergence support repeatability and auditability. The observation “A clean environment rebuild recreates intended controls from approved versioned inputs” would validate that property, rather than the required “The workload runs on two compliant environments using the same core manifest”. Open standards reduce unnecessary vendor coupling across cloud-native infrastructure.
B:Elastic systems can adjust replica capacity according to demand and policy. The observation “A load test scales replicas within limits and meets performance targets” would validate that property, rather than the required “The workload runs on two compliant environments using the same core manifest”. Open standards reduce unnecessary vendor coupling across cloud-native infrastructure.
C:Resilience patterns keep transient dependency faults from consuming all callers. The observation “An injected dependency outage produces bounded latency and graceful degradation” would validate that property, rather than the required “The workload runs on two compliant environments using the same core manifest”. Open standards reduce unnecessary vendor coupling across cloud-native infrastructure.
Question 209
Given the requirement "A Pod is too large for every node and priority preemption fails to fix it", the proposed fix is "Right-size its requests or provide a node pool with adequate allocatable capacity". Which principle explains why it works?
- Preemption cannot create a sufficiently large node from several small nodes
- Topology spread helps distribute matching Pods across failure domains
- Affinity decisions depend on consistent node topology-key labels
- Pod anti-affinity can keep matching Pods on separate topology domains
Explanation
Correct Answer
A:Preemption cannot create a sufficiently large node from several small nodes. That principle directly explains the selected remediation, right-size its requests or provide a node pool with adequate allocatable capacity, for this case. Without the distinction, evicting smaller Pods blindly may disrupt services without making room. The expected confirmation is that the Pod fits the capacity of an eligible node and schedules without excess disruption.
Incorrect Answers
B:Topology spread helps distribute matching Pods across failure domains. The operation “Topology spread helps distribute matching Pods across failure domains” does not address the particular Kubernetes requirement “Preemption cannot create a sufficiently large node from several small nodes”.
C:Affinity decisions depend on consistent node topology-key labels. The operation “Affinity decisions depend on consistent node topology-key labels” does not address the particular Kubernetes requirement “Preemption cannot create a sufficiently large node from several small nodes”.
D:Pod anti-affinity can keep matching Pods on separate topology domains. The operation “Pod anti-affinity can keep matching Pods on separate topology domains” does not address the particular Kubernetes requirement “Preemption cannot create a sufficiently large node from several small nodes”.
Question 210
For this Kubernetes condition, A cluster has multiple priorities and urgent system Pods need preemption protection. The proposed approach is: Assign controlled PriorityClasses to workloads according to service importance. Which technical principle BEST supports that choice?
- Hard placement constraints restrict eligible nodes through label matching
- Priority influences scheduling order and can affect lower-priority eviction
- Pod anti-affinity can keep matching Pods on separate topology domains
- Taints repel Pods while tolerations allow them to be considered for placement
Explanation
Correct Answer
B:Priority influences scheduling order and can affect lower-priority eviction. That principle directly explains the selected remediation, assign controlled PriorityClasses to workloads according to service importance, for this case. Without the distinction, giving every business Pod system-level priority defeats meaningful preemption. The expected confirmation is that an urgent essential Pod gains resources while lower-priority capacity is displaced.
Incorrect Answers
A:Hard placement constraints restrict eligible nodes through label matching. The operation “Hard placement constraints restrict eligible nodes through label matching” does not address the particular Kubernetes requirement “Priority influences scheduling order and can affect lower-priority eviction”.
C:Pod anti-affinity can keep matching Pods on separate topology domains. The operation “Pod anti-affinity can keep matching Pods on separate topology domains” does not address the particular Kubernetes requirement “Priority influences scheduling order and can affect lower-priority eviction”.
D:Taints repel Pods while tolerations allow them to be considered for placement. The operation “Taints repel Pods while tolerations allow them to be considered for placement” does not address the particular Kubernetes requirement “Priority influences scheduling order and can affect lower-priority eviction”.
