Kubernetes and Cloud Native Associate KCNA Practice Test 69
Question 680
An operator notices this unresolved gap: A team has multiple similarly named clusters and needs safe scripting for read-only checks. What consequence BEST explains the need to address it?
- Reading only current logs may miss the failure message from a restarted process
- Ad hoc production editing creates changes that are difficult to trace or reverse
- Leaving nodes cordoned after maintenance reduces available cluster capacity
- Inherited interactive context can send scripts to the wrong cluster
Explanation
Correct Answer
D:Inherited interactive context can send scripts to the wrong cluster. This is the direct concern in the stated scenario because automation should bind every Kubernetes command to its intended target environment. The matching mitigation is to pass an explicit context and namespace to automation rather than relying on defaults. Successful verification would show that a dry run shows each command's target cluster and namespace unambiguously.
Incorrect Answers
A:Kubectl logs can request output from the previous container instance. That explains the warning “Reading only current logs may miss the failure message from a restarted process”; this case instead concerns “Inherited interactive context can send scripts to the wrong cluster”. Automation should bind every Kubernetes command to its intended target environment.
B:Versioned declarative configuration supports auditability and repeatable changes. That explains the warning “Ad hoc production editing creates changes that are difficult to trace or reverse”; this case instead concerns “Inherited interactive context can send scripts to the wrong cluster”. Automation should bind every Kubernetes command to its intended target environment.
C:Uncordon reverses the unschedulable scheduling designation. That explains the warning “Leaving nodes cordoned after maintenance reduces available cluster capacity”; this case instead concerns “Inherited interactive context can send scripts to the wrong cluster”. Automation should bind every Kubernetes command to its intended target environment.
Question 681
For this Kubernetes condition, A security gate wants to block high-risk image vulnerabilities before rollout. The proposed approach is: Scan release artifacts and enforce an approved image policy before deployment. Which technical principle BEST supports that choice?
- Container image scanning finds known package risk before admission
- Immutable image-based deployment moves application packaging into build workflows
- Registry authentication is distinct from Kubernetes workload API authorization
- Image tags are mutable references while digests identify specific image content
Explanation
Correct Answer
A:Container image scanning finds known package risk before admission. That principle directly explains the selected remediation, scan release artifacts and enforce an approved image policy before deployment, for this case. Without the distinction, treating a successful build as security approval can release vulnerable libraries. The expected confirmation is that the pipeline blocks an intentionally vulnerable test image under its policy.
Incorrect Answers
B: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 “Container image scanning finds known package risk before admission”.
C:Registry authentication is distinct from Kubernetes workload API authorization. The operation “Registry authentication is distinct from Kubernetes workload API authorization” does not address the particular Kubernetes requirement “Container image scanning finds known package risk before admission”.
D:Image tags are mutable references while digests identify specific image content. The operation “Image tags are mutable references while digests identify specific image content” does not address the particular Kubernetes requirement “Container image scanning finds known package risk before admission”.
Question 682
A platform engineer recommends: Compare effective ConfigMaps, Secrets references, and environment settings. The original problem is: An application works in development but fails in production because an API hostname differs. Which concept explains the remedy?
- Recurring task execution is tracked through Job and CronJob objects
- Application configuration differences are common causes of release-specific faults
- A Running Pod indicates process state rather than end-to-end service success
- Service networking requires matching endpoints and correct destination ports
Explanation
Correct Answer
B:Application configuration differences are common causes of release-specific faults. That principle directly explains the selected remediation, compare effective ConfigMaps, Secrets references, and environment settings, for this case. Without the distinction, rebuilding the identical binary cannot repair an incorrect environment URL. The expected confirmation is that the approved production endpoint is used and a smoke request succeeds.
Incorrect Answers
A:Recurring task execution is tracked through Job and CronJob objects. The operation “Recurring task execution is tracked through Job and CronJob objects” does not address the particular Kubernetes requirement “Application configuration differences are common causes of release-specific faults”.
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 “Application configuration differences are common causes of release-specific faults”.
D:Service networking requires matching endpoints and correct destination ports. The operation “Service networking requires matching endpoints and correct destination ports” does not address the particular Kubernetes requirement “Application configuration differences are common causes of release-specific faults”.
Question 683
In the situation "An application should always check for an updated image when using a mutable tag", the team applies "Set an appropriate imagePullPolicy and prefer immutable release identifiers". Which outcome is the strongest verification?
- A verified image inspection finds no secrets and the exposed credential is rotated
- Both supported runtimes can load and run the same compliant image
- Restarted Pods retrieve the intended image under the configured policy
- A second build reuses unchanged dependency layers and finishes faster
Explanation
Correct Answer
C:Restarted Pods retrieve the intended image under the configured policy. This is stronger than observing a saved configuration because it tests the actual outcome of set an appropriate imagePullPolicy and prefer immutable release identifiers. The underlying principle is that image pull policy determines whether a node checks the registry for an image. The original risk was that assuming local cache always matches an updated mutable tag causes drift.
Incorrect Answers
A: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 “Restarted Pods retrieve the intended image under the configured policy”. Image pull policy determines whether a node checks the registry for an image.
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 “Restarted Pods retrieve the intended image under the configured policy”. Image pull policy determines whether a node checks the registry for an image.
D:Layered image caching can avoid rebuilding unchanged instructions. The observation “A second build reuses unchanged dependency layers and finishes faster” would validate that property, rather than the required “Restarted Pods retrieve the intended image under the configured policy”. Image pull policy determines whether a node checks the registry for an image.
Question 684
For this Kubernetes condition, A developer needs to identify which users can update Deployments in one namespace. The proposed approach is: Review Role, RoleBinding, and subject references for the namespace. Which technical principle BEST supports that choice?
- Structured API output exposes desired specifications and object metadata
- Deployment revision history supports rollback of Pod-template changes
- Namespaced API queries avoid mixing identical resource names from other teams
- RBAC permissions are granted through bound roles rather than folder ownership
Explanation
Correct Answer
D:RBAC permissions are granted through bound roles rather than folder ownership. That principle directly explains the selected remediation, review Role, RoleBinding, and subject references for the namespace, for this case. Without the distinction, assuming source repository access equals cluster authorization misstates privileges. The expected confirmation is that a test user can read allowed objects but cannot update forbidden Deployments.
Incorrect Answers
A:Structured API output exposes desired specifications and object metadata. The operation “Structured API output exposes desired specifications and object metadata” does not address the particular Kubernetes requirement “RBAC permissions are granted through bound roles rather than folder ownership”.
B: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 “RBAC permissions are granted through bound roles rather than folder ownership”.
C:Namespaced API queries avoid mixing identical resource names from other teams. The operation “Namespaced API queries avoid mixing identical resource names from other teams” does not address the particular Kubernetes requirement “RBAC permissions are granted through bound roles rather than folder ownership”.
Question 685
A platform engineer recommends: Use kubectl describe to inspect conditions and recent warning events. The original problem is: An operator knows a Pod name but needs to identify why it never starts. Which concept explains the remedy?
- Object descriptions expose controller and scheduler diagnostics beyond names and phases
- Structured API output exposes desired specifications and object metadata
- Cordon marks a node unschedulable without directly evicting running Pods
- Namespaced API queries avoid mixing identical resource names from other teams
Explanation
Correct Answer
A:Object descriptions expose controller and scheduler diagnostics beyond names and phases. That principle directly explains the selected remediation, use kubectl describe to inspect conditions and recent warning events, for this case. Without the distinction, relying only on a short Pod listing hides actionable failure reasons. The expected confirmation is that the reported warning identifies the blocked scheduling or image-pull step.
Incorrect Answers
B:Structured API output exposes desired specifications and object metadata. The operation “Structured API output exposes desired specifications and object metadata” does not address the particular Kubernetes requirement “Object descriptions expose controller and scheduler diagnostics beyond names and phases”.
C:Cordon marks a node unschedulable without directly evicting running Pods. The operation “Cordon marks a node unschedulable without directly evicting running Pods” does not address the particular Kubernetes requirement “Object descriptions expose controller and scheduler diagnostics beyond names and phases”.
D:Namespaced API queries avoid mixing identical resource names from other teams. The operation “Namespaced API queries avoid mixing identical resource names from other teams” does not address the particular Kubernetes requirement “Object descriptions expose controller and scheduler diagnostics beyond names and phases”.
Question 686
In the situation "Security requires Pods in one namespace to reach only two approved upstream services", the team applies "Enforce supported CNI NetworkPolicies on ingress and egress traffic". Which outcome is the strongest verification?
- Requests for each host and path reach only its designated Service
- Allowed flows succeed and disallowed cross-namespace traffic is denied
- EndpointSlice members appear after selectors align and traffic recovers
- Connectivity tests succeed between Pod IPs on separate workers
Explanation
Correct Answer
B:Allowed flows succeed and disallowed cross-namespace traffic is denied. This is stronger than observing a saved configuration because it tests the actual outcome of enforce supported CNI NetworkPolicies on ingress and egress traffic. The underlying principle is that networkPolicies specify allowable communication but require network-plugin enforcement. The original risk was that a manifest without compatible CNI support may not filter any packets.
Incorrect Answers
A: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 “Allowed flows succeed and disallowed cross-namespace traffic is denied”. NetworkPolicies specify allowable communication but require network-plugin enforcement.
C: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 “Allowed flows succeed and disallowed cross-namespace traffic is denied”. NetworkPolicies specify allowable communication but require network-plugin enforcement.
D: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 “Allowed flows succeed and disallowed cross-namespace traffic is denied”. NetworkPolicies specify allowable communication but require network-plugin enforcement.
Question 687
In a Kubernetes environment this issue remains open: A compliance reviewer expects cluster rebuilds to reproduce exactly the current running setup. Which failure is the MOST direct consequence?
- Unlimited retries can amplify downstream overload and collapse the calling service
- Treating containers alone as cloud-native adoption can ignore deployment and reliability needs
- Undocumented manual changes make recovery and verification unreliable
- Dependence on an undocumented provider-specific API can make migration difficult
Explanation
Correct Answer
C:Undocumented manual changes make recovery and verification unreliable. This is the direct concern in the stated scenario because infrastructure as code and desired-state convergence support repeatability and auditability. The matching mitigation is to store declarative infrastructure and workload configurations in reviewed source control. Successful verification would show that a clean environment rebuild recreates intended controls from approved versioned inputs.
Incorrect Answers
A:Resilience patterns keep transient dependency faults from consuming all callers. That explains the warning “Unlimited retries can amplify downstream overload and collapse the calling service”; this case instead concerns “Undocumented manual changes make recovery and verification unreliable”. Infrastructure as code and desired-state convergence support repeatability and auditability.
B:Cloud-native systems combine organizational practices and technology, not only a container runtime. That explains the warning “Treating containers alone as cloud-native adoption can ignore deployment and reliability needs”; this case instead concerns “Undocumented manual changes make recovery and verification unreliable”. Infrastructure as code and desired-state convergence support repeatability and auditability.
D:Open standards reduce unnecessary vendor coupling across cloud-native infrastructure. That explains the warning “Dependence on an undocumented provider-specific API can make migration difficult”; this case instead concerns “Undocumented manual changes make recovery and verification unreliable”. Infrastructure as code and desired-state convergence support repeatability and auditability.
Question 688
The team has not corrected this condition: A new image repeatedly crashes because a required flag was renamed. Which risk is MOST relevant?
- Treating memory kills as network errors delays a useful capacity or code fix
- Removing endpoints too late or starting them too early can cause cutover errors
- Monitoring only Deployments can miss failed scheduled business processes
- Deleting failing Pods without changing the invalid flag repeats CrashLoopBackOff
Explanation
Correct Answer
D:Deleting failing Pods without changing the invalid flag repeats CrashLoopBackOff. This is the direct concern in the stated scenario because startup failures often appear in terminated container output and process configuration. The matching mitigation is to inspect previous container logs and the current image command and arguments. Successful verification would show that corrected arguments let the container remain Running without repeated restarts.
Incorrect Answers
A:An OOM termination indicates a breached memory boundary or node memory pressure. That explains the warning “Treating memory kills as network errors delays a useful capacity or code fix”; this case instead concerns “Deleting failing Pods without changing the invalid flag repeats CrashLoopBackOff”. Startup failures often appear in terminated container output and process configuration.
B: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 “Deleting failing Pods without changing the invalid flag repeats CrashLoopBackOff”. Startup failures often appear in terminated container output and process configuration.
C:Recurring task execution is tracked through Job and CronJob objects. That explains the warning “Monitoring only Deployments can miss failed scheduled business processes”; this case instead concerns “Deleting failing Pods without changing the invalid flag repeats CrashLoopBackOff”. Startup failures often appear in terminated container output and process configuration.
Question 689
Given the requirement "A controller needs one consistent entry point for creating and watching cluster objects", the proposed fix is "Use the Kubernetes API server rather than editing etcd or node files directly". Which principle explains why it works?
- The API server validates requests and exposes the supported declarative control interface
- Jobs manage finite tasks while CronJobs create Jobs on a time schedule
- Kubernetes controllers continually compare observed state to declared desired state
- A Service provides a stable virtual endpoint decoupled from changing Pod addresses
Explanation
Correct Answer
A:The API server validates requests and exposes the supported declarative control interface. That principle directly explains the selected remediation, use the Kubernetes API server rather than editing etcd or node files directly, for this case. Without the distinction, writing cluster state through an unsupported path bypasses expected API safeguards. The expected confirmation is that a create request is accepted through the API and appears in resource listings.
Incorrect Answers
B:Jobs manage finite tasks while CronJobs create Jobs on a time schedule. The operation “Jobs manage finite tasks while CronJobs create Jobs on a time schedule” does not address the particular Kubernetes requirement “The API server validates requests and exposes the supported declarative control interface”.
C:Kubernetes controllers continually compare observed state to declared desired state. The operation “Kubernetes controllers continually compare observed state to declared desired state” does not address the particular Kubernetes requirement “The API server validates requests and exposes the supported declarative control interface”.
D:A Service provides a stable virtual endpoint decoupled from changing Pod addresses. The operation “A Service provides a stable virtual endpoint decoupled from changing Pod addresses” does not address the particular Kubernetes requirement “The API server validates requests and exposes the supported declarative control interface”.
Question 690
A team implemented the proposed remedy for this problem: An operations node has a NoSchedule taint and only a privileged agent should run there. Which evidence BEST shows it works?
- The collaborating Pods run within the expected topology relationship
- The approved agent schedules with node selection and normal applications stay away
- The namespace receives approved quota capacity and the Pod is admitted
- The scheduler chooses preferred nodes when available and falls back otherwise
Explanation
Correct Answer
B:The approved agent schedules with node selection and normal applications stay away. This is stronger than observing a saved configuration because it tests the actual outcome of give the approved agent a matching toleration and restrict other workloads. The underlying principle is that taints repel Pods while tolerations allow them to be considered for placement. The original risk was that a matching toleration does not itself select or reserve the correct node.
Incorrect Answers
A: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 approved agent schedules with node selection and normal applications stay away”. Taints repel Pods while tolerations allow them to be considered for placement.
C:Admission quota checks operate independently from node scheduling capacity. The observation “The namespace receives approved quota capacity and the Pod is admitted” would validate that property, rather than the required “The approved agent schedules with node selection and normal applications stay away”. Taints repel Pods while tolerations allow them to be considered for placement.
D: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 approved agent schedules with node selection and normal applications stay away”. Taints repel Pods while tolerations allow them to be considered for placement.
