Courseiva

CCNA Cluster Hardening Questions

15 questions · Cluster Hardening topic · All types, answers revealed

Practice these questionsExam hubAll 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

Correct scope and verb for listing pods across all namespaces.

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 can enforce both requirements flexibly.

Why this answer

Option B is correct because 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
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

Authenticates clients.

Why this answer

Option C is correct because 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 →
4
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

Reduces attack surface.

Why this answer

Option B is correct because 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 →
5
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

'enforce' blocks non-compliant pods, and 'restricted' requires seccomp.

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 →
6
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

Another admission controller.

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 →
7
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

Valid authentication method.

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 →
8
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

Enforces seccomp as part of the restricted policy.

Why this answer

Option A is correct because 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 →
9
Drag & Dropmedium

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

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

Practice this question →
10
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

These tools are widely used in the Kubernetes security ecosystem.

Practice this question →
11
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

Directly restricts egress.

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 →
12
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

Runs as non-root user, satisfying runAsNonRoot.

Why this answer

Option C is correct because 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 →
13
MCQmedium

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

A.The ClusterRole must be bound with a RoleBinding
B.The user needs a ServiceAccount
C.The ClusterRoleBinding might have a namespace set
D.The pod-reader ClusterRole is missing 'list' verb
AnswerC

If namespace is set, it becomes namespace-scoped, breaking access.

Why this answer

Option C is correct because a ClusterRoleBinding is cluster-scoped and does not have a namespace field, but if a RoleBinding is used instead, it can restrict permissions to a specific namespace. The most likely cause is that the user inadvertently created a RoleBinding in the 'test' namespace (or the ClusterRoleBinding was misconfigured with a namespace selector), which would limit the binding's effect to that namespace. Since the user cannot list pods in 'test', the binding likely has a namespace constraint, preventing the cluster-wide permissions from applying.

Exam trap

CNCF often tests the distinction between ClusterRoleBinding (cluster-wide) and RoleBinding (namespace-scoped), and the trap here is that candidates assume a ClusterRole always grants cluster-wide access, forgetting that the binding type (RoleBinding) can restrict it to a specific namespace.

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 →
14
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

Sets both Node and RBAC as required.

Why this answer

Option D is correct because 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 →
15
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

Explicitly prevents root.

Why this answer

Option D is correct because 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 →

Ready to test yourself?

Try a timed practice session using only Cluster Hardening questions.

Start 20-question session