Kubernetes and Cloud Native Associate KCNA Practice Test 31
Question 300
For this Kubernetes condition, An administrator wants to examine only workloads belonging to the payments namespace. The proposed approach is: Use a namespace-scoped kubectl query with the explicit namespace flag. Which technical principle BEST supports that choice?
- Namespace quotas constrain aggregate API resource consumption
- Cluster management is expressed primarily through versioned API objects
- Deployment revision history supports rollback of Pod-template changes
- Namespaced API queries avoid mixing identical resource names from other teams
Explanation
Correct Answer
D:Namespaced API queries avoid mixing identical resource names from other teams. That principle directly explains the selected remediation, use a namespace-scoped kubectl query with the explicit namespace flag, for this case. Without the distinction, running an unrestricted query can lead to changing the wrong team's workload. The expected confirmation is that the command returns only payments resources and excludes other namespaces.
Incorrect Answers
A:Namespace quotas constrain aggregate API resource consumption. The operation “Namespace quotas constrain aggregate API resource consumption” does not address the particular Kubernetes requirement “Namespaced API queries avoid mixing identical resource names from other teams”.
B:Cluster management is expressed primarily through versioned API objects. The operation “Cluster management is expressed primarily through versioned API objects” does not address the particular Kubernetes requirement “Namespaced API queries avoid mixing identical resource names from other teams”.
C:Deployment revision history supports rollback of Pod-template changes. The operation “Deployment revision history supports rollback of Pod-template changes” does not address the particular Kubernetes requirement “Namespaced API queries avoid mixing identical resource names from other teams”.
Question 301
A platform engineer recommends: Compare Service selectors with the actual Pod labels and ownership. The original problem is: A Service routes requests to an unrelated workload after an application migration. Which concept explains the remedy?
- Label selectors determine which eligible Pods become Service endpoints
- A Deployment reconciles ReplicaSets to maintain desired stateless workload capacity
- The scheduler assigns unscheduled Pods to feasible nodes based on constraints
- The API server validates requests and exposes the supported declarative control interface
Explanation
Correct Answer
A:Label selectors determine which eligible Pods become Service endpoints. That principle directly explains the selected remediation, compare Service selectors with the actual Pod labels and ownership, for this case. Without the distinction, careless broad labels may send production traffic to an unintended backend. The expected confirmation is that endpointSlices contain only the matching and intended application Pod addresses.
Incorrect Answers
B:A Deployment reconciles ReplicaSets to maintain desired stateless workload capacity. The operation “A Deployment reconciles ReplicaSets to maintain desired stateless workload capacity” does not address the particular Kubernetes requirement “Label selectors determine which eligible Pods become Service endpoints”.
C:The scheduler assigns unscheduled Pods to feasible nodes based on constraints. The operation “The scheduler assigns unscheduled Pods to feasible nodes based on constraints” does not address the particular Kubernetes requirement “Label selectors determine which eligible Pods become Service endpoints”.
D:The API server validates requests and exposes the supported declarative control interface. The operation “The API server validates requests and exposes the supported declarative control interface” does not address the particular Kubernetes requirement “Label selectors determine which eligible Pods become Service endpoints”.
Question 302
An operator notices this unresolved gap: An app requires scratch storage shared by two containers but no long-term persistence. What consequence BEST explains the need to address it?
- Rescheduling can lose files not written to durable storage
- Relying on emptyDir for customer records loses data when the Pod is removed
- A Bound claim alone does not prove a successful node-level mount
- Hardcoding a host path ties data availability to one worker node
Explanation
Correct Answer
B:Relying on emptyDir for customer records loses data when the Pod is removed. This is the direct concern in the stated scenario because emptyDir storage lives for a Pod's lifetime and is shared by its containers. The matching mitigation is to mount an emptyDir volume with suitable resource limits in their common Pod. Successful verification would show that the containers share temporary files and replacement starts with a clean directory.
Incorrect Answers
A:Pod writable layers are ephemeral and do not guarantee persistence across replacement. That explains the warning “Rescheduling can lose files not written to durable storage”; this case instead concerns “Relying on emptyDir for customer records loses data when the Pod is removed”. EmptyDir storage lives for a Pod's lifetime and is shared by its containers.
C:CSI drivers integrate vendor storage provisioning and mounting with Kubernetes. That explains the warning “A Bound claim alone does not prove a successful node-level mount”; this case instead concerns “Relying on emptyDir for customer records loses data when the Pod is removed”. EmptyDir storage lives for a Pod's lifetime and is shared by its containers.
D:PersistentVolumeClaims request storage independently of physical volume provisioning. That explains the warning “Hardcoding a host path ties data availability to one worker node”; this case instead concerns “Relying on emptyDir for customer records loses data when the Pod is removed”. EmptyDir storage lives for a Pod's lifetime and is shared by its containers.
Question 303
For this Kubernetes condition, An alert fires on every harmless CPU spike and overwhelms the on-call team. The proposed approach is: Alert on meaningful sustained user impact and tune severity and routing. Which technical principle BEST supports that choice?
- Metrics summarize quantities while logs and traces provide event and request context
- Distributed tracing requires correlation propagation to connect spans across boundaries
- Actionable alerting links signals to service health and response decisions
- OpenTelemetry standardizes telemetry generation and transport across languages
Explanation
Correct Answer
C:Actionable alerting links signals to service health and response decisions. That principle directly explains the selected remediation, alert on meaningful sustained user impact and tune severity and routing, for this case. Without the distinction, noisy threshold alerts create fatigue and can hide real incidents. The expected confirmation is that a controlled user-impact regression pages on-call while short harmless spikes do not.
Incorrect Answers
A:Metrics summarize quantities while logs and traces provide event and request context. The operation “Metrics summarize quantities while logs and traces provide event and request context” does not address the particular Kubernetes requirement “Actionable alerting links signals to service health and response decisions”.
B:Distributed tracing requires correlation propagation to connect spans across boundaries. The operation “Distributed tracing requires correlation propagation to connect spans across boundaries” does not address the particular Kubernetes requirement “Actionable alerting links signals to service health and response decisions”.
D:OpenTelemetry standardizes telemetry generation and transport across languages. The operation “OpenTelemetry standardizes telemetry generation and transport across languages” does not address the particular Kubernetes requirement “Actionable alerting links signals to service health and response decisions”.
Question 304
A platform engineer recommends: Use a blue-green strategy with a validated traffic-switch operation. The original problem is: Two complete application environments should alternate traffic during approved releases. Which concept explains the remedy?
- Kubernetes sends shutdown signals and allows bounded cleanup before forced stop
- Rolling updates progressively replace Pods while controlling replacement availability
- Release tooling preserves revisions that support controlled restoration
- Blue-green releases keep separate old and new environments during cutover
Explanation
Correct Answer
D:Blue-green releases keep separate old and new environments during cutover. That principle directly explains the selected remediation, use a blue-green strategy with a validated traffic-switch operation, for this case. Without the distinction, switching before validating the new environment can redirect all traffic to faults. The expected confirmation is that the traffic switch is reversible and end-to-end smoke tests pass.
Incorrect Answers
A:Kubernetes sends shutdown signals and allows bounded cleanup before forced stop. The operation “Kubernetes sends shutdown signals and allows bounded cleanup before forced stop” does not address the particular Kubernetes requirement “Blue-green releases keep separate old and new environments during cutover”.
B: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 “Blue-green releases keep separate old and new environments during cutover”.
C:Release tooling preserves revisions that support controlled restoration. The operation “Release tooling preserves revisions that support controlled restoration” does not address the particular Kubernetes requirement “Blue-green releases keep separate old and new environments during cutover”.
Question 305
In the situation "Several product teams share a cluster and must scope ordinary object names separately", the team applies "Place their workloads in appropriate namespaces and assign scoped access". Which outcome is the strongest verification?
- Two teams can use the same Deployment name without colliding across namespaces
- Each eligible node reports exactly one healthy agent Pod
- An isolated restoration recovers expected objects from a verified etcd snapshot
- The controller recreates missing desired objects after service restoration
Explanation
Correct Answer
A:Two teams can use the same Deployment name without colliding across namespaces. This is stronger than observing a saved configuration because it tests the actual outcome of place their workloads in appropriate namespaces and assign scoped access. The underlying principle is that namespaces partition names and policy scope for namespaced Kubernetes resources. The original risk was that putting every resource in default creates collisions and weak administration boundaries.
Incorrect Answers
B:DaemonSets maintain a designated Pod copy on every selected node. The observation “Each eligible node reports exactly one healthy agent Pod” would validate that property, rather than the required “Two teams can use the same Deployment name without colliding across namespaces”. Namespaces partition names and policy scope for namespaced Kubernetes resources.
C:Etcd holds persistent Kubernetes API object state for the control plane. The observation “An isolated restoration recovers expected objects from a verified etcd snapshot” would validate that property, rather than the required “Two teams can use the same Deployment name without colliding across namespaces”. Namespaces partition names and policy scope for namespaced Kubernetes resources.
D:Kubernetes controllers continually compare observed state to declared desired state. The observation “The controller recreates missing desired objects after service restoration” would validate that property, rather than the required “Two teams can use the same Deployment name without colliding across namespaces”. Namespaces partition names and policy scope for namespaced Kubernetes resources.
Question 306
A Kubernetes platform team observes this situation: A scheduler assigns Pods based on requests but users expect it to react to live utilization by itself. Which action BEST addresses the requirement?
- Check ResourceQuota usage and the Pod's requested resources
- Use suitable autoscaling or descheduling components rather than assuming automatic migrations
- Assign controlled PriorityClasses to workloads according to service importance
- Use topology spread constraints with the proper topology key and skew
Explanation
Correct Answer
B:Use suitable autoscaling or descheduling components rather than assuming automatic migrations. This is appropriate for the described asset and control gap because default placement is not continuous live-CPU load balancing among healthy nodes. If the issue is left untreated, leaving workloads to drift can create hotspots after initial scheduling. An assessor can verify remediation when measured autoscaling changes intended replica capacity without forced random migrations.
Incorrect Answers
A: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 “Use suitable autoscaling or descheduling components rather than assuming automatic migrations”.
C:Assign controlled PriorityClasses to workloads according to service importance. The operation “Assign controlled PriorityClasses to workloads according to service importance” does not address the particular Kubernetes requirement “Use suitable autoscaling or descheduling components rather than assuming automatic migrations”.
D:Use topology spread constraints with the proper topology key and skew. The operation “Use topology spread constraints with the proper topology key and skew” does not address the particular Kubernetes requirement “Use suitable autoscaling or descheduling components rather than assuming automatic migrations”.
Question 307
The platform team applies this control: Inspect the CronJob's created Jobs, deadlines, and logs separately. The original issue is: A scheduled task fails intermittently but the long-running application Pod is healthy. 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
- The failed Job records an actionable reason and the next run succeeds
- The image download succeeds after correcting the registered pull credential
Explanation
Correct Answer
C:The failed Job records an actionable reason and the next run succeeds. This is stronger than observing a saved configuration because it tests the actual outcome of inspect the CronJob's created Jobs, deadlines, and logs separately. The underlying principle is that recurring task execution is tracked through Job and CronJob objects. The original risk was that monitoring only Deployments can miss failed scheduled business processes.
Incorrect Answers
A:Service networking requires matching endpoints and correct destination ports. The observation “The Service has ready endpoints and test requests reach the target container port” would validate that property, rather than the required “The failed Job records an actionable reason and the next run succeeds”. Recurring task execution is tracked through Job and CronJob objects.
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 failed Job records an actionable reason and the next run succeeds”. Recurring task execution is tracked through Job and CronJob objects.
D:Container retrieval requires valid credentials before the process can launch. The observation “The image download succeeds after correcting the registered pull credential” would validate that property, rather than the required “The failed Job records an actionable reason and the next run succeeds”. Recurring task execution is tracked through Job and CronJob objects.
Question 308
An operator notices this unresolved gap: A Deployment's actual replica count stays below its declared number after a failure. What consequence BEST explains the need to address it?
- Using mutable ticket text as a Service selector can disconnect endpoints
- Mistaking base64 representation for encryption can expose credentials to readers
- Clients targeting individual ephemeral Pod addresses will break after replacement
- Without functioning reconciliation a missing replica can remain absent indefinitely
Explanation
Correct Answer
D:Without functioning reconciliation a missing replica can remain absent indefinitely. This is the direct concern in the stated scenario because kubernetes controllers continually compare observed state to declared desired state. The matching mitigation is to investigate controller-manager reconciliation and relevant resource conditions. Successful verification would show that the controller recreates missing desired objects after service restoration.
Incorrect Answers
A:Annotations hold auxiliary object information that need not identify selection groups. That explains the warning “Using mutable ticket text as a Service selector can disconnect endpoints”; this case instead concerns “Without functioning reconciliation a missing replica can remain absent indefinitely”. Kubernetes controllers continually compare observed state to declared desired state.
B:Secrets represent sensitive data objects but require additional RBAC and storage protection. That explains the warning “Mistaking base64 representation for encryption can expose credentials to readers”; this case instead concerns “Without functioning reconciliation a missing replica can remain absent indefinitely”. Kubernetes controllers continually compare observed state to declared desired state.
C:A Service provides a stable virtual endpoint decoupled from changing Pod addresses. That explains the warning “Clients targeting individual ephemeral Pod addresses will break after replacement”; this case instead concerns “Without functioning reconciliation a missing replica can remain absent indefinitely”. Kubernetes controllers continually compare observed state to declared desired state.
Question 309
For this Kubernetes condition, A crashing container exits before an engineer can read its most recent startup output. The proposed approach is: Retrieve the prior terminated container logs using the appropriate kubectl option. Which technical principle BEST supports that choice?
- kubectl logs can request output from the previous container instance
- Kubernetes service accounts provide workload identity within API authorization
- Draining uses the eviction workflow to prepare nodes for maintenance
- Automation should bind every Kubernetes command to its intended target environment
Explanation
Correct Answer
A:kubectl logs can request output from the previous container instance. That principle directly explains the selected remediation, retrieve the prior terminated container logs using the appropriate kubectl option, for this case. Without the distinction, reading only current logs may miss the failure message from a restarted process. The expected confirmation is that the recovered previous log contains the relevant startup exception.
Incorrect Answers
B:Kubernetes service accounts provide workload identity within API authorization. The operation “Kubernetes service accounts provide workload identity within API authorization” does not address the particular Kubernetes requirement “kubectl logs can request output from the previous container instance”.
C:Draining uses the eviction workflow to prepare nodes for maintenance. The operation “Draining uses the eviction workflow to prepare nodes for maintenance” does not address the particular Kubernetes requirement “kubectl logs can request output from the previous container instance”.
D:Automation should bind every Kubernetes command to its intended target environment. The operation “Automation should bind every Kubernetes command to its intended target environment” does not address the particular Kubernetes requirement “kubectl logs can request output from the previous container instance”.
Question 310
The team has not corrected this condition: A support engineer must reproduce a container fault without adding debugging tools to the production image. Which risk is MOST relevant?
- Assuming a completed image push means runtime readiness conceals deployment defects
- Installing tools inside the running container causes untracked deployment mutation
- Removing endpoints too late or starting them too early can cause cutover errors
- Restarting identical faulty images cannot repair a deterministic regression
Explanation
Correct Answer
B:Installing tools inside the running container causes untracked deployment mutation. This is the direct concern in the stated scenario because ephemeral troubleshooting separates observation tooling from the release artifact. The matching mitigation is to use an approved ephemeral debug container with captured evidence and minimal privileges. Successful verification would show that the debug session identifies the fault while the original image digest remains unchanged.
Incorrect Answers
A:Delivery debugging begins with resource status and failure conditions. That explains the warning “Assuming a completed image push means runtime readiness conceals deployment defects”; this case instead concerns “Installing tools inside the running container causes untracked deployment mutation”. Ephemeral troubleshooting separates observation tooling from the release artifact.
C:Traffic routing and Pod lifecycle transitions must be coordinated during delivery. That explains the warning “Removing endpoints too late or starting them too early can cause cutover errors”; this case instead concerns “Installing tools inside the running container causes untracked deployment mutation”. Ephemeral troubleshooting separates observation tooling from the release artifact.
D:Version-aware troubleshooting isolates failures introduced by specific changes. That explains the warning “Restarting identical faulty images cannot repair a deterministic regression”; this case instead concerns “Installing tools inside the running container causes untracked deployment mutation”. Ephemeral troubleshooting separates observation tooling from the release artifact.
