Kubernetes and Cloud Native Associate KCNA Practice Test 49
Question 480
A team implemented the proposed remedy for this problem: A Node reports container runtime errors while the control-plane scheduler is healthy. Which evidence BEST shows it works?
- Image inventory lists only required runtime packages after rebuild
- Uploaded files remain accessible after a complete Pod replacement
- A verified image inspection finds no secrets and the exposed credential is rotated
- Runtime health recovers and the assigned Pod successfully starts
Explanation
Correct Answer
D:Runtime health recovers and the assigned Pod successfully starts. This is stronger than observing a saved configuration because it tests the actual outcome of inspect the node's CRI-compatible runtime service and kubelet connection. The underlying principle is that kubernetes uses the Container Runtime Interface to coordinate container execution. The original risk was that fixing the API server cannot replace a missing node container runtime.
Incorrect Answers
A:Reducing unneeded image contents reduces exposed packages and maintenance cost. The observation “Image inventory lists only required runtime packages after rebuild” would validate that property, rather than the required “Runtime health recovers and the assigned Pod successfully starts”. Kubernetes uses the Container Runtime Interface to coordinate container execution.
B:Container writable filesystems are ephemeral across replacement and rescheduling. The observation “Uploaded files remain accessible after a complete Pod replacement” would validate that property, rather than the required “Runtime health recovers and the assigned Pod successfully starts”. Kubernetes uses the Container Runtime Interface to coordinate container execution.
C:Image history and published layers may expose secrets even when files are deleted later. The observation “A verified image inspection finds no secrets and the exposed credential is rotated” would validate that property, rather than the required “Runtime health recovers and the assigned Pod successfully starts”. Kubernetes uses the Container Runtime Interface to coordinate container execution.
Question 481
A cloud-native operations team faces this condition: Multiple HTTP applications need hostname and path routing behind one controlled entry point. Which response is MOST appropriate?
- Configure Gateway API or a supported Ingress controller with matching routes
- Select a ClusterIP Service and match it to the intended backend Pods
- Confirm dual-stack address families and supported Service IP family policy
- Use application TLS or an approved mesh policy for required encrypted connections
Explanation
Correct Answer
A:Configure Gateway API or a supported Ingress controller with matching routes. This is appropriate for the described asset and control gap because hTTP routing objects require a working controller to implement actual data-plane behavior. If the issue is left untreated, writing an Ingress object without its controller produces no effective routing. An assessor can verify remediation when requests for each host and path reach only its designated Service.
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 Gateway API or a supported Ingress controller with matching routes”.
C:Confirm dual-stack address families and supported Service IP family policy. The operation “Confirm dual-stack address families and supported Service IP family policy” does not address the particular Kubernetes requirement “Configure Gateway API or a supported Ingress controller with matching routes”.
D:Use application TLS or an approved mesh policy for required encrypted connections. The operation “Use application TLS or an approved mesh policy for required encrypted connections” does not address the particular Kubernetes requirement “Configure Gateway API or a supported Ingress controller with matching routes”.
Question 482
Consider this Kubernetes scenario: A cluster has multiple priorities and urgent system Pods need preemption protection. What is the BEST next action?
- Use appropriate Pod affinity matching the collaborating workload labels
- Assign controlled PriorityClasses to workloads according to service importance
- Combine required node affinity with the correct tolerations for the isolated pool
- Use a nodeSelector or required node affinity matching that label
Explanation
Correct Answer
B:Assign controlled PriorityClasses to workloads according to service importance. This is appropriate for the described asset and control gap because priority influences scheduling order and can affect lower-priority eviction. If the issue is left untreated, giving every business Pod system-level priority defeats meaningful preemption. An assessor can verify remediation when an urgent essential Pod gains resources while lower-priority capacity is displaced.
Incorrect Answers
A:Use appropriate Pod affinity matching the collaborating workload labels. The operation “Use appropriate Pod affinity matching the collaborating workload labels” does not address the particular Kubernetes requirement “Assign controlled PriorityClasses to workloads according to service importance”.
C:Combine required node affinity with the correct tolerations for the isolated pool. The operation “Combine required node affinity with the correct tolerations for the isolated pool” does not address the particular Kubernetes requirement “Assign controlled PriorityClasses to workloads according to service importance”.
D:Use a nodeSelector or required node affinity matching that label. The operation “Use a nodeSelector or required node affinity matching that label” does not address the particular Kubernetes requirement “Assign controlled PriorityClasses to workloads according to service importance”.
Question 483
A Kubernetes platform team observes this situation: Two tightly coupled applications should be placed near one another for low latency. Which action BEST addresses the requirement?
- Apply required Pod anti-affinity using a node topology key
- Review memory limits against peak needs and adjust efficient application behavior
- Use appropriate Pod affinity matching the collaborating workload labels
- Use suitable autoscaling or descheduling components rather than assuming automatic migrations
Explanation
Correct Answer
C:Use appropriate Pod affinity matching the collaborating workload labels. This is appropriate for the described asset and control gap because pod affinity can make placements depend on other matching Pods in topology domains. If the issue is left untreated, selecting a node label does not necessarily colocate with the intended application. An assessor can verify remediation when the collaborating Pods run within the expected topology relationship.
Incorrect Answers
A:Apply required Pod anti-affinity using a node topology key. The operation “Apply required Pod anti-affinity using a node topology key” does not address the particular Kubernetes requirement “Use appropriate Pod affinity matching the collaborating workload labels”.
B:Review memory limits against peak needs and adjust efficient application behavior. The operation “Review memory limits against peak needs and adjust efficient application behavior” does not address the particular Kubernetes requirement “Use appropriate Pod affinity matching the collaborating workload labels”.
D:Use suitable autoscaling or descheduling components rather than assuming automatic migrations. The operation “Use suitable autoscaling or descheduling components rather than assuming automatic migrations” does not address the particular Kubernetes requirement “Use appropriate Pod affinity matching the collaborating workload labels”.
Question 484
A platform engineer recommends: Check DNS policy, resolv.conf, CoreDNS Pod health, and network reachability. The original problem is: A Pod cannot resolve any cluster Service though its container and network interface are healthy. Which concept explains the remedy?
- Ephemeral containers can supply troubleshooting tools without rebuilding application images
- CrashLoopBackOff reflects repeated container start failures with increasing delay
- Node Ready conditions summarize whether the node can safely host workloads
- Kubernetes name resolution depends on DNS service and Pod resolver configuration
Explanation
Correct Answer
D:Kubernetes name resolution depends on DNS service and Pod resolver configuration. That principle directly explains the selected remediation, check DNS policy, resolv.conf, CoreDNS Pod health, and network reachability, for this case. Without the distinction, changing application service ports will not repair broken DNS lookups. The expected confirmation is that a Pod successfully resolves both short and qualified Service names.
Incorrect Answers
A:Ephemeral containers can supply troubleshooting tools without rebuilding application images. The operation “Ephemeral containers can supply troubleshooting tools without rebuilding application images” does not address the particular Kubernetes requirement “Kubernetes name resolution depends on DNS service and Pod resolver configuration”.
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 “Kubernetes name resolution depends on DNS service and Pod resolver configuration”.
C:Node Ready conditions summarize whether the node can safely host workloads. The operation “Node Ready conditions summarize whether the node can safely host workloads” does not address the particular Kubernetes requirement “Kubernetes name resolution depends on DNS service and Pod resolver configuration”.
Question 485
An operator notices this unresolved gap: Deleting a Deployment leaves owned child resources unexpectedly pending deletion. What consequence BEST explains the need to address it?
- Blindly deleting finalizers may bypass resource cleanup responsibilities
- A stateless Deployment can reshuffle names and make stable peer discovery difficult
- Manually creating independent Pods provides no reliable replica reconciliation
- Careless broad labels may send production traffic to an unintended backend
Explanation
Correct Answer
A:Blindly deleting finalizers may bypass resource cleanup responsibilities. This is the direct concern in the stated scenario because kubernetes garbage collection uses owner references while finalizers can delay removal. The matching mitigation is to inspect owner references and finalizers before forcing orphan cleanup. Successful verification would show that an approved cleanup clears blockers and owned resources are removed safely.
Incorrect Answers
B:StatefulSets preserve ordered identity for Pods in stateful applications. That explains the warning “A stateless Deployment can reshuffle names and make stable peer discovery difficult”; this case instead concerns “Blindly deleting finalizers may bypass resource cleanup responsibilities”. Kubernetes garbage collection uses owner references while finalizers can delay removal.
C:A Deployment reconciles ReplicaSets to maintain desired stateless workload capacity. That explains the warning “Manually creating independent Pods provides no reliable replica reconciliation”; this case instead concerns “Blindly deleting finalizers may bypass resource cleanup responsibilities”. Kubernetes garbage collection uses owner references while finalizers can delay removal.
D:Label selectors determine which eligible Pods become Service endpoints. That explains the warning “Careless broad labels may send production traffic to an unintended backend”; this case instead concerns “Blindly deleting finalizers may bypass resource cleanup responsibilities”. Kubernetes garbage collection uses owner references while finalizers can delay removal.
Question 486
A Kubernetes platform team observes this situation: A Service routes requests to an unrelated workload after an application migration. Which action BEST addresses the requirement?
- Reference a Kubernetes Secret with least-privilege access and encryption-at-rest policy
- Compare Service selectors with the actual Pod labels and ownership
- Investigate node service-proxy or equivalent dataplane implementation
- Supply nonsecret configuration through a ConfigMap and suitable Pod reference
Explanation
Correct Answer
B:Compare Service selectors with the actual Pod labels and ownership. This is appropriate for the described asset and control gap because label selectors determine which eligible Pods become Service endpoints. If the issue is left untreated, careless broad labels may send production traffic to an unintended backend. An assessor can verify remediation when endpointSlices contain only the matching and intended application Pod addresses.
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 “Compare Service selectors with the actual Pod labels and ownership”.
C:Investigate node service-proxy or equivalent dataplane implementation. The operation “Investigate node service-proxy or equivalent dataplane implementation” does not address the particular Kubernetes requirement “Compare Service selectors with the actual Pod labels and ownership”.
D:Supply nonsecret configuration through a ConfigMap and suitable Pod reference. The operation “Supply nonsecret configuration through a ConfigMap and suitable Pod reference” does not address the particular Kubernetes requirement “Compare Service selectors with the actual Pod labels and ownership”.
Question 487
A cloud-native operations team faces this condition: A namespace administrator wants to ensure a particular app never receives host-network access. Which response is MOST appropriate?
- Enable encryption at rest and secure backups alongside fine-grained RBAC
- Use supported short-lived projected service-account tokens with audience restrictions
- Set admission guardrails and validate workload Pod specifications against policy
- Configure supported Pod Security Admission labels and verify enforcement levels
Explanation
Correct Answer
C:Set admission guardrails and validate workload Pod specifications against policy. This is appropriate for the described asset and control gap because host networking increases the impact of insecure workloads and bypasses Pod isolation assumptions. If the issue is left untreated, an app with unrestricted host networking can expose host-level network services. An assessor can verify remediation when a negative admission test blocks hostNetwork on the target namespace.
Incorrect Answers
A:Enable encryption at rest and secure backups alongside fine-grained RBAC. The operation “Enable encryption at rest and secure backups alongside fine-grained RBAC” does not address the particular Kubernetes requirement “Set admission guardrails and validate workload Pod specifications against policy”.
B:Use supported short-lived projected service-account tokens with audience restrictions. The operation “Use supported short-lived projected service-account tokens with audience restrictions” does not address the particular Kubernetes requirement “Set admission guardrails and validate workload Pod specifications against policy”.
D:Configure supported Pod Security Admission labels and verify enforcement levels. The operation “Configure supported Pod Security Admission labels and verify enforcement levels” does not address the particular Kubernetes requirement “Set admission guardrails and validate workload Pod specifications against policy”.
Question 488
Given the requirement "A team needs to combine a common base manifest with different namespace settings", the proposed fix is "Use Kustomize overlays or equivalent declarative environment customization". Which principle explains why it works?
- Delivery gates use measured user outcomes to decide whether to continue rollout
- Continuous delivery can require approvals without conflating deployment with building
- Mixed-version rolling deployments require old and new software to tolerate shared data schema
- Configuration overlays allow controlled differences without copying complete manifests
Explanation
Correct Answer
D:Configuration overlays allow controlled differences without copying complete manifests. That principle directly explains the selected remediation, use Kustomize overlays or equivalent declarative environment customization, for this case. Without the distinction, duplicating entire YAML files creates inconsistent security and probe settings. The expected confirmation is that each environment renders the same base with only documented overrides.
Incorrect Answers
A: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 “Configuration overlays allow controlled differences without copying complete manifests”.
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 “Configuration overlays allow controlled differences without copying complete manifests”.
C:Mixed-version rolling deployments require old and new software to tolerate shared data schema. The operation “Mixed-version rolling deployments require old and new software to tolerate shared data schema” does not address the particular Kubernetes requirement “Configuration overlays allow controlled differences without copying complete manifests”.
Question 489
For this Kubernetes condition, A scheduled task fails intermittently but the long-running application Pod is healthy. The proposed approach is: Inspect the CronJob's created Jobs, deadlines, and logs separately. Which technical principle BEST supports that choice?
- Recurring task execution is tracked through Job and CronJob objects
- Distributed services require selecting the affected execution instance
- A Running Pod indicates process state rather than end-to-end service success
- Node-local dataplane or runtime problems can affect only a subset of replicas
Explanation
Correct Answer
A:Recurring task execution is tracked through Job and CronJob objects. That principle directly explains the selected remediation, inspect the CronJob's created Jobs, deadlines, and logs separately, for this case. Without the distinction, monitoring only Deployments can miss failed scheduled business processes. The expected confirmation is that the failed Job records an actionable reason and the next run succeeds.
Incorrect Answers
B:Distributed services require selecting the affected execution instance. The operation “Distributed services require selecting the affected execution instance” does not address the particular Kubernetes requirement “Recurring task execution is tracked through Job and CronJob objects”.
C:A Running Pod indicates process state rather than end-to-end service success. The operation “A Running Pod indicates process state rather than end-to-end service success” does not address the particular Kubernetes requirement “Recurring task execution is tracked through Job and CronJob objects”.
D:Node-local dataplane or runtime problems can affect only a subset of replicas. The operation “Node-local dataplane or runtime problems can affect only a subset of replicas” does not address the particular Kubernetes requirement “Recurring task execution is tracked through Job and CronJob objects”.
Question 490
The platform team applies this control: Compare Deployment conditions, Pod events, and readiness failures before promotion. The original issue is: A Deployment revision rolls out but a subset of Pods never reach Ready state. Which observation BEST validates the result?
- The Service has ready endpoints and test requests reach the target container port
- A corrected Pod passes readiness and rollout status becomes Complete
- Tests isolate one affected worker and service recovers after node remediation
- The failed Job records an actionable reason and the next run succeeds
Explanation
Correct Answer
B:A corrected Pod passes readiness and rollout status becomes Complete. This is stronger than observing a saved configuration because it tests the actual outcome of compare Deployment conditions, Pod events, and readiness failures before promotion. The underlying principle is that delivery debugging begins with resource status and failure conditions. The original risk was that assuming a completed image push means runtime readiness conceals deployment defects.
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 “A corrected Pod passes readiness and rollout status becomes Complete”. Delivery debugging begins with resource status and failure conditions.
C:Node-local dataplane or runtime problems can affect only a subset of replicas. The observation “Tests isolate one affected worker and service recovers after node remediation” would validate that property, rather than the required “A corrected Pod passes readiness and rollout status becomes Complete”. Delivery debugging begins with resource status and failure conditions.
D:Recurring task execution is tracked through Job and CronJob objects. The observation “The failed Job records an actionable reason and the next run succeeds” would validate that property, rather than the required “A corrected Pod passes readiness and rollout status becomes Complete”. Delivery debugging begins with resource status and failure conditions.
