Kubernetes and Cloud Native Associate KCNA Practice Test 46
Question 450
A Kubernetes platform team observes this situation: A Pod resolves an external domain but cannot resolve another Service by its short name. Which action BEST addresses the requirement?
- Use a StatefulSet with stable identity and persistent storage design
- Inspect CoreDNS and the namespace-aware Service DNS naming rules
- Place tightly coupled containers in one Pod with explicit volume sharing
- Supply nonsecret configuration through a ConfigMap and suitable Pod reference
Explanation
Correct Answer
B:Inspect CoreDNS and the namespace-aware Service DNS naming rules. This is appropriate for the described asset and control gap because cluster DNS maps Kubernetes Service names to records within configured search domains. If the issue is left untreated, hardcoding current Pod IPs to bypass name resolution creates fragile dependencies. An assessor can verify remediation when the proper service.namespace DNS name resolves to its expected ClusterIP.
Incorrect Answers
A: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 “Inspect CoreDNS and the namespace-aware Service DNS naming rules”.
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 “Inspect CoreDNS and the namespace-aware Service DNS naming rules”.
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 “Inspect CoreDNS and the namespace-aware Service DNS naming rules”.
Question 451
A platform engineer recommends: Add a narrow permitted egress rule to the designated DNS service. The original problem is: A pod can send traffic to a database but outbound DNS queries fail under a default-deny policy. Which concept explains the remedy?
- DNS search paths are namespace-sensitive inside ordinary Pod configurations
- Headless Services expose endpoint records rather than an ordinary virtual ClusterIP
- Egress-deny policies also affect support dependencies such as DNS resolution
- LoadBalancer Services integrate with a compatible provider to provision external traffic access
Explanation
Correct Answer
C:Egress-deny policies also affect support dependencies such as DNS resolution. That principle directly explains the selected remediation, add a narrow permitted egress rule to the designated DNS service, for this case. Without the distinction, allowing only the business destination leaves name lookup unable to complete. The expected confirmation is that dNS queries and the approved database connection work while unrelated egress fails.
Incorrect Answers
A:DNS search paths are namespace-sensitive inside ordinary Pod configurations. The operation “DNS search paths are namespace-sensitive inside ordinary Pod configurations” does not address the particular Kubernetes requirement “Egress-deny policies also affect support dependencies such as DNS resolution”.
B:Headless Services expose endpoint records rather than an ordinary virtual ClusterIP. The operation “Headless Services expose endpoint records rather than an ordinary virtual ClusterIP” does not address the particular Kubernetes requirement “Egress-deny policies also affect support dependencies such as DNS resolution”.
D:LoadBalancer Services integrate with a compatible provider to provision external traffic access. The operation “LoadBalancer Services integrate with a compatible provider to provision external traffic access” does not address the particular Kubernetes requirement “Egress-deny policies also affect support dependencies such as DNS resolution”.
Question 452
In the situation "An engineer needs to roll back an application after the new image violates latency objectives", the team applies "Use the versioned Deployment or delivery tool rollback workflow". Which outcome is the strongest verification?
- A synthetic error-rate regression pauses promotion and restores the stable version
- A reviewed commit is reconciled and unauthorized live drift is corrected
- A consistent chart deploys with separately reviewed development and production values
- The prior verified revision is serving after an automated rollback
Explanation
Correct Answer
D:The prior verified revision is serving after an automated rollback. This is stronger than observing a saved configuration because it tests the actual outcome of use the versioned Deployment or delivery tool rollback workflow. The underlying principle is that release tooling preserves revisions that support controlled restoration. The original risk was that manually editing a live container cannot recover a consistent prior release.
Incorrect Answers
A:Delivery gates use measured user outcomes to decide whether to continue rollout. The observation “A synthetic error-rate regression pauses promotion and restores the stable version” would validate that property, rather than the required “The prior verified revision is serving after an automated rollback”. Release tooling preserves revisions that support controlled restoration.
B:GitOps uses declared source-control desired state with automated convergence. The observation “A reviewed commit is reconciled and unauthorized live drift is corrected” would validate that property, rather than the required “The prior verified revision is serving after an automated rollback”. Release tooling preserves revisions that support controlled restoration.
C:Helm templates Kubernetes resources and tracks packaged release revisions. The observation “A consistent chart deploys with separately reviewed development and production values” would validate that property, rather than the required “The prior verified revision is serving after an automated rollback”. Release tooling preserves revisions that support controlled restoration.
Question 453
In a Kubernetes environment this issue remains open: A Pod can reach neighboring containers over localhost but not Pods assigned to other nodes. Which failure is the MOST direct consequence?
- A healthy container runtime does not itself guarantee cross-node Pod networking
- Persisting Pod IPs in client configuration breaks during restarts or scaling
- Allowing only the business destination leaves name lookup unable to complete
- Assuming both IP families exist on every deployment can break one protocol
Explanation
Correct Answer
A:A healthy container runtime does not itself guarantee cross-node Pod networking. This is the direct concern in the stated scenario because cNI plugins configure Pod network connectivity across the cluster. The matching mitigation is to verify the cluster's Container Network Interface implementation and inter-node routes. Successful verification would show that connectivity tests succeed between Pod IPs on separate workers.
Incorrect Answers
B:Service virtual IPs represent logical backends whose endpoints may change. That explains the warning “Persisting Pod IPs in client configuration breaks during restarts or scaling”; this case instead concerns “A healthy container runtime does not itself guarantee cross-node Pod networking”. CNI plugins configure Pod network connectivity across the cluster.
C:Egress-deny policies also affect support dependencies such as DNS resolution. That explains the warning “Allowing only the business destination leaves name lookup unable to complete”; this case instead concerns “A healthy container runtime does not itself guarantee cross-node Pod networking”. CNI plugins configure Pod network connectivity across the cluster.
D:Dual-stack configuration controls IPv4 and IPv6 allocation and Service behavior. That explains the warning “Assuming both IP families exist on every deployment can break one protocol”; this case instead concerns “A healthy container runtime does not itself guarantee cross-node Pod networking”. CNI plugins configure Pod network connectivity across the cluster.
Question 454
A platform engineer recommends: Inspect the node's CRI-compatible runtime service and kubelet connection. The original problem is: A Node reports container runtime errors while the control-plane scheduler is healthy. Which concept explains the remedy?
- Immutable image-based deployment moves application packaging into build workflows
- Kubernetes uses the Container Runtime Interface to coordinate container execution
- Container image scanning finds known package risk before admission
- Reducing unneeded image contents reduces exposed packages and maintenance cost
Explanation
Correct Answer
B:Kubernetes uses the Container Runtime Interface to coordinate container execution. That principle directly explains the selected remediation, inspect the node's CRI-compatible runtime service and kubelet connection, for this case. Without the distinction, fixing the API server cannot replace a missing node container runtime. The expected confirmation is that runtime health recovers and the assigned Pod successfully starts.
Incorrect Answers
A:Immutable image-based deployment moves application packaging into build workflows. The operation “Immutable image-based deployment moves application packaging into build workflows” does not address the particular Kubernetes requirement “Kubernetes uses the Container Runtime Interface to coordinate container execution”.
C:Container image scanning finds known package risk before admission. The operation “Container image scanning finds known package risk before admission” does not address the particular Kubernetes requirement “Kubernetes uses the Container Runtime Interface to coordinate container execution”.
D:Reducing unneeded image contents reduces exposed packages and maintenance cost. The operation “Reducing unneeded image contents reduces exposed packages and maintenance cost” does not address the particular Kubernetes requirement “Kubernetes uses the Container Runtime Interface to coordinate container execution”.
Question 455
Given the requirement "A cluster operator wants a non-destructive listing of objects in all namespaces", the proposed fix is "Use the appropriate kubectl all-namespaces query and resource types". Which principle explains why it works?
- LimitRanges can provide default constraints to containers in a namespace
- Automation should bind every Kubernetes command to its intended target environment
- The default kubectl namespace view excludes resources in other namespaces
- Object descriptions expose controller and scheduler diagnostics beyond names and phases
Explanation
Correct Answer
C:The default kubectl namespace view excludes resources in other namespaces. That principle directly explains the selected remediation, use the appropriate kubectl all-namespaces query and resource types, for this case. Without the distinction, assuming a blank default namespace means the cluster is empty omits workloads. The expected confirmation is that the inventory includes deployments from each permitted namespace.
Incorrect Answers
A:LimitRanges can provide default constraints to containers in a namespace. The operation “LimitRanges can provide default constraints to containers in a namespace” does not address the particular Kubernetes requirement “The default kubectl namespace view excludes resources in other namespaces”.
B: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 “The default kubectl namespace view excludes resources in other namespaces”.
D:Object descriptions expose controller and scheduler diagnostics beyond names and phases. The operation “Object descriptions expose controller and scheduler diagnostics beyond names and phases” does not address the particular Kubernetes requirement “The default kubectl namespace view excludes resources in other namespaces”.
Question 456
For this Kubernetes condition, A Deployment revision rolls out but a subset of Pods never reach Ready state. The proposed approach is: Compare Deployment conditions, Pod events, and readiness failures before promotion. Which technical principle BEST supports that choice?
- Application configuration differences are common causes of release-specific faults
- Container retrieval requires valid credentials before the process can launch
- Node-local dataplane or runtime problems can affect only a subset of replicas
- Delivery debugging begins with resource status and failure conditions
Explanation
Correct Answer
D:Delivery debugging begins with resource status and failure conditions. That principle directly explains the selected remediation, compare Deployment conditions, Pod events, and readiness failures before promotion, for this case. Without the distinction, assuming a completed image push means runtime readiness conceals deployment defects. The expected confirmation is that a corrected Pod passes readiness and rollout status becomes Complete.
Incorrect Answers
A:Application configuration differences are common causes of release-specific faults. The operation “Application configuration differences are common causes of release-specific faults” does not address the particular Kubernetes requirement “Delivery debugging begins with resource status and failure conditions”.
B:Container retrieval requires valid credentials before the process can launch. The operation “Container retrieval requires valid credentials before the process can launch” does not address the particular Kubernetes requirement “Delivery debugging begins with resource status and failure conditions”.
C: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 “Delivery debugging begins with resource status and failure conditions”.
Question 457
The team has not corrected this condition: A database needs persistent disk capacity without hardcoding a specific underlying disk resource. Which risk is MOST relevant?
- Hardcoding a host path ties data availability to one worker node
- Assuming ReadWriteOnce supports arbitrary simultaneous writers can prevent attachment
- Assuming every PV is retained can cause permanent loss after claim deletion
- Rescheduling can lose files not written to durable storage
Explanation
Correct Answer
A:Hardcoding a host path ties data availability to one worker node. This is the direct concern in the stated scenario because persistentVolumeClaims request storage independently of physical volume provisioning. The matching mitigation is to create a PVC with the required size, access mode, and StorageClass. Successful verification would show that the claim binds and the database mounts compatible persistent storage.
Incorrect Answers
B:Volume access modes express compatibility requirements for concurrent mounts. That explains the warning “Assuming ReadWriteOnce supports arbitrary simultaneous writers can prevent attachment”; this case instead concerns “Hardcoding a host path ties data availability to one worker node”. PersistentVolumeClaims request storage independently of physical volume provisioning.
C:Reclaim policies such as Delete and Retain control backing-volume disposition. That explains the warning “Assuming every PV is retained can cause permanent loss after claim deletion”; this case instead concerns “Hardcoding a host path ties data availability to one worker node”. PersistentVolumeClaims request storage independently of physical volume provisioning.
D: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 “Hardcoding a host path ties data availability to one worker node”. PersistentVolumeClaims request storage independently of physical volume provisioning.
Question 458
In the situation "A Pod cannot resolve any cluster Service though its container and network interface are healthy", the team applies "Check DNS policy, resolv.conf, CoreDNS Pod health, and network reachability". Which outcome is the strongest verification?
- Ready replicas appear in EndpointSlices and complete test requests
- A Pod successfully resolves both short and qualified Service names
- 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 Pod successfully resolves both short and qualified Service names. This is stronger than observing a saved configuration because it tests the actual outcome of check DNS policy, resolv.conf, CoreDNS Pod health, and network reachability. The underlying principle is that kubernetes name resolution depends on DNS service and Pod resolver configuration. The original risk was that changing application service ports will not repair broken DNS lookups.
Incorrect Answers
A:Readiness failures remove unready containers from normal Service routing. The observation “Ready replicas appear in EndpointSlices and complete test requests” would validate that property, rather than the required “A Pod successfully resolves both short and qualified Service names”. Kubernetes name resolution depends on DNS service and Pod resolver configuration.
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 Pod successfully resolves both short and qualified Service names”. Kubernetes name resolution depends on DNS service and Pod resolver configuration.
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 Pod successfully resolves both short and qualified Service names”. Kubernetes name resolution depends on DNS service and Pod resolver configuration.
Question 459
A Kubernetes platform team observes this situation: A Node reports container runtime errors while the control-plane scheduler is healthy. Which action BEST addresses the requirement?
- Version and publish the full application image rather than altering running containers
- Set an appropriate imagePullPolicy and prefer immutable release identifiers
- Inspect the node's CRI-compatible runtime service and kubelet connection
- Choose an appropriately minimal trusted runtime image and maintain updates
Explanation
Correct Answer
C:Inspect the node's CRI-compatible runtime service and kubelet connection. This is appropriate for the described asset and control gap because kubernetes uses the Container Runtime Interface to coordinate container execution. If the issue is left untreated, fixing the API server cannot replace a missing node container runtime. An assessor can verify remediation when runtime health recovers and the assigned Pod successfully starts.
Incorrect Answers
A:Version and publish the full application image rather than altering running containers. The operation “Version and publish the full application image rather than altering running containers” does not address the particular Kubernetes requirement “Inspect the node's CRI-compatible runtime service and kubelet connection”.
B:Set an appropriate imagePullPolicy and prefer immutable release identifiers. The operation “Set an appropriate imagePullPolicy and prefer immutable release identifiers” does not address the particular Kubernetes requirement “Inspect the node's CRI-compatible runtime service and kubelet connection”.
D:Choose an appropriately minimal trusted runtime image and maintain updates. The operation “Choose an appropriately minimal trusted runtime image and maintain updates” does not address the particular Kubernetes requirement “Inspect the node's CRI-compatible runtime service and kubelet connection”.
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.
