Linux Foundation KCNA Practice Test 64
Question 630
A workload expects a ConfigMap-mounted configuration file to update after restart yet uses an immutable environment variable without rollout. Which observable result BEST confirms the desired Kubernetes or cloud native behavior?
- The container sees the intended isolated resources while usage limits are reflected in host accounting.
- Teams see only permitted namespaced resources and network access is constrained by explicit policies.
- Workloads read needed configuration while unauthorized users cannot retrieve credential material through the API.
- Control-plane and node upgrades complete within supported skew with workload compatibility checks passing.
Explanation
Correct Answer
C:Workloads read needed configuration while unauthorized users cannot retrieve credential material through the API. This is an observable service outcome, not just evidence that a configuration file was saved. Kubernetes Secret data is base64-encoded by default, not inherently encrypted or a substitute for managed secret governance. Workload context: A workload expects a ConfigMap-mounted configuration file to update after restart yet uses an immutable environment variable without rollout.
Incorrect Answers
A:The container sees the intended isolated resources while usage limits are reflected in host accounting. That result validates Linux namespaces and cgroups rather than the requirement here. Verify instead: Workloads read needed configuration while unauthorized users cannot retrieve credential material through the API. Workload context: A workload expects a ConfigMap-mounted configuration file to update after restart yet uses an immutable environment variable without rollout.
B:Teams see only permitted namespaced resources and network access is constrained by explicit policies. That result validates Namespace scope and limits rather than the requirement here. Verify instead: Workloads read needed configuration while unauthorized users cannot retrieve credential material through the API. Workload context: A workload expects a ConfigMap-mounted configuration file to update after restart yet uses an immutable environment variable without rollout.
D:Control-plane and node upgrades complete within supported skew with workload compatibility checks passing. That result validates Kubernetes upgrades and version skew rather than the requirement here. Verify instead: Workloads read needed configuration while unauthorized users cannot retrieve credential material through the API. Workload context: A workload expects a ConfigMap-mounted configuration file to update after restart yet uses an immutable environment variable without rollout.
Question 631
A team deploys a proprietary cloud load-balancer annotation and assumes the same manifest will work unchanged on bare metal. Which Kubernetes or cloud native approach BEST addresses the stated requirement?
- Evaluate CNCF sandbox, incubating and graduated projects in context of maintenance, community adoption and technical fit.
- Choose metrics for measurements over time, logs for detailed events and traces for end-to-end request execution analysis.
- Prefer open APIs, OCI images and Kubernetes-compatible deployment contracts where portability matters while accounting for provider-specific extensions.
- Design bounded microservice interfaces with timeouts, retries and independently deployable service contracts where modularity is useful.
Explanation
Correct Answer
C:Prefer open APIs, OCI images and Kubernetes-compatible deployment contracts where portability matters while accounting for provider-specific extensions. This response implements the controlling Kubernetes or cloud native principle. Cloud native APIs improve portability but do not guarantee identical storage classes, load balancers or custom controllers across clouds. Check its effect by: Inspect manifests for proprietary resources, storage/network API dependencies, image compatibility and migration cost. Workload context: A team deploys a proprietary cloud load-balancer annotation and assumes the same manifest will work unchanged on bare metal.
Incorrect Answers
A:Evaluate CNCF sandbox, incubating and graduated projects in context of maintenance, community adoption and technical fit. This action addresses CNCF project maturity and adoption decisions instead of the controlling requirement. CNCF maturity levels indicate aspects of governance and adoption, not a guarantee of security or perfect product fit. For this scenario prefer: Prefer open APIs, OCI images and Kubernetes-compatible deployment contracts where portability matters while accounting for provider-specific extensions. Workload context: A team deploys a proprietary cloud load-balancer annotation and assumes the same manifest will work unchanged on bare metal.
B:Choose metrics for measurements over time, logs for detailed events and traces for end-to-end request execution analysis. This action addresses Metrics logs and traces distinctions instead of the controlling requirement. Logs, metrics and traces answer different questions; observability requires instrumenting and interpreting their context. For this scenario prefer: Prefer open APIs, OCI images and Kubernetes-compatible deployment contracts where portability matters while accounting for provider-specific extensions. Workload context: A team deploys a proprietary cloud load-balancer annotation and assumes the same manifest will work unchanged on bare metal.
D:Design bounded microservice interfaces with timeouts, retries and independently deployable service contracts where modularity is useful. This action addresses Microservices contracts and failure isolation instead of the controlling requirement. Microservices improve modularity but add network and operational overhead; splitting code does not automatically yield reliability. For this scenario prefer: Prefer open APIs, OCI images and Kubernetes-compatible deployment contracts where portability matters while accounting for provider-specific extensions. Workload context: A team deploys a proprietary cloud load-balancer annotation and assumes the same manifest will work unchanged on bare metal.
Question 632
An operator greps every Pod log to calculate cluster-wide request-rate trends that a suitable metric would show directly. 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.
- Inspect metric labels and samples, log fields, trace/span correlation and sampling rates.
- Inspect LICENSE files, contribution guidelines, DCO or CLA requirements and third-party dependency notices.
- Inspect tracer/provider setup, context propagation, collector pipeline, resource attributes and exporter endpoint health.
Explanation
Correct Answer
B:Inspect metric labels and samples, log fields, trace/span correlation and sampling rates. This is the most discriminating evidence for the described failure or requirement. Logs, metrics and traces answer different questions; observability requires instrumenting and interpreting their context. The corresponding implementation is: Choose metrics for measurements over time, logs for detailed events and traces for end-to-end request execution analysis. Workload context: An operator greps every Pod log to calculate cluster-wide request-rate trends that a suitable metric would show directly.
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: Inspect metric labels and samples, log fields, trace/span correlation and sampling rates. Workload context: An operator greps every Pod log to calculate cluster-wide request-rate trends that a suitable metric would show directly.
C: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: Inspect metric labels and samples, log fields, trace/span correlation and sampling rates. Workload context: An operator greps every Pod log to calculate cluster-wide request-rate trends that a suitable metric would show directly.
D:Inspect tracer/provider setup, context propagation, collector pipeline, resource attributes and exporter endpoint health. These observations are more relevant to OpenTelemetry instrumentation and exporters, not this case. The distinguishing check is: Inspect metric labels and samples, log fields, trace/span correlation and sampling rates. Workload context: An operator greps every Pod log to calculate cluster-wide request-rate trends that a suitable metric would show directly.
Question 633
An engineer manually starts three standalone Pods and expects the controller manager to restore them when a node disappears. Which TWO complementary steps supply the appropriate approach AND the evidence required to validate it? Select TWO.
- Allow Kubernetes controllers to reconcile declared desired object state instead of manually replacing each Pod after failure.
- Use namespaces to group namespaced resources and policies, and add explicit RBAC and network controls for isolation.
- Compare object metadata labels, Service/Deployment selectors and selected object lists.
- Compare desired and observed replicas, controller events, ReplicaSet ownership and controller-manager health.
- The container sees the intended isolated resources while usage limits are reflected in host accounting.
Explanation
Correct Answers
A:Allow Kubernetes controllers to reconcile declared desired object state instead of manually replacing each Pod after failure. This response implements the controlling Kubernetes or cloud native principle. Controllers continuously reconcile desired state; an isolated manually created Pod lacks a Deployment's replica management. Check its effect by: Compare desired and observed replicas, controller events, ReplicaSet ownership and controller-manager health. This is the implementation part of the required paired answer. Workload context: An engineer manually starts three standalone Pods and expects the controller manager to restore them when a node disappears.
D:Compare desired and observed replicas, controller events, ReplicaSet ownership and controller-manager health. This is the most discriminating evidence for the described failure or requirement. Controllers continuously reconcile desired state; an isolated manually created Pod lacks a Deployment's replica management. The corresponding implementation is: Allow Kubernetes controllers to reconcile declared desired object state instead of manually replacing each Pod after failure. This is the diagnostic evidence part of the paired answer. Workload context: An engineer manually starts three standalone Pods and expects the controller manager to restore them when a node disappears.
Incorrect Answers
B:Use namespaces to group namespaced resources and policies, and add explicit RBAC and network controls for isolation. This step belongs to Namespace scope and limits rather than the complementary implementation and evidence pair. The intended approach is: Allow Kubernetes controllers to reconcile declared desired object state instead of manually replacing each Pod after failure. Validate with: Compare desired and observed replicas, controller events, ReplicaSet ownership and controller-manager health. Workload context: An engineer manually starts three standalone Pods and expects the controller manager to restore them when a node disappears.
C:Compare object metadata labels, Service/Deployment selectors and selected object lists. This step belongs to Labels selectors and annotations rather than the complementary implementation and evidence pair. The intended approach is: Allow Kubernetes controllers to reconcile declared desired object state instead of manually replacing each Pod after failure. Validate with: Compare desired and observed replicas, controller events, ReplicaSet ownership and controller-manager health. Workload context: An engineer manually starts three standalone Pods and expects the controller manager to restore them when a node disappears.
E:The container sees the intended isolated resources while usage limits are reflected in host accounting. This step belongs to Linux namespaces and cgroups rather than the complementary implementation and evidence pair. The intended approach is: Allow Kubernetes controllers to reconcile declared desired object state instead of manually replacing each Pod after failure. Validate with: Compare desired and observed replicas, controller events, ReplicaSet ownership and controller-manager health. Workload context: An engineer manually starts three standalone Pods and expects the controller manager to restore them when a node disappears.
Question 634
A registry migration changes its host name and worker nodes report image pull failures despite healthy deployment manifests. Which evidence should the engineer inspect FIRST to distinguish the likely cause or verify the prerequisite?
- Check registry path, pull Secret, tag or digest, IAM grant, TLS trust and registry audit logs.
- Compare host kernel sharing, namespace isolation, hypervisor boundaries and workload trust requirements.
- Inspect process namespace, container cgroup limits, OOM events and host resource metrics.
- Inspect container membership, localhost connectivity, Pod IP, restart policies and inter-container volumes.
Explanation
Correct Answer
A:Check registry path, pull Secret, tag or digest, IAM grant, TLS trust and registry audit logs. This is the most discriminating evidence for the described failure or requirement. OCI registries store/distribute image artifacts; they do not orchestrate Pods or apply cluster networking. The corresponding implementation is: Pull images from approved OCI-compatible registries with controlled image credentials and documented access boundaries. Workload context: A registry migration changes its host name and worker nodes report image pull failures despite healthy deployment manifests.
Incorrect Answers
B:Compare host kernel sharing, namespace isolation, hypervisor boundaries and workload trust requirements. These observations are more relevant to Container versus virtual machine isolation, not this case. The distinguishing check is: Check registry path, pull Secret, tag or digest, IAM grant, TLS trust and registry audit logs. Workload context: A registry migration changes its host name and worker nodes report image pull failures despite healthy deployment manifests.
C:Inspect process namespace, container cgroup limits, OOM events and host resource metrics. These observations are more relevant to Linux namespaces and cgroups, not this case. The distinguishing check is: Check registry path, pull Secret, tag or digest, IAM grant, TLS trust and registry audit logs. Workload context: A registry migration changes its host name and worker nodes report image pull failures despite healthy deployment manifests.
D:Inspect container membership, localhost connectivity, Pod IP, restart policies and inter-container volumes. These observations are more relevant to Pod shared network namespace and lifecycle, not this case. The distinguishing check is: Check registry path, pull Secret, tag or digest, IAM grant, TLS trust and registry audit logs. Workload context: A registry migration changes its host name and worker nodes report image pull failures despite healthy deployment manifests.
Question 635
A worker runs out of ephemeral disk space and BestEffort Pods disappear with Evicted status. Which TWO complementary steps supply the appropriate approach AND the evidence required to validate it? Select TWO.
- Inspect securityContext, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile and startup errors.
- External HTTP clients reach the correct application by hostname and route rules while unrelated paths stay rejected.
- Diagnose memory limit terminations using lastState and observed working-set growth rather than assuming every restart is application logic.
- Investigate node disk, memory and PID pressure conditions and distinguish eviction from application-probe restarts.
- Inspect node conditions, eviction events, kubelet logs, disk usage and QoS/resource request settings.
Explanation
Correct Answers
D:Investigate node disk, memory and PID pressure conditions and distinguish eviction from application-probe restarts. This response implements the controlling Kubernetes or cloud native principle. Kubelet can evict Pods under node pressure; eviction is different from a liveness probe killing one container. Check its effect by: Inspect node conditions, eviction events, kubelet logs, disk usage and QoS/resource request settings. This is the implementation part of the required paired answer. Workload context: A worker runs out of ephemeral disk space and BestEffort Pods disappear with Evicted status.
E:Inspect node conditions, eviction events, kubelet logs, disk usage and QoS/resource request settings. This is the most discriminating evidence for the described failure or requirement. Kubelet can evict Pods under node pressure; eviction is different from a liveness probe killing one container. The corresponding implementation is: Investigate node disk, memory and PID pressure conditions and distinguish eviction from application-probe restarts. This is the diagnostic evidence part of the paired answer. Workload context: A worker runs out of ephemeral disk space and BestEffort Pods disappear with Evicted status.
Incorrect Answers
A:Inspect securityContext, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile and startup errors. This step belongs to Linux securityContext and seccomp basics rather than the complementary implementation and evidence pair. The intended approach is: Investigate node disk, memory and PID pressure conditions and distinguish eviction from application-probe restarts. Validate with: Inspect node conditions, eviction events, kubelet logs, disk usage and QoS/resource request settings. Workload context: A worker runs out of ephemeral disk space and BestEffort Pods disappear with Evicted status.
B:External HTTP clients reach the correct application by hostname and route rules while unrelated paths stay rejected. This step belongs to Ingress and Gateway API routing rather than the complementary implementation and evidence pair. The intended approach is: Investigate node disk, memory and PID pressure conditions and distinguish eviction from application-probe restarts. Validate with: Inspect node conditions, eviction events, kubelet logs, disk usage and QoS/resource request settings. Workload context: A worker runs out of ephemeral disk space and BestEffort Pods disappear with Evicted status.
C:Diagnose memory limit terminations using lastState and observed working-set growth rather than assuming every restart is application logic. This step belongs to Container OOMKilled and resource pressure rather than the complementary implementation and evidence pair. The intended approach is: Investigate node disk, memory and PID pressure conditions and distinguish eviction from application-probe restarts. Validate with: Inspect node conditions, eviction events, kubelet logs, disk usage and QoS/resource request settings. Workload context: A worker runs out of ephemeral disk space and BestEffort Pods disappear with Evicted status.
Question 636
A new worker has ample CPU but never receives Pods because kubelet cannot reach the API and the NodeReady condition is false. Which evidence should the engineer inspect FIRST to distinguish the likely cause or verify the prerequisite?
- Review kubelet service logs, node conditions, CRI connectivity and Pod events for assigned nodes.
- Inspect allowedDisruptions, healthy replicas, minAvailable/maxUnavailable and drain eviction results.
- Review node labels, conditions, capacity versus allocatable, topology zones and node allocatable metrics.
- Check NodeReady condition, kubelet heartbeats, network connectivity, pressure conditions and scheduler events.
Explanation
Correct Answer
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. Workload context: A new worker has ample CPU but never receives Pods because kubelet cannot reach the API and the NodeReady condition is false.
Incorrect Answers
A:Review kubelet service logs, node conditions, CRI connectivity and Pod events for assigned nodes. These observations are more relevant to Kubelet node agent responsibilities, not this case. The distinguishing check is: Check NodeReady condition, kubelet heartbeats, network connectivity, pressure conditions and scheduler events. Workload context: A new worker has ample CPU but never receives Pods because kubelet cannot reach the API and the NodeReady condition is false.
B:Inspect allowedDisruptions, healthy replicas, minAvailable/maxUnavailable and drain eviction results. These observations are more relevant to PodDisruptionBudget during voluntary eviction, not this case. The distinguishing check is: Check NodeReady condition, kubelet heartbeats, network connectivity, pressure conditions and scheduler events. Workload context: A new worker has ample CPU but never receives Pods because kubelet cannot reach the API and the NodeReady condition is false.
C:Review node labels, conditions, capacity versus allocatable, topology zones and node allocatable metrics. These observations are more relevant to Node labels and allocatable inventory, not this case. The distinguishing check is: Check NodeReady condition, kubelet heartbeats, network connectivity, pressure conditions and scheduler events. Workload context: A new worker has ample CPU but never receives Pods because kubelet cannot reach the API and the NodeReady condition is false.
Question 637
A release routes 2% of users to a canary but health dashboards aggregate both versions and hide a canary-only error surge. Which observable result BEST confirms the desired Kubernetes or cloud native behavior?
- Troubleshooters inspect network and process behavior without bloating or rebuilding the immutable production image.
- Template rendering produces intended resources and upgrades or rollbacks remain tied to specific chart revisions.
- Traffic shifts as planned with clear rollback triggers and both versions behaving under their measured loads.
- A failing candidate build halts or rolls back before reaching full audience while healthy versions progress safely.
Explanation
Correct Answer
C:Traffic shifts as planned with clear rollback triggers and both versions behaving under their measured loads. This is an observable service outcome, not just evidence that a configuration file was saved. Blue-green switches environments, whereas canary ramps exposure; a basic Deployment alone may not provide precise traffic percentages. Workload context: A release routes 2% of users to a canary but health dashboards aggregate both versions and hide a canary-only error surge.
Incorrect Answers
A:Troubleshooters inspect network and process behavior without bloating or rebuilding the immutable production image. That result validates Ephemeral debug containers for minimal images rather than the requirement here. Verify instead: Traffic shifts as planned with clear rollback triggers and both versions behaving under their measured loads. Workload context: A release routes 2% of users to a canary but health dashboards aggregate both versions and hide a canary-only error surge.
B:Template rendering produces intended resources and upgrades or rollbacks remain tied to specific chart revisions. That result validates Helm charts templates and values rather than the requirement here. Verify instead: Traffic shifts as planned with clear rollback triggers and both versions behaving under their measured loads. Workload context: A release routes 2% of users to a canary but health dashboards aggregate both versions and hide a canary-only error surge.
D:A failing candidate build halts or rolls back before reaching full audience while healthy versions progress safely. That result validates Progressive delivery and release metrics rather than the requirement here. Verify instead: Traffic shifts as planned with clear rollback triggers and both versions behaving under their measured loads. Workload context: A release routes 2% of users to a canary but health dashboards aggregate both versions and hide a canary-only error surge.
Question 638
A new chart bundles an image from an unknown third-party registry without a documented trust decision or supplier metadata. Which evidence should the engineer inspect FIRST to distinguish the likely cause or verify the prerequisite?
- Review ephemeralContainers spec, target container namespace, attach status and host-level privileges requested.
- Compare Git revision, application sync status, live resource diff and reconciliation events.
- Inspect traffic split, Service selectors or routing weights, version identity and representative user metrics.
- Examine trusted builder identity, attestation payload, artifact digest, SBOM and admission verification result.
Explanation
Correct Answer
D:Examine trusted builder identity, attestation payload, artifact digest, SBOM and admission verification result. This is the most discriminating evidence for the described failure or requirement. SBOM inventory and signed provenance provide different evidence; neither replaces vulnerability and security-policy review. The corresponding implementation is: Record artifact provenance, dependency inventories and signed attestations so deployment policy can trace a build to authorized source. Workload context: A new chart bundles an image from an unknown third-party registry without a documented trust decision or supplier metadata.
Incorrect Answers
A:Review ephemeralContainers spec, target container namespace, attach status and host-level privileges requested. These observations are more relevant to Ephemeral debug containers for minimal images, not this case. The distinguishing check is: Examine trusted builder identity, attestation payload, artifact digest, SBOM and admission verification result. Workload context: A new chart bundles an image from an unknown third-party registry without a documented trust decision or supplier metadata.
B:Compare Git revision, application sync status, live resource diff and reconciliation events. These observations are more relevant to GitOps reconciliation and source of truth, not this case. The distinguishing check is: Examine trusted builder identity, attestation payload, artifact digest, SBOM and admission verification result. Workload context: A new chart bundles an image from an unknown third-party registry without a documented trust decision or supplier metadata.
C:Inspect traffic split, Service selectors or routing weights, version identity and representative user metrics. These observations are more relevant to Blue-green versus canary release patterns, not this case. The distinguishing check is: Examine trusted builder identity, attestation payload, artifact digest, SBOM and admission verification result. Workload context: A new chart bundles an image from an unknown third-party registry without a documented trust decision or supplier metadata.
Question 639
A service fails after runAsNonRoot is applied because its image expects to write to a root-owned directory. Which evidence should the engineer inspect FIRST to distinguish the likely cause or verify the prerequisite?
- Inspect external IP status, controller events, security groups, health checks and upstream target availability.
- Review image references, signing identities, attestations, admission decisions and deployed imageIDs.
- Review namespace pod-security labels, admission warnings, violations and workload securityContext.
- Inspect securityContext, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile and startup errors.
Explanation
Correct Answer
D:Inspect securityContext, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile and startup errors. This is the most discriminating evidence for the described failure or requirement. Disabling privilege escalation and dropping Linux capabilities reduce risk but do not replace image or API authorization. The corresponding implementation is: Run containers with nonroot identities, minimal capabilities and an appropriate seccomp profile for reduced kernel attack surface. Workload context: A service fails after runAsNonRoot is applied because its image expects to write to a root-owned directory.
Incorrect Answers
A:Inspect external IP status, controller events, security groups, health checks and upstream target availability. These observations are more relevant to LoadBalancer Service provisioning, not this case. The distinguishing check is: Inspect securityContext, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile and startup errors. Workload context: A service fails after runAsNonRoot is applied because its image expects to write to a root-owned directory.
B:Review image references, signing identities, attestations, admission decisions and deployed imageIDs. These observations are more relevant to Image provenance and admission policies, not this case. The distinguishing check is: Inspect securityContext, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile and startup errors. Workload context: A service fails after runAsNonRoot is applied because its image expects to write to a root-owned directory.
C:Review namespace pod-security labels, admission warnings, violations and workload securityContext. These observations are more relevant to Pod Security Admission and namespaces, not this case. The distinguishing check is: Inspect securityContext, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile and startup errors. Workload context: A service fails after runAsNonRoot is applied because its image expects to write to a root-owned directory.
Question 640
A worker runs out of ephemeral disk space and BestEffort Pods disappear with Evicted status. Which evidence should the engineer inspect FIRST to distinguish the likely cause or verify the prerequisite?
- Inspect probe paths, thresholds, failure conditions, Service endpoints and container restart events.
- Review container lastState, exit code, restart count, previous logs and application configuration.
- Inspect StorageClass provisioner name, allowed topology, PVC events and CSI controller logs.
- Inspect node conditions, eviction events, kubelet logs, disk usage and QoS/resource request settings.
Explanation
Correct Answer
D:Inspect node conditions, eviction events, kubelet logs, disk usage and QoS/resource request settings. This is the most discriminating evidence for the described failure or requirement. Kubelet can evict Pods under node pressure; eviction is different from a liveness probe killing one container. The corresponding implementation is: Investigate node disk, memory and PID pressure conditions and distinguish eviction from application-probe restarts. Workload context: A worker runs out of ephemeral disk space and BestEffort Pods disappear with Evicted status.
Incorrect Answers
A:Inspect probe paths, thresholds, failure conditions, Service endpoints and container restart events. These observations are more relevant to Readiness liveness and startup probe behavior, not this case. The distinguishing check is: Inspect node conditions, eviction events, kubelet logs, disk usage and QoS/resource request settings. Workload context: A worker runs out of ephemeral disk space and BestEffort Pods disappear with Evicted status.
B:Review container lastState, exit code, restart count, previous logs and application configuration. These observations are more relevant to CrashLoopBackOff and previous logs, not this case. The distinguishing check is: Inspect node conditions, eviction events, kubelet logs, disk usage and QoS/resource request settings. Workload context: A worker runs out of ephemeral disk space and BestEffort Pods disappear with Evicted status.
C:Inspect StorageClass provisioner name, allowed topology, PVC events and CSI controller logs. These observations are more relevant to StorageClass dynamic provisioning, not this case. The distinguishing check is: Inspect node conditions, eviction events, kubelet logs, disk usage and QoS/resource request settings. Workload context: A worker runs out of ephemeral disk space and BestEffort Pods disappear with Evicted status.