Kubernetes and Cloud Native Associate KCNA Practice Test 47
Question 460
The platform team applies this control: Compare node conditions, CNI health, DNS, and packet paths across workers. The original issue is: A critical service is intermittent only when traffic reaches one specific node. Which observation BEST validates the result?
- Memory profiling and adjusted limits remove the repeated OOM terminations
- The debug session identifies the fault while the original image digest remains unchanged
- The correlated failing request appears in logs from the affected replica
- Tests isolate one affected worker and service recovers after node remediation
Explanation
Correct Answer
D:Tests isolate one affected worker and service recovers after node remediation. This is stronger than observing a saved configuration because it tests the actual outcome of compare node conditions, CNI health, DNS, and packet paths across workers. The underlying principle is that node-local dataplane or runtime problems can affect only a subset of replicas. The original risk was that changing the global image tag may obscure a node-specific infrastructure issue.
Incorrect Answers
A:An OOM termination indicates a breached memory boundary or node memory pressure. The observation “Memory profiling and adjusted limits remove the repeated OOM terminations” would validate that property, rather than the required “Tests isolate one affected worker and service recovers after node remediation”. Node-local dataplane or runtime problems can affect only a subset of replicas.
B:Ephemeral troubleshooting separates observation tooling from the release artifact. The observation “The debug session identifies the fault while the original image digest remains unchanged” would validate that property, rather than the required “Tests isolate one affected worker and service recovers after node remediation”. Node-local dataplane or runtime problems can affect only a subset of replicas.
C:Distributed services require selecting the affected execution instance. The observation “The correlated failing request appears in logs from the affected replica” would validate that property, rather than the required “Tests isolate one affected worker and service recovers after node remediation”. Node-local dataplane or runtime problems can affect only a subset of replicas.
Question 461
Consider this Kubernetes scenario: A payment processing service needs a graceful shutdown during rolling replacement. What is the BEST next action?
- Configure termination handling and adequate termination grace period
- Implement a CI/CD promotion gate separating build, test, and release stages
- Use the versioned Deployment or delivery tool rollback workflow
- Package and manage shared resources through Helm charts with explicit values
Explanation
Correct Answer
A:Configure termination handling and adequate termination grace period. This is appropriate for the described asset and control gap because kubernetes sends shutdown signals and allows bounded cleanup before forced stop. If the issue is left untreated, immediate process termination can interrupt in-flight work or cause duplicate payment calls. An assessor can verify remediation when an update drains active requests before the previous Pod is removed.
Incorrect Answers
B:Implement a CI/CD promotion gate separating build, test, and release stages. The operation “Implement a CI/CD promotion gate separating build, test, and release stages” does not address the particular Kubernetes requirement “Configure termination handling and adequate termination grace period”.
C:Use the versioned Deployment or delivery tool rollback workflow. The operation “Use the versioned Deployment or delivery tool rollback workflow” does not address the particular Kubernetes requirement “Configure termination handling and adequate termination grace period”.
D:Package and manage shared resources through Helm charts with explicit values. The operation “Package and manage shared resources through Helm charts with explicit values” does not address the particular Kubernetes requirement “Configure termination handling and adequate termination grace period”.
Question 462
For this Kubernetes condition, A team enables a restrictive ingress policy but fails to document a required health-check caller. The proposed approach is: Add a precise rule for authenticated approved probe traffic while retaining default denial. Which technical principle BEST supports that choice?
- Pod Security Admission uses namespace-level modes such as enforce, audit, and warn
- Least-privilege network controls require enumerating all legitimate communication paths
- Admission controls can reject noncompliant resources before they are stored
- Bound tokens reduce exposure compared with indefinite reusable credentials
Explanation
Correct Answer
B:Least-privilege network controls require enumerating all legitimate communication paths. That principle directly explains the selected remediation, add a precise rule for authenticated approved probe traffic while retaining default denial, for this case. Without the distinction, a blanket untested deny can make healthy applications appear unavailable. The expected confirmation is that approved probes succeed and unrelated Pod-to-Pod connections remain rejected.
Incorrect Answers
A:Pod Security Admission uses namespace-level modes such as enforce, audit, and warn. The operation “Pod Security Admission uses namespace-level modes such as enforce, audit, and warn” does not address the particular Kubernetes requirement “Least-privilege network controls require enumerating all legitimate communication paths”.
C:Admission controls can reject noncompliant resources before they are stored. The operation “Admission controls can reject noncompliant resources before they are stored” does not address the particular Kubernetes requirement “Least-privilege network controls require enumerating all legitimate communication paths”.
D:Bound tokens reduce exposure compared with indefinite reusable credentials. The operation “Bound tokens reduce exposure compared with indefinite reusable credentials” does not address the particular Kubernetes requirement “Least-privilege network controls require enumerating all legitimate communication paths”.
Question 463
The platform team applies this control: Check the claim binding, CSI driver, node attachment, and event messages. The original issue is: A workload declares a PVC but its Pod never mounts the volume. Which observation BEST validates the result?
- The invoice survives deletion and recreation of its original Pod
- Capacity grows and prior data remains readable after resizing
- The Pod reports the mounted filesystem after the driver issue is fixed
- The containers share temporary files and replacement starts with a clean directory
Explanation
Correct Answer
C:The Pod reports the mounted filesystem after the driver issue is fixed. This is stronger than observing a saved configuration because it tests the actual outcome of check the claim binding, CSI driver, node attachment, and event messages. The underlying principle is that cSI drivers integrate vendor storage provisioning and mounting with Kubernetes. The original risk was that a Bound claim alone does not prove a successful node-level mount.
Incorrect Answers
A:Pod writable layers are ephemeral and do not guarantee persistence across replacement. The observation “The invoice survives deletion and recreation of its original Pod” would validate that property, rather than the required “The Pod reports the mounted filesystem after the driver issue is fixed”. CSI drivers integrate vendor storage provisioning and mounting with Kubernetes.
B:PVC expansion depends on driver support and filesystem resizing behavior. The observation “Capacity grows and prior data remains readable after resizing” would validate that property, rather than the required “The Pod reports the mounted filesystem after the driver issue is fixed”. CSI drivers integrate vendor storage provisioning and mounting with Kubernetes.
D:EmptyDir storage lives for a Pod's lifetime and is shared by its containers. The observation “The containers share temporary files and replacement starts with a clean directory” would validate that property, rather than the required “The Pod reports the mounted filesystem after the driver issue is fixed”. CSI drivers integrate vendor storage provisioning and mounting with Kubernetes.
Question 464
Given the requirement "A service container runs as root without a business justification", the proposed fix is "Run the container with an unprivileged UID and restricted capabilities". Which principle explains why it works?
- Image history and published layers may expose secrets even when files are deleted later
- Init containers complete sequentially before ordinary application containers start
- Pod-level co-location permits coordinated companion services and local networking
- Linux user and capability boundaries can constrain process privileges
Explanation
Correct Answer
D:Linux user and capability boundaries can constrain process privileges. That principle directly explains the selected remediation, run the container with an unprivileged UID and restricted capabilities, for this case. Without the distinction, default root privileges can widen impact after application compromise. The expected confirmation is that the process runs without root and cannot perform prohibited privileged actions.
Incorrect Answers
A:Image history and published layers may expose secrets even when files are deleted later. The operation “Image history and published layers may expose secrets even when files are deleted later” does not address the particular Kubernetes requirement “Linux user and capability boundaries can constrain process privileges”.
B:Init containers complete sequentially before ordinary application containers start. The operation “Init containers complete sequentially before ordinary application containers start” does not address the particular Kubernetes requirement “Linux user and capability boundaries can constrain process privileges”.
C:Pod-level co-location permits coordinated companion services and local networking. The operation “Pod-level co-location permits coordinated companion services and local networking” does not address the particular Kubernetes requirement “Linux user and capability boundaries can constrain process privileges”.
Question 465
For this Kubernetes condition, A payment processing service needs a graceful shutdown during rolling replacement. The proposed approach is: Configure termination handling and adequate termination grace period. Which technical principle BEST supports that choice?
- Kubernetes sends shutdown signals and allows bounded cleanup before forced stop
- Continuous delivery can require approvals without conflating deployment with building
- Helm templates Kubernetes resources and tracks packaged release revisions
- Delivery gates use measured user outcomes to decide whether to continue rollout
Explanation
Correct Answer
A:Kubernetes sends shutdown signals and allows bounded cleanup before forced stop. That principle directly explains the selected remediation, configure termination handling and adequate termination grace period, for this case. Without the distinction, immediate process termination can interrupt in-flight work or cause duplicate payment calls. The expected confirmation is that an update drains active requests before the previous Pod is removed.
Incorrect Answers
B:Continuous delivery can require approvals without conflating deployment with building. The operation “Continuous delivery can require approvals without conflating deployment with building” does not address the particular Kubernetes requirement “Kubernetes sends shutdown signals and allows bounded cleanup before forced stop”.
C:Helm templates Kubernetes resources and tracks packaged release revisions. The operation “Helm templates Kubernetes resources and tracks packaged release revisions” does not address the particular Kubernetes requirement “Kubernetes sends shutdown signals and allows bounded cleanup before forced stop”.
D:Delivery gates use measured user outcomes to decide whether to continue rollout. The operation “Delivery gates use measured user outcomes to decide whether to continue rollout” does not address the particular Kubernetes requirement “Kubernetes sends shutdown signals and allows bounded cleanup before forced stop”.
Question 466
A cloud-native operations team faces this condition: A Deployment revision rolls out but a subset of Pods never reach Ready state. Which response is MOST appropriate?
- Inspect application latency and request traces alongside resource health
- Compare Deployment conditions, Pod events, and readiness failures before promotion
- Inspect the CronJob's created Jobs, deadlines, and logs separately
- Use an approved ephemeral debug container with captured evidence and minimal privileges
Explanation
Correct Answer
B:Compare Deployment conditions, Pod events, and readiness failures before promotion. This is appropriate for the described asset and control gap because delivery debugging begins with resource status and failure conditions. If the issue is left untreated, assuming a completed image push means runtime readiness conceals deployment defects. An assessor can verify remediation when a corrected Pod passes readiness and rollout status becomes Complete.
Incorrect Answers
A:Inspect application latency and request traces alongside resource health. The operation “Inspect application latency and request traces alongside resource health” does not address the particular Kubernetes requirement “Compare Deployment conditions, Pod events, and readiness failures before promotion”.
C:Inspect the CronJob's created Jobs, deadlines, and logs separately. The operation “Inspect the CronJob's created Jobs, deadlines, and logs separately” does not address the particular Kubernetes requirement “Compare Deployment conditions, Pod events, and readiness failures before promotion”.
D:Use an approved ephemeral debug container with captured evidence and minimal privileges. The operation “Use an approved ephemeral debug container with captured evidence and minimal privileges” does not address the particular Kubernetes requirement “Compare Deployment conditions, Pod events, and readiness failures before promotion”.
Question 467
Consider this Kubernetes scenario: A scheduled task fails intermittently but the long-running application Pod is healthy. What is the BEST next action?
- Compare Deployment conditions, Pod events, and readiness failures before promotion
- Inspect readiness thresholds, shutdown behavior, and termination sequencing
- Inspect the CronJob's created Jobs, deadlines, and logs separately
- Correlate OOMKilled events with memory limits and workload allocation
Explanation
Correct Answer
C:Inspect the CronJob's created Jobs, deadlines, and logs separately. This is appropriate for the described asset and control gap because recurring task execution is tracked through Job and CronJob objects. If the issue is left untreated, monitoring only Deployments can miss failed scheduled business processes. An assessor can verify remediation when the failed Job records an actionable reason and the next run succeeds.
Incorrect Answers
A:Compare Deployment conditions, Pod events, and readiness failures before promotion. The operation “Compare Deployment conditions, Pod events, and readiness failures before promotion” does not address the particular Kubernetes requirement “Inspect the CronJob's created Jobs, deadlines, and logs separately”.
B:Inspect readiness thresholds, shutdown behavior, and termination sequencing. The operation “Inspect readiness thresholds, shutdown behavior, and termination sequencing” does not address the particular Kubernetes requirement “Inspect the CronJob's created Jobs, deadlines, and logs separately”.
D:Correlate OOMKilled events with memory limits and workload allocation. The operation “Correlate OOMKilled events with memory limits and workload allocation” does not address the particular Kubernetes requirement “Inspect the CronJob's created Jobs, deadlines, and logs separately”.
Question 468
A team implemented the proposed remedy for this problem: A Pod is too large for every node and priority preemption fails to fix it. Which evidence BEST shows it works?
- The namespace receives approved quota capacity and the Pod is admitted
- The container stays within a tested memory budget and avoids OOMKilled restarts
- Scheduling events clear and Pods land across correctly labeled topology groups
- The Pod fits the capacity of an eligible node and schedules without excess disruption
Explanation
Correct Answer
D:The Pod fits the capacity of an eligible node and schedules without excess disruption. This is stronger than observing a saved configuration because it tests the actual outcome of right-size its requests or provide a node pool with adequate allocatable capacity. The underlying principle is that preemption cannot create a sufficiently large node from several small nodes. The original risk was that evicting smaller Pods blindly may disrupt services without making room.
Incorrect Answers
A:Admission quota checks operate independently from node scheduling capacity. The observation “The namespace receives approved quota capacity and the Pod is admitted” would validate that property, rather than the required “The Pod fits the capacity of an eligible node and schedules without excess disruption”. Preemption cannot create a sufficiently large node from several small nodes.
B:Exceeding a container memory limit can trigger termination independent of CPU usage. The observation “The container stays within a tested memory budget and avoids OOMKilled restarts” would validate that property, rather than the required “The Pod fits the capacity of an eligible node and schedules without excess disruption”. Preemption cannot create a sufficiently large node from several small nodes.
C:Affinity decisions depend on consistent node topology-key labels. The observation “Scheduling events clear and Pods land across correctly labeled topology groups” would validate that property, rather than the required “The Pod fits the capacity of an eligible node and schedules without excess disruption”. Preemption cannot create a sufficiently large node from several small nodes.
Question 469
The platform team applies this control: Verify Service selector, endpoint readiness, port, and targetPort mappings. The original issue is: A new service is healthy locally but is unreachable through its cluster virtual Service. Which observation BEST validates the result?
- The Service has ready endpoints and test requests reach the target container port
- The debug session identifies the fault while the original image digest remains unchanged
- A rollout load test maintains successful responses during replacement
- The correlated failing request appears in logs from the affected replica
Explanation
Correct Answer
A:The Service has ready endpoints and test requests reach the target container port. This is stronger than observing a saved configuration because it tests the actual outcome of verify Service selector, endpoint readiness, port, and targetPort mappings. The underlying principle is that service networking requires matching endpoints and correct destination ports. The original risk was that increasing application replicas cannot fix a Service with no matched endpoints.
Incorrect Answers
B:Ephemeral troubleshooting separates observation tooling from the release artifact. The observation “The debug session identifies the fault while the original image digest remains unchanged” would validate that property, rather than the required “The Service has ready endpoints and test requests reach the target container port”. Service networking requires matching endpoints and correct destination ports.
C:Traffic routing and Pod lifecycle transitions must be coordinated during delivery. The observation “A rollout load test maintains successful responses during replacement” would validate that property, rather than the required “The Service has ready endpoints and test requests reach the target container port”. Service networking requires matching endpoints and correct destination ports.
D:Distributed services require selecting the affected execution instance. The observation “The correlated failing request appears in logs from the affected replica” would validate that property, rather than the required “The Service has ready endpoints and test requests reach the target container port”. Service networking requires matching endpoints and correct destination ports.
Question 470
Consider this Kubernetes scenario: Users report timeouts but basic kubectl Pod phase reports Running for every workload. What is the BEST next action?
- Inspect the CronJob's created Jobs, deadlines, and logs separately
- Inspect application latency and request traces alongside resource health
- Filter logs by namespace, labels, Pod identity, and relevant time range
- Inspect pull events and verify scoped imagePullSecret references and registry access
Explanation
Correct Answer
B:Inspect application latency and request traces alongside resource health. This is appropriate for the described asset and control gap because a Running Pod indicates process state rather than end-to-end service success. If the issue is left untreated, relying on Pod phase alone can conceal saturation or failed dependencies. An assessor can verify remediation when a trace identifies the slow dependency and recovery reduces user latency.
Incorrect Answers
A:Inspect the CronJob's created Jobs, deadlines, and logs separately. The operation “Inspect the CronJob's created Jobs, deadlines, and logs separately” does not address the particular Kubernetes requirement “Inspect application latency and request traces alongside resource health”.
C:Filter logs by namespace, labels, Pod identity, and relevant time range. The operation “Filter logs by namespace, labels, Pod identity, and relevant time range” does not address the particular Kubernetes requirement “Inspect application latency and request traces alongside resource health”.
D:Inspect pull events and verify scoped imagePullSecret references and registry access. The operation “Inspect pull events and verify scoped imagePullSecret references and registry access” does not address the particular Kubernetes requirement “Inspect application latency and request traces alongside resource health”.
