Scenario practice questions

You are configuring kubelet to protect kernel defaults. Which flag enables this?

Trap 1: --security-opt=protect-kernel

The flag --security-opt=protect-kernel is a Docker daemon/container runtime flag used to add security labels to containers, not a kubelet flag. The kubelet does not parse --security-opt at all; kernel hardening for the node is controlled by the dedicated kubelet flag --protect-kernel-defaults. Attempting to pass this Docker-specific option to kubelet will result in an 'unknown flag' error and prevent the kubelet from starting.

Trap 2: --enable-protect-kernel

--enable-protect-kernel is not a recognized kubelet flag; the kubelet's CLI and configuration schema only define a boolean flag named --protect-kernel-defaults. Kubelet flags do not use an 'enable' prefix for this feature, so supplying this variant would cause a fatal 'unknown flag' error during startup. The correct way to enable the protection is to set --protect-kernel-defaults=true (or via the protectKernelDefaults field in the kubelet configuration file).

Trap 3: --kernel-security

--kernel-security is a hypothetical flag that does not exist in the kubelet's flag list. Kubelet security is implemented via discrete options such as --protect-kernel-defaults, --read-only-port, and --anonymous-auth, but there is no catch-all 'kernel-security' switch. This option might be confused with SELinux or AppArmor profiles, which are configured at the container runtime level, not through a single kubelet flag.

A
--security-opt=protect-kernel
Why it fails: The flag --security-opt=protect-kernel is a Docker daemon/container runtime flag used to add security labels to containers, not a kubelet flag. The kubelet does not parse --security-opt at all; kernel hardening for the node is controlled by the dedicated kubelet flag --protect-kernel-defaults. Attempting to pass this Docker-specific option to kubelet will result in an 'unknown flag' error and prevent the kubelet from starting.
B
--protect-kernel-defaults
The kubelet flag --protect-kernel-defaults, when set to true, enforces that the node's kernel parameters (such as vm.overcommit_memory and kernel.panic) are at their default secure values, and it refuses to start if these settings deviate. This flag also blocks pods from overriding unsafe sysctls, preventing kernel-level misconfigurations that could compromise the node. It is the only correct flag among the options for enabling this kind of kernel protection in a Kubernetes kubelet.
C
--enable-protect-kernel
Why it fails: --enable-protect-kernel is not a recognized kubelet flag; the kubelet's CLI and configuration schema only define a boolean flag named --protect-kernel-defaults. Kubelet flags do not use an 'enable' prefix for this feature, so supplying this variant would cause a fatal 'unknown flag' error during startup. The correct way to enable the protection is to set --protect-kernel-defaults=true (or via the protectKernelDefaults field in the kubelet configuration file).
D
--kernel-security
Why it fails: --kernel-security is a hypothetical flag that does not exist in the kubelet's flag list. Kubelet security is implemented via discrete options such as --protect-kernel-defaults, --read-only-port, and --anonymous-auth, but there is no catch-all 'kernel-security' switch. This option might be confused with SELinux or AppArmor profiles, which are configured at the container runtime level, not through a single kubelet flag.

Question 2mediummultiple choice

A Kubernetes cluster has Kyverno installed. A policy requires that all images come from a trusted registry 'trusted.example.com'. A Deployment uses the image 'nginx:latest'. When the Deployment is created, it is blocked. What Kyverno policy action is being used?

Trap 1: audit

A validate policy with failureAction: audit still evaluates the resource but does not block it; it records the violation in a policy report and may emit a warning, allowing the non-compliant resource to be created anyway. Because the goal is to force compliance, audit mode is insufficient because it only provides visibility without enforcement. This is useful for testing or reporting but not for enforcing a 'require' constraint.

Trap 2: mutate

A mutate policy is used to automatically patch incoming resources, such as adding labels or setting defaults, but it cannot deny a resource. The mutation rule rewrites the request before validation, and if the policy's 'require' condition would need a denial, mutation has no mechanism to block admission. For a requirement that a resource must already conform, checking via a validate policy is necessary rather than mutating it.

Trap 3: generate

A generate policy creates a new child resource (like a ConfigMap or Namespace) whenever a triggering resource is created or updated; it does not assess or block the triggering resource's compliance. It runs independently of the resource's content, so it cannot enforce a 'require' condition on the existing resource. Thus generate ignores whether the resource meets the requirement and fails to provide any enforcement.

A
validate with failureAction: enforce
A validate policy with failureAction: enforce configures Kyverno to actively reject any resource that does not match the required pattern. When the validation rule fails, the admission webhook returns a denial to the API server, preventing the resource from being created or updated. This is the correct way to make a 'require' policy block non-compliant resources.
B
audit
Why it fails: A validate policy with failureAction: audit still evaluates the resource but does not block it; it records the violation in a policy report and may emit a warning, allowing the non-compliant resource to be created anyway. Because the goal is to force compliance, audit mode is insufficient because it only provides visibility without enforcement. This is useful for testing or reporting but not for enforcing a 'require' constraint.
C
mutate
Why it fails: A mutate policy is used to automatically patch incoming resources, such as adding labels or setting defaults, but it cannot deny a resource. The mutation rule rewrites the request before validation, and if the policy's 'require' condition would need a denial, mutation has no mechanism to block admission. For a requirement that a resource must already conform, checking via a validate policy is necessary rather than mutating it.
D
generate
Why it fails: A generate policy creates a new child resource (like a ConfigMap or Namespace) whenever a triggering resource is created or updated; it does not assess or block the triggering resource's compliance. It runs independently of the resource's content, so it cannot enforce a 'require' condition on the existing resource. Thus generate ignores whether the resource meets the requirement and fails to provide any enforcement.

Question 3hardmultiple choice

Given the exhibit, what will happen when a user creates a pod with an image from an untrusted registry?

Network Topology

Trap 1: The pod is rejected by NodeRestriction admission

NodeRestriction admission controller is an alpha/beta feature that constrains the kubelet's ability to modify Node and Pod objects, primarily by enforcing that the kubelet can only update its own Node and the pods bound to it. It applies only to kubelet API requests, not to normal user authentication when creating a pod, and it has no logic to inspect image names or registries. Therefore it cannot reject a user's pod creation.

Trap 2: The pod is rejected by PodSecurity admission

PodSecurity admission (the successor to PodSecurityPolicy) evaluates the pod's security context against a policy level of privileged, baseline, or restricted, checking options like privileged containers, Linux capabilities, host namespaces, and allowed volume types. It does not parse the image reference, registry host, or digest, nor does it enforce any policy on which registries are allowed. A pod with an unusual registry would still pass PodSecurity because that is outside its scope.

Trap 3: The pod is created but the image is not pulled because it's…

There is no built-in mechanism in the standard Kubernetes admission chain that checks whether an image registry is 'trusted' or 'untrusted'. The kubelet simply attempts to pull the image based on the imagePullPolicy; if the registry is reachable and the image exists, it will be pulled. Blocking untrusted registries requires explicit supply-chain security layers, such as a validating admission policy, an image policy webhook, or container runtime signature verification like Container Image Signing, none of which are indicated in the exhibit.

A
The pod is rejected by NodeRestriction admission
Why it fails: NodeRestriction admission controller is an alpha/beta feature that constrains the kubelet's ability to modify Node and Pod objects, primarily by enforcing that the kubelet can only update its own Node and the pods bound to it. It applies only to kubelet API requests, not to normal user authentication when creating a pod, and it has no logic to inspect image names or registries. Therefore it cannot reject a user's pod creation.
B
The pod is rejected by PodSecurity admission
Why it fails: PodSecurity admission (the successor to PodSecurityPolicy) evaluates the pod's security context against a policy level of privileged, baseline, or restricted, checking options like privileged containers, Linux capabilities, host namespaces, and allowed volume types. It does not parse the image reference, registry host, or digest, nor does it enforce any policy on which registries are allowed. A pod with an unusual registry would still pass PodSecurity because that is outside its scope.
C
The pod is created and the image is pulled
The AlwaysPullImages admission controller mutates each new pod's containers, setting imagePullPolicy to Always, which forces the kubelet to pull the image from the registry at every pod start rather than using local cache. This mutation is a validation-type operation that does not reject the pod; the pod is admitted and scheduled. The kubelet then performs an image pull from the specified registry, and since no admission controller or runtime configuration in the default chain blocks untrusted registries, the pull succeeds and the pod runs.
D
The pod is created but the image is not pulled because it's untrusted
Why it fails: There is no built-in mechanism in the standard Kubernetes admission chain that checks whether an image registry is 'trusted' or 'untrusted'. The kubelet simply attempts to pull the image based on the imagePullPolicy; if the registry is reachable and the image exists, it will be pulled. Blocking untrusted registries requires explicit supply-chain security layers, such as a validating admission policy, an image policy webhook, or container runtime signature verification like Container Image Signing, none of which are indicated in the exhibit.

Question 4mediummultiple choice

A DevOps engineer wants to enforce that all container images running in the cluster are signed using Cosign. Which Kubernetes admission controller is designed for this purpose?

Trap 1: MutatingAdmissionWebhook

A MutatingAdmissionWebhook is invoked during admission to modify the incoming resource object—for example, injecting sidecar containers or setting default tolerations—before it is stored. While it could theoretically call an external image-signing service, its intended purpose is mutation, not policy decision-making. Kubernetes does not provide a built-in image-signature check through this controller; that functionality is specifically delegated to ImagePolicyWebhook.

Trap 2: PodSecurityPolicy (deprecated)

PodSecurityPolicy, before its removal in v1.25, enforced constraints like privileged containers, host namespaces, and volume types based on the user or group running the Pod. It had no awareness of image content, signatures, or registry provenance, so it could never verify that an image was signed. With PSP deprecated and gone, Pod Security Admission (PSA) took over the same role, and neither path involves image signature validation.

Trap 3: ValidatingAdmissionWebhook

A ValidatingAdmissionWebhook provides general-purpose admission validation; you could implement custom logic that fetches and checks an image signature using an external service, but that logic must be developed, hosted, and maintained by you. It is not designed specifically for image policy, and unlike ImagePolicyWebhook, it does not have a well-defined contract for returning replacement image references. Kubernetes therefore recommends ImagePolicyWebhook as the native, out-of-the-box solution for image signing verification.

A
MutatingAdmissionWebhook
Why it fails: A MutatingAdmissionWebhook is invoked during admission to modify the incoming resource object—for example, injecting sidecar containers or setting default tolerations—before it is stored. While it could theoretically call an external image-signing service, its intended purpose is mutation, not policy decision-making. Kubernetes does not provide a built-in image-signature check through this controller; that functionality is specifically delegated to ImagePolicyWebhook.
B
ImagePolicyWebhook
The ImagePolicyWebhook is an admission controller that contacts an external webhook service to evaluate every Pod's image references at creation time. The external service can verify signatures, digest pins, or other supply-chain criteria, returning an allow/deny decision (and optionally an image rewrite). This is the built-in, dedicated mechanism for enforcing image signing and provenance policies, distinct from generic webhooks.
C
PodSecurityPolicy (deprecated)
Why it fails: PodSecurityPolicy, before its removal in v1.25, enforced constraints like privileged containers, host namespaces, and volume types based on the user or group running the Pod. It had no awareness of image content, signatures, or registry provenance, so it could never verify that an image was signed. With PSP deprecated and gone, Pod Security Admission (PSA) took over the same role, and neither path involves image signature validation.
D
ValidatingAdmissionWebhook
Why it fails: A ValidatingAdmissionWebhook provides general-purpose admission validation; you could implement custom logic that fetches and checks an image signature using an external service, but that logic must be developed, hosted, and maintained by you. It is not designed specifically for image policy, and unlike ImagePolicyWebhook, it does not have a well-defined contract for returning replacement image references. Kubernetes therefore recommends ImagePolicyWebhook as the native, out-of-the-box solution for image signing verification.

Question 5mediummultiple choice

A cluster uses a custom mutating admission webhook that adds a sidecar container to all pods. After an upgrade, the webhook crashes and pods cannot be created. What is the best way to prevent this scenario in future?

Trap 1: Run multiple replicas of the webhook

Running multiple replicas of the webhook provides high availability but does not solve the fundamental issue of webhook unavailability due to network partition, misconfiguration, or a bug that crashes all replicas at once. If the webhook is down, the API server still fails closed when failurePolicy=Fail, so multiple replicas reduce but do not eliminate the risk; they also introduce consistency issues if the webhook is stateful.

Trap 2: Disable admission webhooks in the cluster

Disabling admission webhooks in the cluster, for example by changing the kube-apiserver --disable-admission-plugins list, would stop the custom mutating webhook but also disables essential built-in admission controllers like NamespaceLifecycle, LimitRanger, or ServiceAccount. This is a drastic cluster-wide change that undermines security and policy enforcement, and it does not specifically address the webhook outage; it would affect all API requests and require an API server restart.

Trap 3: Create a validating webhook as a backup

Creating a validating webhook as a backup does not resolve the outage because validating webhooks sit in the same admission chain and, if unreachable, block or ignore requests based on their own failurePolicy, so they can fail the same way. Additionally, a validating webhook can only observe, not mutate, the pod, so it cannot apply the missing mutations; it could only validate their absence. A second mutating webhook with failurePolicy: Ignore would be needed, but that just replicates the same availability tradeoff.

A
Run multiple replicas of the webhook
Why it fails: Running multiple replicas of the webhook provides high availability but does not solve the fundamental issue of webhook unavailability due to network partition, misconfiguration, or a bug that crashes all replicas at once. If the webhook is down, the API server still fails closed when failurePolicy=Fail, so multiple replicas reduce but do not eliminate the risk; they also introduce consistency issues if the webhook is stateful.
B
Set the webhook's failurePolicy to Ignore
Setting failurePolicy: Ignore tells the API server to bypass the webhook if it cannot be reached or returns an error, allowing pod creation to proceed without the mutation. This guarantees availability but at the cost of correctness, as the pod may miss required mutations. It is a standard mitigator for webhook outages, but should be used only when the mutation is non-critical or the mutation can be enforced elsewhere.
C
Disable admission webhooks in the cluster
Why it fails: Disabling admission webhooks in the cluster, for example by changing the kube-apiserver --disable-admission-plugins list, would stop the custom mutating webhook but also disables essential built-in admission controllers like NamespaceLifecycle, LimitRanger, or ServiceAccount. This is a drastic cluster-wide change that undermines security and policy enforcement, and it does not specifically address the webhook outage; it would affect all API requests and require an API server restart.
D
Create a validating webhook as a backup
Why it fails: Creating a validating webhook as a backup does not resolve the outage because validating webhooks sit in the same admission chain and, if unreachable, block or ignore requests based on their own failurePolicy, so they can fail the same way. Additionally, a validating webhook can only observe, not mutate, the pod, so it cannot apply the missing mutations; it could only validate their absence. A second mutating webhook with failurePolicy: Ignore would be needed, but that just replicates the same availability tradeoff.