Kubernetes and Cloud Native Associate KCNA Practice Test 50
Question 490
The platform team applies this control: Compare Deployment conditions, Pod events, and readiness failures before promotion. The original issue is: A Deployment revision rolls out but a subset of Pods never reach Ready state. Which observation BEST validates the result?
- The Service has ready endpoints and test requests reach the target container port
- A corrected Pod passes readiness and rollout status becomes Complete
- Tests isolate one affected worker and service recovers after node remediation
- The failed Job records an actionable reason and the next run succeeds
Explanation
Correct Answer
B:A corrected Pod passes readiness and rollout status becomes Complete. This is stronger than observing a saved configuration because it tests the actual outcome of compare Deployment conditions, Pod events, and readiness failures before promotion. The underlying principle is that delivery debugging begins with resource status and failure conditions. The original risk was that assuming a completed image push means runtime readiness conceals deployment defects.
Incorrect Answers
A:Service networking requires matching endpoints and correct destination ports. The observation “The Service has ready endpoints and test requests reach the target container port” would validate that property, rather than the required “A corrected Pod passes readiness and rollout status becomes Complete”. Delivery debugging begins with resource status and failure conditions.
C:Node-local dataplane or runtime problems can affect only a subset of replicas. The observation “Tests isolate one affected worker and service recovers after node remediation” would validate that property, rather than the required “A corrected Pod passes readiness and rollout status becomes Complete”. Delivery debugging begins with resource status and failure conditions.
D:Recurring task execution is tracked through Job and CronJob objects. The observation “The failed Job records an actionable reason and the next run succeeds” would validate that property, rather than the required “A corrected Pod passes readiness and rollout status becomes Complete”. Delivery debugging begins with resource status and failure conditions.
Question 491
In the situation "A slow Java application repeatedly fails liveness checks while still initializing", the team applies "Add a startup probe so liveness is deferred until startup completes". Which outcome is the strongest verification?
- Requests through the Service reach the application on its listening port
- Ready replicas appear in EndpointSlices and complete test requests
- The app finishes startup before normal liveness and readiness checks begin
- The claim becomes Bound and the workload mounts the intended volume
Explanation
Correct Answer
C:The app finishes startup before normal liveness and readiness checks begin. This is stronger than observing a saved configuration because it tests the actual outcome of add a startup probe so liveness is deferred until startup completes. The underlying principle is that startup probes protect slow initialization from premature liveness restarts. The original risk was that aggressive liveness checks can keep a healthy slow-starting app in a reboot loop.
Incorrect Answers
A:Service targetPort maps the abstract port to the selected Pod's target. The observation “Requests through the Service reach the application on its listening port” would validate that property, rather than the required “The app finishes startup before normal liveness and readiness checks begin”. Startup probes protect slow initialization from premature liveness restarts.
B: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 “The app finishes startup before normal liveness and readiness checks begin”. Startup probes protect slow initialization from premature liveness restarts.
D: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 “The app finishes startup before normal liveness and readiness checks begin”. Startup probes protect slow initialization from premature liveness restarts.
Question 492
For this Kubernetes condition, A network application listens on port 9090 but a Service forwards to port 8080. The proposed approach is: Inspect Service targetPort and the container's actual listening endpoint. Which technical principle BEST supports that choice?
- CrashLoopBackOff reflects repeated container start failures with increasing delay
- Liveness probes detect a running container that requires restart
- Readiness failures remove unready containers from normal Service routing
- Service targetPort maps the abstract port to the selected Pod's target
Explanation
Correct Answer
D:Service targetPort maps the abstract port to the selected Pod's target. That principle directly explains the selected remediation, inspect Service targetPort and the container's actual listening endpoint, for this case. Without the distinction, a correct Service name cannot compensate for a wrong backend port. The expected confirmation is that requests through the Service reach the application on its listening port.
Incorrect Answers
A:CrashLoopBackOff reflects repeated container start failures with increasing delay. The operation “CrashLoopBackOff reflects repeated container start failures with increasing delay” does not address the particular Kubernetes requirement “Service targetPort maps the abstract port to the selected Pod's target”.
B:Liveness probes detect a running container that requires restart. The operation “Liveness probes detect a running container that requires restart” does not address the particular Kubernetes requirement “Service targetPort maps the abstract port to the selected Pod's target”.
C:Readiness failures remove unready containers from normal Service routing. The operation “Readiness failures remove unready containers from normal Service routing” does not address the particular Kubernetes requirement “Service targetPort maps the abstract port to the selected Pod's target”.
Question 493
A cloud-native operations team faces this condition: An engineer proposes storing a service-account token in source control for convenience. Which response is MOST appropriate?
- Use supported short-lived projected service-account tokens with audience restrictions
- Configure supported Pod Security Admission labels and verify enforcement levels
- Set runAsNonRoot and compatible user and filesystem settings
- Use workload identity with narrowly scoped external permissions
Explanation
Correct Answer
A:Use supported short-lived projected service-account tokens with audience restrictions. This is appropriate for the described asset and control gap because bound tokens reduce exposure compared with indefinite reusable credentials. If the issue is left untreated, committed long-lived bearer tokens may remain valid after repository deletion. An assessor can verify remediation when the projected token expires and unauthorized audiences cannot reuse it.
Incorrect Answers
B:Configure supported Pod Security Admission labels and verify enforcement levels. The operation “Configure supported Pod Security Admission labels and verify enforcement levels” does not address the particular Kubernetes requirement “Use supported short-lived projected service-account tokens with audience restrictions”.
C:Set runAsNonRoot and compatible user and filesystem settings. The operation “Set runAsNonRoot and compatible user and filesystem settings” does not address the particular Kubernetes requirement “Use supported short-lived projected service-account tokens with audience restrictions”.
D:Use workload identity with narrowly scoped external permissions. The operation “Use workload identity with narrowly scoped external permissions” does not address the particular Kubernetes requirement “Use supported short-lived projected service-account tokens with audience restrictions”.
Question 494
An operator notices this unresolved gap: A production change must wait for a security approval after staging validation. What consequence BEST explains the need to address it?
- Switching every user at once makes regression impact harder to contain
- Automatically pushing every successful build to production bypasses change control
- Deleting every old Pod at once may create a user-visible service outage
- Hand-edited copies can diverge and make rollback unpredictable
Explanation
Correct Answer
B:Automatically pushing every successful build to production bypasses change control. This is the direct concern in the stated scenario because continuous delivery can require approvals without conflating deployment with building. The matching mitigation is to implement a CI/CD promotion gate separating build, test, and release stages. Successful verification would show that the release log shows validated artifacts and the required approval decision.
Incorrect Answers
A:Canary delivery limits the blast radius of new behavior for evaluation. That explains the warning “Switching every user at once makes regression impact harder to contain”; this case instead concerns “Automatically pushing every successful build to production bypasses change control”. Continuous delivery can require approvals without conflating deployment with building.
C:Rolling updates progressively replace Pods while controlling replacement availability. That explains the warning “Deleting every old Pod at once may create a user-visible service outage”; this case instead concerns “Automatically pushing every successful build to production bypasses change control”. Continuous delivery can require approvals without conflating deployment with building.
D:Helm templates Kubernetes resources and tracks packaged release revisions. That explains the warning “Hand-edited copies can diverge and make rollback unpredictable”; this case instead concerns “Automatically pushing every successful build to production bypasses change control”. Continuous delivery can require approvals without conflating deployment with building.
Question 495
For this Kubernetes condition, A new service is healthy locally but is unreachable through its cluster virtual Service. The proposed approach is: Verify Service selector, endpoint readiness, port, and targetPort mappings. Which technical principle BEST supports that choice?
- Recurring task execution is tracked through Job and CronJob objects
- An OOM termination indicates a breached memory boundary or node memory pressure
- Service networking requires matching endpoints and correct destination ports
- Delivery debugging begins with resource status and failure conditions
Explanation
Correct Answer
C:Service networking requires matching endpoints and correct destination ports. That principle directly explains the selected remediation, verify Service selector, endpoint readiness, port, and targetPort mappings, for this case. Without the distinction, increasing application replicas cannot fix a Service with no matched endpoints. The expected confirmation is that the Service has ready endpoints and test requests reach the target container port.
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 “Service networking requires matching endpoints and correct destination ports”.
B:An OOM termination indicates a breached memory boundary or node memory pressure. The operation “An OOM termination indicates a breached memory boundary or node memory pressure” does not address the particular Kubernetes requirement “Service networking requires matching endpoints and correct destination ports”.
D:Delivery debugging begins with resource status and failure conditions. The operation “Delivery debugging begins with resource status and failure conditions” does not address the particular Kubernetes requirement “Service networking requires matching endpoints and correct destination ports”.
Question 496
A platform engineer recommends: Remove secrets from image layers and use controlled runtime secret delivery. The original problem is: A container image stores credentials in its build arguments and image history. Which concept explains the remedy?
- Image tags are mutable references while digests identify specific image content
- Multi-stage builds copy only selected results into the final container image
- Image pull policy determines whether a node checks the registry for an image
- Image history and published layers may expose secrets even when files are deleted later
Explanation
Correct Answer
D:Image history and published layers may expose secrets even when files are deleted later. That principle directly explains the selected remediation, remove secrets from image layers and use controlled runtime secret delivery, for this case. Without the distinction, changing the last Dockerfile command will not erase a previously leaked credential. The expected confirmation is that a verified image inspection finds no secrets and the exposed credential is rotated.
Incorrect Answers
A: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 “Image history and published layers may expose secrets even when files are deleted later”.
B:Multi-stage builds copy only selected results into the final container image. The operation “Multi-stage builds copy only selected results into the final container image” does not address the particular Kubernetes requirement “Image history and published layers may expose secrets even when files are deleted later”.
C: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 “Image history and published layers may expose secrets even when files are deleted later”.
Question 497
An operator notices this unresolved gap: A platform team wants a neutral venue for collaboration across competing cloud providers. What consequence BEST explains the need to address it?
- Relying solely on one provider's private roadmap may increase dependency risk
- Publishing an untested fix outside the community can fragment maintenance
- Assuming every hosted project has equal maturity can distort procurement decisions
- Assuming every user can approve an upstream release obscures project governance
Explanation
Correct Answer
A:Relying solely on one provider's private roadmap may increase dependency risk. This is the direct concern in the stated scenario because vendor-neutral communities can coordinate shared cloud-native standards and adoption. The matching mitigation is to evaluate CNCF community structures and Linux Foundation open governance principles. Successful verification would show that multiple stakeholders participate through documented open community channels.
Incorrect Answers
B:Open-source collaboration relies on actionable reports and maintainer review. That explains the warning “Publishing an untested fix outside the community can fragment maintenance”; this case instead concerns “Relying solely on one provider's private roadmap may increase dependency risk”. Vendor-neutral communities can coordinate shared cloud-native standards and adoption.
C:CNCF maturity stages such as Sandbox, Incubating, and Graduated have distinct meanings. That explains the warning “Assuming every hosted project has equal maturity can distort procurement decisions”; this case instead concerns “Relying solely on one provider's private roadmap may increase dependency risk”. Vendor-neutral communities can coordinate shared cloud-native standards and adoption.
D:Community roles and technical roles have different ownership and decision rights. That explains the warning “Assuming every user can approve an upstream release obscures project governance”; this case instead concerns “Relying solely on one provider's private roadmap may increase dependency risk”. Vendor-neutral communities can coordinate shared cloud-native standards and adoption.
Question 498
In a Kubernetes environment this issue remains open: A developer needs to identify which users can update Deployments in one namespace. Which failure is the MOST direct consequence?
- Increasing Pod memory limits alone does not provide extra replicas
- Assuming source repository access equals cluster authorization misstates privileges
- A successful manifest apply does not guarantee replacement Pods became healthy
- Inferring the labels from a local stale repository file may be inaccurate
Explanation
Correct Answer
B:Assuming source repository access equals cluster authorization misstates privileges. This is the direct concern in the stated scenario because rBAC permissions are granted through bound roles rather than folder ownership. The matching mitigation is to review Role, RoleBinding, and subject references for the namespace. Successful verification would show that a test user can read allowed objects but cannot update forbidden Deployments.
Incorrect Answers
A:Replica count can be adjusted without modifying container application source. That explains the warning “Increasing Pod memory limits alone does not provide extra replicas”; this case instead concerns “Assuming source repository access equals cluster authorization misstates privileges”. RBAC permissions are granted through bound roles rather than folder ownership.
C:Rollout observability distinguishes declared updates from successful availability. That explains the warning “A successful manifest apply does not guarantee replacement Pods became healthy”; this case instead concerns “Assuming source repository access equals cluster authorization misstates privileges”. RBAC permissions are granted through bound roles rather than folder ownership.
D:Structured API output exposes desired specifications and object metadata. That explains the warning “Inferring the labels from a local stale repository file may be inaccurate”; this case instead concerns “Assuming source repository access equals cluster authorization misstates privileges”. RBAC permissions are granted through bound roles rather than folder ownership.
Question 499
The platform team applies this control: Inspect owner references and finalizers before forcing orphan cleanup. The original issue is: Deleting a Deployment leaves owned child resources unexpectedly pending deletion. Which observation BEST validates the result?
- Each eligible node reports exactly one healthy agent Pod
- The desired configuration persists through controller restarts and Pod replacements
- An approved cleanup clears blockers and owned resources are removed safely
- Deleting one replica causes its replacement and desired count is restored
Explanation
Correct Answer
C:An approved cleanup clears blockers and owned resources are removed safely. This is stronger than observing a saved configuration because it tests the actual outcome of inspect owner references and finalizers before forcing orphan cleanup. The underlying principle is that kubernetes garbage collection uses owner references while finalizers can delay removal. The original risk was that blindly deleting finalizers may bypass resource cleanup responsibilities.
Incorrect Answers
A:DaemonSets maintain a designated Pod copy on every selected node. The observation “Each eligible node reports exactly one healthy agent Pod” would validate that property, rather than the required “An approved cleanup clears blockers and owned resources are removed safely”. Kubernetes garbage collection uses owner references while finalizers can delay removal.
B: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 “An approved cleanup clears blockers and owned resources are removed safely”. Kubernetes garbage collection uses owner references while finalizers can delay removal.
D:A Deployment reconciles ReplicaSets to maintain desired stateless workload capacity. The observation “Deleting one replica causes its replacement and desired count is restored” would validate that property, rather than the required “An approved cleanup clears blockers and owned resources are removed safely”. Kubernetes garbage collection uses owner references while finalizers can delay removal.
Question 500
Consider this Kubernetes scenario: A web service needs five identical Pods with replacement when one worker crashes. What is the BEST next action?
- Supply nonsecret configuration through a ConfigMap and suitable Pod reference
- Reference a Kubernetes Secret with least-privilege access and encryption-at-rest policy
- Protect and back up etcd according to the cluster distribution recovery procedure
- Create a Deployment with the required replicas and a Pod template
Explanation
Correct Answer
D:Create a Deployment with the required replicas and a Pod template. This is appropriate for the described asset and control gap because a Deployment reconciles ReplicaSets to maintain desired stateless workload capacity. If the issue is left untreated, manually creating independent Pods provides no reliable replica reconciliation. An assessor can verify remediation when deleting one replica causes its replacement and desired count is restored.
Incorrect Answers
A: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 “Create a Deployment with the required replicas and a Pod template”.
B:Reference a Kubernetes Secret with least-privilege access and encryption-at-rest policy. The operation “Reference a Kubernetes Secret with least-privilege access and encryption-at-rest policy” does not address the particular Kubernetes requirement “Create a Deployment with the required replicas and a Pod template”.
C:Protect and back up etcd according to the cluster distribution recovery procedure. The operation “Protect and back up etcd according to the cluster distribution recovery procedure” does not address the particular Kubernetes requirement “Create a Deployment with the required replicas and a Pod template”.
