Certified Kubernetes Security Specialist CKS (CKS) — Questions 451–525

Why this answer

How to eliminate wrong answers

Option A is wrong because `type: RuntimeDefault` applies the container runtime's default seccomp profile, not a custom profile at the specified path. Option C is wrong because it uses the deprecated `seccomp` field and `profile` key instead of the current `seccompProfile` API with `localhostProfile`. Option D is wrong because `localhostProfile: "audit.json"` is a bare filename, not a relative path; Kubernetes requires a relative path (e.g., `profiles/audit.json`) to locate the profile under `/var/lib/kubelet/seccomp/`.

Why this answer

How to eliminate wrong answers

Option A is wrong because `capabilities.allow` is not a valid field in the Kubernetes `securityContext`; the correct field is `capabilities.add` to add capabilities. Option B is wrong because `capabilities.add: ["ALL"]` adds all Linux capabilities to the container, which is the opposite of dropping them and increases the attack surface. Option D is wrong because `dropCapabilities: true` is not a valid Kubernetes field; the correct syntax uses `capabilities.drop` with a list of capability names.

Why this answer

How to eliminate wrong answers

Option A is wrong because `--audit-file` is not a valid kube-apiserver flag; the correct flag for specifying the audit log file path is `--audit-log-path`. Option C is wrong because `--audit-policy-file` specifies the path to the audit policy YAML file that defines which events to log, but it does not enable audit logging by itself—it must be used together with `--audit-log-path`. Option D is wrong because `--audit-log-file` is not a recognized flag; the correct flag name uses `--audit-log-path` as per the Kubernetes API server command-line options.

Why this answer

How to eliminate wrong answers

Option B is wrong because the container runtime not being Docker is irrelevant — `crictl` works with any CRI-compliant runtime (containerd, CRI-O, etc.) and does not require Docker. Option C is wrong because `crictl` is designed to work with any CRI-compliant runtime; it does not care which specific runtime the pod uses as long as the endpoint is correct. Option D is wrong because containers are not namespaced in a way that hides them from `crictl`; `crictl` lists all containers managed by the runtime on that node, regardless of Kubernetes namespaces.

Why this answer

How to eliminate wrong answers

Option A is wrong because a generate rule creates resources like ConfigMaps but does not enforce image digest usage at admission time; it only provides data that must be referenced elsewhere. Option B is wrong because a mutate rule would automatically replace tags with digests, which violates the policy's intent to require explicit digest references from the user, not automatic remediation. Option D is wrong because the annotation 'image.openshift.io/triggers' is OpenShift-specific for triggering image updates, not a Kyverno mechanism for validating image references.

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `--admission-control` is a deprecated flag; the correct flag is `--enable-admission-plugins`. Option B is wrong because `PodNodeSelector` is a different admission plugin that enforces namespace-level node selector constraints, not the NodeRestriction plugin. Option C is wrong because `--authorization-mode=Node` enables the Node authorizer, which authorizes kubelet API requests, but does not enable the NodeRestriction admission plugin.

Why this answer

How to eliminate wrong answers

Option B is wrong because `--admission-control` is a legacy flag from older Kubernetes versions (pre-1.10) and is no longer supported; the correct flag is `--enable-admission-plugins`. Option C is wrong because `--feature-gates=PodSecurity=true` only enables the PodSecurity feature gate (which is needed for the plugin to be available), but does not actually activate the admission plugin itself; the plugin must be explicitly added via `--enable-admission-plugins`. Option D is wrong because `--pod-security-policy=true` is not a valid kube-apiserver flag; the PodSecurityPolicy admission controller was enabled via `--enable-admission-plugins=PodSecurityPolicy` (now deprecated and removed in v1.25), and the flag shown does not exist.

Why this answer

How to eliminate wrong answers

Option A is wrong because ValidatingAdmissionWebhooks only reject or allow requests based on validation logic; they do not modify the Pod spec, so they cannot cause a container to fail at runtime due to a misconfiguration injected into the Pod. Option C is wrong because PodSecurity (formerly PodSecurityPolicy) enforces security contexts (e.g., privileged, hostNetwork) and would either reject the Pod or allow it; it does not mutate the Pod spec to cause a container crash. Option D is wrong because PersistentVolumeClaimResize is an admission controller that handles PVC resize requests, not Pod creation or container execution, so it has no impact on a Pod entering CrashLoopBackOff.

Why this answer

How to eliminate wrong answers

Option A is wrong because a syntax error in the Rego policy would typically cause the ConstraintTemplate to fail validation or produce an error in the Gatekeeper logs, but the question states the Constraint is created, implying the template is valid. Option B is wrong because if Gatekeeper were not installed, the ConstraintTemplate and Constraint resources would not be processed at all, and the question implies the Constraint is created (which requires Gatekeeper's webhook to be present). Option D is wrong because namespace exclusion via Gatekeeper configuration would prevent the policy from applying to pods in excluded namespaces, but the question does not mention any namespace exclusion; the most common and direct cause is the missing Constraint object.

Why this answer

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (PSP) is a deprecated admission controller that controls pod security contexts (e.g., privileged containers, host namespaces), not RBAC permissions; it cannot restrict what a service account can do via ClusterRoleBindings. Option B is wrong because deleting the service account and creating a new one without any roles would break the pod's functionality entirely, as it would have no permissions to perform any API operations, which is not a practical security fix. Option D is wrong because NetworkPolicy controls network traffic at the pod level (e.g., ingress/egress rules), not RBAC permissions; it cannot prevent a service account from abusing its cluster-admin privileges to escalate privileges via the Kubernetes API.

Why this answer

How to eliminate wrong answers

Option A is wrong because `kubectl create rolebinding` creates a namespaced RoleBinding, which only grants permissions within a specific namespace (default if not specified), not across all resources cluster-wide. Option B is wrong because it creates a new ClusterRole with `*` as the resource, which is invalid syntax (resources must be specific, e.g., `'*'` is not a valid resource name) and it does not bind the role to the user. Option C is wrong because it uses `--role=view` instead of `--clusterrole=view`; `--role` expects a namespaced Role, not a ClusterRole, and a ClusterRoleBinding cannot reference a namespaced Role.

Why this answer

How to eliminate wrong answers

Option B is wrong because `--disable-anonymous` is not a valid kubelet flag; the kubelet uses `--anonymous-auth` to control anonymous access. Option C is wrong because `--no-anonymous` is not a recognized flag; the kubelet does not support a `--no-` prefix for this setting. Option D is wrong because `--enable-anonymous-auth=false` is not a valid flag; the correct flag is `--anonymous-auth`, and setting it to `false` disables anonymous access, not `--enable-anonymous-auth`.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because service accounts can use both RoleBindings (namespace-scoped) and ClusterRoleBindings (cluster-scoped) depending on the required scope; there is no Kubernetes restriction limiting them to RoleBindings only. Option B is wrong because ClusterRoleBindings are not deprecated; they remain a core, actively supported RBAC resource for granting cluster-wide permissions. Option C is wrong because service accounts can absolutely use ClusterRoleBindings; the Kubernetes API allows binding any subject (user, group, or service account) to a ClusterRole via a ClusterRoleBinding.

Why this answer

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) controls security-sensitive aspects of pod specs (e.g., privileged containers, host namespaces) but does not restrict modifications to node objects. Option B is wrong because NodeAffinity is a scheduling constraint that influences pod placement based on node labels, not an admission plugin that enforces node object modification restrictions. Option C is wrong because PodNodeSelector is an admission plugin that enforces namespace-level node selector constraints on pods, but it does not prevent pods or kubelets from modifying node objects.

Why this answer

How to eliminate wrong answers

Option B is wrong because `/tmp` is not always writable; its writability depends on the filesystem mount flags, and with `readOnlyRootFilesystem: true`, the entire root filesystem, including `/tmp`, is read-only. Option C is wrong because the container does not crash; the write operation simply fails with an error, and the application may handle it gracefully or log the failure, but the container continues running. Option D is wrong because writes are not silently dropped; the kernel returns an explicit error (e.g., EROFS or EACCES) to the application, and the data is not written.

Why this answer

How to eliminate wrong answers

Option B is wrong because `crictl exec` is used to run a command inside a running container (e.g., `crictl exec -it <container-id> sh`), not to view logs; there is no `logs` subcommand for `exec`. Option C is wrong because `crictl inspect` returns detailed metadata and configuration of a container (e.g., mounts, environment variables, resource limits), not its log output. Option D is wrong because `crictl ps -a` lists all containers (including stopped ones) with their status and IDs, but does not display logs; appending a container ID to `ps` is syntactically invalid.

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because etcdctl does not have a command to encrypt the entire data directory; encryption is handled at the Kubernetes API server level, not by directly manipulating etcd. Option C is wrong because --encryption-provider is not a valid flag for etcd; etcd itself does not natively support encryption at rest via a flag, and the encryption provider configuration is applied to the kube-apiserver, not etcd. Option D is wrong because ETCD_ENABLE_ENCRYPTION is not a recognized environment variable in etcd v3.5; encryption at rest is not enabled by setting an environment variable on etcd.

Why this answer

How to eliminate wrong answers

Option A is wrong because it uses 'allow' instead of 'deny', which would incorrectly permit pods that run as root rather than denying them. Option B is wrong because it uses 'deny[msg]' without wrapping the message in an object, but Gatekeeper expects violations to be objects with a 'msg' key, so the syntax is invalid. Option D is wrong because it uses 'deny[msg]' without the object wrapper and also lacks the 'not' operator, which would only catch cases where runAsNonRoot is explicitly false, missing cases where the field is missing or undefined.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `kubectl run` creates a Pod (or Deployment) from an image, not a ValidatingWebhookConfiguration; it cannot parse a YAML file for custom resource types. Option C is wrong because `kubectl create -f webhook.yaml` would attempt to create resources from the file, but it uses imperative management and may fail if the resource already exists or if the YAML contains complex configurations that require `apply` semantics; more importantly, `kubectl create` is not the typical command for ValidatingWebhookConfiguration as it does not handle updates gracefully. Option D is wrong because `kubectl expose` creates a Service to expose a deployment, not a ValidatingWebhookConfiguration; it has no relation to webhook configuration resources.

Why this answer

How to eliminate wrong answers

Option A is wrong because `--authentication-token-webhook=true` enables webhook-based token authentication (e.g., for service accounts), but it does not affect anonymous requests; anonymous auth is controlled by a separate flag. Option B is wrong because `--read-only-port=0` disables the read-only port (10255), which reduces exposure but does not prevent anonymous requests on the secure port (10250). Option D is wrong because `--protect-kernel-defaults=true` ensures kernel-level security settings (e.g., sysctl parameters) are enforced, but it has no impact on kubelet authentication or anonymous request handling.

Why this answer

How to eliminate wrong answers

Option A is wrong because `kubectl taint nodes control-plane node-role.kubernetes.io/control-plane-` removes the taint from the control-plane node, which would allow all pods to schedule there, but this is a cluster-wide change that violates security best practices (control-plane nodes should remain tainted to isolate critical components). Option B is wrong because `kubectl cordon control-plane` marks the node as unschedulable, which would prevent any new pods from being scheduled on it, making the problem worse. Option D is wrong because `kubectl delete pod --all` deletes all pods in the current namespace, which does not address the scheduling issue caused by the taint and may disrupt running workloads.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `capabilities.disable` is not a valid field in the Kubernetes securityContext; the correct field is `capabilities.drop`. Option B is wrong because `capabilities.remove` is not a recognized field in the Kubernetes API; the field is specifically named `drop`. Option D is wrong because `privileged: false` only disables privileged mode, but the container still retains its default set of capabilities; it does not drop all capabilities.

Why this answer

How to eliminate wrong answers

Option A is wrong because exposing the Dashboard via NodePort bypasses authentication and authorization, relying solely on network firewalls which do not provide user-level access control or audit logging. Option B is wrong because granting cluster-admin to all service accounts would give every service account full administrative privileges, violating the principle of least privilege and creating a massive security risk. Option C is wrong because setting the Dashboard to use HTTP instead of HTTPS exposes all traffic in plaintext, allowing man-in-the-middle attacks and credential theft, and does not address authentication or authorization.

Why this answer

How to eliminate wrong answers

Option B is wrong because `audit` mode only generates a policy violation report without blocking the resource; the Deployment would be created but flagged. Option C is wrong because `mutate` policies modify resources to meet policy requirements (e.g., prepending a registry prefix) rather than blocking them; they do not deny creation. Option D is wrong because `generate` policies create additional resources (e.g., NetworkPolicies) based on triggers, not block or validate existing resources.

Why this answer

How to eliminate wrong answers

Option B is wrong because checking the image size only helps with storage and performance optimization, not with detecting known vulnerabilities. Option C is wrong because unit tests validate application logic and functionality, not the security posture of the container image or its dependencies. Option D is wrong because linting the Dockerfile checks for syntax errors and best practices in the build instructions, but it does not scan the resulting image for known CVEs.

Why this answer

How to eliminate wrong answers

Option B is wrong because it uses a raw IP address (10.96.0.1) which is not a stable or recommended way to reference a Kubernetes service; the URL should use the service DNS name to ensure reliability and avoid hardcoding IPs that may change. Option C is wrong because the URL uses an incomplete DNS name: `webhook-svc.webhook.svc` is missing the `.cluster.local` suffix (the full DNS name is `webhook-svc.webhook.svc.cluster.local`), and the port is appended to the hostname incorrectly (should be `https://webhook-svc.webhook.svc.cluster.local:443/validate`). Option D is wrong because it omits the `port` field; while the default port is 443, the `caBundle` field is required when using a service reference to secure the connection, but the absence of `port` is not the primary issue—the real problem is that a `caBundle` is mandatory for service references to verify the webhook server's TLS certificate, and without it the configuration will fail admission checks.

Why this answer

How to eliminate wrong answers

Option B is wrong because `remove` is not a valid field in the Kubernetes security context; the correct field is `drop`. Option C is wrong because setting `capabilities: []` is invalid syntax—the `capabilities` field must be an object with `add` and/or `drop` arrays, not an empty list. Option D is wrong because `add: []` adds no capabilities but does not drop any existing ones, so the container retains its default capabilities, failing to drop all.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because setting `--insecure-port=8080` enables an unencrypted, non-authenticated HTTP port, which is a severe security risk and explicitly deprecated in Kubernetes; the CIS benchmark recommends disabling the insecure port entirely. Option B is wrong because disabling the NodeRestriction admission plugin would allow compromised nodes to modify their own Node and Pod objects, reducing security; the CIS benchmark recommends enabling it to enforce node authorization. Option C is wrong because enabling encryption at rest for secrets in etcd protects data confidentiality at the storage layer but does not prevent unauthorized access to the kube-apiserver itself; it addresses a different control (data protection) rather than authentication hardening.

Why this answer

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.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because dropping only `NET_RAW` and `CHOWN` does not satisfy the 'restricted' PSS requirement to drop all capabilities; it leaves other potentially dangerous capabilities (e.g., `SYS_ADMIN`, `NET_ADMIN`) intact, violating the standard. Option C is wrong because adding `NET_BIND_SERVICE` is unnecessary and contradicts the 'restricted' PSS, which expects no capabilities to be added; the runtime already provides minimal capabilities, and explicit adds can introduce privileges beyond the allowed set. Option D is wrong because adding `ALL` capabilities grants every Linux capability to the container, which directly violates the 'restricted' PSS and defeats the purpose of capability dropping, creating a severe security risk.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because a ClusterRoleBinding applies cluster-wide, not just to the 'default' namespace; the service account can access resources in all namespaces. Option C is wrong because while service accounts can be bound to cluster-admin, doing so without justification is a significant security concern that violates least-privilege and should be avoided unless absolutely necessary. Option D is wrong because replacing the ClusterRoleBinding with a RoleBinding would limit the binding to a single namespace, but the core issue is the excessive privilege of the 'cluster-admin' ClusterRole, not the binding type; a RoleBinding with 'cluster-admin' is not possible (RoleBindings can only reference ClusterRoles for resources in the same namespace, but 'cluster-admin' still grants cluster-wide scope via a RoleBinding).

Why these pairings

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because using read-only root filesystems prevents containers from writing to their own filesystem, which limits the impact of a compromise by making it harder for an attacker to persist or modify binaries. Option B is wrong because running containers as non-root (e.g., with `runAsUser: 1000`) reduces the risk of privilege escalation by ensuring the container process does not have root UID 0 inside the container, which is a fundamental security best practice. Option D is wrong because disabling unnecessary system services on nodes (e.g., stopping unused daemons like `cups` or `rpcbind`) reduces the number of potential entry points for an attacker, directly shrinking the node's attack surface.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because keyless signing does enforce identity matching via OIDC tokens; the policy specifies allowed identities, and mismatches cause denial. Option B is wrong because the policy uses a regex `v*` which matches any tag starting with 'v', and 'v1' matches that pattern, so the policy applies. Option C is wrong because the policy restricts based on signer identity, not just registry; the image is from an allowed registry but the signer identity does not match, so admission is denied.

Why this order

Why this answer

How to eliminate wrong answers

Option A is wrong because baseline does not require dropping ALL capabilities first; it only restricts a specific set of capabilities (e.g., CAP_SYS_ADMIN, CAP_NET_RAW) but allows others like NET_ADMIN. Option B is wrong because while the pod does drop ALL and then add NET_ADMIN, the reason it is allowed is not simply because of that order but because NET_ADMIN is permitted by baseline. Option C is wrong because dropping ALL capabilities is not prohibited by baseline; in fact, dropping ALL is a common security hardening practice and is allowed.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because increasing CPU and memory limits does not affect the software packages or libraries present in the container image; resource limits only control runtime behavior, not the vulnerability surface. Option C is wrong because signing an image with Cosign provides integrity and provenance verification but does not remove or patch any vulnerabilities within the image. Option D is wrong because removing environment variables from the Dockerfile reduces the risk of secret leakage but has no impact on the vulnerability count reported by Trivy, which scans filesystem packages and libraries.

Why this answer

How to eliminate wrong answers

Option A is wrong because `kubectl describe node <node> | grep AppArmor` only shows the AppArmor annotations on the node object (like whether a pod requests a profile), not the actual AppArmor status or loaded profiles on the node. Option B is wrong because `kubectl get apparmor` is not a valid kubectl command; AppArmor is not a Kubernetes resource and cannot be queried via the API. Option D is wrong because `kubectl exec <pod> -- aa-status` runs the command inside a container, which typically lacks the necessary privileges and access to the host's AppArmor subsystem; `aa-status` must be executed on the node itself.

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `--anonymous-enabled=false` is not a valid kube-apiserver flag; the correct flag is `--anonymous-auth`. Option B is wrong because `--no-anonymous` is not a recognized flag; the kube-apiserver uses boolean flags like `--anonymous-auth` rather than negated prefixes. Option D is wrong because `--disable-anonymous` is not a valid flag; the API server uses `--anonymous-auth` with a boolean value to control anonymous access.

Why these pairings

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because a NodePort Service exposes the Dashboard on a static port on every node's IP address, making it accessible from within the cluster network and potentially from outside if network policies are misconfigured, violating the principle of least exposure. Option C is wrong because a LoadBalancer Service provisions a public-facing cloud load balancer, directly exposing the Dashboard to the internet or broader network, which is unnecessary and increases the attack surface significantly. Option D is wrong because using an Ingress with a public DNS exposes the Dashboard via a hostname, often terminating TLS at the ingress controller, but still making the service reachable from outside the cluster and requiring additional security controls like authentication and network policies that are easy to misconfigure.

Why this answer

How to eliminate wrong answers

Option A is wrong because a score of -1 is not a valid security score; kubesec returns positive scores (0-10) for successful scans, and a passed scan would yield a score of at least 0, not -1. Option B is wrong because -1 does not indicate a security posture; it signals a scan failure, and a deployment needing immediate attention would receive a low positive score (e.g., 0 or 1) with specific vulnerability details. Option D is wrong because critical vulnerabilities are reported with a low positive score (e.g., 0-2) and detailed findings, not a -1 error code.

Why this answer

Why this order

Why this answer

How to eliminate wrong answers

Option B is wrong because /etc/kubernetes/admin.conf is the kubeconfig file used by kubectl and administrators for cluster authentication and authorization, not a configuration file for the API server itself. Option C is wrong because /etc/kubernetes/pki/etcd/ca.crt is the CA certificate for etcd, used for TLS communication between etcd members and clients; it has no role in configuring API server encryption at rest. Option D is wrong because /etc/kubernetes/kubelet.conf is the kubeconfig file for the kubelet to authenticate to the API server, not a file that controls API server encryption settings.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `crictl pods` lists pods (groups of containers), not individual containers, and is used for pod-level debugging. Option C is wrong because `crictl images` lists container images stored locally, not running containers. Option D is wrong because `crictl stats` shows resource usage statistics (CPU, memory) for running containers, not a list of them.

Why this answer

How to eliminate wrong answers

Option A is wrong because `--read-only-port=0` disables the read-only port (10255) on the kubelet, which prevents unauthenticated access to node metrics, but it does not enforce kernel defaults. Option B is wrong because `--security-context` is not a valid kubelet flag; security contexts are configured at the Pod or container level via the Kubernetes API, not on the kubelet itself. Option D is wrong because `--kernel-security` is not a recognized kubelet flag; the correct flag for enforcing kernel defaults is `--protect-kernel-defaults`.