Kubernetes and Cloud Native Associate KCNA Practice Test 15
Question 140
In the situation "A cluster app cannot resolve names of other namespaces using an unqualified Service name", the team applies "Use the namespace-qualified Kubernetes Service DNS name where needed". Which outcome is the strongest verification?
- EndpointSlice members appear after selectors align and traffic recovers
- Connectivity tests succeed between Pod IPs on separate workers
- Requests for each host and path reach only its designated Service
- The fully qualified Service name resolves to the expected target endpoint
Explanation
Correct Answer
D:The fully qualified Service name resolves to the expected target endpoint. This is stronger than observing a saved configuration because it tests the actual outcome of use the namespace-qualified Kubernetes Service DNS name where needed. The underlying principle is that dNS search paths are namespace-sensitive inside ordinary Pod configurations. The original risk was that a short name can refer to an unintended same-named local Service.
Incorrect Answers
A:EndpointSlices enumerate ready or eligible network endpoints behind Services. The observation “EndpointSlice members appear after selectors align and traffic recovers” would validate that property, rather than the required “The fully qualified Service name resolves to the expected target endpoint”. DNS search paths are namespace-sensitive inside ordinary Pod configurations.
B:CNI plugins configure Pod network connectivity across the cluster. The observation “Connectivity tests succeed between Pod IPs on separate workers” would validate that property, rather than the required “The fully qualified Service name resolves to the expected target endpoint”. DNS search paths are namespace-sensitive inside ordinary Pod configurations.
C:HTTP routing objects require a working controller to implement actual data-plane behavior. The observation “Requests for each host and path reach only its designated Service” would validate that property, rather than the required “The fully qualified Service name resolves to the expected target endpoint”. DNS search paths are namespace-sensitive inside ordinary Pod configurations.
Question 141
A team implemented the proposed remedy for this problem: Two complete application environments should alternate traffic during approved releases. Which evidence BEST shows it works?
- The traffic switch is reversible and end-to-end smoke tests pass
- The agent applies only approved resources and unrelated changes are denied
- Both application revisions function during the transition and cleanup follows cutover
- The Service endpoint appears only after initialization succeeds
Explanation
Correct Answer
A:The traffic switch is reversible and end-to-end smoke tests pass. This is stronger than observing a saved configuration because it tests the actual outcome of use a blue-green strategy with a validated traffic-switch operation. The underlying principle is that blue-green releases keep separate old and new environments during cutover. The original risk was that switching before validating the new environment can redirect all traffic to faults.
Incorrect Answers
B:Pull-based deployment agents can reduce the need to distribute cluster-admin keys. The observation “The agent applies only approved resources and unrelated changes are denied” would validate that property, rather than the required “The traffic switch is reversible and end-to-end smoke tests pass”. Blue-green releases keep separate old and new environments during cutover.
C:Mixed-version rolling deployments require old and new software to tolerate shared data schema. The observation “Both application revisions function during the transition and cleanup follows cutover” would validate that property, rather than the required “The traffic switch is reversible and end-to-end smoke tests pass”. Blue-green releases keep separate old and new environments during cutover.
D:Readiness probes control endpoint eligibility independently of process status. The observation “The Service endpoint appears only after initialization succeeds” would validate that property, rather than the required “The traffic switch is reversible and end-to-end smoke tests pass”. Blue-green releases keep separate old and new environments during cutover.
Question 142
The team has not corrected this condition: A Pod cannot resolve any cluster Service though its container and network interface are healthy. Which risk is MOST relevant?
- A correct Service name cannot compensate for a wrong backend port
- Changing application service ports will not repair broken DNS lookups
- A readiness probe alone only changes traffic eligibility and will not restart it
- Deleting the Pod without fixing its startup error may repeat the failure
Explanation
Correct Answer
B:Changing application service ports will not repair broken DNS lookups. This is the direct concern in the stated scenario because kubernetes name resolution depends on DNS service and Pod resolver configuration. The matching mitigation is to check DNS policy, resolv.conf, CoreDNS Pod health, and network reachability. Successful verification would show that a Pod successfully resolves both short and qualified Service names.
Incorrect Answers
A:Service targetPort maps the abstract port to the selected Pod's target. That explains the warning “A correct Service name cannot compensate for a wrong backend port”; this case instead concerns “Changing application service ports will not repair broken DNS lookups”. Kubernetes name resolution depends on DNS service and Pod resolver configuration.
C:Liveness probes detect a running container that requires restart. That explains the warning “A readiness probe alone only changes traffic eligibility and will not restart it”; this case instead concerns “Changing application service ports will not repair broken DNS lookups”. Kubernetes name resolution depends on DNS service and Pod resolver configuration.
D:CrashLoopBackOff reflects repeated container start failures with increasing delay. That explains the warning “Deleting the Pod without fixing its startup error may repeat the failure”; this case instead concerns “Changing application service ports will not repair broken DNS lookups”. Kubernetes name resolution depends on DNS service and Pod resolver configuration.
Question 143
Given the requirement "A node-mounted privileged Pod needs to read its own configuration but asks for all host devices", the proposed fix is "Remove unnecessary privileged mode, hostPath mounts, and Linux capabilities". Which principle explains why it works?
- Least-privilege network controls require enumerating all legitimate communication paths
- Security contexts can enforce nonroot process identity for Pod containers
- Pod security context and admission standards limit process and host access
- Namespaces partition resource names and policy scope but are not automatic network firewalls
Explanation
Correct Answer
C:Pod security context and admission standards limit process and host access. That principle directly explains the selected remediation, remove unnecessary privileged mode, hostPath mounts, and Linux capabilities, for this case. Without the distinction, unrestricted host mounts can let a compromised Pod affect worker filesystems. The expected confirmation is that a policy-compliant Pod operates without privileged mode or unnecessary host mounts.
Incorrect Answers
A:Least-privilege network controls require enumerating all legitimate communication paths. The operation “Least-privilege network controls require enumerating all legitimate communication paths” does not address the particular Kubernetes requirement “Pod security context and admission standards limit process and host access”.
B:Security contexts can enforce nonroot process identity for Pod containers. The operation “Security contexts can enforce nonroot process identity for Pod containers” does not address the particular Kubernetes requirement “Pod security context and admission standards limit process and host access”.
D:Namespaces partition resource names and policy scope but are not automatic network firewalls. The operation “Namespaces partition resource names and policy scope but are not automatic network firewalls” does not address the particular Kubernetes requirement “Pod security context and admission standards limit process and host access”.
Question 144
In a Kubernetes environment this issue remains open: A new team assumes that separating Pods into namespaces blocks all network traffic between them. Which failure is the MOST direct consequence?
- A blanket untested deny can make healthy applications appear unavailable
- Using a cluster-admin binding for basic monitoring creates excessive authority
- Policy notes alone cannot prevent an unsafe Pod specification from admission
- A default open Pod network can permit cross-team connections despite namespace separation
Explanation
Correct Answer
D:A default open Pod network can permit cross-team connections despite namespace separation. This is the direct concern in the stated scenario because namespaces partition resource names and policy scope but are not automatic network firewalls. The matching mitigation is to apply explicit NetworkPolicies in addition to namespace and RBAC organization. Successful verification would show that a negative connection test shows cross-namespace traffic blocked by enforced policy.
Incorrect Answers
A:Least-privilege network controls require enumerating all legitimate communication paths. That explains the warning “A blanket untested deny can make healthy applications appear unavailable”; this case instead concerns “A default open Pod network can permit cross-team connections despite namespace separation”. Namespaces partition resource names and policy scope but are not automatic network firewalls.
B:Kubernetes RBAC grants explicit verbs on resource types to bound subjects. That explains the warning “Using a cluster-admin binding for basic monitoring creates excessive authority”; this case instead concerns “A default open Pod network can permit cross-team connections despite namespace separation”. Namespaces partition resource names and policy scope but are not automatic network firewalls.
C:Pod Security Admission uses namespace-level modes such as enforce, audit, and warn. That explains the warning “Policy notes alone cannot prevent an unsafe Pod specification from admission”; this case instead concerns “A default open Pod network can permit cross-team connections despite namespace separation”. Namespaces partition resource names and policy scope but are not automatic network firewalls.
Question 145
The platform team applies this control: Investigate controller-manager reconciliation and relevant resource conditions. The original issue is: A Deployment's actual replica count stays below its declared number after a failure. Which observation BEST validates the result?
- The controller recreates missing desired objects after service restoration
- Replica identities remain predictable through controlled rollout and rescheduling
- An isolated restoration recovers expected objects from a verified etcd snapshot
- The ownership annotation changes without modifying the selected backend set
Explanation
Correct Answer
A:The controller recreates missing desired objects after service restoration. This is stronger than observing a saved configuration because it tests the actual outcome of investigate controller-manager reconciliation and relevant resource conditions. The underlying principle is that kubernetes controllers continually compare observed state to declared desired state. The original risk was that without functioning reconciliation a missing replica can remain absent indefinitely.
Incorrect Answers
B:StatefulSets preserve ordered identity for Pods in stateful applications. The observation “Replica identities remain predictable through controlled rollout and rescheduling” would validate that property, rather than the required “The controller recreates missing desired objects after service restoration”. Kubernetes controllers continually compare observed state to declared desired state.
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 “The controller recreates missing desired objects after service restoration”. Kubernetes controllers continually compare observed state to declared desired state.
D:Annotations hold auxiliary object information that need not identify selection groups. The observation “The ownership annotation changes without modifying the selected backend set” would validate that property, rather than the required “The controller recreates missing desired objects after service restoration”. Kubernetes controllers continually compare observed state to declared desired state.
Question 146
Given the requirement "A platform uses two runtimes and wants identical portable container image metadata", the proposed fix is "Follow Open Container Initiative image and runtime specification conventions". Which principle explains why it works?
- Container lifecycle normally follows its primary process state
- OCI specifications help standardize image packaging and execution interfaces
- Container image scanning finds known package risk before admission
- Image pull policy determines whether a node checks the registry for an image
Explanation
Correct Answer
B:OCI specifications help standardize image packaging and execution interfaces. That principle directly explains the selected remediation, follow Open Container Initiative image and runtime specification conventions, for this case. Without the distinction, a proprietary image layout may not work across compliant runtimes. The expected confirmation is that both supported runtimes can load and run the same compliant image.
Incorrect Answers
A:Container lifecycle normally follows its primary process state. The operation “Container lifecycle normally follows its primary process state” does not address the particular Kubernetes requirement “OCI specifications help standardize image packaging and execution interfaces”.
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 “OCI specifications help standardize image packaging and execution interfaces”.
D:Image pull policy determines whether a node checks the registry for an image. The operation “Image pull policy determines whether a node checks the registry for an image” does not address the particular Kubernetes requirement “OCI specifications help standardize image packaging and execution interfaces”.
Question 147
A team implemented the proposed remedy for this problem: A base image has unnecessary shell packages and large attack surface. Which evidence BEST shows it works?
- The pipeline blocks an intentionally vulnerable test image under its policy
- Both supported runtimes can load and run the same compliant image
- Image inventory lists only required runtime packages after rebuild
- Uploaded files remain accessible after a complete Pod replacement
Explanation
Correct Answer
C:Image inventory lists only required runtime packages after rebuild. This is stronger than observing a saved configuration because it tests the actual outcome of choose an appropriately minimal trusted runtime image and maintain updates. The underlying principle is that reducing unneeded image contents reduces exposed packages and maintenance cost. The original risk was that a bloated image may contain vulnerable software unused by the application.
Incorrect Answers
A:Container image scanning finds known package risk before admission. The observation “The pipeline blocks an intentionally vulnerable test image under its policy” would validate that property, rather than the required “Image inventory lists only required runtime packages after rebuild”. Reducing unneeded image contents reduces exposed packages and maintenance cost.
B:OCI specifications help standardize image packaging and execution interfaces. The observation “Both supported runtimes can load and run the same compliant image” would validate that property, rather than the required “Image inventory lists only required runtime packages after rebuild”. Reducing unneeded image contents reduces exposed packages and maintenance cost.
D: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 “Image inventory lists only required runtime packages after rebuild”. Reducing unneeded image contents reduces exposed packages and maintenance cost.
Question 148
The platform team applies this control: Use topology spread constraints with the proper topology key and skew. The original issue is: An API spans three zones but too many replicas accumulate in one zone during rollout. Which observation BEST validates the result?
- The scheduler chooses preferred nodes when available and falls back otherwise
- The approved agent schedules with node selection and normal applications stay away
- Measured autoscaling changes intended replica capacity without forced random migrations
- The new Pods meet the configured maximum zone skew
Explanation
Correct Answer
D:The new Pods meet the configured maximum zone skew. This is stronger than observing a saved configuration because it tests the actual outcome of use topology spread constraints with the proper topology key and skew. The underlying principle is that topology spread helps distribute matching Pods across failure domains. The original risk was that a replica count alone does not ensure zone diversity.
Incorrect Answers
A:Preferred scheduling preferences rank candidates without making placement mandatory. The observation “The scheduler chooses preferred nodes when available and falls back otherwise” would validate that property, rather than the required “The new Pods meet the configured maximum zone skew”. Topology spread helps distribute matching Pods across failure domains.
B:Taints repel Pods while tolerations allow them to be considered for placement. The observation “The approved agent schedules with node selection and normal applications stay away” would validate that property, rather than the required “The new Pods meet the configured maximum zone skew”. Topology spread helps distribute matching Pods across failure domains.
C:Default placement is not continuous live-CPU load balancing among healthy nodes. The observation “Measured autoscaling changes intended replica capacity without forced random migrations” would validate that property, rather than the required “The new Pods meet the configured maximum zone skew”. Topology spread helps distribute matching Pods across failure domains.
Question 149
In the situation "A very low priority batch job is evicted while critical workloads remain running", the team applies "Review eviction and priority behavior rather than treating every eviction as a crash". Which outcome is the strongest verification?
- The eviction event cites resource pressure and critical Pods remain served
- After a correct node label or policy change the Pod becomes scheduled
- Measured autoscaling changes intended replica capacity without forced random migrations
- The collaborating Pods run within the expected topology relationship
Explanation
Correct Answer
A:The eviction event cites resource pressure and critical Pods remain served. This is stronger than observing a saved configuration because it tests the actual outcome of review eviction and priority behavior rather than treating every eviction as a crash. The underlying principle is that scheduling priority and node pressure affect workload retention. The original risk was that restart loops may be mistaken for application faults when pressure causes eviction.
Incorrect Answers
B:Unsatisfied hard node affinity prevents scheduler placement despite free resources. The observation “After a correct node label or policy change the Pod becomes scheduled” would validate that property, rather than the required “The eviction event cites resource pressure and critical Pods remain served”. Scheduling priority and node pressure affect workload retention.
C:Default placement is not continuous live-CPU load balancing among healthy nodes. The observation “Measured autoscaling changes intended replica capacity without forced random migrations” would validate that property, rather than the required “The eviction event cites resource pressure and critical Pods remain served”. Scheduling priority and node pressure affect workload retention.
D:Pod affinity can make placements depend on other matching Pods in topology domains. The observation “The collaborating Pods run within the expected topology relationship” would validate that property, rather than the required “The eviction event cites resource pressure and critical Pods remain served”. Scheduling priority and node pressure affect workload retention.
Question 150
A team implemented the proposed remedy for this problem: An incident review needs evidence that a cluster change was approved and reversible. Which evidence BEST shows it works?
- Requests beyond quota are rejected and existing approved workloads remain
- An applied release matches an approved commit and rollback is reproducible
- The rollout reaches completion only after updated replicas satisfy readiness
- The Deployment generation and running image reflect the updated manifest
Explanation
Correct Answer
B:An applied release matches an approved commit and rollback is reproducible. This is stronger than observing a saved configuration because it tests the actual outcome of manage Kubernetes manifests in version control with reviewed promotion. The underlying principle is that versioned declarative configuration supports auditability and repeatable changes. The original risk was that ad hoc production editing creates changes that are difficult to trace or reverse.
Incorrect Answers
A:Namespace quotas constrain aggregate API resource consumption. The observation “Requests beyond quota are rejected and existing approved workloads remain” would validate that property, rather than the required “An applied release matches an approved commit and rollback is reproducible”. Versioned declarative configuration supports auditability and repeatable changes.
C:Rollout observability distinguishes declared updates from successful availability. The observation “The rollout reaches completion only after updated replicas satisfy readiness” would validate that property, rather than the required “An applied release matches an approved commit and rollback is reproducible”. Versioned declarative configuration supports auditability and repeatable changes.
D:Kubectl apply submits desired object configuration for controller reconciliation. The observation “The Deployment generation and running image reflect the updated manifest” would validate that property, rather than the required “An applied release matches an approved commit and rollback is reproducible”. Versioned declarative configuration supports auditability and repeatable changes.