Linux Foundation KCNA Practice Test 16
Question 150
A drain is blocked when a PDB requires two healthy replicas but only one is currently Ready. Which TWO complementary steps supply the appropriate approach AND the evidence required to validate it? Select TWO.
- Inspect allowedDisruptions, healthy replicas, minAvailable/maxUnavailable and drain eviction results.
- Configure PodDisruptionBudgets for voluntary disruptions while distinguishing eviction safety from normal scheduling decisions.
- Principals can perform only intended operations at the correct scope while denied actions remain inaccessible.
- Match Pod CPU/memory requests to node allocatable resources and scheduling constraints before blaming a container image.
- Check registry path, pull Secret, tag or digest, IAM grant, TLS trust and registry audit logs.
Explanation
Correct Answers
A:Inspect allowedDisruptions, healthy replicas, minAvailable/maxUnavailable and drain eviction results. This is the most discriminating evidence for the described failure or requirement. A PodDisruptionBudget governs voluntary eviction; it does not guarantee protection against hardware failure or create new replicas. The corresponding implementation is: Configure PodDisruptionBudgets for voluntary disruptions while distinguishing eviction safety from normal scheduling decisions. This is the diagnostic evidence part of the paired answer. Workload context: A drain is blocked when a PDB requires two healthy replicas but only one is currently Ready.
B:Configure PodDisruptionBudgets for voluntary disruptions while distinguishing eviction safety from normal scheduling decisions. This response implements the controlling Kubernetes or cloud native principle. A PodDisruptionBudget governs voluntary eviction; it does not guarantee protection against hardware failure or create new replicas. Check its effect by: Inspect allowedDisruptions, healthy replicas, minAvailable/maxUnavailable and drain eviction results. This is the implementation part of the required paired answer. Workload context: A drain is blocked when a PDB requires two healthy replicas but only one is currently Ready.
Incorrect Answers
C:Principals can perform only intended operations at the correct scope while denied actions remain inaccessible. This step belongs to Role and ClusterRole authorization rather than the complementary implementation and evidence pair. The intended approach is: Configure PodDisruptionBudgets for voluntary disruptions while distinguishing eviction safety from normal scheduling decisions. Validate with: Inspect allowedDisruptions, healthy replicas, minAvailable/maxUnavailable and drain eviction results. Workload context: A drain is blocked when a PDB requires two healthy replicas but only one is currently Ready.
D:Match Pod CPU/memory requests to node allocatable resources and scheduling constraints before blaming a container image. This step belongs to Pending Pods and resource-fit checks rather than the complementary implementation and evidence pair. The intended approach is: Configure PodDisruptionBudgets for voluntary disruptions while distinguishing eviction safety from normal scheduling decisions. Validate with: Inspect allowedDisruptions, healthy replicas, minAvailable/maxUnavailable and drain eviction results. Workload context: A drain is blocked when a PDB requires two healthy replicas but only one is currently Ready.
E:Check registry path, pull Secret, tag or digest, IAM grant, TLS trust and registry audit logs. This step belongs to OCI registries and image distribution rather than the complementary implementation and evidence pair. The intended approach is: Configure PodDisruptionBudgets for voluntary disruptions while distinguishing eviction safety from normal scheduling decisions. Validate with: Inspect allowedDisruptions, healthy replicas, minAvailable/maxUnavailable and drain eviction results. Workload context: A drain is blocked when a PDB requires two healthy replicas but only one is currently Ready.
Question 151
An app in namespace finance resolves api to its own nonexistent finance Service instead of the api Service in payments. Which observable result BEST confirms the desired Kubernetes or cloud native behavior?
- The application operates within measured memory budgets or receives justified capacity changes without repeated OOM restarts.
- Client connections reach healthy backing Pods and troubleshooters isolate selection from routing problems.
- External clients reach only the intended healthy Service backends and the allocated endpoint matches network policy.
- Clients resolve the intended in-cluster Service name and external DNS forwarding operates as designed.
Explanation
Correct Answer
D:Clients resolve the intended in-cluster Service name and external DNS forwarding operates as designed. This is an observable service outcome, not just evidence that a configuration file was saved. Kubernetes DNS uses namespace-aware search paths; a fully qualified Service name avoids ambiguity across namespaces. Workload context: An app in namespace finance resolves api to its own nonexistent finance Service instead of the api Service in payments.
Incorrect Answers
A:The application operates within measured memory budgets or receives justified capacity changes without repeated OOM restarts. That result validates Container OOMKilled and resource pressure rather than the requirement here. Verify instead: Clients resolve the intended in-cluster Service name and external DNS forwarding operates as designed. Workload context: An app in namespace finance resolves api to its own nonexistent finance Service instead of the api Service in payments.
B:Client connections reach healthy backing Pods and troubleshooters isolate selection from routing problems. That result validates Service endpoint routing and kube-proxy rather than the requirement here. Verify instead: Clients resolve the intended in-cluster Service name and external DNS forwarding operates as designed. Workload context: An app in namespace finance resolves api to its own nonexistent finance Service instead of the api Service in payments.
C:External clients reach only the intended healthy Service backends and the allocated endpoint matches network policy. That result validates LoadBalancer Service provisioning rather than the requirement here. Verify instead: Clients resolve the intended in-cluster Service name and external DNS forwarding operates as designed. Workload context: An app in namespace finance resolves api to its own nonexistent finance Service instead of the api Service in payments.
Question 152
A Pod reports Running yet its Service has no ready endpoints because the readiness probe uses a nonexistent URL. Which evidence should the engineer inspect FIRST to distinguish the likely cause or verify the prerequisite?
- Examine authentication identity, RBAC decision, admission webhook result and API response status.
- Inspect Pod pull events, image tag existence, registry TLS, imagePullSecrets and service-account references.
- Inspect Service selector, Pod readiness, EndpointSlice addresses, kube-proxy or eBPF service programming and target ports.
- Inspect probe paths, thresholds, failure conditions, Service endpoints and container restart events.
Explanation
Correct Answer
D:Inspect probe paths, thresholds, failure conditions, Service endpoints and container restart events. This is the most discriminating evidence for the described failure or requirement. Readiness failure removes a Pod from ready endpoints; liveness failure may restart a container. The corresponding implementation is: Assign readiness for traffic acceptance, liveness for unhealthy restarts and startup for slow initialization when appropriate. Workload context: A Pod reports Running yet its Service has no ready endpoints because the readiness probe uses a nonexistent URL.
Incorrect Answers
A:Examine authentication identity, RBAC decision, admission webhook result and API response status. These observations are more relevant to Authentication authorization and admission order, not this case. The distinguishing check is: Inspect probe paths, thresholds, failure conditions, Service endpoints and container restart events. Workload context: A Pod reports Running yet its Service has no ready endpoints because the readiness probe uses a nonexistent URL.
B:Inspect Pod pull events, image tag existence, registry TLS, imagePullSecrets and service-account references. These observations are more relevant to ImagePullBackOff registry and auth errors, not this case. The distinguishing check is: Inspect probe paths, thresholds, failure conditions, Service endpoints and container restart events. Workload context: A Pod reports Running yet its Service has no ready endpoints because the readiness probe uses a nonexistent URL.
C:Inspect Service selector, Pod readiness, EndpointSlice addresses, kube-proxy or eBPF service programming and target ports. These observations are more relevant to Service endpoint routing and kube-proxy, not this case. The distinguishing check is: Inspect probe paths, thresholds, failure conditions, Service endpoints and container restart events. Workload context: A Pod reports Running yet its Service has no ready endpoints because the readiness probe uses a nonexistent URL.
Question 153
A controller-plane report shows a Pod bound to a worker that has a stopped kubelet and no running containers. Which Kubernetes or cloud native approach BEST addresses the stated requirement?
- Assign PriorityClasses carefully and understand when the scheduler may preempt lower-priority Pods to place urgent workloads.
- Keep etcd highly available and maintain secure, tested snapshots of Kubernetes API state rather than treating it as ordinary container storage.
- Use an authorized ephemeral container for live Pod diagnostics when the original image lacks troubleshooting tools.
- Let kubelet on each node reconcile assigned Pod specifications with the container runtime and report node and Pod status.
Explanation
Correct Answer
D:Let kubelet on each node reconcile assigned Pod specifications with the container runtime and report node and Pod status. This response implements the controlling Kubernetes or cloud native principle. kubelet manages Pod execution on a node; it does not serve the central Kubernetes API or select new nodes. Check its effect by: Review kubelet service logs, node conditions, CRI connectivity and Pod events for assigned nodes. Workload context: A controller-plane report shows a Pod bound to a worker that has a stopped kubelet and no running containers.
Incorrect Answers
A:Assign PriorityClasses carefully and understand when the scheduler may preempt lower-priority Pods to place urgent workloads. This action addresses PriorityClass and preemption instead of the controlling requirement. Priority influences scheduling and potential preemption but does not bypass hard affinity or lack of suitable hardware. For this scenario prefer: Let kubelet on each node reconcile assigned Pod specifications with the container runtime and report node and Pod status. Workload context: A controller-plane report shows a Pod bound to a worker that has a stopped kubelet and no running containers.
B:Keep etcd highly available and maintain secure, tested snapshots of Kubernetes API state rather than treating it as ordinary container storage. This action addresses etcd consistency and cluster state instead of the controlling requirement. etcd is a consistent key-value store for API state; it is not where persistent application volume data lives. For this scenario prefer: Let kubelet on each node reconcile assigned Pod specifications with the container runtime and report node and Pod status. Workload context: A controller-plane report shows a Pod bound to a worker that has a stopped kubelet and no running containers.
C:Use an authorized ephemeral container for live Pod diagnostics when the original image lacks troubleshooting tools. This action addresses Ephemeral debugging containers instead of the controlling requirement. Ephemeral containers are intended for debugging and do not behave like ordinary replicated application containers. For this scenario prefer: Let kubelet on each node reconcile assigned Pod specifications with the container runtime and report node and Pod status. Workload context: A controller-plane report shows a Pod bound to a worker that has a stopped kubelet and no running containers.
Question 154
A Service declares port 80 and targetPort 8080 but the app listens on 9090, producing connection failures despite valid DNS. Which evidence should the engineer inspect FIRST to distinguish the likely cause or verify the prerequisite?
- Inspect NetworkPolicy podSelector, namespaces, allowed ports, CNI enforcement support and packet test results.
- Compare Service type, clusterIP, nodePort, targetPort, node addresses and backend EndpointSlices.
- Inspect node conditions, eviction events, kubelet logs, disk usage and QoS/resource request settings.
- Inspect kubectl describe Pod events, requests, node taints, PVC claims and node affinity.
Explanation
Correct Answer
B:Compare Service type, clusterIP, nodePort, targetPort, node addresses and backend EndpointSlices. This is the most discriminating evidence for the described failure or requirement. ClusterIP does not automatically provide an external endpoint; NodePort opens a port on eligible nodes with network policy constraints. The corresponding implementation is: Use ClusterIP for private service access and NodePort only when node-level external ports are intentionally needed. Workload context: A Service declares port 80 and targetPort 8080 but the app listens on 9090, producing connection failures despite valid DNS.
Incorrect Answers
A:Inspect NetworkPolicy podSelector, namespaces, allowed ports, CNI enforcement support and packet test results. These observations are more relevant to NetworkPolicy ingress egress isolation, not this case. The distinguishing check is: Compare Service type, clusterIP, nodePort, targetPort, node addresses and backend EndpointSlices. Workload context: A Service declares port 80 and targetPort 8080 but the app listens on 9090, producing connection failures despite valid DNS.
C:Inspect node conditions, eviction events, kubelet logs, disk usage and QoS/resource request settings. These observations are more relevant to Node pressure and Pod eviction analysis, not this case. The distinguishing check is: Compare Service type, clusterIP, nodePort, targetPort, node addresses and backend EndpointSlices. Workload context: A Service declares port 80 and targetPort 8080 but the app listens on 9090, producing connection failures despite valid DNS.
D:Inspect kubectl describe Pod events, requests, node taints, PVC claims and node affinity. These observations are more relevant to Pending pod FailedScheduling events, not this case. The distinguishing check is: Compare Service type, clusterIP, nodePort, targetPort, node addresses and backend EndpointSlices. Workload context: A Service declares port 80 and targetPort 8080 but the app listens on 9090, producing connection failures despite valid DNS.
Question 155
An app container is distroless with no shell, but the team assumes kubectl exec /bin/sh must always succeed. Which TWO complementary steps supply the appropriate approach AND the evidence required to validate it? Select TWO.
- Use kubectl exec with least privilege for approved diagnostics in running containers, avoiding permanent production mutations.
- Inspect selected Pod/container, executed command, RBAC exec permission and audit records.
- Distinguish readiness endpoint failures from application process exits before deciding whether to restart or change service routing.
- Live cluster configurations converge to reviewed Git commits and unauthorized drift is flagged or corrected.
- Inspect pod/container name, restartCount, lastState, previous log output and log collector availability.
Explanation
Correct Answers
A:Use kubectl exec with least privilege for approved diagnostics in running containers, avoiding permanent production mutations. This response implements the controlling Kubernetes or cloud native principle. kubectl exec runs a process in an existing container; it does not persist edits across new image-based replacements. Check its effect by: Inspect selected Pod/container, executed command, RBAC exec permission and audit records. This is the implementation part of the required paired answer. Workload context: An app container is distroless with no shell, but the team assumes kubectl exec /bin/sh must always succeed.
B:Inspect selected Pod/container, executed command, RBAC exec permission and audit records. This is the most discriminating evidence for the described failure or requirement. kubectl exec runs a process in an existing container; it does not persist edits across new image-based replacements. The corresponding implementation is: Use kubectl exec with least privilege for approved diagnostics in running containers, avoiding permanent production mutations. This is the diagnostic evidence part of the paired answer. Workload context: An app container is distroless with no shell, but the team assumes kubectl exec /bin/sh must always succeed.
Incorrect Answers
C:Distinguish readiness endpoint failures from application process exits before deciding whether to restart or change service routing. This step belongs to Readiness-probe failure versus process crash rather than the complementary implementation and evidence pair. The intended approach is: Use kubectl exec with least privilege for approved diagnostics in running containers, avoiding permanent production mutations. Validate with: Inspect selected Pod/container, executed command, RBAC exec permission and audit records. Workload context: An app container is distroless with no shell, but the team assumes kubectl exec /bin/sh must always succeed.
D:Live cluster configurations converge to reviewed Git commits and unauthorized drift is flagged or corrected. This step belongs to GitOps reconciliation and source of truth rather than the complementary implementation and evidence pair. The intended approach is: Use kubectl exec with least privilege for approved diagnostics in running containers, avoiding permanent production mutations. Validate with: Inspect selected Pod/container, executed command, RBAC exec permission and audit records. Workload context: An app container is distroless with no shell, but the team assumes kubectl exec /bin/sh must always succeed.
E:Inspect pod/container name, restartCount, lastState, previous log output and log collector availability. This step belongs to kubectl logs current versus previous instance rather than the complementary implementation and evidence pair. The intended approach is: Use kubectl exec with least privilege for approved diagnostics in running containers, avoiding permanent production mutations. Validate with: Inspect selected Pod/container, executed command, RBAC exec permission and audit records. Workload context: An app container is distroless with no shell, but the team assumes kubectl exec /bin/sh must always succeed.
Question 156
A monitoring agent obtains a 403 from the Kubernetes API and operators mistakenly conclude the backing etcd database is unavailable. Which TWO complementary steps supply the appropriate approach AND the evidence required to validate it? Select TWO.
- Inspect Dockerfile layer history, build context, cache usage, image size and scanner findings.
- Check API endpoint connectivity, request audit records, resource authorization and response status.
- Use kube-apiserver as the authenticated front end for Kubernetes API objects, rather than connecting clients directly to etcd.
- Let kubelet on each node reconcile assigned Pod specifications with the container runtime and report node and Pod status.
- Pods with persistent volumes schedule to nodes capable of mounting the selected storage without zone conflicts.
Explanation
Correct Answers
B:Check API endpoint connectivity, request audit records, resource authorization and response status. This is the most discriminating evidence for the described failure or requirement. kube-apiserver validates and serves API requests; etcd stores cluster state rather than exposing the user API. The corresponding implementation is: Use kube-apiserver as the authenticated front end for Kubernetes API objects, rather than connecting clients directly to etcd. This is the diagnostic evidence part of the paired answer. Workload context: A monitoring agent obtains a 403 from the Kubernetes API and operators mistakenly conclude the backing etcd database is unavailable.
C:Use kube-apiserver as the authenticated front end for Kubernetes API objects, rather than connecting clients directly to etcd. This response implements the controlling Kubernetes or cloud native principle. kube-apiserver validates and serves API requests; etcd stores cluster state rather than exposing the user API. Check its effect by: Check API endpoint connectivity, request audit records, resource authorization and response status. This is the implementation part of the required paired answer. Workload context: A monitoring agent obtains a 403 from the Kubernetes API and operators mistakenly conclude the backing etcd database is unavailable.
Incorrect Answers
A:Inspect Dockerfile layer history, build context, cache usage, image size and scanner findings. This step belongs to Image layers and build cache rather than the complementary implementation and evidence pair. The intended approach is: Use kube-apiserver as the authenticated front end for Kubernetes API objects, rather than connecting clients directly to etcd. Validate with: Check API endpoint connectivity, request audit records, resource authorization and response status. Workload context: A monitoring agent obtains a 403 from the Kubernetes API and operators mistakenly conclude the backing etcd database is unavailable.
D:Let kubelet on each node reconcile assigned Pod specifications with the container runtime and report node and Pod status. This step belongs to Kubelet node agent responsibilities rather than the complementary implementation and evidence pair. The intended approach is: Use kube-apiserver as the authenticated front end for Kubernetes API objects, rather than connecting clients directly to etcd. Validate with: Check API endpoint connectivity, request audit records, resource authorization and response status. Workload context: A monitoring agent obtains a 403 from the Kubernetes API and operators mistakenly conclude the backing etcd database is unavailable.
E:Pods with persistent volumes schedule to nodes capable of mounting the selected storage without zone conflicts. This step belongs to PersistentVolume zone binding and placement rather than the complementary implementation and evidence pair. The intended approach is: Use kube-apiserver as the authenticated front end for Kubernetes API objects, rather than connecting clients directly to etcd. Validate with: Check API endpoint connectivity, request audit records, resource authorization and response status. Workload context: A monitoring agent obtains a 403 from the Kubernetes API and operators mistakenly conclude the backing etcd database is unavailable.
Question 157
A team changes only imagePullPolicy but expects it to provide cryptographic provenance for untrusted registry content. Which evidence should the engineer inspect FIRST to distinguish the likely cause or verify the prerequisite?
- Compare image digest, registry manifest, Pod imageID, rollout timestamp and supply-chain approval.
- Compare Deployment spec, ReplicaSet ownership, rollout history and updated/available replica conditions.
- Compare imagePullPolicy, local image cache, registry digest, pull events and Pod imageID.
- Check registry path, pull Secret, tag or digest, IAM grant, TLS trust and registry audit logs.
Explanation
Correct Answer
A:Compare image digest, registry manifest, Pod imageID, rollout timestamp and supply-chain approval. This is the most discriminating evidence for the described failure or requirement. Mutable image tags can resolve to different builds over time; digests identify immutable content. The corresponding implementation is: Pin production images to verified digests or governed immutable tags so every node runs a known artifact. Workload context: A team changes only imagePullPolicy but expects it to provide cryptographic provenance for untrusted registry content.
Incorrect Answers
B:Compare Deployment spec, ReplicaSet ownership, rollout history and updated/available replica conditions. These observations are more relevant to Deployment and ReplicaSet ownership, not this case. The distinguishing check is: Compare image digest, registry manifest, Pod imageID, rollout timestamp and supply-chain approval. Workload context: A team changes only imagePullPolicy but expects it to provide cryptographic provenance for untrusted registry content.
C:Compare imagePullPolicy, local image cache, registry digest, pull events and Pod imageID. These observations are more relevant to Image pull policy and cached images, not this case. The distinguishing check is: Compare image digest, registry manifest, Pod imageID, rollout timestamp and supply-chain approval. Workload context: A team changes only imagePullPolicy but expects it to provide cryptographic provenance for untrusted registry content.
D:Check registry path, pull Secret, tag or digest, IAM grant, TLS trust and registry audit logs. These observations are more relevant to OCI registries and image distribution, not this case. The distinguishing check is: Compare image digest, registry manifest, Pod imageID, rollout timestamp and supply-chain approval. Workload context: A team changes only imagePullPolicy but expects it to provide cryptographic provenance for untrusted registry content.
Question 158
A node loses CNI connectivity and control-plane heartbeats before workloads appear stuck in Terminating state. Which TWO complementary steps supply the appropriate approach AND the evidence required to validate it? Select TWO.
- Check Pod priority, preemptionPolicy, scheduling events, available alternatives and victim selection.
- Use nodeSelector for straightforward required label equality and confirm matching nodes exist in the cluster.
- Diagnose NotReady nodes and distinguish node health from Pod-level readiness before reopening scheduling.
- Check NodeReady condition, kubelet heartbeats, network connectivity, pressure conditions and scheduler events.
- Kubelet can start Pod sandboxes and containers through the configured CRI without incompatible shim failures.
Explanation
Correct Answers
C:Diagnose NotReady nodes and distinguish node health from Pod-level readiness before reopening scheduling. This response implements the controlling Kubernetes or cloud native principle. Node readiness affects cluster placement and lifecycle; a single Pod readiness-probe failure does not make the entire node NotReady. Check its effect by: Check NodeReady condition, kubelet heartbeats, network connectivity, pressure conditions and scheduler events. This is the implementation part of the required paired answer. Workload context: A node loses CNI connectivity and control-plane heartbeats before workloads appear stuck in Terminating state.
D:Check NodeReady condition, kubelet heartbeats, network connectivity, pressure conditions and scheduler events. This is the most discriminating evidence for the described failure or requirement. Node readiness affects cluster placement and lifecycle; a single Pod readiness-probe failure does not make the entire node NotReady. The corresponding implementation is: Diagnose NotReady nodes and distinguish node health from Pod-level readiness before reopening scheduling. This is the diagnostic evidence part of the paired answer. Workload context: A node loses CNI connectivity and control-plane heartbeats before workloads appear stuck in Terminating state.
Incorrect Answers
A:Check Pod priority, preemptionPolicy, scheduling events, available alternatives and victim selection. This step belongs to PriorityClass and preemption rather than the complementary implementation and evidence pair. The intended approach is: Diagnose NotReady nodes and distinguish node health from Pod-level readiness before reopening scheduling. Validate with: Check NodeReady condition, kubelet heartbeats, network connectivity, pressure conditions and scheduler events. Workload context: A node loses CNI connectivity and control-plane heartbeats before workloads appear stuck in Terminating state.
B:Use nodeSelector for straightforward required label equality and confirm matching nodes exist in the cluster. This step belongs to nodeSelector equality placement rather than the complementary implementation and evidence pair. The intended approach is: Diagnose NotReady nodes and distinguish node health from Pod-level readiness before reopening scheduling. Validate with: Check NodeReady condition, kubelet heartbeats, network connectivity, pressure conditions and scheduler events. Workload context: A node loses CNI connectivity and control-plane heartbeats before workloads appear stuck in Terminating state.
E:Kubelet can start Pod sandboxes and containers through the configured CRI without incompatible shim failures. This step belongs to Container runtime and CRI rather than the complementary implementation and evidence pair. The intended approach is: Diagnose NotReady nodes and distinguish node health from Pod-level readiness before reopening scheduling. Validate with: Check NodeReady condition, kubelet heartbeats, network connectivity, pressure conditions and scheduler events. Workload context: A node loses CNI connectivity and control-plane heartbeats before workloads appear stuck in Terminating state.
Question 159
An engineer changes node affinity to fix repeated process crashes even though the Pod already has a healthy node assignment. Which evidence should the engineer inspect FIRST to distinguish the likely cause or verify the prerequisite?
- Review container lastState, exit code, restart count, previous logs and application configuration.
- Inspect securityContext, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile and startup errors.
- Inspect Pod pull events, image tag existence, registry TLS, imagePullSecrets and service-account references.
- Compare Service type, clusterIP, nodePort, targetPort, node addresses and backend EndpointSlices.
Explanation
Correct Answer
A:Review container lastState, exit code, restart count, previous logs and application configuration. This is the most discriminating evidence for the described failure or requirement. CrashLoopBackOff indicates repeated container exits and restart delays, not a scheduler placement failure. The corresponding implementation is: Inspect restart history and previous-container logs to diagnose repeatedly exiting containers and fix startup or runtime failures. Workload context: An engineer changes node affinity to fix repeated process crashes even though the Pod already has a healthy node assignment.
Incorrect Answers
B:Inspect securityContext, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile and startup errors. These observations are more relevant to Linux securityContext and seccomp basics, not this case. The distinguishing check is: Review container lastState, exit code, restart count, previous logs and application configuration. Workload context: An engineer changes node affinity to fix repeated process crashes even though the Pod already has a healthy node assignment.
C:Inspect Pod pull events, image tag existence, registry TLS, imagePullSecrets and service-account references. These observations are more relevant to ImagePullBackOff registry and auth errors, not this case. The distinguishing check is: Review container lastState, exit code, restart count, previous logs and application configuration. Workload context: An engineer changes node affinity to fix repeated process crashes even though the Pod already has a healthy node assignment.
D:Compare Service type, clusterIP, nodePort, targetPort, node addresses and backend EndpointSlices. These observations are more relevant to ClusterIP and NodePort Service exposure, not this case. The distinguishing check is: Review container lastState, exit code, restart count, previous logs and application configuration. Workload context: An engineer changes node affinity to fix repeated process crashes even though the Pod already has a healthy node assignment.
Question 160
A new team dismisses every CNCF sandbox project as unusable despite a well-scoped pilot and maintained code. Which evidence should the engineer inspect FIRST to distinguish the likely cause or verify the prerequisite?
- Inspect SLI queries, SLO target/window, request populations, error budgets and alert rule outcomes.
- Identify each project role, integration point, maintainer documentation and whether it belongs to Kubernetes core.
- Review CNCF landscape category, project governance, release cadence, support ecosystem and security disclosures.
- Inspect LICENSE files, contribution guidelines, DCO or CLA requirements and third-party dependency notices.
Explanation
Correct Answer
C:Review CNCF landscape category, project governance, release cadence, support ecosystem and security disclosures. This is the most discriminating evidence for the described failure or requirement. CNCF maturity levels indicate aspects of governance and adoption, not a guarantee of security or perfect product fit. The corresponding implementation is: Evaluate CNCF sandbox, incubating and graduated projects in context of maintenance, community adoption and technical fit. Workload context: A new team dismisses every CNCF sandbox project as unusable despite a well-scoped pilot and maintained code.
Incorrect Answers
A:Inspect SLI queries, SLO target/window, request populations, error budgets and alert rule outcomes. These observations are more relevant to SLIs SLOs and golden signals, not this case. The distinguishing check is: Review CNCF landscape category, project governance, release cadence, support ecosystem and security disclosures. Workload context: A new team dismisses every CNCF sandbox project as unusable despite a well-scoped pilot and maintained code.
B:Identify each project role, integration point, maintainer documentation and whether it belongs to Kubernetes core. These observations are more relevant to CNCF ecosystem and Kubernetes roles, not this case. The distinguishing check is: Review CNCF landscape category, project governance, release cadence, support ecosystem and security disclosures. Workload context: A new team dismisses every CNCF sandbox project as unusable despite a well-scoped pilot and maintained code.
D:Inspect LICENSE files, contribution guidelines, DCO or CLA requirements and third-party dependency notices. These observations are more relevant to Open source licensing and contribution basics, not this case. The distinguishing check is: Review CNCF landscape category, project governance, release cadence, support ecosystem and security disclosures. Workload context: A new team dismisses every CNCF sandbox project as unusable despite a well-scoped pilot and maintained code.
