Cluster Hardening practice questions

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?

Trap 1: Use a mutating admission webhook to automatically add seccomp…

A mutating admission webhook that automatically adds seccomp profiles only modifies the pod spec; it does not reject pods that still violate other restricted constraints such as running as root, adding capabilities, or using privileged containers. Attackers could craft pods that bypass the webhook if it's not configured as the only admission controller, and mutation alone never produces an admission rejection. Therefore, it lacks the enforcement guarantee required to ensure all pods are compliant.

Trap 2: Enable the PodSecurity admission plugin with the 'baseline' policy…

The 'baseline' policy is intentionally less restrictive than 'restricted'; it does not mandate a seccomp profile and permits several privileged settings that restricted forbids, like certain capabilities and hostPID sharing. Even with 'enforce' mode blocking violations of baseline, pods would still be allowed without seccomp, failing the security team's requirement. Only the restricted policy imposes the necessary seccomp requirement, so this combination is insufficient.

Trap 3: Enable the PodSecurity admission plugin with the 'restricted'…

'warn' mode with the restricted policy generates warning messages for violating pods, but it does not block their creation; a pod that lacks seccomp would still be admitted and run. This mode is designed for user-facing feedback or auditing, not enforcement, and therefore doesn't guarantee compliance. The security team needs enforce mode to actually prevent non-compliant pods from running.

A
Enable the PodSecurity admission plugin with the 'restricted' policy and 'enforce' mode
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.
B
Use a mutating admission webhook to automatically add seccomp profiles
Why wrong: A mutating admission webhook that automatically adds seccomp profiles only modifies the pod spec; it does not reject pods that still violate other restricted constraints such as running as root, adding capabilities, or using privileged containers. Attackers could craft pods that bypass the webhook if it's not configured as the only admission controller, and mutation alone never produces an admission rejection. Therefore, it lacks the enforcement guarantee required to ensure all pods are compliant.
C
Enable the PodSecurity admission plugin with the 'baseline' policy and 'enforce' mode
Why wrong: The 'baseline' policy is intentionally less restrictive than 'restricted'; it does not mandate a seccomp profile and permits several privileged settings that restricted forbids, like certain capabilities and hostPID sharing. Even with 'enforce' mode blocking violations of baseline, pods would still be allowed without seccomp, failing the security team's requirement. Only the restricted policy imposes the necessary seccomp requirement, so this combination is insufficient.
D
Enable the PodSecurity admission plugin with the 'restricted' policy and 'warn' mode
Why wrong: 'warn' mode with the restricted policy generates warning messages for violating pods, but it does not block their creation; a pod that lacks seccomp would still be admitted and run. This mode is designed for user-facing feedback or auditing, not enforcement, and therefore doesn't guarantee compliance. The security team needs enforce mode to actually prevent non-compliant pods from running.

Question 2mediummultiple choice

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?

Trap 1: Role with 'list' on pods, RoleBinding in observability

A Role is always namespace-scoped; it can only grant permissions inside the namespace where it is created. Here, the Role is defined in the observability namespace and bound there, so the monitor ServiceAccount can list pods only in that namespace, not across the cluster. If the monitoring requirement spans all namespaces, this configuration fails due to scope limitation, regardless of the correct 'list' verb.

Trap 2: ClusterRole with 'get' on pods, ClusterRoleBinding

The 'get' verb allows retrieving a single pod by name, but it does not permit enumeration or listing of pods. For monitoring use cases that need to discover all pods in the cluster, 'list' (or 'watch') is required. ClusterRoleBinding gives the right scope, but the verb is too restrictive, so this combination cannot fulfill the requirement.

Trap 3: ClusterRole with 'list' on pods, RoleBinding in observability

Even though the ClusterRole itself has cluster-wide scope, a RoleBinding can only grant permissions within the namespace where the binding exists. In this option, the RoleBinding is placed in observability, so the monitor ServiceAccount only receives the 'list' permission for pods in that namespace. Lacking a ClusterRoleBinding, this configuration incorrectly narrows the effective authorization to a single namespace.

A
Role with 'list' on pods, RoleBinding in observability
Why wrong: A Role is always namespace-scoped; it can only grant permissions inside the namespace where it is created. Here, the Role is defined in the observability namespace and bound there, so the monitor ServiceAccount can list pods only in that namespace, not across the cluster. If the monitoring requirement spans all namespaces, this configuration fails due to scope limitation, regardless of the correct 'list' verb.
B
ClusterRole with 'get' on pods, ClusterRoleBinding
Why wrong: The 'get' verb allows retrieving a single pod by name, but it does not permit enumeration or listing of pods. For monitoring use cases that need to discover all pods in the cluster, 'list' (or 'watch') is required. ClusterRoleBinding gives the right scope, but the verb is too restrictive, so this combination cannot fulfill the requirement.
C
ClusterRole with 'list' on pods, RoleBinding in observability
Why wrong: Even though the ClusterRole itself has cluster-wide scope, a RoleBinding can only grant permissions within the namespace where the binding exists. In this option, the RoleBinding is placed in observability, so the monitor ServiceAccount only receives the 'list' permission for pods in that namespace. Lacking a ClusterRoleBinding, this configuration incorrectly narrows the effective authorization to a single namespace.
D
ClusterRole with 'list' on pods, ClusterRoleBinding
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.

Question 3easymultiple choice

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

Trap 1: fsGroup: 2000

The fsGroup field controls the group ownership assigned to mounted volumes, not the identity of the container's primary process. A pod can still run with UID 0 while fsGroup is set, so it does not satisfy the requirement to prevent root execution. It only affects how files and directories on volumes are group-readable/writable, leaving the process user unchanged.

Trap 2: runAsGroup: 3000

Setting runAsGroup only overrides the primary group ID (GID) of the container's processes; the user ID (UID) remains whatever the image and runAsUser define. If runAsUser is absent, the image's default user is often root (UID 0), so the process still runs as root. Thus runAsGroup alone cannot guarantee a non-root execution context.

Trap 3: runAsUser: 1000

While runAsUser can set a non-zero UID, it is merely a specific user assignment and does not inherently enforce a non-root policy. If omitted or set to 0, the container runs as root; even a value like 1000 only works if it matches the desired security constraint and the image supports that user. Since the goal is to prevent root, this field must be explicitly combined with runAsNonRoot or set to a non-zero value, making it an indirect and error-prone control.

A
fsGroup: 2000
Why wrong: The fsGroup field controls the group ownership assigned to mounted volumes, not the identity of the container's primary process. A pod can still run with UID 0 while fsGroup is set, so it does not satisfy the requirement to prevent root execution. It only affects how files and directories on volumes are group-readable/writable, leaving the process user unchanged.
B
runAsGroup: 3000
Why wrong: Setting runAsGroup only overrides the primary group ID (GID) of the container's processes; the user ID (UID) remains whatever the image and runAsUser define. If runAsUser is absent, the image's default user is often root (UID 0), so the process still runs as root. Thus runAsGroup alone cannot guarantee a non-root execution context.
C
runAsUser: 1000
Why wrong: While runAsUser can set a non-zero UID, it is merely a specific user assignment and does not inherently enforce a non-root policy. If omitted or set to 0, the container runs as root; even a value like 1000 only works if it matches the desired security constraint and the image supports that user. Since the goal is to prevent root, this field must be explicitly combined with runAsNonRoot or set to a non-zero value, making it an indirect and error-prone control.
D
runAsNonRoot: true
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.

Question 4mediummultiple choice

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?

Trap 1: Add --authorization-mode=AlwaysDeny to the API server

AlwaysDeny is not a valid authorization mode for the kube-apiserver in current Kubernetes versions; it was deprecated and removed. Even if it were accepted, AlwaysDeny would reject every API request, making the control plane unusable. The CIS benchmark and kube-bench require the Node and RBAC authorizers, not a blanket deny. You need to modify the kube-apiserver manifest to set --authorization-mode=Node,RBAC.

Trap 2: Restart the API server with --authorization-webhook-config-file

Configuring --authorization-webhook-config-file delegates authorization to an external webhook service, but the CIS baseline requires the built-in Node and RBAC authorizers to be active as well. The webhook is an additional authorizer for custom policy, not a replacement for the core modes. Removing Node and RBAC in favor of a webhook would break kubelet permissions and standard RBAC enforcement. Restarting with only the webhook config does not satisfy the kube-bench check.

Trap 3: Set --authorization-mode=RBAC only

Setting --authorization-mode=RBAC only omits the Node authorizer, which is specifically required to authorize kubelet API requests like pods, secrets, and nodes. The Node authorizer grants kubelets their narrow per-node permissions, while RBAC governs users, groups, and service accounts. Without Node mode, kubelet requests fall back to RBAC rules, which may not cover all node API paths and can cause authorization failures or require overly broad permissions. The correct flag is --authorization-mode=Node,RBAC.

A
Add --authorization-mode=AlwaysDeny to the API server
Why wrong: AlwaysDeny is not a valid authorization mode for the kube-apiserver in current Kubernetes versions; it was deprecated and removed. Even if it were accepted, AlwaysDeny would reject every API request, making the control plane unusable. The CIS benchmark and kube-bench require the Node and RBAC authorizers, not a blanket deny. You need to modify the kube-apiserver manifest to set --authorization-mode=Node,RBAC.
B
Restart the API server with --authorization-webhook-config-file
Why wrong: Configuring --authorization-webhook-config-file delegates authorization to an external webhook service, but the CIS baseline requires the built-in Node and RBAC authorizers to be active as well. The webhook is an additional authorizer for custom policy, not a replacement for the core modes. Removing Node and RBAC in favor of a webhook would break kubelet permissions and standard RBAC enforcement. Restarting with only the webhook config does not satisfy the kube-bench check.
C
Set --authorization-mode=RBAC only
Why wrong: Setting --authorization-mode=RBAC only omits the Node authorizer, which is specifically required to authorize kubelet API requests like pods, secrets, and nodes. The Node authorizer grants kubelets their narrow per-node permissions, while RBAC governs users, groups, and service accounts. Without Node mode, kubelet requests fall back to RBAC rules, which may not cover all node API paths and can cause authorization failures or require overly broad permissions. The correct flag is --authorization-mode=Node,RBAC.
D
Edit the kube-apiserver manifest to add --authorization-mode=Node,RBAC
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.

Question 5hardmultiple choice

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?

Trap 1: Remove runAsNonRoot: true

Removing runAsNonRoot: true merely disables the security check, but the underlying container still runs as root (UID 0). This relaxes the workload's security posture and violates Pod Security Standards, which require containers to run as non-root in most production namespaces. The correct action is to make the container actually run as a non-root user, not to bypass the validation.

Trap 2: Add a PodSecurityPolicy that allows root

PodSecurityPolicy is deprecated and scheduled for removal in newer Kubernetes versions, so relying on it is not a forward-looking solution. Moreover, a PSP that allows root does not change the container's effective UID; if runAsNonRoot: true is set, the kubelet or container runtime rejects the pod regardless of any policy. This option fails to address the direct failure and introduces an outdated admission control mechanism.

Trap 3: Use a mutating webhook to change the image

A mutating webhook could modify the image or pod spec at admission time, but it requires deploying and configuring a separate webhook server, which is heavy infrastructure for a single failing pod. It is not an immediate fix, and it introduces unacceptable complexity for what is simply a missing securityContext field. Moreover, the webhook would need to be cluster-wide and might not even be installed, making this approach impractical in most real-world scenarios.

A
Remove runAsNonRoot: true
Why wrong: Removing runAsNonRoot: true merely disables the security check, but the underlying container still runs as root (UID 0). This relaxes the workload's security posture and violates Pod Security Standards, which require containers to run as non-root in most production namespaces. The correct action is to make the container actually run as a non-root user, not to bypass the validation.
B
Add a PodSecurityPolicy that allows root
Why wrong: PodSecurityPolicy is deprecated and scheduled for removal in newer Kubernetes versions, so relying on it is not a forward-looking solution. Moreover, a PSP that allows root does not change the container's effective UID; if runAsNonRoot: true is set, the kubelet or container runtime rejects the pod regardless of any policy. This option fails to address the direct failure and introduces an outdated admission control mechanism.
C
Set runAsUser: 1000 in the container securityContext
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.
D
Use a mutating webhook to change the image
Why wrong: A mutating webhook could modify the image or pod spec at admission time, but it requires deploying and configuring a separate webhook server, which is heavy infrastructure for a single failing pod. It is not an immediate fix, and it introduces unacceptable complexity for what is simply a missing securityContext field. Moreover, the webhook would need to be cluster-wide and might not even be installed, making this approach impractical in most real-world scenarios.

Question 6easymultiple choice

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

Trap 1: PodSecurityPolicy

PodSecurityPolicy (PSP) is an admission controller that governs pod security contexts — such as privilege escalation, host namespaces, or Linux capabilities. It never touches network packets or low-level traffic routing, so it has no mechanism to block outbound connections. The resource is deprecated and removed in Kubernetes 1.25, and it was never a network policy object. Thus, using PSP to restrict egress is conceptually invalid and technically impossible.

Trap 2: iptables rules on nodes

iptables rules placed on nodes are not a Kubernetes resource; they are operating-system-level firewall entries managed via iptables/ipvs on each host. While on the data path, they lack pod identity awareness and selectors, so many users implement them as static rules that cannot scale or adapt to dynamic pod IPs. Also, the Kubernetes API has no knowledge of these rules, which breaks declarative management and auditability. Therefore, they are an external tool, not a resource, and unsuitable for pod-specific egress control.

Trap 3: NetworkPolicy with ingress rules

NetworkPolicy with ingress rules restricts only incoming traffic to the selected pods. Although the policy object shares the same schema, an ingress rule has no effect on outbound sessions initiated by pods; egress traffic will still be routed as per the cluster defaults. To control traffic leaving a pod, you must explicitly add an egress section (or use policyTypes: ['Egress']). Thus, ingress rules alone cannot limit egress and are the inverse of the required direction.

A
NetworkPolicy with egress rules
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.
B
PodSecurityPolicy
Why wrong: PodSecurityPolicy (PSP) is an admission controller that governs pod security contexts — such as privilege escalation, host namespaces, or Linux capabilities. It never touches network packets or low-level traffic routing, so it has no mechanism to block outbound connections. The resource is deprecated and removed in Kubernetes 1.25, and it was never a network policy object. Thus, using PSP to restrict egress is conceptually invalid and technically impossible.
C
iptables rules on nodes
Why wrong: iptables rules placed on nodes are not a Kubernetes resource; they are operating-system-level firewall entries managed via iptables/ipvs on each host. While on the data path, they lack pod identity awareness and selectors, so many users implement them as static rules that cannot scale or adapt to dynamic pod IPs. Also, the Kubernetes API has no knowledge of these rules, which breaks declarative management and auditability. Therefore, they are an external tool, not a resource, and unsuitable for pod-specific egress control.
D
NetworkPolicy with ingress rules
Why wrong: NetworkPolicy with ingress rules restricts only incoming traffic to the selected pods. Although the policy object shares the same schema, an ingress rule has no effect on outbound sessions initiated by pods; egress traffic will still be routed as per the cluster defaults. To control traffic leaving a pod, you must explicitly add an egress section (or use policyTypes: ['Egress']). Thus, ingress rules alone cannot limit egress and are the inverse of the required direction.

Question 7hardmultiple choice

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?

Trap 1: Create a new PSP with seccomp profile and assign it to the namespace

PSP was removed in Kubernetes 1.25, so on a modern cluster this policy object does not exist; even on older versions PSPs are cluster-scoped authorization rules, not namespace-scoped assignments. You cannot 'assign' a PSP to a namespace — instead you bind it to a ServiceAccount via RBAC, which leaves many pods unaffected if their SA lacks the binding, and seccomp requirements in PSPs are easy to bypass. Relying on PSP is defensively obsolete and not a viable enforcement solution.

Trap 2: Set seccomp profile in the kubelet configuration

The kubelet's `--seccomp-default` flag only instructs the node's runtime to apply the runtime default profile when a container does not specify one; it is a runtime-level default, not an admission policy. It has no awareness of namespaces or pod security constraints, and an explicit `seccompProfile` in the pod spec overrides it, while older runtimes may ignore it entirely. Therefore it never guarantees that a given namespace cannot run without a profile.

Trap 3: Use a mutating admission webhook to add seccomp profile

A mutating admission webhook can inject a seccomp profile into a pod's security context, but it does not validate or reject anything; if the webhook is not registered, fails open, or a pod already sets an unconfined profile, the mutation may simply never occur. The API server never checks the final pod state against seccomp requirements, so a client communicating directly or using a privileged profile can still result in containers without the intended restriction. It is an operational defaulting tool, not an enforcement control.

A
Enable PodSecurity admission with 'restricted' policy in enforce mode
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.
B
Create a new PSP with seccomp profile and assign it to the namespace
Why wrong: PSP was removed in Kubernetes 1.25, so on a modern cluster this policy object does not exist; even on older versions PSPs are cluster-scoped authorization rules, not namespace-scoped assignments. You cannot 'assign' a PSP to a namespace — instead you bind it to a ServiceAccount via RBAC, which leaves many pods unaffected if their SA lacks the binding, and seccomp requirements in PSPs are easy to bypass. Relying on PSP is defensively obsolete and not a viable enforcement solution.
C
Set seccomp profile in the kubelet configuration
Why wrong: The kubelet's `--seccomp-default` flag only instructs the node's runtime to apply the runtime default profile when a container does not specify one; it is a runtime-level default, not an admission policy. It has no awareness of namespaces or pod security constraints, and an explicit `seccompProfile` in the pod spec overrides it, while older runtimes may ignore it entirely. Therefore it never guarantees that a given namespace cannot run without a profile.
D
Use a mutating admission webhook to add seccomp profile
Why wrong: A mutating admission webhook can inject a seccomp profile into a pod's security context, but it does not validate or reject anything; if the webhook is not registered, fails open, or a pod already sets an unconfined profile, the mutation may simply never occur. The API server never checks the final pod state against seccomp requirements, so a client communicating directly or using a privileged profile can still result in containers without the intended restriction. It is an operational defaulting tool, not an enforcement control.

Question 8mediummulti select

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

Trap 1: Use static token file

A static token file stores plaintext bearer tokens in a CSV on the control-plane node. These tokens cannot be individually revoked without rotating the entire file, and they are transmitted as raw credentials, making them vulnerable to interception and theft. Kubernetes has deprecated this mechanism because it offers no per-user expiration, no integration with external identity providers, and no audit trail for token issuance, so it is not a recommended way to restrict cluster access.

Trap 2: Enable NodeRestriction admission plugin

The NodeRestriction admission plugin is an admission controller that limits the kubelet’s ability to create or modify resources, restricting it to nodes and pods bound to its node name. It does not govern how API server clients authenticate or authorize; it only limits what the kubelet can do after it has already been authenticated. Therefore, enabling it does not restrict access for human users, service accounts, or other clients, making it irrelevant to the goal of controlling general cluster access.

Trap 3: Enable anonymous access

Enabling anonymous access allows unauthenticated requests to reach the API server, effectively bypassing the authentication layer. If RBAC policies happen to grant permissions to the `system:anonymous` user or `system:unauthenticated` group, these requests can perform actions without any credentials, which creates a severe security risk. It should only be enabled when intentionally exposing public information, and it is not a mechanism for restricting access; it is the opposite of a secure access control measure.

A
Use static token file
Why wrong: A static token file stores plaintext bearer tokens in a CSV on the control-plane node. These tokens cannot be individually revoked without rotating the entire file, and they are transmitted as raw credentials, making them vulnerable to interception and theft. Kubernetes has deprecated this mechanism because it offers no per-user expiration, no integration with external identity providers, and no audit trail for token issuance, so it is not a recommended way to restrict cluster access.
B
Use webhook token authentication
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.
C
Enable NodeRestriction admission plugin
Why wrong: The NodeRestriction admission plugin is an admission controller that limits the kubelet’s ability to create or modify resources, restricting it to nodes and pods bound to its node name. It does not govern how API server clients authenticate or authorize; it only limits what the kubelet can do after it has already been authenticated. Therefore, enabling it does not restrict access for human users, service accounts, or other clients, making it irrelevant to the goal of controlling general cluster access.
D
Configure RBAC authorization
RBAC (Role-Based Access Control) is the standard authorization mode in Kubernetes, used to determine whether an authenticated user or service account is allowed to perform a requested action. It lets administrators define Roles and ClusterRoles, bind them to subjects via RoleBindings and ClusterRoleBindings, and thereby enforce least-privilege access—for example, allowing a developer to read pods in a namespace but not delete deployments. RBAC is a valid and essential way to restrict access because it ensures that even authenticated users only have the permissions they actually need.
E
Enable anonymous access
Why wrong: Enabling anonymous access allows unauthenticated requests to reach the API server, effectively bypassing the authentication layer. If RBAC policies happen to grant permissions to the `system:anonymous` user or `system:unauthenticated` group, these requests can perform actions without any credentials, which creates a severe security risk. It should only be enabled when intentionally exposing public information, and it is not a mechanism for restricting access; it is the opposite of a secure access control measure.

Question 9hardmulti select

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

Trap 1: Configure RBAC for etcd

Kubernetes RBAC applies to the Kubernetes API server, not directly to etcd, which is a separate datastore. etcd does offer its own user/role object model, but in standard cluster deployments access is enforced through mutual TLS client certificate authentication, not RBAC. Configuring RBAC is therefore not one of the required controls to secure etcd itself.

Trap 2: Allow anonymous access for monitoring

Allowing anonymous access to etcd means any unauthenticated client can read or modify the entire cluster state, including secrets, without presenting credentials. This completely undermines the confidentiality and integrity of the datastore. Monitoring should be performed using authenticated read-only accounts or dedicated agent certificates, never by permitting anonymous connections, making this practice inherently insecure.

A
Configure RBAC for etcd
Why wrong: Kubernetes RBAC applies to the Kubernetes API server, not directly to etcd, which is a separate datastore. etcd does offer its own user/role object model, but in standard cluster deployments access is enforced through mutual TLS client certificate authentication, not RBAC. Configuring RBAC is therefore not one of the required controls to secure etcd itself.
B
Allow anonymous access for monitoring
Why wrong: Allowing anonymous access to etcd means any unauthenticated client can read or modify the entire cluster state, including secrets, without presenting credentials. This completely undermines the confidentiality and integrity of the datastore. Monitoring should be performed using authenticated read-only accounts or dedicated agent certificates, never by permitting anonymous connections, making this practice inherently insecure.
C
Require client certificate authentication
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.
D
Enable encryption at rest for secrets
Encryption at rest protects etcd data when it is persisted on disk or stored in backups, shielding it from physical theft or filesystem-level unauthorized access. Kubernetes achieves this through encryption providers that encrypt resources like Secrets before they are written to etcd. Since TLS only protects data in transit and not on disk, enabling encryption at rest is a required control to secure sensitive cluster data at rest.
E
Use TLS for peer and client communication
TLS for peer and client communication encrypts all traffic to and from etcd, preventing network-level eavesdropping, tampering, and man-in-the-middle attacks. Peer TLS secures communication between etcd members during leader election and data replication, while client TLS secures traffic from the API server to etcd. Because etcd stores the entire cluster state, including secrets, enforcing TLS on all network paths is critically required.

Question 10easymulti select

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

Trap 1: Always use the latest tag

Using the `latest` tag means the same tag may refer to a different image digest tomorrow; a rebuild or an upstream push silently changes what your cluster runs. This breaks reproducibility, makes rollbacks harder, and can pull in newly introduced vulnerabilities or incompatible versions. For auditability and supply-chain security, always reference images by an exact digest (e.g., `image@sha256:...`) or at least a fully versioned and internally managed tag.

Trap 2: Run containers as root

Running as root (UID 0) inside a container is dangerous because kernel vulnerabilities or misconfigurations can allow a container process to perform actions with host root privileges. Even without an escape, root can modify binaries, install tools, or tamper with runtime metadata inside the container. The pod security context should set `runAsNonRoot: true` or a numeric non-zero UID, and the container image should declare a dedicated user.

Trap 3: Run containers in privileged mode

Privileged mode essentially disables the container runtime’s isolation: it grants all Linux capabilities, allows access to host devices, and typically disables restrictions like seccomp and AppArmor. A single vulnerability in a privileged container can give an attacker direct access to the host kernel, device files, and cgroups, effectively yielding host root. It should never be used unless absolutely required, and alternatives like specific capability drops or device annotations should be applied.

A
Always use the latest tag
Why wrong: Using the `latest` tag means the same tag may refer to a different image digest tomorrow; a rebuild or an upstream push silently changes what your cluster runs. This breaks reproducibility, makes rollbacks harder, and can pull in newly introduced vulnerabilities or incompatible versions. For auditability and supply-chain security, always reference images by an exact digest (e.g., `image@sha256:...`) or at least a fully versioned and internally managed tag.
B
Use minimal base images like distroless
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.
C
Run containers as root
Why wrong: Running as root (UID 0) inside a container is dangerous because kernel vulnerabilities or misconfigurations can allow a container process to perform actions with host root privileges. Even without an escape, root can modify binaries, install tools, or tamper with runtime metadata inside the container. The pod security context should set `runAsNonRoot: true` or a numeric non-zero UID, and the container image should declare a dedicated user.
D
Run containers in privileged mode
Why wrong: Privileged mode essentially disables the container runtime’s isolation: it grants all Linux capabilities, allows access to host devices, and typically disables restrictions like seccomp and AppArmor. A single vulnerability in a privileged container can give an attacker direct access to the host kernel, device files, and cgroups, effectively yielding host root. It should never be used unless absolutely required, and alternatives like specific capability drops or device annotations should be applied.
E
Use image vulnerability scanning
Image vulnerability scanning compares the content of image layers against public CVE databases (e.g., via Trivy, Grype, or Clair). Running these scans in CI/CD and on the registry identifies known operating-system and dependency vulnerabilities before they reach production, allowing teams to block critical findings or reject images older than a threshold. Scanning should be continuous, not one-time, because new CVEs are disclosed after the image is built.

Question 11hardmulti select

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

Trap 1: Run kube-bench on the cluster

kube-bench is a compliance assessment tool that runs a series of automated checks against a cluster to verify adherence to the CIS Kubernetes Benchmark. It inspects configuration files, API server flags, and node settings, generating a report of pass/fail findings, but it does not register as an admission controller or otherwise intercept API requests. Consequently, kube-bench can only highlight weaknesses after the fact and cannot prevent a non-compliant pod from being created, so it is not an enforcement mechanism.

Trap 2: Manual review of all pod specs

Manual review of every pod spec relies on human inspection of manifests or live resources, which is not only unscalable but also fails to provide a technical control that blocks non-compliant pods at creation time. In a dynamic cluster with continuous deployments, automated workloads, or many developers, manual review is error-prone and cannot intercept API requests before a pod is scheduled. Since it lacks integration with the admission control flow, this approach is neither reliable nor enforceable, making it an invalid method for enforcing pod security.

A
Use Kyverno policy engine
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.
B
Run kube-bench on the cluster
Why wrong: kube-bench is a compliance assessment tool that runs a series of automated checks against a cluster to verify adherence to the CIS Kubernetes Benchmark. It inspects configuration files, API server flags, and node settings, generating a report of pass/fail findings, but it does not register as an admission controller or otherwise intercept API requests. Consequently, kube-bench can only highlight weaknesses after the fact and cannot prevent a non-compliant pod from being created, so it is not an enforcement mechanism.
C
Manual review of all pod specs
Why wrong: Manual review of every pod spec relies on human inspection of manifests or live resources, which is not only unscalable but also fails to provide a technical control that blocks non-compliant pods at creation time. In a dynamic cluster with continuous deployments, automated workloads, or many developers, manual review is error-prone and cannot intercept API requests before a pod is scheduled. Since it lacks integration with the admission control flow, this approach is neither reliable nor enforceable, making it an invalid method for enforcing pod security.
D
Use Open Policy Agent (OPA) with Gatekeeper
OPA Gatekeeper is an external admission controller that integrates the Open Policy Agent with Kubernetes through a validating webhook. It evaluates policies written in Rego against incoming AdmissionReview objects and can either admit or deny requests based on constraints defined as Kubernetes custom resources. While Gatekeeper also offers an audit feature, its core enforcement is synchronous and occurs before a pod is persisted, making it a valid and widely adopted enforcement method.
E
Enable PodSecurity admission plugin
The PodSecurity admission plugin is a native Kubernetes admission controller that evaluates pods against the Pod Security Standards (privileged, baseline, and restricted). It operates in three configurable modes—enforce, audit, and warn—defined via labels on namespaces, and in enforce mode it rejects pod creation that does not match the specified standard. Because it is built into the API server, it requires no external components and directly blocks non-compliant pods, making it a valid enforcement method.

Question 12hardmultiple choice

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?

Trap 1: Enable Pod Security Admission with the 'baseline' policy in enforce…

Pod Security Admission (PSA) with the 'baseline' policy in enforce mode restricts a limited set of dangerous features but does not enforce readOnlyRootFilesystem, and it also does not limit allowed capabilities to only NET_BIND_SERVICE — it merely blocks a handful of dangerous capabilities. Adding a mutating webhook to inject readOnlyRootFilesystem would mean maintaining a separate cluster-critical component, introducing possible bypasses or ordering issues with PSA, and still leaves the capability set too broad. This approach is complex and does not fully express the required security controls, making it inferior to a policy engine like Gatekeeper.

Trap 2: Use Pod Security Admission with the 'privileged' policy and rely on…

Pod Security Admission with the 'privileged' policy is the most permissive profile — it explicitly permits privileged containers, host namespaces, host networking, and any Linux capabilities, so it does not provide any baseline tenant isolation. Relying on individual container securityContext settings is unenforceable at the admission level; a developer could omit those settings and the pod would run with the full privileges of the policy. This setup essentially delegates security to human error and is the opposite of the least-privilege requirements in the question.

Trap 3: Create a new PSP that allows NET_BIND_SERVICE and requires…

Creating a new PodSecurityPolicy is not the best approach because PSPs are deprecated in Kubernetes v1.24 and are scheduled for removal in v1.25. Relying on a deprecated feature for a new tenant's configuration, especially when the cluster plans to migrate to Pod Security Admission, contradicts Kubernetes best practices. PSPs were previously the standard mechanism for enforcing granular pod security constraints, such as `readOnlyRootFilesystem` and specific capabilities like `NET_BIND_SERVICE`, and could be effectively scoped to namespaces via RoleBindings in older Kubernetes versions.

A
Enable Pod Security Admission with the 'baseline' policy in enforce mode for acme-corp namespace, and add a mutating webhook to set readOnlyRootFilesystem
Why wrong: Pod Security Admission (PSA) with the 'baseline' policy in enforce mode restricts a limited set of dangerous features but does not enforce readOnlyRootFilesystem, and it also does not limit allowed capabilities to only NET_BIND_SERVICE — it merely blocks a handful of dangerous capabilities. Adding a mutating webhook to inject readOnlyRootFilesystem would mean maintaining a separate cluster-critical component, introducing possible bypasses or ordering issues with PSA, and still leaves the capability set too broad. This approach is complex and does not fully express the required security controls, making it inferior to a policy engine like Gatekeeper.
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
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.
C
Use Pod Security Admission with the 'privileged' policy and rely on the legacy container's securityContext
Why wrong: Pod Security Admission with the 'privileged' policy is the most permissive profile — it explicitly permits privileged containers, host namespaces, host networking, and any Linux capabilities, so it does not provide any baseline tenant isolation. Relying on individual container securityContext settings is unenforceable at the admission level; a developer could omit those settings and the pod would run with the full privileges of the policy. This setup essentially delegates security to human error and is the opposite of the least-privilege requirements in the question.
D
Create a new PSP that allows NET_BIND_SERVICE and requires readOnlyRootFilesystem, then bind it to the acme-corp namespace via RoleBinding
Why wrong: Creating a new PodSecurityPolicy is not the best approach because PSPs are deprecated in Kubernetes v1.24 and are scheduled for removal in v1.25. Relying on a deprecated feature for a new tenant's configuration, especially when the cluster plans to migrate to Pod Security Admission, contradicts Kubernetes best practices. PSPs were previously the standard mechanism for enforcing granular pod security constraints, such as `readOnlyRootFilesystem` and specific capabilities like `NET_BIND_SERVICE`, and could be effectively scoped to namespaces via RoleBindings in older Kubernetes versions.

Question 13mediumdrag order

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

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: 1

This order is incorrect because audit flags reference the policy file path, but the file does not exist yet. Adding flags before creating and mounting the policy file will cause the API server to fail to start or ignore the flags.

Trap 2: 1

This order is incorrect because adding audit flags before mounting the policy file means the API server cannot access the policy file at startup, leading to errors or the flags being ignored. The mount must precede the flag addition.

Trap 3: 1

The restart occurs before the audit flags are added, so the API server never loads the audit configuration during that restart. Since kube-apiserver reads command-line flags (e.g., --audit-policy-file, --audit-log-path) only at process startup, adding them afterward leaves the running process unaware of them and requires a second restart to take effect. Even though the policy file is already mounted, without the flags the API server will not enable audit logging. Therefore, the correct order must place the flag addition before the restart, after the policy file is mounted and accessible.

A
1. Create audit policy file, 2. Mount policy file to API server, 3. Add audit flags to API server, 4. Restart API server, 5. Verify audit logs
This is the correct order because the audit policy file must be created first, then mounted to the API server so it is accessible, then flags are added to reference the file, then the API server is restarted to apply changes, and finally verification ensures audit logging is working correctly.
B
1. Add audit flags to API server, 2. Create audit policy file, 3. Mount policy file to API server, 4. Restart API server, 5. Verify audit logs
Why wrong: This order is incorrect because audit flags reference the policy file path, but the file does not exist yet. Adding flags before creating and mounting the policy file will cause the API server to fail to start or ignore the flags.
C
1. Create audit policy file, 2. Add audit flags to API server, 3. Mount policy file to API server, 4. Restart API server, 5. Verify audit logs
Why wrong: This order is incorrect because adding audit flags before mounting the policy file means the API server cannot access the policy file at startup, leading to errors or the flags being ignored. The mount must precede the flag addition.
D
1. Create audit policy file, 2. Mount policy file to API server, 3. Restart API server, 4. Add audit flags to API server, 5. Verify audit logs
Why wrong: The restart occurs before the audit flags are added, so the API server never loads the audit configuration during that restart. Since kube-apiserver reads command-line flags (e.g., --audit-policy-file, --audit-log-path) only at process startup, adding them afterward leaves the running process unaware of them and requires a second restart to take effect. Even though the policy file is already mounted, without the flags the API server will not enable audit logging. Therefore, the correct order must place the flag addition before the restart, after the policy file is mounted and accessible.

Question 14mediummatching

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

Trap 1: Pod Security Admission: Controls network traffic between pods

This statement is factually wrong because Pod Security Admission has no data-plane role; it is entirely an admission-time gate on the API server. PSA only inspects the pod spec for security context compliance before creation and issues an admission response—allow or deny—based on the Pod Security Standards. Network traffic between pods is controlled by Network Policies, which are enforced by the CNI plugin after pods are running, so this option confuses admission-time policy with runtime traffic filtering.

Trap 2: Network Policies: Enforces pod security standards

Network Policies do not enforce pod security standards; they only govern which workloads can communicate over the network by matching selectors, ports, and IP blocks. They cannot evaluate or enforce security contexts such as privileged containers, hostPID, or allowed capabilities—those are validated by Pod Security Admission at pod creation time. This answer is wrong because it attributes a control-plane admission responsibility to a data-plane traffic filter, mixing two distinct layers of Kubernetes security.

A
Pod Security Admission: Enforces pod security standards at admission time
Pod Security Admission is a native admission controller that intercepts pod creation requests and validates them against the Pod Security Standards (privileged, baseline, restricted). It can be configured per namespace with enforce, audit, or warn modes, and it rejects non-compliant pods before they are persisted in etcd. As an admission-time control, it directly inspects the pod's SecurityContext, capabilities, and host namespaces.
B
Network Policies: Controls traffic flow between pods and namespaces
Network Policies are cluster-scoped (via namespaces) objects that define granular ingress and egress rules at the IP and port level using selectors and CIDR blocks. They function only if the underlying CNI plugin (such as Calico, Cilium, or Weave) implements them, acting as a distributed firewall for pod-to-pod and pod-to-external traffic. They do not inspect pod security contexts; they only filter network packets based on labels, ports, and IPs.
C
RBAC: Regulates access to Kubernetes API resources
RBAC (Role-Based Access Control) is the authorization mechanism governing which identities—human users, Kubernetes users, or ServiceAccounts—can perform specific verbs (e.g., get, list, watch, create) on Kubernetes API resources, such as Pods, Secrets, and Deployments. It relies on Role and ClusterRole objects bound to subjects via RoleBinding or ClusterRoleBinding, making it a pure control-plane security layer. It is orthogonal to network traffic and admission validation, focusing exclusively on API access.
D
kube-bench: Checks Kubernetes clusters against CIS benchmarks
kube-bench is an externally run security scanner that evaluates a Kubernetes cluster's configuration against the CIS Kubernetes Benchmark, a published set of security best practices. It executes a series of automated checks via a pod or binary, covering areas like etcd TLS settings, kubelet authentication, API server flags, and file permissions on sensitive files. This tool provides a detailed pass/fail/warn report that helps operators identify insecure hardening gaps.
E
Pod Security Admission: Controls network traffic between pods
Why wrong: This statement is factually wrong because Pod Security Admission has no data-plane role; it is entirely an admission-time gate on the API server. PSA only inspects the pod spec for security context compliance before creation and issues an admission response—allow or deny—based on the Pod Security Standards. Network traffic between pods is controlled by Network Policies, which are enforced by the CNI plugin after pods are running, so this option confuses admission-time policy with runtime traffic filtering.
F
Network Policies: Enforces pod security standards
Why wrong: Network Policies do not enforce pod security standards; they only govern which workloads can communicate over the network by matching selectors, ports, and IP blocks. They cannot evaluate or enforce security contexts such as privileged containers, hostPID, or allowed capabilities—those are validated by Pod Security Admission at pod creation time. This answer is wrong because it attributes a control-plane admission responsibility to a data-plane traffic filter, mixing two distinct layers of Kubernetes security.

Question 15mediummultiple choice

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?

Trap 1: The ClusterRole must be bound with a RoleBinding

A ClusterRole does not have to be bound with a RoleBinding; in fact, to grant cluster-wide access, a ClusterRoleBinding is required. Binding a ClusterRole with a RoleBinding would further restrict permissions to a single namespace, which is the opposite of what is needed to allow listing pods in the 'test' namespace.

Trap 2: The user needs a ServiceAccount

ServiceAccounts are identities for pods to authenticate to the Kubernetes API, not for human users. Human users typically authenticate via X.509 certificates or OIDC tokens, and RBAC grants them permissions directly without any ServiceAccount. Requiring a ServiceAccount would not change the binding scope and is unrelated to the access problem.

Trap 3: The pod-reader ClusterRole is missing 'list' verb

The ClusterRole definition explicitly includes the 'list' verb for pods, so a missing verb is not the cause of the failure. If 'list' were absent, the user would get a validation error when attempting to list pods across all namespaces, but the issue here is specifically the binding scope, not the verb set.

A
The ClusterRole must be bound with a RoleBinding
Why wrong: A ClusterRole does not have to be bound with a RoleBinding; in fact, to grant cluster-wide access, a ClusterRoleBinding is required. Binding a ClusterRole with a RoleBinding would further restrict permissions to a single namespace, which is the opposite of what is needed to allow listing pods in the 'test' namespace.
B
The user needs a ServiceAccount
Why wrong: ServiceAccounts are identities for pods to authenticate to the Kubernetes API, not for human users. Human users typically authenticate via X.509 certificates or OIDC tokens, and RBAC grants them permissions directly without any ServiceAccount. Requiring a ServiceAccount would not change the binding scope and is unrelated to the access problem.
C
The ClusterRole was bound with a namespace-scoped RoleBinding in 'default' instead of a ClusterRoleBinding
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.
D
The pod-reader ClusterRole is missing 'list' verb
Why wrong: The ClusterRole definition explicitly includes the 'list' verb for pods, so a missing verb is not the cause of the failure. If 'list' were absent, the user would get a validation error when attempting to list pods across all namespaces, but the issue here is specifically the binding scope, not the verb set.