Kubernetes and Cloud Native Associate KCNA Practice Test 9
Question 80
Given the requirement "An internal service needs a stable address reachable only inside the cluster network", the proposed fix is "Select a ClusterIP Service and match it to the intended backend Pods". Which principle explains why it works?
- HTTP routing objects require a working controller to implement actual data-plane behavior
- CNI plugins configure Pod network connectivity across the cluster
- NodePort makes a selected port accessible via nodes and forwards to the Service
- ClusterIP exposes an in-cluster virtual service endpoint by default
Explanation
Correct Answer
D:ClusterIP exposes an in-cluster virtual service endpoint by default. That principle directly explains the selected remediation, select a ClusterIP Service and match it to the intended backend Pods, for this case. Without the distinction, changing to NodePort unnecessarily exposes a new reachable node-level port. The expected confirmation is that the service resolves and responds internally without an external node port.
Incorrect Answers
A: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 “ClusterIP exposes an in-cluster virtual service endpoint by default”.
B:CNI plugins configure Pod network connectivity across the cluster. The operation “CNI plugins configure Pod network connectivity across the cluster” does not address the particular Kubernetes requirement “ClusterIP exposes an in-cluster virtual service endpoint by default”.
C:NodePort makes a selected port accessible via nodes and forwards to the Service. The operation “NodePort makes a selected port accessible via nodes and forwards to the Service” does not address the particular Kubernetes requirement “ClusterIP exposes an in-cluster virtual service endpoint by default”.
Question 81
A team implemented the proposed remedy for this problem: A team has multiple similarly named clusters and needs safe scripting for read-only checks. Which evidence BEST shows it works?
- A dry run shows each command's target cluster and namespace unambiguously
- The prior image is restored and healthy endpoints are serving requests
- The reported warning identifies the blocked scheduling or image-pull step
- The API output reflects current labels and the current resource version
Explanation
Correct Answer
A:A dry run shows each command's target cluster and namespace unambiguously. This is stronger than observing a saved configuration because it tests the actual outcome of pass an explicit context and namespace to automation rather than relying on defaults. The underlying principle is that automation should bind every Kubernetes command to its intended target environment. The original risk was that inherited interactive context can send scripts to the wrong cluster.
Incorrect Answers
B:Deployment revision history supports rollback of Pod-template changes. The observation “The prior image is restored and healthy endpoints are serving requests” would validate that property, rather than the required “A dry run shows each command's target cluster and namespace unambiguously”. Automation should bind every Kubernetes command to its intended target environment.
C:Object descriptions expose controller and scheduler diagnostics beyond names and phases. The observation “The reported warning identifies the blocked scheduling or image-pull step” would validate that property, rather than the required “A dry run shows each command's target cluster and namespace unambiguously”. Automation should bind every Kubernetes command to its intended target environment.
D:Structured API output exposes desired specifications and object metadata. The observation “The API output reflects current labels and the current resource version” would validate that property, rather than the required “A dry run shows each command's target cluster and namespace unambiguously”. Automation should bind every Kubernetes command to its intended target environment.
Question 82
The team has not corrected this condition: A new service is healthy locally but is unreachable through its cluster virtual Service. Which risk is MOST relevant?
- Restarting identical faulty images cannot repair a deterministic regression
- Increasing application replicas cannot fix a Service with no matched endpoints
- One healthy Pod's logs cannot exonerate a different crashing replica
- Relying on Pod phase alone can conceal saturation or failed dependencies
Explanation
Correct Answer
B:Increasing application replicas cannot fix a Service with no matched endpoints. This is the direct concern in the stated scenario because service networking requires matching endpoints and correct destination ports. The matching mitigation is to verify Service selector, endpoint readiness, port, and targetPort mappings. Successful verification would show that the Service has ready endpoints and test requests reach the target container port.
Incorrect Answers
A:Version-aware troubleshooting isolates failures introduced by specific changes. That explains the warning “Restarting identical faulty images cannot repair a deterministic regression”; this case instead concerns “Increasing application replicas cannot fix a Service with no matched endpoints”. Service networking requires matching endpoints and correct destination ports.
C:Distributed services require selecting the affected execution instance. That explains the warning “One healthy Pod's logs cannot exonerate a different crashing replica”; this case instead concerns “Increasing application replicas cannot fix a Service with no matched endpoints”. Service networking requires matching endpoints and correct destination ports.
D:A Running Pod indicates process state rather than end-to-end service success. That explains the warning “Relying on Pod phase alone can conceal saturation or failed dependencies”; this case instead concerns “Increasing application replicas cannot fix a Service with no matched endpoints”. Service networking requires matching endpoints and correct destination ports.
Question 83
Consider this Kubernetes scenario: A compiled application needs a tiny runtime image without source compilers. What is the BEST next action?
- Configure a scoped imagePullSecret on the appropriate Pod or service account
- Inspect the node's CRI-compatible runtime service and kubelet connection
- Use multi-stage builds to separate build tools from runtime artifacts
- Run the container with an unprivileged UID and restricted capabilities
Explanation
Correct Answer
C:Use multi-stage builds to separate build tools from runtime artifacts. This is appropriate for the described asset and control gap because multi-stage builds copy only selected results into the final container image. If the issue is left untreated, shipping compilers and build caches unnecessarily increases image size and risk. An assessor can verify remediation when the final image runs the binary without development toolchains installed.
Incorrect Answers
A:Configure a scoped imagePullSecret on the appropriate Pod or service account. The operation “Configure a scoped imagePullSecret on the appropriate Pod or service account” does not address the particular Kubernetes requirement “Use multi-stage builds to separate build tools from runtime artifacts”.
B:Inspect the node's CRI-compatible runtime service and kubelet connection. The operation “Inspect the node's CRI-compatible runtime service and kubelet connection” does not address the particular Kubernetes requirement “Use multi-stage builds to separate build tools from runtime artifacts”.
D:Run the container with an unprivileged UID and restricted capabilities. The operation “Run the container with an unprivileged UID and restricted capabilities” does not address the particular Kubernetes requirement “Use multi-stage builds to separate build tools from runtime artifacts”.
Question 84
A Kubernetes platform team observes this situation: A crashing container exits before an engineer can read its most recent startup output. Which action BEST addresses the requirement?
- Use supported Kubernetes API configuration workflows and controlled reviews
- Apply a ResourceQuota appropriate to the namespace and its workload needs
- Use the appropriate kubectl all-namespaces query and resource types
- Retrieve the prior terminated container logs using the appropriate kubectl option
Explanation
Correct Answer
D:Retrieve the prior terminated container logs using the appropriate kubectl option. This is appropriate for the described asset and control gap because kubectl logs can request output from the previous container instance. If the issue is left untreated, reading only current logs may miss the failure message from a restarted process. An assessor can verify remediation when the recovered previous log contains the relevant startup exception.
Incorrect Answers
A:Use supported Kubernetes API configuration workflows and controlled reviews. The operation “Use supported Kubernetes API configuration workflows and controlled reviews” does not address the particular Kubernetes requirement “Retrieve the prior terminated container logs using the appropriate kubectl option”.
B:Apply a ResourceQuota appropriate to the namespace and its workload needs. The operation “Apply a ResourceQuota appropriate to the namespace and its workload needs” does not address the particular Kubernetes requirement “Retrieve the prior terminated container logs using the appropriate kubectl option”.
C:Use the appropriate kubectl all-namespaces query and resource types. The operation “Use the appropriate kubectl all-namespaces query and resource types” does not address the particular Kubernetes requirement “Retrieve the prior terminated container logs using the appropriate kubectl option”.
Question 85
A platform engineer recommends: Configure a supported VolumeSnapshot mechanism and test restore procedures. The original problem is: A disaster recovery plan assumes all PVCs are automatically snapshotted every night. Which concept explains the remedy?
- Kubernetes snapshots require compatible snapshot controller and CSI support
- Reclaim policies such as Delete and Retain control backing-volume disposition
- emptyDir storage lives for a Pod's lifetime and is shared by its containers
- StorageClasses describe how persistent volumes are created by storage drivers
Explanation
Correct Answer
A:Kubernetes snapshots require compatible snapshot controller and CSI support. That principle directly explains the selected remediation, configure a supported VolumeSnapshot mechanism and test restore procedures, for this case. Without the distinction, an unconfigured snapshot class cannot provide usable point-in-time backups. The expected confirmation is that a test VolumeSnapshot restores the expected dataset to a new claim.
Incorrect Answers
B:Reclaim policies such as Delete and Retain control backing-volume disposition. The operation “Reclaim policies such as Delete and Retain control backing-volume disposition” does not address the particular Kubernetes requirement “Kubernetes snapshots require compatible snapshot controller and CSI support”.
C:EmptyDir storage lives for a Pod's lifetime and is shared by its containers. The operation “emptyDir storage lives for a Pod's lifetime and is shared by its containers” does not address the particular Kubernetes requirement “Kubernetes snapshots require compatible snapshot controller and CSI support”.
D: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 “Kubernetes snapshots require compatible snapshot controller and CSI support”.
Question 86
In the situation "A new container image must be reproducible after a source-code change", the team applies "Build from a versioned Dockerfile or Containerfile with pinned dependencies". Which outcome is the strongest verification?
- A rollout with the same digest runs the same image across nodes
- Two clean builds from the same inputs produce compatible functional outputs
- Image inventory lists only required runtime packages after rebuild
- A verified image inspection finds no secrets and the exposed credential is rotated
Explanation
Correct Answer
B:Two clean builds from the same inputs produce compatible functional outputs. This is stronger than observing a saved configuration because it tests the actual outcome of build from a versioned Dockerfile or Containerfile with pinned dependencies. The underlying principle is that image builds package application layers from reproducible instructions. The original risk was that building mutable local state without source control undermines release reproducibility.
Incorrect Answers
A:Image tags are mutable references while digests identify specific image content. The observation “A rollout with the same digest runs the same image across nodes” would validate that property, rather than the required “Two clean builds from the same inputs produce compatible functional outputs”. Image builds package application layers from reproducible instructions.
C:Reducing unneeded image contents reduces exposed packages and maintenance cost. The observation “Image inventory lists only required runtime packages after rebuild” would validate that property, rather than the required “Two clean builds from the same inputs produce compatible functional outputs”. Image builds package application layers from reproducible instructions.
D: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 “Two clean builds from the same inputs produce compatible functional outputs”. Image builds package application layers from reproducible instructions.
Question 87
A team implemented the proposed remedy for this problem: A YAML Deployment is modified but the existing cluster still runs an old image version. Which evidence BEST shows it works?
- The node is Ready and becomes eligible for new suitable workloads
- An applied release matches an approved commit and rollback is reproducible
- The Deployment generation and running image reflect the updated manifest
- New Pods receive expected admission defaults or clear validation errors
Explanation
Correct Answer
C:The Deployment generation and running image reflect the updated manifest. This is stronger than observing a saved configuration because it tests the actual outcome of apply the declarative manifest and inspect the resulting rollout. The underlying principle is that kubectl apply submits desired object configuration for controller reconciliation. The original risk was that editing local YAML without submitting it leaves running state unchanged.
Incorrect Answers
A:Uncordon reverses the unschedulable scheduling designation. The observation “The node is Ready and becomes eligible for new suitable workloads” would validate that property, rather than the required “The Deployment generation and running image reflect the updated manifest”. Kubectl apply submits desired object configuration for controller reconciliation.
B:Versioned declarative configuration supports auditability and repeatable changes. The observation “An applied release matches an approved commit and rollback is reproducible” would validate that property, rather than the required “The Deployment generation and running image reflect the updated manifest”. Kubectl apply submits desired object configuration for controller reconciliation.
D:LimitRanges can provide default constraints to containers in a namespace. The observation “New Pods receive expected admission defaults or clear validation errors” would validate that property, rather than the required “The Deployment generation and running image reflect the updated manifest”. Kubectl apply submits desired object configuration for controller reconciliation.
Question 88
A platform engineer recommends: Explain containers, orchestration, automation, observability, and open interfaces together. The original problem is: A team must understand why Kubernetes is part of a broader cloud-native ecosystem. Which concept explains the remedy?
- Resilience patterns keep transient dependency faults from consuming all callers
- Cloud-native architecture often favors independently deployable components with clear boundaries
- Serverless and event-driven designs can suit intermittent work but have operational tradeoffs
- Cloud-native systems combine organizational practices and technology, not only a container runtime
Explanation
Correct Answer
D:Cloud-native systems combine organizational practices and technology, not only a container runtime. That principle directly explains the selected remediation, explain containers, orchestration, automation, observability, and open interfaces together, for this case. Without the distinction, treating containers alone as cloud-native adoption can ignore deployment and reliability needs. The expected confirmation is that the architecture design accounts for automated rollout, monitoring, and scaling.
Incorrect Answers
A: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 systems combine organizational practices and technology, not only a container runtime”.
B:Cloud-native architecture often favors independently deployable components with clear boundaries. The operation “Cloud-native architecture often favors independently deployable components with clear boundaries” does not address the particular Kubernetes requirement “Cloud-native systems combine organizational practices and technology, not only a container runtime”.
C:Serverless and event-driven designs can suit intermittent work but have operational tradeoffs. The operation “Serverless and event-driven designs can suit intermittent work but have operational tradeoffs” does not address the particular Kubernetes requirement “Cloud-native systems combine organizational practices and technology, not only a container runtime”.
Question 89
In the situation "A specific worker becomes NotReady while other nodes continue to run normally", the team applies "Inspect kubelet, runtime, node conditions, and network status". Which outcome is the strongest verification?
- The node becomes Ready after the recorded condition clears
- The claim becomes Bound and the workload mounts the intended volume
- Requests through the Service reach the application on its listening port
- The app finishes startup before normal liveness and readiness checks begin
Explanation
Correct Answer
A:The node becomes Ready after the recorded condition clears. This is stronger than observing a saved configuration because it tests the actual outcome of inspect kubelet, runtime, node conditions, and network status. The underlying principle is that node Ready conditions summarize whether the node can safely host workloads. The original risk was that retrying an application request does not restore a failing kubelet.
Incorrect Answers
B: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 node becomes Ready after the recorded condition clears”. Node Ready conditions summarize whether the node can safely host workloads.
C: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 node becomes Ready after the recorded condition clears”. Node Ready conditions summarize whether the node can safely host workloads.
D:Startup probes protect slow initialization from premature liveness restarts. The observation “The app finishes startup before normal liveness and readiness checks begin” would validate that property, rather than the required “The node becomes Ready after the recorded condition clears”. Node Ready conditions summarize whether the node can safely host workloads.
Question 90
A Kubernetes platform team observes this situation: A slow Java application repeatedly fails liveness checks while still initializing. Which action BEST addresses the requirement?
- Check DNS policy, resolv.conf, CoreDNS Pod health, and network reachability
- Add a startup probe so liveness is deferred until startup completes
- Inspect readiness probes and the Service's eligible endpoints
- Inspect image pull events and correct the repository or tag reference
Explanation
Correct Answer
B:Add a startup probe so liveness is deferred until startup completes. This is appropriate for the described asset and control gap because startup probes protect slow initialization from premature liveness restarts. If the issue is left untreated, aggressive liveness checks can keep a healthy slow-starting app in a reboot loop. An assessor can verify remediation when the app finishes startup before normal liveness and readiness checks begin.
Incorrect Answers
A: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 “Add a startup probe so liveness is deferred until startup completes”.
C:Inspect readiness probes and the Service's eligible endpoints. The operation “Inspect readiness probes and the Service's eligible endpoints” does not address the particular Kubernetes requirement “Add a startup probe so liveness is deferred until startup completes”.
D:Inspect image pull events and correct the repository or tag reference. The operation “Inspect image pull events and correct the repository or tag reference” does not address the particular Kubernetes requirement “Add a startup probe so liveness is deferred until startup completes”.
