Courseiva

CCNA Cluster Hardening Questions

20 questions · Cluster Hardening · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

A cluster uses RBAC and a ServiceAccount 'monitor' in namespace 'observability'. The account needs to list pods in all namespaces. Which ClusterRole and binding should be created?

A.Role with 'list' on pods, RoleBinding in observability
B.ClusterRole with 'get' on pods, ClusterRoleBinding
C.ClusterRole with 'list' on pods, RoleBinding in observability
D.ClusterRole with 'list' on pods, ClusterRoleBinding
AnswerD

A ClusterRole is not bound to any namespace, and a ClusterRoleBinding grants its permissions cluster-wide or across all namespaces. By combining the 'list' verb on pods with these two cluster-scoped resources, the monitor ServiceAccount can list pods in every namespace. This is the standard and correct way to grant cross-namespace pod enumeration in RBAC.

Why this answer

A ServiceAccount that needs to list pods across all namespaces requires a ClusterRole with the 'list' verb on pods, because ClusterRoles are not namespaced and can grant permissions cluster-wide. A ClusterRoleBinding is necessary to bind that ClusterRole to the ServiceAccount, as RoleBindings only apply within a single namespace and cannot grant cluster-scoped permissions.

Exam trap

The trap here is that candidates often confuse RoleBindings with ClusterRoleBindings, thinking a RoleBinding can grant cluster-wide access if the role is a ClusterRole, but in reality the binding's scope (namespace vs. cluster) determines the effective scope of the permissions.

How to eliminate wrong answers

Option A is wrong because a Role is namespaced and cannot grant permissions across all namespaces; also, a RoleBinding only applies within its namespace. Option B is wrong because the verb 'get' only allows retrieving a specific pod, not listing pods; the required verb is 'list'. Option C is wrong because a RoleBinding cannot bind a ClusterRole to grant cluster-wide access; it would only apply the ClusterRole's permissions within the 'observability' namespace, not across all namespaces.

Practice this question →
2
MCQhard

You are the security engineer for a multi-tenant Kubernetes cluster. The cluster uses kubeadm and runs Kubernetes v1.24. Each tenant has a dedicated namespace. A new tenant, 'acme-corp', requires that all pods in their namespace run with a read-only root filesystem and must not be able to escalate privileges. They also need to run a legacy container that must listen on a port below 1024. The cluster currently uses PodSecurityPolicy (PSP) but is planning to migrate to Pod Security Admission (PSA). The legacy container needs to run as non-root with the NET_BIND_SERVICE capability to bind to port 80. You need to configure security policies for the 'acme-corp' namespace without affecting other tenants. Which approach best meets these requirements while following Kubernetes best practices?

A.Enable Pod Security Admission with the 'baseline' policy in enforce mode for acme-corp namespace, and add a mutating webhook to set readOnlyRootFilesystem
B.Use OPA/Gatekeeper to create a ConstraintTemplate that requires readOnlyRootFilesystem and allows only NET_BIND_SERVICE capability, then apply it to acme-corp namespace
C.Use Pod Security Admission with the 'privileged' policy and rely on the legacy container's securityContext
D.Create a new PSP that allows NET_BIND_SERVICE and requires readOnlyRootFilesystem, then bind it to the acme-corp namespace via RoleBinding
AnswerB

OPA/Gatekeeper is the appropriate choice because it provides a flexible, declarative policy engine that can enforce arbitrary constraints via ConstraintTemplates. A dedicated template can validate that every pod in acme-corp sets securityContext.readOnlyRootFilesystem to true and that any added Linux capabilities are limited to exactly NET_BIND_SERVICE. This approach is more precise than Pod Security Standards, is actively maintained, and can be scoped to a namespace with a Constraint resource, while also supporting dry-run and audit modes for safe rollout.

Why this answer

OPA/Gatekeeper allows fine-grained, namespace-scoped policy enforcement that can require readOnlyRootFilesystem and restrict capabilities to only NET_BIND_SERVICE, meeting all requirements without affecting other tenants. Pod Security Admission (PSA) does not support custom capability restrictions or readOnlyRootFilesystem enforcement natively, and PSP is deprecated in Kubernetes v1.24 and being removed, making it unsuitable for new configurations. Gatekeeper’s ConstraintTemplate provides the flexibility to enforce these specific security contexts while following best practices for policy-as-code.

Exam trap

The trap here is that candidates may choose Pod Security Admission (PSA) because it is the newer, recommended replacement for PSP, but PSA lacks the granularity to enforce readOnlyRootFilesystem or restrict capabilities to a single capability like NET_BIND_SERVICE, leading to an incorrect choice like Option A or C.

How to eliminate wrong answers

Option A is wrong because Pod Security Admission (PSA) with the 'baseline' policy does not enforce readOnlyRootFilesystem or allow fine-grained capability control like only NET_BIND_SERVICE; it only restricts privileged containers and host namespaces, and a mutating webhook would be an additional, non-standard workaround. Option C is wrong because the 'privileged' policy in PSA allows all capabilities and privilege escalation, directly violating the requirement to prevent privilege escalation and enforce a read-only root filesystem. Option D is wrong because PodSecurityPolicy (PSP) is deprecated in Kubernetes v1.24 and will be removed in v1.25, making it a non-compliant choice for new configurations; additionally, PSPs are cluster-scoped and binding them via RoleBinding to a namespace is not the intended mechanism (they require PSP-specific RBAC bindings).

Practice this question →
3
MCQmedium

An operator must upgrade a kubeadm cluster and wants to verify that the new control plane binaries are authentic before installing them. The team already has the Kubernetes release signing key. Which step confirms the integrity and origin of the downloaded binary?

A.Run openssl dgst -sha256 on the binary and confirm it matches the checksum file downloaded from the same server.
B.Import the release key into kubeadm's trust store and let kubeadm verify binaries automatically during upgrade.
C.Compare the SHA-512 hash of the binary against the value published in the release notes, then install it.
D.Verify the detached signature over the checksum file with the release signing key, then confirm the binary's hash matches the signed checksum.
AnswerD

Signing the checksum file and verifying that signature with the trusted release key establishes origin, and matching the binary's hash to the signed checksum establishes integrity. This two-step chain is exactly what the Kubernetes release process publishes and is the recommended verification for downloaded artifacts before installing them on control plane nodes.

Why this answer

The Kubernetes release process publishes a checksum file and a detached signature over that file. Verifying the signature with the trusted release key proves the checksum file is authentic, and matching the binary's hash to the signed checksum proves the binary itself is intact. Hash comparisons alone or checksums fetched from the same origin do not establish origin, and kubeadm does not verify binaries automatically.

Exam trap

The trap here is treating a SHA-512 hash comparison as sufficient provenance verification, when a signed checksum verified with the release key is what actually binds the artifact to the project.

Practice this question →
4
MCQmedium

A security team is hardening a cluster where the kube-apiserver is started with the flag --authorization-mode=Node,RBAC. A penetration test reveals that kubelet authentication is using anonymous requests and the webhook authorizer is not enabled. To ensure that kubelet API requests are authenticated and authorized, which combination of kubelet configuration changes should be applied?

A.Set authentication.webhook.enabled=true and authorization.mode=Node in the kubelet config file.
B.Set authentication.x509.clientCAFile to a valid CA and authorization.mode=AlwaysAllow in the kubelet config file.
C.Set authentication.anonymous.enabled=true and authorization.mode=AlwaysAllow in the kubelet config file.
D.Set authentication.anonymous.enabled=false and authorization.mode=Webhook in the kubelet config file.
AnswerD

Disabling anonymous authentication forces all requests to be authenticated, and setting authorization mode to Webhook delegates authorization decisions to the API server. This ensures that only authenticated and authorized entities can access the kubelet API. It directly addresses the penetration test finding by preventing anonymous access and enforcing proper authorization, aligning with Kubernetes security best practices for cluster hardening.

Why this answer

The correct configuration disables anonymous authentication and sets the kubelet authorization mode to Webhook. This forces all kubelet API requests to be authenticated and then authorized by the API server, eliminating anonymous access and ensuring only authorized actions are allowed. This directly remediates the penetration test finding and is a fundamental step in cluster hardening.

Exam trap

The trap here is assuming that enabling any authentication method is sufficient, while overlooking that authorization mode must also be set to Webhook to prevent anonymous or overly permissive access.

Practice this question →
5
Multi-Selecthard

Which THREE of the following are required to secure etcd in a Kubernetes cluster?

Select 3 answers
A.Configure RBAC for etcd
B.Allow anonymous access for monitoring
C.Require client certificate authentication
D.Enable encryption at rest for secrets
E.Use TLS for peer and client communication
AnswersC, D, E

Requiring client certificate authentication ensures that every request to etcd comes from a verified client, such as the Kubernetes API server. The etcd server validates the client's certificate against a trusted CA, preventing unauthorized or forged clients from connecting. This mutual TLS authentication is a foundational requirement because without it, attackers could directly query or alter cluster data, bypassing API server controls.

Why this answer

Etcd requires client certificate authentication to verify the identity of clients (such as kube-apiserver) connecting to it. Without mutual TLS (mTLS), an attacker could impersonate a legitimate client and read or modify cluster state, including secrets and configuration data.

Exam trap

CNCF often tests the misconception that etcd has its own RBAC or that anonymous access can be safely allowed for monitoring, when in fact etcd relies solely on TLS certificate authentication and encryption at rest is a separate mandatory control.

Practice this question →
6
Multi-Selecteasy

Which TWO of the following are best practices for securing container images?

Select 2 answers
A.Always use the latest tag
B.Use minimal base images like distroless
C.Run containers as root
D.Run containers in privileged mode
E.Use image vulnerability scanning
AnswersB, E

Distroless base images contain only the application and its runtime libraries, omitting shells, package managers, and compilers. This dramatically reduces the attack surface because an attacker who gains code execution has no interactive shell, no apt/yum, and no build toolchain to pivot with, and there are fewer packages to scan for known vulnerabilities. They also encourage running as non-root and keeping the filesystem read-only.

Why this answer

Minimal base images like distroless reduce the attack surface by eliminating unnecessary packages, libraries, and shell access. This aligns with the principle of least functionality, making it harder for attackers to exploit vulnerabilities or execute arbitrary commands within the container. Distroless images typically contain only the application and its runtime dependencies, significantly lowering the risk of privilege escalation or lateral movement.

Exam trap

CNCF often tests the misconception that using the 'latest' tag is safe or recommended, when in fact it is a security anti-pattern that undermines image integrity and reproducibility.

Practice this question →
7
MCQhard

A security team wants to ensure that all pods in a namespace run with a restricted seccomp profile. Which Pod Security Standard admission controller mode should be used to enforce this without blocking necessary pods?

A.Enable the PodSecurity admission plugin with the 'restricted' policy and 'enforce' mode
B.Use a mutating admission webhook to automatically add seccomp profiles
C.Enable the PodSecurity admission plugin with the 'baseline' policy and 'enforce' mode
D.Enable the PodSecurity admission plugin with the 'restricted' policy and 'warn' mode
AnswerA

PodSecurity admission with the 'restricted' policy in 'enforce' mode acts as an admission controller that rejects any pod that fails the restricted profile, including the requirement that seccomp be set to RuntimeDefault or Localhost. This directly blocks non-compliant pods at creation time, ensuring only pods meeting the strict security requirements run in the namespace. Enforce mode is the only mode that provides hard enforcement, making this the correct choice.

Why this answer

The Pod Security Standards (PSS) define three policies: privileged, baseline, and restricted. The restricted policy enforces the most stringent security controls, including requiring a seccomp profile to be set to 'RuntimeDefault' or 'localhost/*'. Using the PodSecurity admission plugin with 'enforce' mode ensures that any pod failing the restricted policy is immediately rejected, guaranteeing that only compliant pods run in the namespace.

Exam trap

CNCF often tests the distinction between 'enforce' and 'warn' modes: candidates mistakenly choose 'warn' thinking it is sufficient, but 'enforce' is required to actually block non-compliant pods.

How to eliminate wrong answers

Option B is wrong because a mutating admission webhook can automatically add seccomp profiles, but it does not enforce a Pod Security Standard policy; it only mutates the pod spec, and pods could still be created without the required profile if the webhook fails or is bypassed. Option C is wrong because the 'baseline' policy is less restrictive and does not require a seccomp profile; it only prevents known privilege escalations, so it would not enforce the restricted seccomp requirement. Option D is wrong because 'warn' mode only generates a warning for non-compliant pods but still allows them to be created, which does not enforce the restricted seccomp profile as required by the question.

Practice this question →
8
Multi-Selecthard

Which THREE of the following are valid methods to enforce pod security standards in a Kubernetes cluster?

Select 3 answers
A.Use Kyverno policy engine
B.Run kube-bench on the cluster
C.Manual review of all pod specs
D.Use Open Policy Agent (OPA) with Gatekeeper
E.Enable PodSecurity admission plugin
AnswersA, D, E

Kyverno is a Kubernetes-native policy engine that operates as a dynamic admission controller, intercepting AdmissionReview requests during resource creation and modification. It enforces pod security by evaluating policies written as custom Kubernetes resources, which can include built-in rules aligned with the Pod Security Standards. Unlike static analysis or auditing, Kyverno actively rejects or mutates non-compliant pod manifests before they are persisted in etcd, making it a valid enforcement method.

Why this answer

Kyverno is a Kubernetes-native policy engine that can enforce pod security standards by validating, mutating, and generating resources based on policies written as Kubernetes custom resources. It integrates with the Kubernetes API server via dynamic admission webhooks, allowing it to reject non-compliant pod specs before they are persisted.

Exam trap

CNCF often tests the distinction between auditing tools (like kube-bench) and admission controllers that enforce policies at runtime, leading candidates to mistakenly select kube-bench as an enforcement method.

Practice this question →
9
Multi-Selectmedium

Which TWO of the following are valid ways to restrict access to the Kubernetes API server?

Select 2 answers
A.Use static token file
B.Use webhook token authentication
C.Enable NodeRestriction admission plugin
D.Configure RBAC authorization
E.Enable anonymous access
AnswersB, D

Webhook token authentication offloads token validation to an external webhook service, such as an OIDC provider, custom authentication server, or policy engine. When a user presents a token, the API server sends a TokenReview to the webhook endpoint and applies the returned status, allowing dynamic validation, immediate revocation, and integration with enterprise SSO. This is a secure and flexible authentication method that can be combined with RBAC to enforce fine-grained authorization after a user’s identity is reliably established.

Why this answer

Webhook token authentication (Option B) is a valid method to restrict API server access because it delegates token validation to an external service via a webhook, allowing custom authentication logic. This is a supported authentication strategy in Kubernetes, enabling fine-grained control over who can access the API server.

Exam trap

CNCF often tests the distinction between authentication (who you are) and authorization (what you can do), so candidates may confuse RBAC (authorization) with authentication mechanisms like webhook tokens, but the question asks for ways to 'restrict access,' which includes both authentication and authorization controls.

Practice this question →
10
MCQeasy

A Kubernetes administrator is reviewing the cluster's RBAC configuration and notices that a ClusterRoleBinding grants the cluster-admin role to the system:anonymous user. What is the most immediate and appropriate action to harden the cluster?

A.Add an RBAC rule to deny all actions for system:anonymous.
B.Enable the NodeRestriction admission controller to limit anonymous access.
C.Delete the ClusterRoleBinding to revoke anonymous cluster-admin access.
D.Modify the ClusterRoleBinding to bind to a specific user instead of system:anonymous.
AnswerC

Deleting the ClusterRoleBinding immediately removes the excessive privileges granted to the system:anonymous user, preventing unauthenticated users from performing administrative actions. This is the most direct and critical remediation step to close the security hole. Leaving it in place would allow anyone to take full control of the cluster, so removal is essential for hardening.

Why this answer

The most immediate action is to delete the ClusterRoleBinding that grants cluster-admin to system:anonymous. This binding allows unauthenticated users to have full administrative privileges, which is a severe security risk. Removing it eliminates the exposure.

Other options either do not address the binding or rely on incorrect RBAC mechanics.

Exam trap

The trap here is assuming that RBAC supports deny rules or that other admission controllers can override excessive permissions, when in fact RBAC is purely additive and the binding must be removed.

Practice this question →
11
MCQmedium

A security review flags that developers can create pods that mount the host's /etc directory. You need to block hostPath volumes cluster-wide without breaking existing workloads that use the CSI driver for persistent storage. Which control is appropriate?

A.Apply a PodSecurity admission label of restricted to every namespace so hostPath volumes are rejected.
B.Add a NetworkPolicy with an empty podSelector in each namespace to prevent pods from reading host filesystem paths.
C.Create a ValidatingAdmissionPolicy that denies pods whose spec.volumes contain a hostPath entry.
D.Set --allow-privileged=false on the kubelet of every node so hostPath mounts are refused at runtime.
AnswerC

A ValidatingAdmissionPolicy with a CEL expression can inspect pod volumes and reject any object containing a hostPath entry, while leaving CSI-backed volumes untouched because those use a csi volume source instead. This gives a cluster-wide, declarative deny rule that does not require a policy controller and aligns with the modern replacement for PodSecurityPolicy-style restrictions.

Why this answer

Blocking hostPath volumes requires admission-time inspection of the pod spec. ValidatingAdmissionPolicy lets you express a CEL rule that rejects any pod declaring a hostPath volume, which precisely targets the risk without imposing unrelated restrictions. CSI volumes use a different volume source, so legitimate persistent storage continues to work.

PodSecurity restricted, kubelet allow-privileged, and NetworkPolicy all act on different concerns and either over-restrict or miss the mount entirely.

Exam trap

The trap here is reaching for the restricted Pod Security Standard, which does block hostPath but also imposes many other requirements that would break the CSI workloads the scenario says must keep running.

Practice this question →
12
MCQhard

A cluster has a PodSecurityPolicy that requires 'RunAsAny' for the user. An administrator wants to enforce that all pods in namespace 'production' must run with a specific seccomp profile. Which approach is recommended given PSP is deprecated?

A.Enable PodSecurity admission with 'restricted' policy in enforce mode
B.Create a new PSP with seccomp profile and assign it to the namespace
C.Set seccomp profile in the kubelet configuration
D.Use a mutating admission webhook to add seccomp profile
AnswerA

PodSecurity admission is the built-in replacement for PSPs; the `restricted` policy in enforce mode validates every pod against a standard set of constraints, and it specifically requires a seccomp profile of `RuntimeDefault` or `localhost`. Because it runs in the admission phase, the API server rejects any pod that does not declare the profile, making it a true enforcement control at the namespace level. This is the recommended way to guarantee seccomp coverage across all workloads.

Why this answer

PodSecurity admission (the replacement for PSP) allows enforcing a 'restricted' policy that mandates a seccomp profile (e.g., RuntimeDefault) at the namespace level. This directly meets the requirement without relying on deprecated PSPs, and the 'enforce' mode ensures pods violating the policy are rejected.

Exam trap

CNCF often tests the deprecation of PSP and the shift to PodSecurity admission; the trap here is that candidates may still choose a PSP-based option (B) or overcomplicate with webhooks (D), missing the built-in, recommended replacement.

How to eliminate wrong answers

Option B is wrong because PSP is deprecated and will be removed in Kubernetes 1.25+, so creating a new PSP is not a recommended long-term solution; also, PSPs are cluster-scoped and cannot be directly assigned to a namespace without additional RBAC. Option C is wrong because kubelet configuration sets a default seccomp profile for all pods on the node, not per-namespace enforcement, and it cannot selectively target the 'production' namespace. Option D is wrong because while a mutating admission webhook could add the seccomp profile, it is more complex and less standard than using the built-in PodSecurity admission controller, which is the recommended approach per Kubernetes documentation.

Practice this question →
13
Drag & Dropmedium

Arrange the steps to enable and configure audit logging in Kubernetes.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Audit logging requires a policy file, mounting it, adding flags, restarting, and verifying logs.

Practice this question →
14
Matchingmedium

Match each Kubernetes security tool or feature to its purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Checks whether Kubernetes is deployed securely according to CIS benchmarks

Penetration testing tool for Kubernetes clusters

Policy engine for enforcing custom policies on Kubernetes resources

Runtime security monitoring tool that detects abnormal behavior

Vulnerability scanner for container images, filesystems, and Git repos

Why these pairings

Correct matches: Pod Security Admission enforces pod security standards; Network Policies control traffic; RBAC governs API access; kube-bench performs CIS checks. Common confusion arises from swapping definitions between PSA and Network Policies.

Practice this question →
15
MCQeasy

Which Kubernetes resource should be used to restrict egress traffic from pods?

A.NetworkPolicy with egress rules
B.PodSecurityPolicy
C.iptables rules on nodes
D.NetworkPolicy with ingress rules
AnswerA

NetworkPolicy with egress rules is the Kubernetes-native resource for restricting outbound traffic. An egress rule can select target pods via podSelector, namespaceSelector, or CIDR blocks, and also specify allowed ports. This provides API-declarative, label-based access control at L3/L4, enforced by the CNI plugin (e.g., Calico, Cilium). Since NetworkPolicy is a namespaced resource scoped to pods, it is the correct and supported mechanism to directly limit egress within a cluster.

Why this answer

NetworkPolicy with egress rules is the correct Kubernetes-native resource to restrict outbound traffic from pods. It uses label selectors, IP blocks, and port specifications to define which external destinations pods can reach, enforcing zero-trust network segmentation at the pod level.

Exam trap

The trap here is that candidates confuse egress (outbound) with ingress (inbound) rules, or assume PodSecurityPolicy can restrict network traffic, when it only governs pod security contexts like privileged mode and host namespaces.

How to eliminate wrong answers

Option B is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) controls security contexts and pod-level privileges, not network traffic direction. Option C is wrong because iptables rules on nodes are a low-level, node-centric approach that bypasses Kubernetes API management, lacks pod identity awareness, and is not a declarative Kubernetes resource. Option D is wrong because NetworkPolicy with ingress rules only controls incoming traffic to pods, not outgoing egress traffic.

Practice this question →
16
MCQhard

A pod is failing to start with: 'Error: container has runAsNonRoot and image will run as root'. The pod spec sets securityContext.runAsNonRoot: true. The container image is 'nginx:latest' which runs as root. Which change allows the pod to run while maintaining security?

A.Remove runAsNonRoot: true
B.Add a PodSecurityPolicy that allows root
C.Set runAsUser: 1000 in the container securityContext
D.Use a mutating webhook to change the image
AnswerC

Setting runAsUser: 1000 in the container's securityContext explicitly forces the container process to run with a non-zero UID, which satisfies the runAsNonRoot: true validation. The kubelet checks that the effective UID of the container is not 0; by fixing the UID to 1000, the check passes while maintaining a secure, non-root execution model. This is the minimal, direct, and security-preserving fix.

Why this answer

Setting `runAsUser: 1000` in the container's securityContext overrides the default user (root) in the image, ensuring the container process runs as a non-root user (UID 1000). This satisfies the `runAsNonRoot: true` constraint at the pod level, which requires that the container's user ID is non-zero, while still maintaining security by not running as root.

Exam trap

CNCF often tests the distinction between pod-level and container-level securityContext settings, and the trap here is that candidates might think removing `runAsNonRoot` or using a deprecated PSP is acceptable, rather than directly setting a non-root user ID in the container's securityContext.

How to eliminate wrong answers

Option A is wrong because removing `runAsNonRoot: true` would allow the container to run as root, which violates the security requirement of running as non-root. Option B is wrong because PodSecurityPolicy (PSP) is deprecated in Kubernetes 1.21+ and removed in 1.25; even if available, adding a policy that allows root would bypass the security constraint, not maintain it. Option D is wrong because using a mutating webhook to change the image (e.g., to a non-root image) is an indirect and unnecessary workaround; the direct fix is to set `runAsUser` in the container's securityContext, which is simpler and more explicit.

Practice this question →
17
MCQmedium

A developer created a ClusterRole 'pod-reader' with rules to get, list, and watch pods, and bound it to a user. The user reports they cannot list pods in namespace 'test', although the same commands work in the 'default' namespace. What is the most likely cause?

A.The ClusterRole must be bound with a RoleBinding
B.The user needs a ServiceAccount
C.The ClusterRole was bound with a namespace-scoped RoleBinding in 'default' instead of a ClusterRoleBinding
D.The pod-reader ClusterRole is missing 'list' verb
AnswerC

A ClusterRole bound with a RoleBinding inherits the namespace of that RoleBinding, so the permissions are limited to that namespace only. Because the developer created the RoleBinding in the 'default' namespace instead of using a ClusterRoleBinding, the user's list permission on pods does not extend to the 'test' namespace, causing the forbidden error.

Why this answer

The ClusterRole was bound with a namespace-scoped RoleBinding (created in the 'default' namespace) rather than a cluster-scoped ClusterRoleBinding. A RoleBinding can reference a ClusterRole, but it only grants those permissions inside the RoleBinding's own namespace — which is why access works in 'default' but not in 'test'. Binding the ClusterRole with a ClusterRoleBinding would grant pod access in every namespace.

Option A is wrong because a ClusterRoleBinding (not a RoleBinding) is what grants cluster-wide access. Option B is wrong because human users do not need ServiceAccounts. Option D is wrong because the scenario states the ClusterRole includes the 'list' verb.

Exam trap

The CKS exam tests the distinction between ClusterRoleBinding (cluster-wide) and RoleBinding (namespace-scoped). The trap: a ClusterRole grants nothing by itself — the *binding type and its namespace* decide where the permissions apply.

How to eliminate wrong answers

Option A is wrong because a ClusterRole can be bound with either a ClusterRoleBinding (cluster-wide) or a RoleBinding (namespace-scoped); the issue is not about the binding type but about namespace restriction. Option B is wrong because a ServiceAccount is not required for a user to use a ClusterRoleBinding; users (like those authenticated via certificates or OIDC) can be bound directly without a ServiceAccount. Option D is wrong because the question states the ClusterRole 'pod-reader' has rules to get, list, and watch pods, so the 'list' verb is present; the problem is not a missing verb.

Practice this question →
18
MCQmedium

A company uses kube-bench to scan their cluster. The report shows a warning: 'Ensure that the --authorization-mode argument is set to Node,RBAC'. What is the best way to fix this?

A.Add --authorization-mode=AlwaysDeny to the API server
B.Restart the API server with --authorization-webhook-config-file
C.Set --authorization-mode=RBAC only
D.Edit the kube-apiserver manifest to add --authorization-mode=Node,RBAC
AnswerD

Editing the kube-apiserver static manifest under /etc/kubernetes/manifests to add --authorization-mode=Node,RBAC is exactly what the CIS benchmark expects. This enables the Node authorizer for kubelet requests and the RBAC authorizer for all other identities, covering the two essential authorization paths. The kubelet will detect the manifest change and restart the API server as a static pod. This is the recommended configuration identified by kube-bench.

Why this answer

Kube-bench checks that the API server's `--authorization-mode` includes both `Node` and `RBAC` in that order. The `Node` authorizer must come first to handle node-specific requests efficiently, followed by `RBAC` for user and service account authorization. Editing the kube-apiserver manifest (typically `/etc/kubernetes/manifests/kube-apiserver.yaml`) to add `--authorization-mode=Node,RBAC` ensures the static pod is automatically restarted by the kubelet with the correct configuration.

Exam trap

The trap here is that candidates may think setting only `RBAC` is sufficient because it is the most common authorization mode, but the CKS exam specifically tests the requirement that `Node` must precede `RBAC` to handle node-level authorization correctly.

How to eliminate wrong answers

Option A is wrong because `--authorization-mode=AlwaysDeny` is a deprecated mode that denies all requests, which would break the cluster entirely and does not satisfy the requirement for Node and RBAC. Option B is wrong because `--authorization-webhook-config-file` configures an external webhook authorizer, but the warning specifically requires Node and RBAC modes, not a webhook; adding a webhook without Node and RBAC would still fail the kube-bench check. Option C is wrong because setting `--authorization-mode=RBAC` only omits the `Node` authorizer, which is necessary for kubelet and node identity authorization; this would cause node-related requests to be incorrectly handled and fail the kube-bench check.

Practice this question →
19
MCQeasy

An administrator wants to prevent pods from running as root. Which SecurityContext field should be set at the pod level?

A.fsGroup: 2000
B.runAsGroup: 3000
C.runAsUser: 1000
D.runAsNonRoot: true
AnswerD

When set to true, this securityContext field enforces at admission and runtime that the container's UID is non-zero. If the image's configured user or an explicit runAsUser is 0, Kubernetes will refuse to start the pod, producing a CreateContainerConfigError or validation failure. This directly meets the requirement to prevent pods from running as root, making it the correct choice.

Why this answer

Setting `runAsNonRoot: true` at the pod-level SecurityContext enforces that all containers in the pod must run with a non-root user (UID > 0). If a container image specifies a user with UID 0 (root) or does not specify a user, the container will fail to start, preventing privilege escalation from root access.

Exam trap

CNCF often tests the distinction between setting a specific user ID (runAsUser) and enforcing a non-root requirement (runAsNonRoot), where candidates mistakenly think that setting runAsUser to a non-zero value alone prevents root execution, but it does not block an image that runs as root by default if runAsUser is omitted or set to 0.

How to eliminate wrong answers

Option A is wrong because `fsGroup: 2000` sets the group ID for volume ownership, not the user identity, and does not prevent running as root. Option B is wrong because `runAsGroup: 3000` sets the primary group ID for the container process but does not restrict the user to a non-root UID. Option C is wrong because `runAsUser: 1000` sets a specific user ID (1000) for the container process, but it does not enforce that the container cannot run as root; if the image runs as root by default, this field overrides it, but the pod could still be configured with a root UID, and the field itself does not block root execution.

Practice this question →
20
MCQmedium

You are hardening a kubeadm-managed cluster running Kubernetes v1.28. The kubelet's read-only port (10255) is still listening on every node, exposing pod and node metadata without authentication. You must disable it across the cluster. Which action is correct?

A.Add a NetworkPolicy to the kube-system namespace that denies ingress to TCP port 10255 on all pods.
B.Edit each node's kubelet configuration to set readOnlyPort: 0, then restart the kubelet service.
C.Change the kube-apiserver --kubelet-preferred-address-types flag to InternalIP so the read-only port is bypassed.
D.Rotate the kubelet client certificate and enable NodeRestriction so the read-only port requires authentication.
AnswerB

Setting readOnlyPort: 0 in the KubeletConfiguration disables the unauthenticated read-only endpoint entirely. Because the port is deprecated and unauthenticated, it leaks pod specs, node metrics, and mounted volume details to anyone who can reach TCP 10255. Applying the change in the kubelet config file and restarting kubelet on every node removes that exposure without affecting the authenticated API on 10250.

Why this answer

The unauthenticated kubelet read-only port is controlled solely by the readOnlyPort setting inside the kubelet's configuration. Setting it to 0 disables the listener, eliminating anonymous metadata disclosure. NetworkPolicies, apiserver flags, and credential rotation act on different layers and cannot close a listener bound in the node's host network namespace.

The fix must be applied per node and followed by a kubelet restart.

Exam trap

The trap here is assuming pod-level network controls or apiserver flags can suppress a node-level kubelet listener that is bound in the host network namespace.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Cluster Hardening questions.

Start 20-question session