Linux Foundation KCNA Practice Test 11
Question 100
A team specifies a restrictive seccomp profile but its runtime ignores an unsupported profile name and administrators must check enforcement. 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.
- Run containers with nonroot identities, minimal capabilities and an appropriate seccomp profile for reduced kernel attack surface.
- Inspect PVC phase, PV claimRef, capacity, accessModes, storageClassName and volume-mount events.
- Combine RBAC with NetworkPolicy to control both Kubernetes API permissions and east-west workload traffic.
- Only approved Pod flows pass and disallowed lateral or outbound connections fail reproducibly.
Explanation
Correct Answers
A: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. This is the diagnostic evidence part of the paired answer. Workload context: A team specifies a restrictive seccomp profile but its runtime ignores an unsupported profile name and administrators must check enforcement.
B:Run containers with nonroot identities, minimal capabilities and an appropriate seccomp profile for reduced kernel attack surface. This response implements the controlling Kubernetes or cloud native principle. Disabling privilege escalation and dropping Linux capabilities reduce risk but do not replace image or API authorization. Check its effect by: Inspect securityContext, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile and startup errors. This is the implementation part of the required paired answer. Workload context: A team specifies a restrictive seccomp profile but its runtime ignores an unsupported profile name and administrators must check enforcement.
Incorrect Answers
C:Inspect PVC phase, PV claimRef, capacity, accessModes, storageClassName and volume-mount events. This step belongs to PersistentVolume and claim bindings rather than the complementary implementation and evidence pair. The intended approach is: Run containers with nonroot identities, minimal capabilities and an appropriate seccomp profile for reduced kernel attack surface. Validate with: Inspect securityContext, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile and startup errors. Workload context: A team specifies a restrictive seccomp profile but its runtime ignores an unsupported profile name and administrators must check enforcement.
D:Combine RBAC with NetworkPolicy to control both Kubernetes API permissions and east-west workload traffic. This step belongs to Namespace segmentation with NetworkPolicies rather than the complementary implementation and evidence pair. The intended approach is: Run containers with nonroot identities, minimal capabilities and an appropriate seccomp profile for reduced kernel attack surface. Validate with: Inspect securityContext, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile and startup errors. Workload context: A team specifies a restrictive seccomp profile but its runtime ignores an unsupported profile name and administrators must check enforcement.
E:Only approved Pod flows pass and disallowed lateral or outbound connections fail reproducibly. This step belongs to NetworkPolicy ingress egress isolation rather than the complementary implementation and evidence pair. The intended approach is: Run containers with nonroot identities, minimal capabilities and an appropriate seccomp profile for reduced kernel attack surface. Validate with: Inspect securityContext, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile and startup errors. Workload context: A team specifies a restrictive seccomp profile but its runtime ignores an unsupported profile name and administrators must check enforcement.
Question 101
An architect assumes a project listed in the CNCF landscape is necessarily graduated and supported by the Kubernetes maintainers. Which TWO complementary steps supply the appropriate approach AND the evidence required to validate it? Select TWO.
- Evaluate CNCF sandbox, incubating and graduated projects in context of maintenance, community adoption and technical fit.
- Project maintainers receive actionable confidential reports and releases can be coordinated without exposing affected users prematurely.
- Inspect LICENSE files, contribution guidelines, DCO or CLA requirements and third-party dependency notices.
- Review CNCF landscape category, project governance, release cadence, support ecosystem and security disclosures.
- Design bounded microservice interfaces with timeouts, retries and independently deployable service contracts where modularity is useful.
Explanation
Correct Answers
A:Evaluate CNCF sandbox, incubating and graduated projects in context of maintenance, community adoption and technical fit. This response implements the controlling Kubernetes or cloud native principle. CNCF maturity levels indicate aspects of governance and adoption, not a guarantee of security or perfect product fit. Check its effect by: Review CNCF landscape category, project governance, release cadence, support ecosystem and security disclosures. This is the implementation part of the required paired answer. Workload context: An architect assumes a project listed in the CNCF landscape is necessarily graduated and supported by the Kubernetes maintainers.
D: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. This is the diagnostic evidence part of the paired answer. Workload context: An architect assumes a project listed in the CNCF landscape is necessarily graduated and supported by the Kubernetes maintainers.
Incorrect Answers
B:Project maintainers receive actionable confidential reports and releases can be coordinated without exposing affected users prematurely. This step belongs to Responsible vulnerability disclosure in communities rather than the complementary implementation and evidence pair. The intended approach is: Evaluate CNCF sandbox, incubating and graduated projects in context of maintenance, community adoption and technical fit. Validate with: Review CNCF landscape category, project governance, release cadence, support ecosystem and security disclosures. Workload context: An architect assumes a project listed in the CNCF landscape is necessarily graduated and supported by the Kubernetes maintainers.
C:Inspect LICENSE files, contribution guidelines, DCO or CLA requirements and third-party dependency notices. This step belongs to Open source licensing and contribution basics rather than the complementary implementation and evidence pair. The intended approach is: Evaluate CNCF sandbox, incubating and graduated projects in context of maintenance, community adoption and technical fit. Validate with: Review CNCF landscape category, project governance, release cadence, support ecosystem and security disclosures. Workload context: An architect assumes a project listed in the CNCF landscape is necessarily graduated and supported by the Kubernetes maintainers.
E:Design bounded microservice interfaces with timeouts, retries and independently deployable service contracts where modularity is useful. This step belongs to Microservices contracts and failure isolation rather than the complementary implementation and evidence pair. The intended approach is: Evaluate CNCF sandbox, incubating and graduated projects in context of maintenance, community adoption and technical fit. Validate with: Review CNCF landscape category, project governance, release cadence, support ecosystem and security disclosures. Workload context: An architect assumes a project listed in the CNCF landscape is necessarily graduated and supported by the Kubernetes maintainers.
Question 102
An engineer records build information only as an annotation and expects a Deployment selector to find those Pods. 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.
- Controllers and Services select exactly the intended Pods while audit annotations retain descriptive notes.
- Pods assigned to a healthy node start and report status with failed containers surfaced for diagnosis.
- Co-located containers communicate over localhost and move through Pod lifecycle as an atomic scheduling unit.
Explanation
Correct Answer
B:Controllers and Services select exactly the intended Pods while audit annotations retain descriptive notes. This is an observable service outcome, not just evidence that a configuration file was saved. Labels support equality and set-based selectors; annotations do not become Service selectors automatically. Workload context: An engineer records build information only as an annotation and expects a Deployment selector to find those Pods.
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: Controllers and Services select exactly the intended Pods while audit annotations retain descriptive notes. Workload context: An engineer records build information only as an annotation and expects a Deployment selector to find those Pods.
C:Pods assigned to a healthy node start and report status with failed containers surfaced for diagnosis. That result validates Kubelet node agent responsibilities rather than the requirement here. Verify instead: Controllers and Services select exactly the intended Pods while audit annotations retain descriptive notes. Workload context: An engineer records build information only as an annotation and expects a Deployment selector to find those Pods.
D:Co-located containers communicate over localhost and move through Pod lifecycle as an atomic scheduling unit. That result validates Pod shared network namespace and lifecycle rather than the requirement here. Verify instead: Controllers and Services select exactly the intended Pods while audit annotations retain descriptive notes. Workload context: An engineer records build information only as an annotation and expects a Deployment selector to find those Pods.
Question 103
A cluster operator force-applies an updated manifest and overwrites another controller's managed fields without checking conflicts. Which TWO complementary steps supply the appropriate approach AND the evidence required to validate it? Select TWO.
- Pods with persistent volumes schedule to nodes capable of mounting the selected storage without zone conflicts.
- Inspect local-versus-server manifest diff, field ownership, admission rejection and resulting resource generation.
- Inspect resource status, conditions, events, generation, owner references and logs from the relevant container.
- Use kubectl apply or a governed reconciliation workflow for repeatable desired-state changes, reviewing diffs before high-impact updates.
- Set workload requests for placement and limits for bounded runtime use based on measured application needs.
Explanation
Correct Answers
B:Inspect local-versus-server manifest diff, field ownership, admission rejection and resulting resource generation. This is the most discriminating evidence for the described failure or requirement. Declarative apply merges intended fields but conflicts and imperative edits require field ownership review. The corresponding implementation is: Use kubectl apply or a governed reconciliation workflow for repeatable desired-state changes, reviewing diffs before high-impact updates. This is the diagnostic evidence part of the paired answer. Workload context: A cluster operator force-applies an updated manifest and overwrites another controller's managed fields without checking conflicts.
D:Use kubectl apply or a governed reconciliation workflow for repeatable desired-state changes, reviewing diffs before high-impact updates. This response implements the controlling Kubernetes or cloud native principle. Declarative apply merges intended fields but conflicts and imperative edits require field ownership review. Check its effect by: Inspect local-versus-server manifest diff, field ownership, admission rejection and resulting resource generation. This is the implementation part of the required paired answer. Workload context: A cluster operator force-applies an updated manifest and overwrites another controller's managed fields without checking conflicts.
Incorrect Answers
A: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 kubectl apply or a governed reconciliation workflow for repeatable desired-state changes, reviewing diffs before high-impact updates. Validate with: Inspect local-versus-server manifest diff, field ownership, admission rejection and resulting resource generation. Workload context: A cluster operator force-applies an updated manifest and overwrites another controller's managed fields without checking conflicts.
C:Inspect resource status, conditions, events, generation, owner references and logs from the relevant container. This step belongs to kubectl inspect and describe diagnostics rather than the complementary implementation and evidence pair. The intended approach is: Use kubectl apply or a governed reconciliation workflow for repeatable desired-state changes, reviewing diffs before high-impact updates. Validate with: Inspect local-versus-server manifest diff, field ownership, admission rejection and resulting resource generation. Workload context: A cluster operator force-applies an updated manifest and overwrites another controller's managed fields without checking conflicts.
E:Set workload requests for placement and limits for bounded runtime use based on measured application needs. This step belongs to CPU requests and memory limits rather than the complementary implementation and evidence pair. The intended approach is: Use kubectl apply or a governed reconciliation workflow for repeatable desired-state changes, reviewing diffs before high-impact updates. Validate with: Inspect local-versus-server manifest diff, field ownership, admission rejection and resulting resource generation. Workload context: A cluster operator force-applies an updated manifest and overwrites another controller's managed fields without checking conflicts.
Question 104
A Service declares port 80 and targetPort 8080 but the app listens on 9090, producing connection failures despite valid DNS. Which TWO complementary steps supply the appropriate approach AND the evidence required to validate it? Select TWO.
- Approved workloads can access required credentials while unauthorized viewers cannot recover plaintext through the API.
- Compare Service type, clusterIP, nodePort, targetPort, node addresses and backend EndpointSlices.
- Inspect Service selector, Pod readiness, EndpointSlice addresses, kube-proxy or eBPF service programming and target ports.
- Use ClusterIP for private service access and NodePort only when node-level external ports are intentionally needed.
- Use supported Ingress or Gateway API resources together with a running controller to route HTTP traffic by host and path.
Explanation
Correct Answers
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. This is the diagnostic evidence part of the paired answer. Workload context: A Service declares port 80 and targetPort 8080 but the app listens on 9090, producing connection failures despite valid DNS.
D:Use ClusterIP for private service access and NodePort only when node-level external ports are intentionally needed. This response implements the controlling Kubernetes or cloud native principle. ClusterIP does not automatically provide an external endpoint; NodePort opens a port on eligible nodes with network policy constraints. Check its effect by: Compare Service type, clusterIP, nodePort, targetPort, node addresses and backend EndpointSlices. This is the implementation part of the required paired answer. 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:Approved workloads can access required credentials while unauthorized viewers cannot recover plaintext through the API. This step belongs to Secret base64 encoding versus encryption rather than the complementary implementation and evidence pair. The intended approach is: Use ClusterIP for private service access and NodePort only when node-level external ports are intentionally needed. Validate with: 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 Service selector, Pod readiness, EndpointSlice addresses, kube-proxy or eBPF service programming and target ports. This step belongs to Service endpoint routing and kube-proxy rather than the complementary implementation and evidence pair. The intended approach is: Use ClusterIP for private service access and NodePort only when node-level external ports are intentionally needed. Validate with: 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.
E:Use supported Ingress or Gateway API resources together with a running controller to route HTTP traffic by host and path. This step belongs to Ingress and Gateway API routing rather than the complementary implementation and evidence pair. The intended approach is: Use ClusterIP for private service access and NodePort only when node-level external ports are intentionally needed. Validate with: 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 105
A pipeline signs a release tag string without binding its attestation to the exact image digest deployed later. Which evidence should the engineer inspect FIRST to distinguish the likely cause or verify the prerequisite?
- Inspect error-budget impact, traffic exposure, request latency, alert window and controller decisions.
- Compare Git revision, application sync status, live resource diff and reconciliation events.
- Examine trusted builder identity, attestation payload, artifact digest, SBOM and admission verification result.
- Compare trace IDs, time synchronized log events, resource saturation metrics and span durations.
Explanation
Correct Answer
C: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 pipeline signs a release tag string without binding its attestation to the exact image digest deployed later.
Incorrect Answers
A:Inspect error-budget impact, traffic exposure, request latency, alert window and controller decisions. These observations are more relevant to Progressive delivery and release metrics, not this case. The distinguishing check is: Examine trusted builder identity, attestation payload, artifact digest, SBOM and admission verification result. Workload context: A pipeline signs a release tag string without binding its attestation to the exact image digest deployed later.
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 pipeline signs a release tag string without binding its attestation to the exact image digest deployed later.
D:Compare trace IDs, time synchronized log events, resource saturation metrics and span durations. These observations are more relevant to Correlating metrics logs and traces, not this case. The distinguishing check is: Examine trusted builder identity, attestation payload, artifact digest, SBOM and admission verification result. Workload context: A pipeline signs a release tag string without binding its attestation to the exact image digest deployed later.
Question 106
A cluster operator force-applies an updated manifest and overwrites another controller's managed fields without checking conflicts. Which observable result BEST confirms the desired Kubernetes or cloud native behavior?
- Reapplying unchanged configuration is safe and the resulting cluster state matches the reviewed manifest.
- Each eligible node runs the intended agent and newly added eligible nodes receive it automatically.
- All intended replicas run the approved digest and upgrades trace back to a reviewed artifact.
- Co-located containers communicate over localhost and move through Pod lifecycle as an atomic scheduling unit.
Explanation
Correct Answer
A:Reapplying unchanged configuration is safe and the resulting cluster state matches the reviewed manifest. This is an observable service outcome, not just evidence that a configuration file was saved. Declarative apply merges intended fields but conflicts and imperative edits require field ownership review. Workload context: A cluster operator force-applies an updated manifest and overwrites another controller's managed fields without checking conflicts.
Incorrect Answers
B:Each eligible node runs the intended agent and newly added eligible nodes receive it automatically. That result validates DaemonSet node-local workloads rather than the requirement here. Verify instead: Reapplying unchanged configuration is safe and the resulting cluster state matches the reviewed manifest. Workload context: A cluster operator force-applies an updated manifest and overwrites another controller's managed fields without checking conflicts.
C:All intended replicas run the approved digest and upgrades trace back to a reviewed artifact. That result validates Immutable container images and digests rather than the requirement here. Verify instead: Reapplying unchanged configuration is safe and the resulting cluster state matches the reviewed manifest. Workload context: A cluster operator force-applies an updated manifest and overwrites another controller's managed fields without checking conflicts.
D:Co-located containers communicate over localhost and move through Pod lifecycle as an atomic scheduling unit. That result validates Pod shared network namespace and lifecycle rather than the requirement here. Verify instead: Reapplying unchanged configuration is safe and the resulting cluster state matches the reviewed manifest. Workload context: A cluster operator force-applies an updated manifest and overwrites another controller's managed fields without checking conflicts.
Question 107
A registry migration changes its host name and worker nodes report image pull failures despite healthy deployment manifests. Which TWO complementary steps supply the appropriate approach AND the evidence required to validate it? Select TWO.
- Review initContainers/sidecar restart behavior, shared volumes, localhost traffic and termination events.
- Clients reach the intended healthy backends through a stable Service name despite Pod replacement.
- Check registry path, pull Secret, tag or digest, IAM grant, TLS trust and registry audit logs.
- Pull images from approved OCI-compatible registries with controlled image credentials and documented access boundaries.
- Choose imagePullPolicy based on tag immutability and cluster delivery needs, checking runtime cache and registry accessibility.
Explanation
Correct Answers
C: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. This is the diagnostic evidence part of the paired answer. Workload context: A registry migration changes its host name and worker nodes report image pull failures despite healthy deployment manifests.
D:Pull images from approved OCI-compatible registries with controlled image credentials and documented access boundaries. This response implements the controlling Kubernetes or cloud native principle. OCI registries store/distribute image artifacts; they do not orchestrate Pods or apply cluster networking. Check its effect by: Check registry path, pull Secret, tag or digest, IAM grant, TLS trust and registry audit logs. This is the implementation part of the required paired answer. Workload context: A registry migration changes its host name and worker nodes report image pull failures despite healthy deployment manifests.
Incorrect Answers
A:Review initContainers/sidecar restart behavior, shared volumes, localhost traffic and termination events. This step belongs to Sidecar containers and shared Pod lifecycle rather than the complementary implementation and evidence pair. The intended approach is: Pull images from approved OCI-compatible registries with controlled image credentials and documented access boundaries. Validate with: 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.
B:Clients reach the intended healthy backends through a stable Service name despite Pod replacement. This step belongs to Service stable virtual endpoint rather than the complementary implementation and evidence pair. The intended approach is: Pull images from approved OCI-compatible registries with controlled image credentials and documented access boundaries. Validate with: 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.
E:Choose imagePullPolicy based on tag immutability and cluster delivery needs, checking runtime cache and registry accessibility. This step belongs to Image pull policy and cached images rather than the complementary implementation and evidence pair. The intended approach is: Pull images from approved OCI-compatible registries with controlled image credentials and documented access boundaries. Validate with: 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 108
A security review finds unencrypted etcd peer traffic and stale snapshots on a shared administrative workstation. Which evidence should the engineer inspect FIRST to distinguish the likely cause or verify the prerequisite?
- Inspect Pod ephemeralContainers entries, RBAC privileges, target process namespace and active diagnostic sessions.
- Inspect etcd quorum health, member status, snapshot freshness, certificate validity and restore procedure.
- Inspect allowedDisruptions, healthy replicas, minAvailable/maxUnavailable and drain eviction results.
- Inspect Service type, selector, EndpointSlices, DNS name and backend Pod readiness.
Explanation
Correct Answer
B:Inspect etcd quorum health, member status, snapshot freshness, certificate validity and restore procedure. This is the most discriminating evidence for the described failure or requirement. etcd is a consistent key-value store for API state; it is not where persistent application volume data lives. The corresponding implementation is: Keep etcd highly available and maintain secure, tested snapshots of Kubernetes API state rather than treating it as ordinary container storage. Workload context: A security review finds unencrypted etcd peer traffic and stale snapshots on a shared administrative workstation.
Incorrect Answers
A:Inspect Pod ephemeralContainers entries, RBAC privileges, target process namespace and active diagnostic sessions. These observations are more relevant to Ephemeral debugging containers, not this case. The distinguishing check is: Inspect etcd quorum health, member status, snapshot freshness, certificate validity and restore procedure. Workload context: A security review finds unencrypted etcd peer traffic and stale snapshots on a shared administrative workstation.
C: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: Inspect etcd quorum health, member status, snapshot freshness, certificate validity and restore procedure. Workload context: A security review finds unencrypted etcd peer traffic and stale snapshots on a shared administrative workstation.
D:Inspect Service type, selector, EndpointSlices, DNS name and backend Pod readiness. These observations are more relevant to Service stable virtual endpoint, not this case. The distinguishing check is: Inspect etcd quorum health, member status, snapshot freshness, certificate validity and restore procedure. Workload context: A security review finds unencrypted etcd peer traffic and stale snapshots on a shared administrative workstation.
Question 109
A monitoring agent obtains a 403 from the Kubernetes API and operators mistakenly conclude the backing etcd database is unavailable. Which observable result BEST confirms the desired Kubernetes or cloud native behavior?
- Authorized clients create or read resources through the API and unauthorized calls fail consistently.
- Critical workloads gain capacity when eligible without uncontrolled eviction of unrelated protected services.
- Teams receive predictable defaults and cannot consume more namespace resources than policy permits.
- A supported resource can be applied predictably and unknown fields or removed API versions are identified before rollout.
Explanation
Correct Answer
A:Authorized clients create or read resources through the API and unauthorized calls fail consistently. This is an observable service outcome, not just evidence that a configuration file was saved. kube-apiserver validates and serves API requests; etcd stores cluster state rather than exposing the user API. Workload context: A monitoring agent obtains a 403 from the Kubernetes API and operators mistakenly conclude the backing etcd database is unavailable.
Incorrect Answers
B:Critical workloads gain capacity when eligible without uncontrolled eviction of unrelated protected services. That result validates PriorityClass and preemption rather than the requirement here. Verify instead: Authorized clients create or read resources through the API and unauthorized calls fail consistently. Workload context: A monitoring agent obtains a 403 from the Kubernetes API and operators mistakenly conclude the backing etcd database is unavailable.
C:Teams receive predictable defaults and cannot consume more namespace resources than policy permits. That result validates ResourceQuota and LimitRange policies rather than the requirement here. Verify instead: Authorized clients create or read resources through the API and unauthorized calls fail consistently. Workload context: A monitoring agent obtains a 403 from the Kubernetes API and operators mistakenly conclude the backing etcd database is unavailable.
D:A supported resource can be applied predictably and unknown fields or removed API versions are identified before rollout. That result validates Declarative resource manifests and API versions rather than the requirement here. Verify instead: Authorized clients create or read resources through the API and unauthorized calls fail consistently. Workload context: A monitoring agent obtains a 403 from the Kubernetes API and operators mistakenly conclude the backing etcd database is unavailable.
Question 110
A cluster upgrade removes an API version used by an old application chart and production apply fails. Which observable result BEST confirms the desired Kubernetes or cloud native behavior?
- Co-located containers communicate over localhost and move through Pod lifecycle as an atomic scheduling unit.
- Control-plane and node upgrades complete within supported skew with workload compatibility checks passing.
- Workloads read needed configuration while unauthorized users cannot retrieve credential material through the API.
- Scheduling constraints match verified node attributes without exhausting reserved system resources.
Explanation
Correct Answer
B:Control-plane and node upgrades complete within supported skew with workload compatibility checks passing. This is an observable service outcome, not just evidence that a configuration file was saved. API compatibility and supported component skew determine upgrade sequencing; not every Kubernetes version jump is supported. Workload context: A cluster upgrade removes an API version used by an old application chart and production apply fails.
Incorrect Answers
A:Co-located containers communicate over localhost and move through Pod lifecycle as an atomic scheduling unit. That result validates Pod shared network namespace and lifecycle rather than the requirement here. Verify instead: Control-plane and node upgrades complete within supported skew with workload compatibility checks passing. Workload context: A cluster upgrade removes an API version used by an old application chart and production apply fails.
C:Workloads read needed configuration while unauthorized users cannot retrieve credential material through the API. That result validates ConfigMap and Secret boundaries rather than the requirement here. Verify instead: Control-plane and node upgrades complete within supported skew with workload compatibility checks passing. Workload context: A cluster upgrade removes an API version used by an old application chart and production apply fails.
D:Scheduling constraints match verified node attributes without exhausting reserved system resources. That result validates Node labels and allocatable inventory rather than the requirement here. Verify instead: Control-plane and node upgrades complete within supported skew with workload compatibility checks passing. Workload context: A cluster upgrade removes an API version used by an old application chart and production apply fails.
