Kubernetes and Cloud Native Associate KCNA Practice Test 30
Question 290
Given the requirement "A production change must wait for a security approval after staging validation", the proposed fix is "Implement a CI/CD promotion gate separating build, test, and release stages". Which principle explains why it works?
- Delivery gates use measured user outcomes to decide whether to continue rollout
- Continuous delivery can require approvals without conflating deployment with building
- Release tooling preserves revisions that support controlled restoration
- Helm templates Kubernetes resources and tracks packaged release revisions
Explanation
Correct Answer
B:Continuous delivery can require approvals without conflating deployment with building. That principle directly explains the selected remediation, implement a CI/CD promotion gate separating build, test, and release stages, for this case. Without the distinction, automatically pushing every successful build to production bypasses change control. The expected confirmation is that the release log shows validated artifacts and the required approval decision.
Incorrect Answers
A:Delivery gates use measured user outcomes to decide whether to continue rollout. The operation “Delivery gates use measured user outcomes to decide whether to continue rollout” does not address the particular Kubernetes requirement “Continuous delivery can require approvals without conflating deployment with building”.
C:Release tooling preserves revisions that support controlled restoration. The operation “Release tooling preserves revisions that support controlled restoration” does not address the particular Kubernetes requirement “Continuous delivery can require approvals without conflating deployment with building”.
D:Helm templates Kubernetes resources and tracks packaged release revisions. The operation “Helm templates Kubernetes resources and tracks packaged release revisions” does not address the particular Kubernetes requirement “Continuous delivery can require approvals without conflating deployment with building”.
Question 291
In a Kubernetes environment this issue remains open: A Pod resolves an external domain but cannot resolve another Service by its short name. Which failure is the MOST direct consequence?
- Blindly deleting finalizers may bypass resource cleanup responsibilities
- Writing cluster state through an unsupported path bypasses expected API safeguards
- Hardcoding current Pod IPs to bypass name resolution creates fragile dependencies
- Putting every resource in default creates collisions and weak administration boundaries
Explanation
Correct Answer
C:Hardcoding current Pod IPs to bypass name resolution creates fragile dependencies. This is the direct concern in the stated scenario because cluster DNS maps Kubernetes Service names to records within configured search domains. The matching mitigation is to inspect CoreDNS and the namespace-aware Service DNS naming rules. Successful verification would show that the proper service.namespace DNS name resolves to its expected ClusterIP.
Incorrect Answers
A:Kubernetes garbage collection uses owner references while finalizers can delay removal. That explains the warning “Blindly deleting finalizers may bypass resource cleanup responsibilities”; this case instead concerns “Hardcoding current Pod IPs to bypass name resolution creates fragile dependencies”. Cluster DNS maps Kubernetes Service names to records within configured search domains.
B:The API server validates requests and exposes the supported declarative control interface. That explains the warning “Writing cluster state through an unsupported path bypasses expected API safeguards”; this case instead concerns “Hardcoding current Pod IPs to bypass name resolution creates fragile dependencies”. Cluster DNS maps Kubernetes Service names to records within configured search domains.
D:Namespaces partition names and policy scope for namespaced Kubernetes resources. That explains the warning “Putting every resource in default creates collisions and weak administration boundaries”; this case instead concerns “Hardcoding current Pod IPs to bypass name resolution creates fragile dependencies”. Cluster DNS maps Kubernetes Service names to records within configured search domains.
Question 292
A cloud-native operations team faces this condition: A Pod is Pending because required affinity matches no current node. Which response is MOST appropriate?
- Apply required Pod anti-affinity using a node topology key
- Use topology spread constraints with the proper topology key and skew
- Apply preferred node affinity with a documented scheduling weight
- Inspect failed-scheduling conditions and compare affinity with node labels
Explanation
Correct Answer
D:Inspect failed-scheduling conditions and compare affinity with node labels. This is appropriate for the described asset and control gap because unsatisfied hard node affinity prevents scheduler placement despite free resources. If the issue is left untreated, deleting unrelated running Pods cannot create a matching node label. An assessor can verify remediation when after a correct node label or policy change the Pod becomes scheduled.
Incorrect Answers
A:Apply required Pod anti-affinity using a node topology key. The operation “Apply required Pod anti-affinity using a node topology key” does not address the particular Kubernetes requirement “Inspect failed-scheduling conditions and compare affinity with node labels”.
B:Use topology spread constraints with the proper topology key and skew. The operation “Use topology spread constraints with the proper topology key and skew” does not address the particular Kubernetes requirement “Inspect failed-scheduling conditions and compare affinity with node labels”.
C:Apply preferred node affinity with a documented scheduling weight. The operation “Apply preferred node affinity with a documented scheduling weight” does not address the particular Kubernetes requirement “Inspect failed-scheduling conditions and compare affinity with node labels”.
Question 293
In the situation "A container repeatedly fails after a new image was promoted but the old image worked", the team applies "Compare revision diffs and rollback to a validated prior release if necessary". Which outcome is the strongest verification?
- Rollback restores service while the failing revision is retained for analysis
- A rollout load test maintains successful responses during replacement
- The failed Job records an actionable reason and the next run succeeds
- A controlled backend transition refreshes the client destination successfully
Explanation
Correct Answer
A:Rollback restores service while the failing revision is retained for analysis. This is stronger than observing a saved configuration because it tests the actual outcome of compare revision diffs and rollback to a validated prior release if necessary. The underlying principle is that version-aware troubleshooting isolates failures introduced by specific changes. The original risk was that restarting identical faulty images cannot repair a deterministic regression.
Incorrect Answers
B:Traffic routing and Pod lifecycle transitions must be coordinated during delivery. The observation “A rollout load test maintains successful responses during replacement” would validate that property, rather than the required “Rollback restores service while the failing revision is retained for analysis”. Version-aware troubleshooting isolates failures introduced by specific changes.
C: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 “Rollback restores service while the failing revision is retained for analysis”. Version-aware troubleshooting isolates failures introduced by specific changes.
D:Name-resolution caching can outlive endpoint or service changes in some clients. The observation “A controlled backend transition refreshes the client destination successfully” would validate that property, rather than the required “Rollback restores service while the failing revision is retained for analysis”. Version-aware troubleshooting isolates failures introduced by specific changes.
Question 294
For this Kubernetes condition, An engineer needs to roll back an application after the new image violates latency objectives. The proposed approach is: Use the versioned Deployment or delivery tool rollback workflow. Which technical principle BEST supports that choice?
- Continuous delivery can require approvals without conflating deployment with building
- Release tooling preserves revisions that support controlled restoration
- Canary delivery limits the blast radius of new behavior for evaluation
- Configuration overlays allow controlled differences without copying complete manifests
Explanation
Correct Answer
B:Release tooling preserves revisions that support controlled restoration. That principle directly explains the selected remediation, use the versioned Deployment or delivery tool rollback workflow, for this case. Without the distinction, manually editing a live container cannot recover a consistent prior release. The expected confirmation is that the prior verified revision is serving after an automated rollback.
Incorrect Answers
A:Continuous delivery can require approvals without conflating deployment with building. The operation “Continuous delivery can require approvals without conflating deployment with building” does not address the particular Kubernetes requirement “Release tooling preserves revisions that support controlled restoration”.
C:Canary delivery limits the blast radius of new behavior for evaluation. The operation “Canary delivery limits the blast radius of new behavior for evaluation” does not address the particular Kubernetes requirement “Release tooling preserves revisions that support controlled restoration”.
D:Configuration overlays allow controlled differences without copying complete manifests. The operation “Configuration overlays allow controlled differences without copying complete manifests” does not address the particular Kubernetes requirement “Release tooling preserves revisions that support controlled restoration”.
Question 295
The platform team applies this control: Package and manage shared resources through Helm charts with explicit values. The original issue is: A team releases the same application using manually edited YAML in each environment. Which observation BEST validates the result?
- An update drains active requests before the previous Pod is removed
- A reviewed commit is reconciled and unauthorized live drift is corrected
- A consistent chart deploys with separately reviewed development and production values
- Each environment renders the same base with only documented overrides
Explanation
Correct Answer
C:A consistent chart deploys with separately reviewed development and production values. This is stronger than observing a saved configuration because it tests the actual outcome of package and manage shared resources through Helm charts with explicit values. The underlying principle is that helm templates Kubernetes resources and tracks packaged release revisions. The original risk was that hand-edited copies can diverge and make rollback unpredictable.
Incorrect Answers
A:Kubernetes sends shutdown signals and allows bounded cleanup before forced stop. The observation “An update drains active requests before the previous Pod is removed” would validate that property, rather than the required “A consistent chart deploys with separately reviewed development and production values”. Helm templates Kubernetes resources and tracks packaged release revisions.
B:GitOps uses declared source-control desired state with automated convergence. The observation “A reviewed commit is reconciled and unauthorized live drift is corrected” would validate that property, rather than the required “A consistent chart deploys with separately reviewed development and production values”. Helm templates Kubernetes resources and tracks packaged release revisions.
D:Configuration overlays allow controlled differences without copying complete manifests. The observation “Each environment renders the same base with only documented overrides” would validate that property, rather than the required “A consistent chart deploys with separately reviewed development and production values”. Helm templates Kubernetes resources and tracks packaged release revisions.
Question 296
An operator notices this unresolved gap: A Pod cannot retrieve a private image from its authorized enterprise registry. What consequence BEST explains the need to address it?
- Treating every container as a complete VM obscures shared kernel risks
- A bloated image may contain vulnerable software unused by the application
- Building mutable local state without source control undermines release reproducibility
- Mounting registry credentials as unrelated app secrets will not fix image pulls
Explanation
Correct Answer
D:Mounting registry credentials as unrelated app secrets will not fix image pulls. This is the direct concern in the stated scenario because registry authentication is distinct from Kubernetes workload API authorization. The matching mitigation is to configure a scoped imagePullSecret on the appropriate Pod or service account. Successful verification would show that image pulls succeed for the authorized registry while anonymous pulls fail.
Incorrect Answers
A:Containers package processes and dependencies without emulating a full guest OS. That explains the warning “Treating every container as a complete VM obscures shared kernel risks”; this case instead concerns “Mounting registry credentials as unrelated app secrets will not fix image pulls”. Registry authentication is distinct from Kubernetes workload API authorization.
B: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 “Mounting registry credentials as unrelated app secrets will not fix image pulls”. Registry authentication is distinct from Kubernetes workload API authorization.
C:Image builds package application layers from reproducible instructions. That explains the warning “Building mutable local state without source control undermines release reproducibility”; this case instead concerns “Mounting registry credentials as unrelated app secrets will not fix image pulls”. Registry authentication is distinct from Kubernetes workload API authorization.
Question 297
For this Kubernetes condition, An engineer proposes storing a service-account token in source control for convenience. The proposed approach is: Use supported short-lived projected service-account tokens with audience restrictions. Which technical principle BEST supports that choice?
- Bound tokens reduce exposure compared with indefinite reusable credentials
- Pod security context and admission standards limit process and host access
- Pod service-account identity controls API access for in-cluster workloads
- Admission controls can reject noncompliant resources before they are stored
Explanation
Correct Answer
A:Bound tokens reduce exposure compared with indefinite reusable credentials. That principle directly explains the selected remediation, use supported short-lived projected service-account tokens with audience restrictions, for this case. Without the distinction, committed long-lived bearer tokens may remain valid after repository deletion. The expected confirmation is that the projected token expires and unauthorized audiences cannot reuse it.
Incorrect Answers
B:Pod security context and admission standards limit process and host access. The operation “Pod security context and admission standards limit process and host access” does not address the particular Kubernetes requirement “Bound tokens reduce exposure compared with indefinite reusable credentials”.
C:Pod service-account identity controls API access for in-cluster workloads. The operation “Pod service-account identity controls API access for in-cluster workloads” does not address the particular Kubernetes requirement “Bound tokens reduce exposure compared with indefinite reusable credentials”.
D:Admission controls can reject noncompliant resources before they are stored. The operation “Admission controls can reject noncompliant resources before they are stored” does not address the particular Kubernetes requirement “Bound tokens reduce exposure compared with indefinite reusable credentials”.
Question 298
A cloud-native operations team faces this condition: A team must understand why Kubernetes is part of a broader cloud-native ecosystem. Which response is MOST appropriate?
- Apply timeouts, bounded retries, and circuit-breaking where appropriate
- Explain containers, orchestration, automation, observability, and open interfaces together
- Design horizontal scaling with realistic resource metrics and graceful capacity limits
- Use portable OCI images and standard Kubernetes APIs where practical
Explanation
Correct Answer
B:Explain containers, orchestration, automation, observability, and open interfaces together. This is appropriate for the described asset and control gap because cloud-native systems combine organizational practices and technology, not only a container runtime. If the issue is left untreated, treating containers alone as cloud-native adoption can ignore deployment and reliability needs. An assessor can verify remediation when the architecture design accounts for automated rollout, monitoring, and scaling.
Incorrect Answers
A:Apply timeouts, bounded retries, and circuit-breaking where appropriate. The operation “Apply timeouts, bounded retries, and circuit-breaking where appropriate” does not address the particular Kubernetes requirement “Explain containers, orchestration, automation, observability, and open interfaces together”.
C:Design horizontal scaling with realistic resource metrics and graceful capacity limits. The operation “Design horizontal scaling with realistic resource metrics and graceful capacity limits” does not address the particular Kubernetes requirement “Explain containers, orchestration, automation, observability, and open interfaces together”.
D:Use portable OCI images and standard Kubernetes APIs where practical. The operation “Use portable OCI images and standard Kubernetes APIs where practical” does not address the particular Kubernetes requirement “Explain containers, orchestration, automation, observability, and open interfaces together”.
Question 299
In the situation "An alert fires on every harmless CPU spike and overwhelms the on-call team", the team applies "Alert on meaningful sustained user impact and tune severity and routing". Which outcome is the strongest verification?
- A shared collector receives usable traces and metrics from multiple service runtimes
- Series count falls while aggregate service-level signals remain available
- A controlled user-impact regression pages on-call while short harmless spikes do not
- A documented availability SLI drives a clear SLO and measured error budget
Explanation
Correct Answer
C:A controlled user-impact regression pages on-call while short harmless spikes do not. This is stronger than observing a saved configuration because it tests the actual outcome of alert on meaningful sustained user impact and tune severity and routing. The underlying principle is that actionable alerting links signals to service health and response decisions. The original risk was that noisy threshold alerts create fatigue and can hide real incidents.
Incorrect Answers
A:OpenTelemetry standardizes telemetry generation and transport across languages. The observation “A shared collector receives usable traces and metrics from multiple service runtimes” would validate that property, rather than the required “A controlled user-impact regression pages on-call while short harmless spikes do not”. Actionable alerting links signals to service health and response decisions.
B:High-cardinality labels increase time-series storage and query pressure. The observation “Series count falls while aggregate service-level signals remain available” would validate that property, rather than the required “A controlled user-impact regression pages on-call while short harmless spikes do not”. Actionable alerting links signals to service health and response decisions.
D:SLIs quantify observable service behavior while SLOs express a reliability target. The observation “A documented availability SLI drives a clear SLO and measured error budget” would validate that property, rather than the required “A controlled user-impact regression pages on-call while short harmless spikes do not”. Actionable alerting links signals to service health and response decisions.
Question 300
For this Kubernetes condition, An administrator wants to examine only workloads belonging to the payments namespace. The proposed approach is: Use a namespace-scoped kubectl query with the explicit namespace flag. Which technical principle BEST supports that choice?
- Namespace quotas constrain aggregate API resource consumption
- Cluster management is expressed primarily through versioned API objects
- Deployment revision history supports rollback of Pod-template changes
- Namespaced API queries avoid mixing identical resource names from other teams
Explanation
Correct Answer
D:Namespaced API queries avoid mixing identical resource names from other teams. That principle directly explains the selected remediation, use a namespace-scoped kubectl query with the explicit namespace flag, for this case. Without the distinction, running an unrestricted query can lead to changing the wrong team's workload. The expected confirmation is that the command returns only payments resources and excludes other namespaces.
Incorrect Answers
A:Namespace quotas constrain aggregate API resource consumption. The operation “Namespace quotas constrain aggregate API resource consumption” does not address the particular Kubernetes requirement “Namespaced API queries avoid mixing identical resource names from other teams”.
B:Cluster management is expressed primarily through versioned API objects. The operation “Cluster management is expressed primarily through versioned API objects” does not address the particular Kubernetes requirement “Namespaced API queries avoid mixing identical resource names from other teams”.
C: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 “Namespaced API queries avoid mixing identical resource names from other teams”.
