Kubernetes and Cloud Native Associate KCNA Practice Test 66
Question 650
An operator notices this unresolved gap: A platform engineer repeatedly fixes replicas by hand after an automated controller acts. What consequence BEST explains the need to address it?
- Long-running Deployments do not naturally model completion or scheduled batch execution
- Editing an ephemeral child object can be overwritten by the next reconcile loop
- A healthy API server alone cannot launch processes on a broken node agent
- Using mutable ticket text as a Service selector can disconnect endpoints
Explanation
Correct Answer
B:Editing an ephemeral child object can be overwritten by the next reconcile loop. This is the direct concern in the stated scenario because declarative reconciliation continually drives actual state toward API object specification. The matching mitigation is to update the desired-state manifest or controlling resource instead of manual drift. Successful verification would show that the desired configuration persists through controller restarts and Pod replacements.
Incorrect Answers
A:Jobs manage finite tasks while CronJobs create Jobs on a time schedule. That explains the warning “Long-running Deployments do not naturally model completion or scheduled batch execution”; this case instead concerns “Editing an ephemeral child object can be overwritten by the next reconcile loop”. Declarative reconciliation continually drives actual state toward API object specification.
C:The kubelet ensures assigned Pod specifications are carried out by node runtimes. That explains the warning “A healthy API server alone cannot launch processes on a broken node agent”; this case instead concerns “Editing an ephemeral child object can be overwritten by the next reconcile loop”. Declarative reconciliation continually drives actual state toward API object specification.
D: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 “Editing an ephemeral child object can be overwritten by the next reconcile loop”. Declarative reconciliation continually drives actual state toward API object specification.
Question 651
A team implemented the proposed remedy for this problem: An administrator deletes a PVC and unexpectedly destroys critical underlying data. Which evidence BEST shows it works?
- A competing attachment is denied under the selected single-writer policy
- A test VolumeSnapshot restores the expected dataset to a new claim
- A controlled test confirms the intended retain or delete behavior
- The Pod reports the mounted filesystem after the driver issue is fixed
Explanation
Correct Answer
C:A controlled test confirms the intended retain or delete behavior. This is stronger than observing a saved configuration because it tests the actual outcome of review PV reclaim policy and lifecycle before deleting claims. The underlying principle is that reclaim policies such as Delete and Retain control backing-volume disposition. The original risk was that assuming every PV is retained can cause permanent loss after claim deletion.
Incorrect Answers
A:ReadWriteOnce or ReadWriteOncePod semantics constrain mounting according to support. The observation “A competing attachment is denied under the selected single-writer policy” would validate that property, rather than the required “A controlled test confirms the intended retain or delete behavior”. Reclaim policies such as Delete and Retain control backing-volume disposition.
B:Kubernetes snapshots require compatible snapshot controller and CSI support. The observation “A test VolumeSnapshot restores the expected dataset to a new claim” would validate that property, rather than the required “A controlled test confirms the intended retain or delete behavior”. Reclaim policies such as Delete and Retain control backing-volume disposition.
D:CSI drivers integrate vendor storage provisioning and mounting with Kubernetes. The observation “The Pod reports the mounted filesystem after the driver issue is fixed” would validate that property, rather than the required “A controlled test confirms the intended retain or delete behavior”. Reclaim policies such as Delete and Retain control backing-volume disposition.
Question 652
A cloud-native operations team faces this condition: A service becomes available only after loading a cache and initializing connections. Which response is MOST appropriate?
- Use an expand-and-contract schema migration across compatible application versions
- Use a controlled reconciliation agent with narrowly scoped cluster permissions
- Configure automated progressive delivery analysis with meaningful service metrics
- Define a readiness probe that excludes it from traffic until ready
Explanation
Correct Answer
D:Define a readiness probe that excludes it from traffic until ready. This is appropriate for the described asset and control gap because readiness probes control endpoint eligibility independently of process status. If the issue is left untreated, routing requests to a running but uninitialized process causes transient failures. An assessor can verify remediation when the Service endpoint appears only after initialization succeeds.
Incorrect Answers
A:Use an expand-and-contract schema migration across compatible application versions. The operation “Use an expand-and-contract schema migration across compatible application versions” does not address the particular Kubernetes requirement “Define a readiness probe that excludes it from traffic until ready”.
B:Use a controlled reconciliation agent with narrowly scoped cluster permissions. The operation “Use a controlled reconciliation agent with narrowly scoped cluster permissions” does not address the particular Kubernetes requirement “Define a readiness probe that excludes it from traffic until ready”.
C:Configure automated progressive delivery analysis with meaningful service metrics. The operation “Configure automated progressive delivery analysis with meaningful service metrics” does not address the particular Kubernetes requirement “Define a readiness probe that excludes it from traffic until ready”.
Question 653
Given the requirement "A team asks how to track changes to the Kubernetes API that affect its libraries", the proposed fix is "Follow Kubernetes release notes, enhancement proposals, and SIG documentation". Which principle explains why it works?
- Community release processes communicate API evolution and deprecation timelines
- CNCF ecosystem membership is a discovery aid, not a blanket production guarantee
- Community roles and technical roles have different ownership and decision rights
- CNCF maturity stages such as Sandbox, Incubating, and Graduated have distinct meanings
Explanation
Correct Answer
A:Community release processes communicate API evolution and deprecation timelines. That principle directly explains the selected remediation, follow Kubernetes release notes, enhancement proposals, and SIG documentation, for this case. Without the distinction, ignoring published deprecations can break dependent applications on cluster upgrades. The expected confirmation is that compatibility tests pass against the scheduled release using documented migration guidance.
Incorrect Answers
B:CNCF ecosystem membership is a discovery aid, not a blanket production guarantee. The operation “CNCF ecosystem membership is a discovery aid, not a blanket production guarantee” does not address the particular Kubernetes requirement “Community release processes communicate API evolution and deprecation timelines”.
C:Community roles and technical roles have different ownership and decision rights. The operation “Community roles and technical roles have different ownership and decision rights” does not address the particular Kubernetes requirement “Community release processes communicate API evolution and deprecation timelines”.
D:CNCF maturity stages such as Sandbox, Incubating, and Graduated have distinct meanings. The operation “CNCF maturity stages such as Sandbox, Incubating, and Graduated have distinct meanings” does not address the particular Kubernetes requirement “Community release processes communicate API evolution and deprecation timelines”.
Question 654
A team implemented the proposed remedy for this problem: A payment processing service needs a graceful shutdown during rolling replacement. Which evidence BEST shows it works?
- Healthy replicas remain available throughout the image rollout
- An update drains active requests before the previous Pod is removed
- The canary receives the intended fraction of traffic and failure stops promotion
- A reviewed commit is reconciled and unauthorized live drift is corrected
Explanation
Correct Answer
B:An update drains active requests before the previous Pod is removed. This is stronger than observing a saved configuration because it tests the actual outcome of configure termination handling and adequate termination grace period. The underlying principle is that kubernetes sends shutdown signals and allows bounded cleanup before forced stop. The original risk was that immediate process termination can interrupt in-flight work or cause duplicate payment calls.
Incorrect Answers
A:Rolling updates progressively replace Pods while controlling replacement availability. The observation “Healthy replicas remain available throughout the image rollout” would validate that property, rather than the required “An update drains active requests before the previous Pod is removed”. Kubernetes sends shutdown signals and allows bounded cleanup before forced stop.
C:Canary delivery limits the blast radius of new behavior for evaluation. The observation “The canary receives the intended fraction of traffic and failure stops promotion” would validate that property, rather than the required “An update drains active requests before the previous Pod is removed”. Kubernetes sends shutdown signals and allows bounded cleanup before forced stop.
D: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 “An update drains active requests before the previous Pod is removed”. Kubernetes sends shutdown signals and allows bounded cleanup before forced stop.
Question 655
A platform engineer recommends: Choose a storage mode and attachment policy matching single-writer needs. The original problem is: A single-node database requires exclusive read-write mounting to protect data integrity. Which concept explains the remedy?
- StorageClasses describe how persistent volumes are created by storage drivers
- Volume placement influences eligible nodes and availability zones for stateful workloads
- ReadWriteOnce or ReadWriteOncePod semantics constrain mounting according to support
- CSI drivers integrate vendor storage provisioning and mounting with Kubernetes
Explanation
Correct Answer
C:ReadWriteOnce or ReadWriteOncePod semantics constrain mounting according to support. That principle directly explains the selected remediation, choose a storage mode and attachment policy matching single-writer needs, for this case. Without the distinction, using a shared filesystem without application coordination can corrupt database files. The expected confirmation is that a competing attachment is denied under the selected single-writer policy.
Incorrect Answers
A:StorageClasses describe how persistent volumes are created by storage drivers. The operation “StorageClasses describe how persistent volumes are created by storage drivers” does not address the particular Kubernetes requirement “ReadWriteOnce or ReadWriteOncePod semantics constrain mounting according to support”.
B:Volume placement influences eligible nodes and availability zones for stateful workloads. The operation “Volume placement influences eligible nodes and availability zones for stateful workloads” does not address the particular Kubernetes requirement “ReadWriteOnce or ReadWriteOncePod semantics constrain mounting according to support”.
D:CSI drivers integrate vendor storage provisioning and mounting with Kubernetes. The operation “CSI drivers integrate vendor storage provisioning and mounting with Kubernetes” does not address the particular Kubernetes requirement “ReadWriteOnce or ReadWriteOncePod semantics constrain mounting according to support”.
Question 656
Given the requirement "A stateful workload depends on a volume available only in a specific region or zone", the proposed fix is "Honor volume topology binding and scheduling constraints together". Which principle explains why it works?
- Unsatisfied hard node affinity prevents scheduler placement despite free resources
- Requests influence scheduling while limits bound container memory consumption
- Preferred scheduling preferences rank candidates without making placement mandatory
- Persistent storage topology can limit where a Pod may safely start
Explanation
Correct Answer
D:Persistent storage topology can limit where a Pod may safely start. That principle directly explains the selected remediation, honor volume topology binding and scheduling constraints together, for this case. Without the distinction, forcing a Pod onto another zone can leave the volume unattached. The expected confirmation is that the assigned worker is compatible with the bound volume's topology.
Incorrect Answers
A:Unsatisfied hard node affinity prevents scheduler placement despite free resources. The operation “Unsatisfied hard node affinity prevents scheduler placement despite free resources” does not address the particular Kubernetes requirement “Persistent storage topology can limit where a Pod may safely start”.
B:Requests influence scheduling while limits bound container memory consumption. The operation “Requests influence scheduling while limits bound container memory consumption” does not address the particular Kubernetes requirement “Persistent storage topology can limit where a Pod may safely start”.
C:Preferred scheduling preferences rank candidates without making placement mandatory. The operation “Preferred scheduling preferences rank candidates without making placement mandatory” does not address the particular Kubernetes requirement “Persistent storage topology can limit where a Pod may safely start”.
Question 657
For this Kubernetes condition, An administrator deletes a PVC and unexpectedly destroys critical underlying data. The proposed approach is: Review PV reclaim policy and lifecycle before deleting claims. Which technical principle BEST supports that choice?
- Reclaim policies such as Delete and Retain control backing-volume disposition
- PersistentVolumeClaims request storage independently of physical volume provisioning
- StorageClasses describe how persistent volumes are created by storage drivers
- Pod writable layers are ephemeral and do not guarantee persistence across replacement
Explanation
Correct Answer
A:Reclaim policies such as Delete and Retain control backing-volume disposition. That principle directly explains the selected remediation, review PV reclaim policy and lifecycle before deleting claims, for this case. Without the distinction, assuming every PV is retained can cause permanent loss after claim deletion. The expected confirmation is that a controlled test confirms the intended retain or delete behavior.
Incorrect Answers
B:PersistentVolumeClaims request storage independently of physical volume provisioning. The operation “PersistentVolumeClaims request storage independently of physical volume provisioning” does not address the particular Kubernetes requirement “Reclaim policies such as Delete and Retain control backing-volume disposition”.
C:StorageClasses describe how persistent volumes are created by storage drivers. The operation “StorageClasses describe how persistent volumes are created by storage drivers” does not address the particular Kubernetes requirement “Reclaim policies such as Delete and Retain control backing-volume disposition”.
D:Pod writable layers are ephemeral and do not guarantee persistence across replacement. The operation “Pod writable layers are ephemeral and do not guarantee persistence across replacement” does not address the particular Kubernetes requirement “Reclaim policies such as Delete and Retain control backing-volume disposition”.
Question 658
The team has not corrected this condition: A security gate wants to block high-risk image vulnerabilities before rollout. Which risk is MOST relevant?
- A Pod recreation can remove files that were never persisted outside its layer
- Treating a successful build as security approval can release vulnerable libraries
- A proprietary image layout may not work across compliant runtimes
- A bloated image may contain vulnerable software unused by the application
Explanation
Correct Answer
B:Treating a successful build as security approval can release vulnerable libraries. This is the direct concern in the stated scenario because container image scanning finds known package risk before admission. The matching mitigation is to scan release artifacts and enforce an approved image policy before deployment. Successful verification would show that the pipeline blocks an intentionally vulnerable test image under its policy.
Incorrect Answers
A:Container writable filesystems are ephemeral across replacement and rescheduling. That explains the warning “A Pod recreation can remove files that were never persisted outside its layer”; this case instead concerns “Treating a successful build as security approval can release vulnerable libraries”. Container image scanning finds known package risk before admission.
C:OCI specifications help standardize image packaging and execution interfaces. That explains the warning “A proprietary image layout may not work across compliant runtimes”; this case instead concerns “Treating a successful build as security approval can release vulnerable libraries”. Container image scanning finds known package risk before admission.
D:Reducing unneeded image contents reduces exposed packages and maintenance cost. That explains the warning “A bloated image may contain vulnerable software unused by the application”; this case instead concerns “Treating a successful build as security approval can release vulnerable libraries”. Container image scanning finds known package risk before admission.
Question 659
In the situation "An application works in development but fails in production because an API hostname differs", the team applies "Compare effective ConfigMaps, Secrets references, and environment settings". Which outcome is the strongest verification?
- The image download succeeds after correcting the registered pull credential
- The correlated failing request appears in logs from the affected replica
- The approved production endpoint is used and a smoke request succeeds
- Corrected arguments let the container remain Running without repeated restarts
Explanation
Correct Answer
C:The approved production endpoint is used and a smoke request succeeds. This is stronger than observing a saved configuration because it tests the actual outcome of compare effective ConfigMaps, Secrets references, and environment settings. The underlying principle is that application configuration differences are common causes of release-specific faults. The original risk was that rebuilding the identical binary cannot repair an incorrect environment URL.
Incorrect Answers
A: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 approved production endpoint is used and a smoke request succeeds”. Application configuration differences are common causes of release-specific faults.
B: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 “The approved production endpoint is used and a smoke request succeeds”. Application configuration differences are common causes of release-specific faults.
D:Startup failures often appear in terminated container output and process configuration. The observation “Corrected arguments let the container remain Running without repeated restarts” would validate that property, rather than the required “The approved production endpoint is used and a smoke request succeeds”. Application configuration differences are common causes of release-specific faults.
Question 660
A team implemented the proposed remedy for this problem: An application needs a changeable feature flag without rebuilding its container image. Which evidence BEST shows it works?
- The controller recreates missing desired objects after service restoration
- DNS resolution and requests continue to work after all backend Pod IPs change
- The desired configuration persists through controller restarts and Pod replacements
- A deployment uses the configured flag after an appropriate Pod or mount update
Explanation
Correct Answer
D:A deployment uses the configured flag after an appropriate Pod or mount update. This is stronger than observing a saved configuration because it tests the actual outcome of supply nonsecret configuration through a ConfigMap and suitable Pod reference. The underlying principle is that configMaps separate ordinary configuration data from immutable image content. The original risk was that baking every environment setting into images creates configuration and release drift.
Incorrect Answers
A: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 “A deployment uses the configured flag after an appropriate Pod or mount update”. ConfigMaps separate ordinary configuration data from immutable image content.
B:A Service provides a stable virtual endpoint decoupled from changing Pod addresses. The observation “DNS resolution and requests continue to work after all backend Pod IPs change” would validate that property, rather than the required “A deployment uses the configured flag after an appropriate Pod or mount update”. ConfigMaps separate ordinary configuration data from immutable image content.
C:Declarative reconciliation continually drives actual state toward API object specification. The observation “The desired configuration persists through controller restarts and Pod replacements” would validate that property, rather than the required “A deployment uses the configured flag after an appropriate Pod or mount update”. ConfigMaps separate ordinary configuration data from immutable image content.
