Kubernetes and Cloud Native Associate KCNA Practice Test 17
Question 160
A platform engineer recommends: Inspect application latency and request traces alongside resource health. The original problem is: Users report timeouts but basic kubectl Pod phase reports Running for every workload. Which concept explains the remedy?
- An OOM termination indicates a breached memory boundary or node memory pressure
- Traffic routing and Pod lifecycle transitions must be coordinated during delivery
- Name-resolution caching can outlive endpoint or service changes in some clients
- A Running Pod indicates process state rather than end-to-end service success
Explanation
Correct Answer
D:A Running Pod indicates process state rather than end-to-end service success. That principle directly explains the selected remediation, inspect application latency and request traces alongside resource health, for this case. Without the distinction, relying on Pod phase alone can conceal saturation or failed dependencies. The expected confirmation is that a trace identifies the slow dependency and recovery reduces user latency.
Incorrect Answers
A:An OOM termination indicates a breached memory boundary or node memory pressure. The operation “An OOM termination indicates a breached memory boundary or node memory pressure” does not address the particular Kubernetes requirement “A Running Pod indicates process state rather than end-to-end service success”.
B:Traffic routing and Pod lifecycle transitions must be coordinated during delivery. The operation “Traffic routing and Pod lifecycle transitions must be coordinated during delivery” does not address the particular Kubernetes requirement “A Running Pod indicates process state rather than end-to-end service success”.
C: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 “A Running Pod indicates process state rather than end-to-end service success”.
Question 161
In the situation "A dashboard shows millions of unique metric series after user IDs were added as labels", the team applies "Replace unbounded identifiers with low-cardinality metric labels". Which outcome is the strongest verification?
- Series count falls while aggregate service-level signals remain available
- One trace spans services and links the error to relevant logs and metrics
- A controlled user-impact regression pages on-call while short harmless spikes do not
- A shared collector receives usable traces and metrics from multiple service runtimes
Explanation
Correct Answer
A:Series count falls while aggregate service-level signals remain available. This is stronger than observing a saved configuration because it tests the actual outcome of replace unbounded identifiers with low-cardinality metric labels. The underlying principle is that high-cardinality labels increase time-series storage and query pressure. The original risk was that putting a unique customer ID in every metric series can exhaust monitoring resources.
Incorrect Answers
B:Metrics summarize quantities while logs and traces provide event and request context. The observation “One trace spans services and links the error to relevant logs and metrics” would validate that property, rather than the required “Series count falls while aggregate service-level signals remain available”. High-cardinality labels increase time-series storage and query pressure.
C:Actionable alerting links signals to service health and response decisions. The observation “A controlled user-impact regression pages on-call while short harmless spikes do not” would validate that property, rather than the required “Series count falls while aggregate service-level signals remain available”. High-cardinality labels increase time-series storage and query pressure.
D:OpenTelemetry standardizes telemetry generation and transport across languages. The observation “A shared collector receives usable traces and metrics from multiple service runtimes” would validate that property, rather than the required “Series count falls while aggregate service-level signals remain available”. High-cardinality labels increase time-series storage and query pressure.
Question 162
For this Kubernetes condition, A cluster configuration should always match reviewed content in a Git repository. The proposed approach is: Implement GitOps reconciliation using an approved controller such as Flux or Argo CD. Which technical principle BEST supports that choice?
- Helm templates Kubernetes resources and tracks packaged release revisions
- GitOps uses declared source-control desired state with automated convergence
- Readiness probes control endpoint eligibility independently of process status
- Rolling updates progressively replace Pods while controlling replacement availability
Explanation
Correct Answer
B:GitOps uses declared source-control desired state with automated convergence. That principle directly explains the selected remediation, implement GitOps reconciliation using an approved controller such as Flux or Argo CD, for this case. Without the distinction, permanent manual edits can cause configuration drift from the approved repository. The expected confirmation is that a reviewed commit is reconciled and unauthorized live drift is corrected.
Incorrect Answers
A: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 “GitOps uses declared source-control desired state with automated convergence”.
C:Readiness probes control endpoint eligibility independently of process status. The operation “Readiness probes control endpoint eligibility independently of process status” does not address the particular Kubernetes requirement “GitOps uses declared source-control desired state with automated convergence”.
D:Rolling updates progressively replace Pods while controlling replacement availability. The operation “Rolling updates progressively replace Pods while controlling replacement availability” does not address the particular Kubernetes requirement “GitOps uses declared source-control desired state with automated convergence”.
Question 163
A platform engineer recommends: Use portable OCI images and standard Kubernetes APIs where practical. The original problem is: A platform team wants the same app to operate across compliant container runtimes and clusters. Which concept explains the remedy?
- Serverless and event-driven designs can suit intermittent work but have operational tradeoffs
- Elastic systems can adjust replica capacity according to demand and policy
- Open standards reduce unnecessary vendor coupling across cloud-native infrastructure
- Cloud-native architecture often favors independently deployable components with clear boundaries
Explanation
Correct Answer
C:Open standards reduce unnecessary vendor coupling across cloud-native infrastructure. That principle directly explains the selected remediation, use portable OCI images and standard Kubernetes APIs where practical, for this case. Without the distinction, dependence on an undocumented provider-specific API can make migration difficult. The expected confirmation is that the workload runs on two compliant environments using the same core manifest.
Incorrect Answers
A:Serverless and event-driven designs can suit intermittent work but have operational tradeoffs. The operation “Serverless and event-driven designs can suit intermittent work but have operational tradeoffs” does not address the particular Kubernetes requirement “Open standards reduce unnecessary vendor coupling across cloud-native infrastructure”.
B:Elastic systems can adjust replica capacity according to demand and policy. The operation “Elastic systems can adjust replica capacity according to demand and policy” does not address the particular Kubernetes requirement “Open standards reduce unnecessary vendor coupling across cloud-native infrastructure”.
D:Cloud-native architecture often favors independently deployable components with clear boundaries. The operation “Cloud-native architecture often favors independently deployable components with clear boundaries” does not address the particular Kubernetes requirement “Open standards reduce unnecessary vendor coupling across cloud-native infrastructure”.
Question 164
In the situation "A newly deployed app cannot attach a PersistentVolumeClaim and stays Pending", the team applies "Inspect PVC binding status, StorageClass, and volume topology events". Which outcome is the strongest verification?
- A corrected configuration stabilizes the container with no further restarts
- A valid tagged digest pulls and the container enters Running state
- Node disk pressure clears and replacement Pods remain scheduled
- The claim becomes Bound and the workload mounts the intended volume
Explanation
Correct Answer
D:The claim becomes Bound and the workload mounts the intended volume. This is stronger than observing a saved configuration because it tests the actual outcome of inspect PVC binding status, StorageClass, and volume topology events. The underlying principle is that unbound storage claims or topology conflicts can block workload readiness. The original risk was that changing the container command will not provision an unavailable volume.
Incorrect Answers
A:CrashLoopBackOff reflects repeated container start failures with increasing delay. The observation “A corrected configuration stabilizes the container with no further restarts” would validate that property, rather than the required “The claim becomes Bound and the workload mounts the intended volume”. Unbound storage claims or topology conflicts can block workload readiness.
B: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 “The claim becomes Bound and the workload mounts the intended volume”. Unbound storage claims or topology conflicts can block workload readiness.
C:Node resource pressure can trigger Pod eviction independent of application exit codes. The observation “Node disk pressure clears and replacement Pods remain scheduled” would validate that property, rather than the required “The claim becomes Bound and the workload mounts the intended volume”. Unbound storage claims or topology conflicts can block workload readiness.
Question 165
For this Kubernetes condition, A Pod is Evicted from a node where disk usage is near exhaustion. The proposed approach is: Inspect node-pressure conditions and reclaim appropriate ephemeral storage. Which technical principle BEST supports that choice?
- Node resource pressure can trigger Pod eviction independent of application exit codes
- CrashLoopBackOff reflects repeated container start failures with increasing delay
- Readiness failures remove unready containers from normal Service routing
- Startup probes protect slow initialization from premature liveness restarts
Explanation
Correct Answer
A:Node resource pressure can trigger Pod eviction independent of application exit codes. That principle directly explains the selected remediation, inspect node-pressure conditions and reclaim appropriate ephemeral storage, for this case. Without the distinction, restarting every Evicted Pod without fixing disk pressure perpetuates churn. The expected confirmation is that node disk pressure clears and replacement Pods remain scheduled.
Incorrect Answers
B:CrashLoopBackOff reflects repeated container start failures with increasing delay. The operation “CrashLoopBackOff reflects repeated container start failures with increasing delay” does not address the particular Kubernetes requirement “Node resource pressure can trigger Pod eviction independent of application exit codes”.
C:Readiness failures remove unready containers from normal Service routing. The operation “Readiness failures remove unready containers from normal Service routing” does not address the particular Kubernetes requirement “Node resource pressure can trigger Pod eviction independent of application exit codes”.
D:Startup probes protect slow initialization from premature liveness restarts. The operation “Startup probes protect slow initialization from premature liveness restarts” does not address the particular Kubernetes requirement “Node resource pressure can trigger Pod eviction independent of application exit codes”.
Question 166
The team has not corrected this condition: A Node reports container runtime errors while the control-plane scheduler is healthy. Which risk is MOST relevant?
- Launching only a short-lived setup script can cause repeated restarts
- Fixing the API server cannot replace a missing node container runtime
- Running migrations and serving requests concurrently risks startup races
- Changing the last Dockerfile command will not erase a previously leaked credential
Explanation
Correct Answer
B:Fixing the API server cannot replace a missing node container runtime. This is the direct concern in the stated scenario because kubernetes uses the Container Runtime Interface to coordinate container execution. The matching mitigation is to inspect the node's CRI-compatible runtime service and kubelet connection. Successful verification would show that runtime health recovers and the assigned Pod successfully starts.
Incorrect Answers
A:Container lifecycle normally follows its primary process state. That explains the warning “Launching only a short-lived setup script can cause repeated restarts”; this case instead concerns “Fixing the API server cannot replace a missing node container runtime”. Kubernetes uses the Container Runtime Interface to coordinate container execution.
C:Init containers complete sequentially before ordinary application containers start. That explains the warning “Running migrations and serving requests concurrently risks startup races”; this case instead concerns “Fixing the API server cannot replace a missing node container runtime”. Kubernetes uses the Container Runtime Interface to coordinate container execution.
D:Image history and published layers may expose secrets even when files are deleted later. That explains the warning “Changing the last Dockerfile command will not erase a previously leaked credential”; this case instead concerns “Fixing the API server cannot replace a missing node container runtime”. Kubernetes uses the Container Runtime Interface to coordinate container execution.
Question 167
In the situation "A stateless Pod writes invoices to its local filesystem and they vanish after rescheduling", the team applies "Store durable application data on a PersistentVolumeClaim or managed external storage". Which outcome is the strongest verification?
- A test VolumeSnapshot restores the expected dataset to a new claim
- The containers share temporary files and replacement starts with a clean directory
- The invoice survives deletion and recreation of its original Pod
- Capacity grows and prior data remains readable after resizing
Explanation
Correct Answer
C:The invoice survives deletion and recreation of its original Pod. This is stronger than observing a saved configuration because it tests the actual outcome of store durable application data on a PersistentVolumeClaim or managed external storage. The underlying principle is that pod writable layers are ephemeral and do not guarantee persistence across replacement. The original risk was that rescheduling can lose files not written to durable storage.
Incorrect Answers
A:Kubernetes snapshots require compatible snapshot controller and CSI support. The observation “A test VolumeSnapshot restores the expected dataset to a new claim” would validate that property, rather than the required “The invoice survives deletion and recreation of its original Pod”. Pod writable layers are ephemeral and do not guarantee persistence across replacement.
B: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 invoice survives deletion and recreation of its original Pod”. Pod writable layers are ephemeral and do not guarantee persistence across replacement.
D: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 invoice survives deletion and recreation of its original Pod”. Pod writable layers are ephemeral and do not guarantee persistence across replacement.
Question 168
A Kubernetes platform team observes this situation: A dashboard needs extra human-readable incident ownership attached to workloads. Which action BEST addresses the requirement?
- Use the Kubernetes API server rather than editing etcd or node files directly
- Inspect CoreDNS and the namespace-aware Service DNS naming rules
- Place tightly coupled containers in one Pod with explicit volume sharing
- Store nonidentifying descriptive metadata in annotations rather than selectors
Explanation
Correct Answer
D:Store nonidentifying descriptive metadata in annotations rather than selectors. This is appropriate for the described asset and control gap because annotations hold auxiliary object information that need not identify selection groups. If the issue is left untreated, using mutable ticket text as a Service selector can disconnect endpoints. An assessor can verify remediation when the ownership annotation changes without modifying the selected backend set.
Incorrect Answers
A:Use the Kubernetes API server rather than editing etcd or node files directly. The operation “Use the Kubernetes API server rather than editing etcd or node files directly” does not address the particular Kubernetes requirement “Store nonidentifying descriptive metadata in annotations rather than selectors”.
B: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 “Store nonidentifying descriptive metadata in annotations rather than selectors”.
C:Place tightly coupled containers in one Pod with explicit volume sharing. The operation “Place tightly coupled containers in one Pod with explicit volume sharing” does not address the particular Kubernetes requirement “Store nonidentifying descriptive metadata in annotations rather than selectors”.
Question 169
A cloud-native operations team faces this condition: A public client must reach a cloud-hosted Kubernetes HTTP service through managed load balancing. Which response is MOST appropriate?
- Configure a supported LoadBalancer Service or Gateway controller for the platform
- Select a ClusterIP Service and match it to the intended backend Pods
- Use a headless Service and stable StatefulSet DNS identities
- Verify the cluster's Container Network Interface implementation and inter-node routes
Explanation
Correct Answer
A:Configure a supported LoadBalancer Service or Gateway controller for the platform. This is appropriate for the described asset and control gap because loadBalancer Services integrate with a compatible provider to provision external traffic access. If the issue is left untreated, creating a ClusterIP alone cannot allocate a public load-balancer address. An assessor can verify remediation when the provider assigns an approved endpoint that reaches ready backends.
Incorrect Answers
B:Select a ClusterIP Service and match it to the intended backend Pods. The operation “Select a ClusterIP Service and match it to the intended backend Pods” does not address the particular Kubernetes requirement “Configure a supported LoadBalancer Service or Gateway controller for the platform”.
C:Use a headless Service and stable StatefulSet DNS identities. The operation “Use a headless Service and stable StatefulSet DNS identities” does not address the particular Kubernetes requirement “Configure a supported LoadBalancer Service or Gateway controller for the platform”.
D:Verify the cluster's Container Network Interface implementation and inter-node routes. The operation “Verify the cluster's Container Network Interface implementation and inter-node routes” does not address the particular Kubernetes requirement “Configure a supported LoadBalancer Service or Gateway controller for the platform”.
Question 170
Given the requirement "A database cluster needs durable network identities and ordered replica creation", the proposed fix is "Use a StatefulSet with stable identity and persistent storage design". Which principle explains why it works?
- Secrets represent sensitive data objects but require additional RBAC and storage protection
- StatefulSets preserve ordered identity for Pods in stateful applications
- etcd holds persistent Kubernetes API object state for the control plane
- The kubelet ensures assigned Pod specifications are carried out by node runtimes
Explanation
Correct Answer
B:StatefulSets preserve ordered identity for Pods in stateful applications. That principle directly explains the selected remediation, use a StatefulSet with stable identity and persistent storage design, for this case. Without the distinction, a stateless Deployment can reshuffle names and make stable peer discovery difficult. The expected confirmation is that replica identities remain predictable through controlled rollout and rescheduling.
Incorrect Answers
A:Secrets represent sensitive data objects but require additional RBAC and storage protection. The operation “Secrets represent sensitive data objects but require additional RBAC and storage protection” does not address the particular Kubernetes requirement “StatefulSets preserve ordered identity for Pods in stateful applications”.
C:Etcd holds persistent Kubernetes API object state for the control plane. The operation “etcd holds persistent Kubernetes API object state for the control plane” does not address the particular Kubernetes requirement “StatefulSets preserve ordered identity for Pods in stateful applications”.
D:The kubelet ensures assigned Pod specifications are carried out by node runtimes. The operation “The kubelet ensures assigned Pod specifications are carried out by node runtimes” does not address the particular Kubernetes requirement “StatefulSets preserve ordered identity for Pods in stateful applications”.
