Kubernetes and Cloud Native Associate KCNA Practice Test 29
Question 280
A platform engineer recommends: Confirm dual-stack address families and supported Service IP family policy. The original problem is: A dual-stack cluster has IPv4 and IPv6 workloads that need consistent Service reachability. Which concept explains the remedy?
- LoadBalancer Services integrate with a compatible provider to provision external traffic access
- HTTP routing objects require a working controller to implement actual data-plane behavior
- NetworkPolicies specify allowable communication but require network-plugin enforcement
- Dual-stack configuration controls IPv4 and IPv6 allocation and Service behavior
Explanation
Correct Answer
D:Dual-stack configuration controls IPv4 and IPv6 allocation and Service behavior. That principle directly explains the selected remediation, confirm dual-stack address families and supported Service IP family policy, for this case. Without the distinction, assuming both IP families exist on every deployment can break one protocol. The expected confirmation is that both permitted address families resolve and connect according to the specified policy.
Incorrect Answers
A:LoadBalancer Services integrate with a compatible provider to provision external traffic access. The operation “LoadBalancer Services integrate with a compatible provider to provision external traffic access” does not address the particular Kubernetes requirement “Dual-stack configuration controls IPv4 and IPv6 allocation and Service behavior”.
B:HTTP routing objects require a working controller to implement actual data-plane behavior. The operation “HTTP routing objects require a working controller to implement actual data-plane behavior” does not address the particular Kubernetes requirement “Dual-stack configuration controls IPv4 and IPv6 allocation and Service behavior”.
C:NetworkPolicies specify allowable communication but require network-plugin enforcement. The operation “NetworkPolicies specify allowable communication but require network-plugin enforcement” does not address the particular Kubernetes requirement “Dual-stack configuration controls IPv4 and IPv6 allocation and Service behavior”.
Question 281
Consider this Kubernetes scenario: A specific worker becomes NotReady while other nodes continue to run normally. What is the BEST next action?
- Inspect kubelet, runtime, node conditions, and network status
- Use a scoped kubectl port-forward session and terminate it after testing
- Inspect PVC binding status, StorageClass, and volume topology events
- Check DNS policy, resolv.conf, CoreDNS Pod health, and network reachability
Explanation
Correct Answer
A:Inspect kubelet, runtime, node conditions, and network status. This is appropriate for the described asset and control gap because node Ready conditions summarize whether the node can safely host workloads. If the issue is left untreated, retrying an application request does not restore a failing kubelet. An assessor can verify remediation when the node becomes Ready after the recorded condition clears.
Incorrect Answers
B:Use a scoped kubectl port-forward session and terminate it after testing. The operation “Use a scoped kubectl port-forward session and terminate it after testing” does not address the particular Kubernetes requirement “Inspect kubelet, runtime, node conditions, and network status”.
C:Inspect PVC binding status, StorageClass, and volume topology events. The operation “Inspect PVC binding status, StorageClass, and volume topology events” does not address the particular Kubernetes requirement “Inspect kubelet, runtime, node conditions, and network status”.
D:Check DNS policy, resolv.conf, CoreDNS Pod health, and network reachability. The operation “Check DNS policy, resolv.conf, CoreDNS Pod health, and network reachability” does not address the particular Kubernetes requirement “Inspect kubelet, runtime, node conditions, and network status”.
Question 282
For this Kubernetes condition, An organization wants each product component to scale and deploy independently. The proposed approach is: Evaluate loosely coupled services with explicit API and ownership contracts. Which technical principle BEST supports that choice?
- Open standards reduce unnecessary vendor coupling across cloud-native infrastructure
- Cloud-native architecture often favors independently deployable components with clear boundaries
- Resilience patterns keep transient dependency faults from consuming all callers
- Infrastructure as code and desired-state convergence support repeatability and auditability
Explanation
Correct Answer
B:Cloud-native architecture often favors independently deployable components with clear boundaries. That principle directly explains the selected remediation, evaluate loosely coupled services with explicit API and ownership contracts, for this case. Without the distinction, splitting every function into microservices without contracts adds operational complexity. The expected confirmation is that each service deploys safely and interface compatibility tests protect consumers.
Incorrect Answers
A:Open standards reduce unnecessary vendor coupling across cloud-native infrastructure. The operation “Open standards reduce unnecessary vendor coupling across cloud-native infrastructure” does not address the particular Kubernetes requirement “Cloud-native architecture often favors independently deployable components with clear boundaries”.
C:Resilience patterns keep transient dependency faults from consuming all callers. The operation “Resilience patterns keep transient dependency faults from consuming all callers” does not address the particular Kubernetes requirement “Cloud-native architecture often favors independently deployable components with clear boundaries”.
D:Infrastructure as code and desired-state convergence support repeatability and auditability. The operation “Infrastructure as code and desired-state convergence support repeatability and auditability” does not address the particular Kubernetes requirement “Cloud-native architecture often favors independently deployable components with clear boundaries”.
Question 283
A cloud-native operations team faces this condition: A Prometheus server scrapes only half the exporters because labels point to the wrong port. Which response is MOST appropriate?
- Propagate supported trace context through each service call
- Replace unbounded identifiers with low-cardinality metric labels
- Review discovery labels, target endpoints, and scrape configuration
- Collect metrics, structured logs, and distributed traces with correlation identifiers
Explanation
Correct Answer
C:Review discovery labels, target endpoints, and scrape configuration. This is appropriate for the described asset and control gap because prometheus gathers time-series metrics from configured scrape targets. If the issue is left untreated, an exporter being Running does not mean Prometheus successfully collects it. An assessor can verify remediation when all expected targets report UP and sample metrics arrive with useful labels.
Incorrect Answers
A:Propagate supported trace context through each service call. The operation “Propagate supported trace context through each service call” does not address the particular Kubernetes requirement “Review discovery labels, target endpoints, and scrape configuration”.
B:Replace unbounded identifiers with low-cardinality metric labels. The operation “Replace unbounded identifiers with low-cardinality metric labels” does not address the particular Kubernetes requirement “Review discovery labels, target endpoints, and scrape configuration”.
D:Collect metrics, structured logs, and distributed traces with correlation identifiers. The operation “Collect metrics, structured logs, and distributed traces with correlation identifiers” does not address the particular Kubernetes requirement “Review discovery labels, target endpoints, and scrape configuration”.
Question 284
Consider this Kubernetes scenario: An application returns stale values because a dependency's DNS answer is cached too long. What is the BEST next action?
- Inspect the CronJob's created Jobs, deadlines, and logs separately
- Inspect previous container logs and the current image command and arguments
- Filter logs by namespace, labels, Pod identity, and relevant time range
- Inspect client DNS behavior and Service discovery updates during rollout
Explanation
Correct Answer
D:Inspect client DNS behavior and Service discovery updates during rollout. This is appropriate for the described asset and control gap because name-resolution caching can outlive endpoint or service changes in some clients. If the issue is left untreated, assuming every request repeats DNS resolution can hide stale connection targets. An assessor can verify remediation when a controlled backend transition refreshes the client destination successfully.
Incorrect Answers
A:Inspect the CronJob's created Jobs, deadlines, and logs separately. The operation “Inspect the CronJob's created Jobs, deadlines, and logs separately” does not address the particular Kubernetes requirement “Inspect client DNS behavior and Service discovery updates during rollout”.
B:Inspect previous container logs and the current image command and arguments. The operation “Inspect previous container logs and the current image command and arguments” does not address the particular Kubernetes requirement “Inspect client DNS behavior and Service discovery updates during rollout”.
C:Filter logs by namespace, labels, Pod identity, and relevant time range. The operation “Filter logs by namespace, labels, Pod identity, and relevant time range” does not address the particular Kubernetes requirement “Inspect client DNS behavior and Service discovery updates during rollout”.
Question 285
For this Kubernetes condition, An application in a Pod reads all namespace Secrets because it inherited a privileged identity. The proposed approach is: Create a dedicated minimally privileged service account and binding. Which technical principle BEST supports that choice?
- Pod service-account identity controls API access for in-cluster workloads
- Pod security context and admission standards limit process and host access
- Admission controls can reject noncompliant resources before they are stored
- Security contexts can enforce nonroot process identity for Pod containers
Explanation
Correct Answer
A:Pod service-account identity controls API access for in-cluster workloads. That principle directly explains the selected remediation, create a dedicated minimally privileged service account and binding, for this case. Without the distinction, sharing an overprivileged account lets one compromised app read unrelated secrets. The expected confirmation is that the Pod accesses its own approved object and gets a denial for unrelated Secrets.
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 “Pod service-account identity controls API access for in-cluster workloads”.
C: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 “Pod service-account identity controls API access for in-cluster workloads”.
D: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 service-account identity controls API access for in-cluster workloads”.
Question 286
The platform team applies this control: Use a NodePort Service when this exposure model is explicitly appropriate. The original issue is: Operators require temporary direct access to an application through each worker node address. Which observation BEST validates the result?
- The fully qualified Service name resolves to the expected target endpoint
- Requests to approved node ports reach the correct backend under firewall controls
- Connectivity tests succeed between Pod IPs on separate workers
- Requests for each host and path reach only its designated Service
Explanation
Correct Answer
B:Requests to approved node ports reach the correct backend under firewall controls. This is stronger than observing a saved configuration because it tests the actual outcome of use a NodePort Service when this exposure model is explicitly appropriate. The underlying principle is that nodePort makes a selected port accessible via nodes and forwards to the Service. The original risk was that assuming NodePort is a private-only endpoint can expose unintended access.
Incorrect Answers
A:DNS search paths are namespace-sensitive inside ordinary Pod configurations. The observation “The fully qualified Service name resolves to the expected target endpoint” would validate that property, rather than the required “Requests to approved node ports reach the correct backend under firewall controls”. NodePort makes a selected port accessible via nodes and forwards to the Service.
C: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 “Requests to approved node ports reach the correct backend under firewall controls”. NodePort makes a selected port accessible via nodes and forwards to the Service.
D: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 “Requests to approved node ports reach the correct backend under firewall controls”. NodePort makes a selected port accessible via nodes and forwards to the Service.
Question 287
An operator notices this unresolved gap: Two complete application environments should alternate traffic during approved releases. What consequence BEST explains the need to address it?
- Duplicating entire YAML files creates inconsistent security and probe settings
- Rebuilding from an unpinned branch during promotion can change program behavior
- Switching before validating the new environment can redirect all traffic to faults
- Manually editing a live container cannot recover a consistent prior release
Explanation
Correct Answer
C:Switching before validating the new environment can redirect all traffic to faults. This is the direct concern in the stated scenario because blue-green releases keep separate old and new environments during cutover. The matching mitigation is to use a blue-green strategy with a validated traffic-switch operation. Successful verification would show that the traffic switch is reversible and end-to-end smoke tests pass.
Incorrect Answers
A:Configuration overlays allow controlled differences without copying complete manifests. That explains the warning “Duplicating entire YAML files creates inconsistent security and probe settings”; this case instead concerns “Switching before validating the new environment can redirect all traffic to faults”. Blue-green releases keep separate old and new environments during cutover.
B:Artifact promotion preserves the same tested application bits across stages. That explains the warning “Rebuilding from an unpinned branch during promotion can change program behavior”; this case instead concerns “Switching before validating the new environment can redirect all traffic to faults”. Blue-green releases keep separate old and new environments during cutover.
D:Release tooling preserves revisions that support controlled restoration. That explains the warning “Manually editing a live container cannot recover a consistent prior release”; this case instead concerns “Switching before validating the new environment can redirect all traffic to faults”. Blue-green releases keep separate old and new environments during cutover.
Question 288
For this Kubernetes condition, A scheduler assigns Pods based on requests but users expect it to react to live utilization by itself. The proposed approach is: Use suitable autoscaling or descheduling components rather than assuming automatic migrations. Which technical principle BEST supports that choice?
- The scheduler tests resource requests against node allocatable capacity
- Preferred scheduling preferences rank candidates without making placement mandatory
- Persistent storage topology can limit where a Pod may safely start
- Default placement is not continuous live-CPU load balancing among healthy nodes
Explanation
Correct Answer
D:Default placement is not continuous live-CPU load balancing among healthy nodes. That principle directly explains the selected remediation, use suitable autoscaling or descheduling components rather than assuming automatic migrations, for this case. Without the distinction, leaving workloads to drift can create hotspots after initial scheduling. The expected confirmation is that measured autoscaling changes intended replica capacity without forced random migrations.
Incorrect Answers
A:The scheduler tests resource requests against node allocatable capacity. The operation “The scheduler tests resource requests against node allocatable capacity” does not address the particular Kubernetes requirement “Default placement is not continuous live-CPU load balancing among healthy nodes”.
B: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 “Default placement is not continuous live-CPU load balancing among healthy nodes”.
C:Persistent storage topology can limit where a Pod may safely start. The operation “Persistent storage topology can limit where a Pod may safely start” does not address the particular Kubernetes requirement “Default placement is not continuous live-CPU load balancing among healthy nodes”.
Question 289
The platform team applies this control: Follow the public Kubernetes contribution process and relevant SIG discussions. The original issue is: An API designer wants community consensus on a new Kubernetes scheduling field before any code is submitted. Which observation BEST validates the result?
- The change proposal is discussed in the correct SIG and receives documented review
- Multiple stakeholders participate through documented open community channels
- An onboarding guide maps each responsibility to the appropriate project process
- The evaluation records the actual current maturity and independent suitability evidence
Explanation
Correct Answer
A:The change proposal is discussed in the correct SIG and receives documented review. This is stronger than observing a saved configuration because it tests the actual outcome of follow the public Kubernetes contribution process and relevant SIG discussions. The underlying principle is that kubernetes development is organized through open governance and special interest groups. The original risk was that a private unreviewed patch may diverge from upstream behavior and maintenance practices.
Incorrect Answers
B:Vendor-neutral communities can coordinate shared cloud-native standards and adoption. The observation “Multiple stakeholders participate through documented open community channels” would validate that property, rather than the required “The change proposal is discussed in the correct SIG and receives documented review”. Kubernetes development is organized through open governance and special interest groups.
C:Community roles and technical roles have different ownership and decision rights. The observation “An onboarding guide maps each responsibility to the appropriate project process” would validate that property, rather than the required “The change proposal is discussed in the correct SIG and receives documented review”. Kubernetes development is organized through open governance and special interest groups.
D:CNCF maturity stages such as Sandbox, Incubating, and Graduated have distinct meanings. The observation “The evaluation records the actual current maturity and independent suitability evidence” would validate that property, rather than the required “The change proposal is discussed in the correct SIG and receives documented review”. Kubernetes development is organized through open governance and special interest groups.
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”.
