KCSA practice questions and answers

Correct answer: D — The SBOM lists the components and versions in the image, but not which of them are vulnerable or exploitable; that needs a scanner and, for exploitability, a VEX document.

SPDX and CycloneDX are inventory formats. They answer the question 'what is inside this image', which is what you need when a new CVE lands and you must find every affected image fast. They do not carry vulnerability status, so a scanner must map the components to a CVE feed, and only a VEX statement from the vendor says whether an affected component is actually exploitable in that product. A invents scoring data that an SBOM does not hold. B confuses the inventory with signing and attestation, which are separate steps. C is the common misreading - an SBOM is a build-time list and knows nothing about runtime behaviour.

Correct answer: B — Configure a webhook audit backend so the API server sends events to a collector that runs outside the cluster.

A webhook backend makes the API server push each event to an external endpoint, so the evidence leaves the node as it is produced and an attacker with node root cannot delete or edit it after the fact. Option A keeps the only copy on the machine the attacker controls. Option C is better than A but still writes to local disk first and runs the shipper on the same compromised node, so the attacker can stop it or edit the file before it is read. Option D is wrong on its own terms: the audit stages are RequestReceived, ResponseStarted, ResponseComplete and Panic, and RequestReceived alone records that a request arrived with no outcome, so you lose the response code and whether the action succeeded.

Correct answer: B — Use a BuildKit secret mount so the token is only readable during that RUN step and is never written into a layer.

A BuildKit secret mount (`RUN --mount=type=secret,id=npmrc ...`) exposes the value to a single build step through a tmpfs mount, so it is never committed to a layer and never appears in `docker history`. Option A fails because layers are immutable and additive: deleting the file in a later layer leaves the earlier layer, and `--build-arg` values are still visible in the image history. Option C is worse, because ENV values are stored in the image config and are readable by anyone who pulls the image. Option D is a good control for runtime credentials, but this token is needed at BUILD time, so a runtime secrets manager does not solve the problem and adds cost.

Correct answer: B, E — escalate on roles · bind on the roles that a RoleBinding references

The API server has built-in privilege escalation prevention: you may only grant permissions you already have. escalate switches that check off for writing Roles, and bind switches it off for referencing an existing higher-privilege Role from a RoleBinding, so both are ways to climb above your own access. A is a genuine escalation path but impersonate lives on users, groups and serviceaccounts in the core API group, not in rbac.authorization.k8s.io, so it does not answer this question. C is not enough on its own, because a plain create is still blocked by the escalation check unless the user also has bind. D refers to PodSecurityPolicy, which was removed in Kubernetes 1.25.

Correct answer: A — Only pods labelled app=web that run in a namespace labelled team=checkout.

namespaceSelector and podSelector inside one from element are combined with AND, so the source must match both: pod label app=web and namespace label team=checkout. Writing them as two separate list items under from would be OR, which is exactly option B and the most common mistake with this API. C is wrong because the top-level podSelector chooses which pods the policy protects, not which sources are allowed, and once a pod is selected for Ingress everything not listed is dropped. D is wrong because NetworkPolicy is allow-only and additive; there is no deny rule in the API.

Correct answer: A — kube-bench answers the CIS Benchmark question; Kubescape answers the multi-framework question.

kube-bench runs on the node and checks file permissions, ownership and component flags against the numbered controls of the CIS Kubernetes Benchmark, printing PASS, FAIL or WARN per control, which is the evidence format an auditor expects. Kubescape scans the live cluster and its manifests against several control sets, including NSA and CISA hardening guidance, MITRE ATT&CK and CIS, and returns a posture score. C is wrong because kube-bench is CIS only. D swaps in the wrong tools - Falco is runtime threat detection from kernel events, and Trivy scans images and infrastructure code for vulnerabilities and misconfigurations. E ignores that both tools exist and are the standard answer here.

Correct answer: C — Change the pod's labels so it leaves the ReplicaSet selector, apply a deny-all NetworkPolicy that matches the new label, then remove the ServiceAccount's RoleBindings.

Relabelling makes the ReplicaSet see one pod missing and start a healthy replacement, while the compromised pod stays alive and isolated for forensics; the deny-all NetworkPolicy cuts it off from the API server and from other pods, and removing the RoleBindings makes the stolen token useless everywhere. A destroys the evidence, the ReplicaSet recreates the pod anyway, and the token identity keeps working. B does not help because ServiceAccount tokens are signed with the service account key pair, not the cluster CA. D is a good hardening step but only affects pods created later, so it contains nothing today.

Correct answer: D — Ship audit events to object storage outside the cluster with a twelve month immutable retention lock, and give the auditors read-only access to that bucket.

Evidence has to live somewhere the audited system cannot rewrite, so write-once storage with an object lock outside the cluster satisfies both integrity and the retention period, and a read-only grant on that bucket gives auditors what they need without a single Kubernetes permission. Options A and C both hand out cluster access, which the requirement forbids, and neither one lets an auditor read audit records anyway — audit events are not Kubernetes API objects. Option B is worse still: SSH to a control plane node is high privilege access to the very machine that writes the evidence, so nothing is tamper-proof.

Correct answer: A — Write the rules as ValidatingAdmissionPolicy objects with CEL expressions, which the API server evaluates itself.

ValidatingAdmissionPolicy is built into the API server and is generally available, so two simple CEL rules need no extra pods, no webhook serving certificate to rotate and no upgrade path of their own. That is the lowest operational overhead for a small team with a short list of rules. Kyverno is friendly to write because policies are YAML, and Gatekeeper is powerful, but both add a controller and an admission webhook that the team must run, monitor and keep available, and a failing webhook can block deployments. Pod Security admission is also built in, but its three fixed profiles cannot express "limits must be set" or "no :latest tag".

Correct answer: B — Nodes, PersistentVolumes and CustomResourceDefinitions are cluster-scoped, and a Role plus RoleBinding only grants access inside one namespace. Grant them with a ClusterRole bound by a ClusterRoleBinding.

RBAC rules only work on objects that live where the binding lives. A Role and a RoleBinding are namespaced, so they can never grant access to cluster-scoped resources such as nodes, PersistentVolumes or CustomResourceDefinitions, no matter what verbs you write. You need a ClusterRole bound with a ClusterRoleBinding. Option C fails because a ClusterRoleBinding's roleRef must point to a ClusterRole, not a Role. Option D just repeats a namespaced grant many times, which still never covers cluster-scoped objects. Note the reverse is allowed and often useful: a RoleBinding may reference a ClusterRole, but that still limits the access to that one namespace.

Correct answer: B — kubectl auth can-i list secrets --as=jane --as-group=dev-readers -n staging

`kubectl auth can-i` with --as and --as-group asks the API server to run its authorization check as that user and group, using the SubjectAccessReview path. A result of `no` means every authorizer denied the request, which is exactly the confirmation the team wants. Option A shows the permissions of the caller, not jane. Option C prints which subjects a binding names, but not the effective permissions those subjects end up with across all bindings. Option D validates and would apply RBAC objects; it does not answer whether a specific subject can perform a verb. Note that impersonation itself needs the impersonate verb, which a cluster admin already has.

Correct answer: D — restricted

Baseline already blocks hostPath volumes, hostNetwork and other host namespaces, but it still allows allowPrivilegeEscalation: true. Only the restricted profile requires allowPrivilegeEscalation to be false, along with runAsNonRoot, a seccomp profile and dropping ALL capabilities, so restricted is the minimum profile that covers all three requirements. The privileged profile is the opposite of strict: it is fully open and enforces nothing. Seccomp annotations were removed years ago and do not control privilege escalation.

Correct answer: A, D — An egress rule that allows traffic to pods labelled k8s-app=kube-dns in the kube-system namespace on UDP port 53 and TCP port 53. · An egress rule with an ipBlock for the control plane node addresses on the API server port, for example 6443.

A default-deny policy that lists both Ingress and Egress blocks DNS as well, so the first rule you need is egress to the CoreDNS pods in kube-system, selected by namespaceSelector plus podSelector, on both UDP 53 and TCP 53. The API server is not a pod, so it cannot be selected by labels; you allow it with an ipBlock covering the control plane endpoint on its port. Option C is the common trap: traffic to a ClusterIP is translated to a real endpoint address before policy is evaluated, so an ipBlock holding a Service ClusterIP does not reliably match. Option B allows the wrong direction, and option E adds another deny rule rather than an allow rule.

Correct answer: C — Schedule kube-bench, which tests the cluster against the numbered controls of the CIS Kubernetes Benchmark and returns PASS, FAIL or WARN for each one.

The CIS Kubernetes Benchmark is written as numbered, testable controls, and kube-bench automates those checks and prints PASS, FAIL or WARN per control, which is exactly the scored evidence an auditor wants. The NSA/CISA Kubernetes Hardening Guidance is valuable, but it is prose advice with no numbered scored controls and no scanner, so A means manual work every week. B is wrong because an audit log records who called the API, not whether a hardening control is met. D is wrong because Pod Security Admission only covers pod-level settings and says nothing about the control plane, etcd, or kubelet controls the benchmark checks.

Correct answer: B — Apply warn: restricted and audit: restricted first, review the warnings and audit events, fix the workloads, then add enforce: restricted.

Pod Security Admission has three independent modes. warn sends a message back to whoever applies the manifest, audit writes an annotation into the audit log, and only enforce rejects the pod. Setting warn and audit first gives a full list of offending workloads with zero production impact, and enforce is added once the list is empty. A is the risky reverse order and would break the next deployment. C is wrong because enforce-version pins the policy version, it does not exempt old pods. D is wrong because audit never blocks anything. Remember that enforce is checked at pod creation and update, so pods already running are not evicted when the label is added.

Correct answer: C — SAST reads only first-party source code, so the built image must also be scanned for vulnerable base image OS packages and third-party libraries.

SAST analyses the code your developers wrote. Most of a container image is code they did not write: the base image OS packages, the language runtime, and the dependency tree pulled in at build time. Those layers need an image scan of the final artifact, ideally in the pipeline and again in the registry. Option B is the dangerous assumption the question is testing. Option A does not change what SAST can see. Option D exercises the running application over the network, so it will not report a CVE in an unused OS package that is still present in the image.

Correct answer: B — NIST SP 800-190, the Application Container Security Guide

NIST SP 800-190 is organised around the container lifecycle and describes the risks of each tier — images, registries, orchestrator, containers and host OS — together with countermeasures, which is exactly what the architect asked for. Option A is the tempting answer but the CIS Kubernetes Benchmark is prescriptive configuration guidance with pass or fail checks for the API server, scheduler, controller manager, etcd and kubelet, so it covers cluster configuration, not the application lifecycle. Option C applies only where cardholder data is in scope and is not container-specific. Option D catalogues adversary techniques to help you build detections; it is not lifecycle security guidance.

Correct answer: A, D — Secrets that already exist stay unencrypted in etcd until each one is written again, for example with kubectl get secrets -A -o json | kubectl replace -f -. · The first provider in the providers list encrypts new writes, while every provider in the list can be used to decrypt reads.

Encryption at rest only takes effect when an object is written, so old Secrets keep sitting in etcd in the clear until they are rewritten - this is the fact most teams miss after a migration. The provider list is ordered: the first entry encrypts, and all entries are tried for decryption, which is why identity is kept last during a migration and removed later. B is wrong because the kube-apiserver decrypts transparently, so RBAC behaviour does not change. C is wrong because the kube-apiserver, not the kubelet, does the encryption. E is wrong because traffic to the kubelet is already protected by TLS; that is encryption in transit, a different control.

Correct answer: B — Anything that can talk to the socket can ask containerd to start a new privileged container with the host root filesystem mounted, which gives root on the node and access to every pod and Secret on it.

The container runtime socket is a full control API for the node. Any process that can connect to it can create a container with privileged settings and the host filesystem mounted, then read node credentials, kubelet certificates and the Secrets of every pod on that node. The pod's own securityContext is irrelevant, because the new container is created by containerd, not by the pod. The socket is a node-wide endpoint, not a per-pod one, so A is wrong, and it is far more than metadata, so C is wrong. Marking the mount readOnly does not help: a socket is used by connecting and sending requests, not by writing to a file. The right control is to block hostPath mounts through Pod Security admission or an admission policy.

Correct answer: A — Start kube-controller-manager with --use-service-account-credentials=true so each controller acts as its own ServiceAccount in kube-system, bound to its own controller role.

With --use-service-account-credentials=true the controller manager uses a separate ServiceAccount per controller, such as replicaset-controller or job-controller in kube-system, and each of those is bound to a narrow system:controller:* role. A flaw in one controller then has a much smaller blast radius. B keeps a single identity and makes it worse by binding cluster-admin. C only controls which replica is active, not what it may do. D is real hardening for the debug endpoint and the listening address, but every controller still shares one powerful credential.

Correct answer: C — The kubelet client certificate expired because certificate rotation was not working. Turn on rotateCertificates so the kubelet renews it through the CSR API, and re-bootstrap the affected nodes with a fresh token.

Kubelet client certificates are short-lived, usually one year, and the kubelet is supposed to request a new one through the CSR API before expiry when rotateCertificates is on and an approver signs the request. When that does not happen the kubelet can no longer authenticate to the API server, the node stops reporting status and goes NotReady, exactly as described. The admin kubeconfig still works, which tells you the cluster CA is fine, so D is wrong. ServiceAccount tokens are projected and refreshed automatically, so A is wrong. serverTLSBootstrap concerns the kubelet's serving certificate, used for calls such as kubectl logs and metrics, and it does not renew the client certificate.

Correct answer: B — Metadata

Metadata logs the user, the verb, the resource, the namespace, the timestamp and the response code, but no request or response body, which is exactly the who-read-what record the auditor wants with no secret material in the log. RequestResponse would write the full Secret object, including its data, into the log, and Request logs the submitted body, which exposes values on create and update calls. None disables logging for secrets completely and would leave the auditor with nothing. This is why the common hardened policy puts secrets, configmaps and serviceaccounts/token at Metadata only.

Correct answer: B — Mutual TLS between the two workloads, so each side authenticates the peer and the payload is encrypted.

Interception attacks such as ARP or DNS spoofing put the attacker on the path of traffic that is not addressed to it, so the only real defence is to make the traffic useless when captured: encrypt it and verify the peer's certificate. A default-deny NetworkPolicy is valuable, but it restricts who may open a connection - it does not encrypt anything, and it does not stop a compromised node or an on-path pod from reading packets it can already see. C only changes external exposure of the Services. D hardens the API server and has nothing to do with pod-to-pod traffic.

Correct answer: A, D — Set --client-cert-auth=true and --trusted-ca-file to the etcd CA, so client connections must present a certificate signed by that CA. · Set --peer-client-cert-auth=true and --peer-trusted-ca-file to the etcd CA, so members must present a valid certificate to join or talk to the cluster.

etcd only checks client certificates when --client-cert-auth is true and a trusted CA file is set, and it only checks peer certificates when --peer-client-cert-auth and --peer-trusted-ca-file are set. Without those, TLS just encrypts the connection and anyone who can reach port 2379 or 2380 is trusted. Encryption at rest is worth having, but it protects the data on disk and does not stop an authenticated-looking client reading through the etcd API, so B is the classic trap. Self-signed certificates from --auto-tls are not signed by your CA and do not authenticate anyone. NetworkPolicy does not apply to etcd, which runs as a static pod on the host network.

Correct answer: B — Repudiation - a user can deny an action because no trustworthy record of it exists.

Repudiation is about accountability: with no audit trail there is no evidence tying the delete call to an account, so the action can be denied. The countermeasure is an audit policy that logs write requests together with the user identity, shipped off-cluster so it cannot be edited by whoever is being audited. A would apply to a different weakness, such as a forged or stolen token used to act as another identity. C would apply to an exposed Secret or an unauthenticated read endpoint. D would apply to a Role that lets a user create a binding to cluster-admin.

Correct answer: A — The image was produced by the declared build platform from the declared source repository and commit, and it has not been swapped since.

Provenance is a signed statement about how an artifact was made: which builder ran, which source repository and revision it consumed, and which build parameters were used. Verifying the signature and the digest tells you the artifact in front of you is the one that build produced. Higher SLSA build levels raise how much you can trust that statement — Build L3 requires a hardened build platform whose provenance a project cannot forge. It says nothing about vulnerabilities, which needs an SBOM plus a scanner (option B), nothing about human code review (option C), and nothing about base image policy unless a separate policy check inspects the layers (option D).

Correct answer: C — A Falco alert on the syscalls inside the container, because the runtime sensor sees the new process and its outbound connection.

Falco watches kernel syscalls through eBPF or a kernel module, so it sees the write to /tmp, the exec of an unexpected binary and the new outbound connection within seconds of them happening. Option A fails because audit logging records requests to the API server, and this attacker never touches it. Option B eventually shows something, but CPU has to climb and stay high before an alert fires, and a legitimate batch job produces the same shape — it is slower and ambiguous. Option D is wrong: starting a process inside a container does not restart it, and Kubernetes Events do not track processes.

Correct answer: C — Require IMDSv2 on the nodes with a metadata hop limit of 1, and add a NetworkPolicy that denies pod egress to 169.254.169.254/32.

A hop limit of 1 means the metadata response cannot survive the extra network hop out of the pod's network namespace, so only processes on the host itself get an answer, and requiring IMDSv2 blocks simple SSRF-style reads. The NetworkPolicy adds a second layer by dropping pod egress to the link-local address. A fails because 169.254.169.254 is a link-local address served by the hypervisor, not something reached over the internet, so a private subnet changes nothing. B removes the Kubernetes ServiceAccount token but not the cloud credentials. D blocks privileged pod fields such as hostNetwork and hostPath, but Pod Security Admission never filters network traffic.

Correct answer: D — Configure the API server for OIDC authentication against the corporate identity provider and bind RBAC to the groups claim in the ID token.

OIDC moves identity to the provider the company already runs: disabling the account there stops new short-lived ID tokens being issued, and the groups claim maps straight onto RBAC RoleBindings, so no per-user cluster change is needed. A shrinks the exposure window but means a daily certificate issuing job for every engineer, and still no central off switch. B is wrong because ServiceAccounts are meant for workloads, they carry no corporate group membership, and their tokens are easy to copy. C is wrong because a static token file holds long-lived plaintext tokens and requires an API server restart to reload, which is why it is discouraged.

Correct answer: D — Reference images by immutable digest, such as registry.example.com/api@sha256:..., and add an admission policy that rejects any pod whose image uses a tag, including :latest.

A digest is a content hash, so registry.example.com/api@sha256:... can only ever resolve to the exact image that was reviewed, and an admission policy that rejects tagged references stops anyone from slipping back to a mutable name. A is the trap: imagePullPolicy: Always guarantees a fresh pull but a tag can be moved to different content at any time, so it pulls the newest image rather than the approved one. B removes registry controls and scanning, and pushes image distribution onto every node by hand. C does not work, because imagePullSecrets are namespaced and a pod can only reference a Secret in its own namespace.

Correct answer: C — Set authentication.anonymous.enabled to false and authorization.mode to Webhook in the kubelet configuration.

The two ports are separate problems. Port 10255 is the plain HTTP read-only port, and readOnlyPort: 0 closes it, which is why the first finding is already fixed. Port 10250 is the kubelet's real API, and it serves /exec, /run and /logs; it is open to anyone only because anonymous authentication is on and authorization mode is AlwaysAllow. Turning anonymous auth off and switching authorization to Webhook makes the kubelet ask the API server whether the caller may use those endpoints. protectKernelDefaults only controls kernel sysctl behaviour, and NetworkPolicy applies to pod traffic, not to the kubelet listening on the node itself.

Correct answer: B — Keep the mutating webhook for defaults, and add a validating control - a validating webhook or Pod Security Admission - that rejects any pod that still fails the requirement after all mutation is done.

All mutating webhooks run first, then all validating webhooks see the final object, so validation is the only phase that can guarantee what is actually stored. A mutating webhook can be skipped by its own namespaceSelector or objectSelector, can be bypassed if it is down and failurePolicy is Ignore, and its field can be overwritten by another mutating webhook that runs later - so pairing it with a validating check closes the gap. A makes the problem worse by turning the control into a fail-open one. C changes only whether the webhook is called again after other mutations, which weakens rather than strengthens the result. D is impossible: the mutating and validating phases are fixed by the API server and cannot be reordered.

Correct answer: C — Move the API server to a private endpoint reached over the company network or a bastion, and restrict the remaining access with authorized IP ranges.

Strong authentication and RBAC only help after a request reaches the API server; a private endpoint plus an allow list of source ranges means an attacker without network access never gets to send the request in the first place, which is the only option that removes pre-authentication exposure. A shapes load between authenticated clients and does not keep the internet out. B is good hygiene but a public endpoint stays public. D is detection, not prevention, and RequestResponse for everything produces a very large, expensive log.

Correct answer: C — Neither mode isolates pods; kube-proxy only maps Service virtual IPs to endpoints, so NetworkPolicy is needed.

kube-proxy exists to translate a Service ClusterIP into a real pod endpoint. iptables and IPVS are two ways of doing the same load balancing job, and the choice is about scale and performance, not security. A pod can always dial another pod IP directly and skip the Service entirely, so no kube-proxy mode is a boundary. Isolation comes from NetworkPolicy objects enforced by the CNI plugin. A and D invent access control features kube-proxy does not have, and B confuses the presence of iptables rules with actual filtering - those rules only do DNAT.

Correct answer: A, C — privileged: true · capabilities.add: ["SYS_ADMIN"]

privileged: true removes almost every container restriction at once - all capabilities, device access under /dev, and relaxed seccomp and AppArmor - so the process can mount the host disk or write to host devices. CAP_SYS_ADMIN is the single capability closest to that, since it permits mount operations and other kernel administration and is the classic building block of container escapes. NET_RAW is dangerous but network-level: it allows raw sockets, sniffing and ARP spoofing, not node takeover. runAsUser: 0 is root inside the container's namespaces with the restricted default capability set, which is a risk multiplier rather than an escape on its own, and allowPrivilegeEscalation: true only lets a process gain the capabilities the container already has through setuid binaries.

Correct answer: D — Both runtimes hand the profile to the OCI runtime, which applies it to the container process through the Linux kernel, so enforcement is the same.

seccomp and AppArmor are Linux kernel features. The kubelet reads the securityContext, passes the profile through the CRI, and the CRI implementation writes it into the OCI runtime spec; runc (or crun) then applies it to the container process at start. containerd and CRI-O both do this, so swapping the CRI does not change enforcement. Option A is wrong: containerd honours seccompProfile, including RuntimeDefault. Option B is wrong because the API server only validates and admits the object, it never touches the container process. Option C confuses network setup with process confinement.

Correct answer: A, C — Pods from both namespaces can be scheduled onto the same node and share one Linux kernel, so a container breakout reaches the other tenant's workloads. · Cluster-scoped objects such as CustomResourceDefinitions, ClusterRoles and admission webhook configurations are shared, so a change made for one tenant affects every namespace.

A namespace is an API boundary, not a kernel boundary and not a control plane boundary. Tenant pods still land on shared nodes and share the host kernel, so one container escape crosses the namespace line (A), and the cluster-wide layer - CRDs, ClusterRoles, admission webhooks, the API server itself - is common to both tenants (C). That is why hard multi-tenancy for hostile tenants usually means separate clusters, or at least separate node pools plus a sandboxed runtime. B is wrong because Secrets are namespaced and a Pod can only mount Secrets from its own namespace. D is wrong because a Role is namespaced by design. E is wrong because ResourceQuota is namespaced, so each tenant can get its own budget.

Correct answer: B, C — It encrypts traffic between the two workloads, so anything that captures the packets cannot read them. · It gives each workload a certificate-based identity, so the peer is verified by identity instead of by IP address.

mTLS adds encryption in transit and a cryptographic workload identity carried in an X.509 certificate, so a service can authorize callers by identity even if pod IPs change or are spoofed. NetworkPolicy works on IPs and label selectors at connection time and offers neither of those. A describes exactly what an egress NetworkPolicy already does, so it is not the added value. D is wrong because mesh identity applies to service-to-service calls, not to API server authorization. E is Pod Security Admission territory. Note that PERMISSIVE accepts both plain text and mTLS, so during migration the encryption guarantee does not exist yet - only STRICT rejects plain text.

Correct answer: D — Keeping the worker node operating system patched and defining RBAC Roles and RoleBindings.

On a managed control plane the provider runs and patches kube-apiserver, the controller manager, the scheduler and etcd, so the customer cannot set API server flags or manage etcd encryption keys directly. What stays with the customer is everything above that line: node image patching and node upgrades, workloads, and all authorization objects such as Roles, RoleBindings and ClusterRoleBindings. A, B and C all describe control plane work the provider performs, which is exactly why they are tempting - candidates remember these as hardening tasks from a self-managed cluster.

Correct answer: A — Create a StorageClass whose CSI driver parameters turn on volume encryption with a customer-managed KMS key, and move the workload's PersistentVolumeClaims to that StorageClass.

CSI drivers for cloud block storage expose encryption through StorageClass parameters, so the driver encrypts the volume with the key you name and the application writes to the filesystem exactly as before. That meets the key-control requirement with no code change. Application-level encryption is stronger against someone who already has node access, but it is a large code change and holding the key in a Secret on the same cluster weakens it. Encryption at rest in etcd protects API objects such as Secrets and ConfigMaps, not the data inside a PersistentVolume. Access modes and readOnly mounts control who may write, not whether the data is encrypted.

Correct answer: A — Run commands inside any container on that node and read its logs, with no authorization check at all.

The kubelet API exposes /exec, /run, /attach and /logs for every pod on that node. With AlwaysAllow the kubelet approves every request it receives, and with anonymous auth on, the caller does not even need an identity, so reaching port 10250 is equal to a shell in every container on the node. The fix is --authorization-mode=Webhook, which makes the kubelet ask the kube-apiserver with a SubjectAccessReview, plus --anonymous-auth=false. B is wrong because the kubelet has no etcd access, C describes the certificate signing controller on the control plane, and D needs RBAC write access on the API server, not the kubelet.

Correct answer: C — Run the workloads with Kata Containers through a RuntimeClass, so each pod gets its own lightweight virtual machine and its own kernel.

Kata Containers runs each pod inside a lightweight VM with its own guest kernel, so a kernel exploit inside the pod has to break the hypervisor before it reaches the host. That is the strongest boundary of the three, and the price is slower start times and more memory per pod, which the team accepts. gVisor is a real sandbox but its user-space kernel still runs on the host kernel, so the boundary is smaller, and syscall-heavy workloads slow down. Plain runc with seccomp shares the host kernel, so one kernel bug is a full escape. Namespaces, NetworkPolicy and quotas separate tenants logically but give no kernel isolation at all.

Correct answer: B — Pod Security Admission runs only when a pod is created or updated, so running pods keep running; the new pods are rejected when the ReplicaSet tries to create them, so the rollout stalls while the old pods stay up.

Pod Security Admission is an admission controller: it evaluates pods at create and update time and never touches pods that are already running. That is why a label change looks harmless until the next rollout, when the ReplicaSet controller's pod create calls are refused and the Deployment simply stops progressing. A is wrong because the kubelet does not re-evaluate the profile at runtime. C is wrong because the Deployment itself is admitted; only the pods it tries to create are blocked, which is why the failure shows up in ReplicaSet events, not in kubectl apply. D is wrong because the label is read on every admission request with no restart needed.

Correct answer: A, C — Enable encryption at rest with an EncryptionConfiguration that covers the secrets resource, ideally backed by a KMS provider. · Use RBAC to limit get, list and watch on Secrets to only the people and workloads that need them.

base64 is an encoding, not a protection, so the two things that matter are who can read the object and how it is stored. Encryption at rest protects the copy written to etcd, and a KMS provider keeps the encryption key outside the cluster. RBAC controls the far more common attack path: anyone who can read Secrets through the API can decode them in one command. Option B removes even the small barrier and is worse. Option D is wrong: stringData is only a convenience on write, the API server base64-encodes it into data anyway. Option E is true but irrelevant, because TLS only protects data in transit and does nothing about who is allowed to ask.

Correct answer: C — It crosses the boundary between the workload and the control plane, where authentication, RBAC and admission control protect cluster state in etcd from untrusted workloads.

The workload and the control plane sit in different trust zones. When a pod calls the API server, the request leaves the workload zone and enters the control plane, where the API server checks the token, applies RBAC and runs admission control before anything reaches etcd. That boundary exists so a compromised workload cannot change cluster state directly. Being on the same network does not make the call trusted, which is why A is wrong. The runtime boundary in B is the one between the container and the host kernel, and the cloud boundary in D is the one crossed when the node calls the cloud provider API.

Correct answer: D — Mount the Secret as a read-only file in a volume and have the application read the value from disk.

An environment variable lives in the process environment, so it is exposed to crash handlers, error reporters, `/proc/<pid>/environ` and anything that dumps the environment for debugging. A Secret mounted as a file is not in the environment, so a routine environment dump no longer contains it, and the kubelet also refreshes the file when the Secret changes. Option A is a true statement — `kubectl describe` shows only key names and byte counts — but it does not touch the leak path in this scenario. Option C protects the API path, not the application printing its own environment. Option B changes only how the value is written; the API server still stores it in data the same way.

Correct answer: C — Rotate the cluster CA, reissue every client and server certificate signed by it, and distribute new kubeconfig files.

Kubernetes has no certificate revocation support: the API server trusts any client certificate signed by the CA in --client-ca-file until that certificate expires. The only way to invalidate one is to stop trusting the CA that signed it, which means rotating the CA and reissuing everything. Option A does nothing here, because the system:masters group is hard-coded to bypass authorization, so RBAC changes cannot take its power away. Option B is the common wrong instinct — there is no CRL or OCSP check in the API server's x509 authenticator. Option D hardens other paths but leaves the stolen certificate fully valid.

Correct answer: B — The request is authenticated as system:anonymous in the group system:unauthenticated, which the built-in system:public-info-viewer binding allows to read /version and the health endpoints. Setting --anonymous-auth=false rejects requests that carry no credentials.

With the default --anonymous-auth=true, a request without credentials is not dropped; it is given the username system:anonymous and the group system:unauthenticated, and then authorized like any other request. The default system:public-info-viewer ClusterRoleBinding grants that group a few non-resource URLs such as /version, /healthz, /livez and /readyz, which is why /version works while Secrets return 403. Setting --anonymous-auth=false makes those requests fail at authentication instead. Be aware this can break external load balancer health checks, so newer clusters can use the authentication configuration file to keep anonymous access only for the health endpoints. RBAC is enabled here (the 403 proves it), and the insecure port in option D was removed from Kubernetes years ago.

Correct answer: B — Apply a NetworkPolicy that denies egress from the application namespace to 169.254.169.254/32.

The metadata endpoint is reached over the network, so a NetworkPolicy that blocks egress to the link-local metadata address stops the request no matter what tooling the attacker has. Option A raises the bar and is worth doing, but an attacker with code execution can still open a socket from the application process itself, so it does not stop the step. Option C closes a different exposure: the kubelet read-only port on 10255 leaks Pod and node data, and turning it off is correct hardening, but it has nothing to do with the cloud metadata service. Option D limits privilege escalation on the host and is good practice, but an unprivileged non-root process can still make outbound HTTP calls.

Correct answer: B — Image scanning is a Container-layer control and the firewall is a Cloud-layer control. The firewall does not remove the need for scanning, because a vulnerable image still runs inside the perimeter.

The 4Cs are Cloud, Cluster, Container and Code, from the outside in. Scanning an image for vulnerable packages is a Container-layer control, and a network firewall around the infrastructure is a Cloud-layer control. Each layer builds on the one outside it, but a strong outer layer cannot fix a weak inner one: the firewall still allows normal application traffic, and that traffic is exactly what exploits a vulnerable library in the running container. Options A and C put the controls at the wrong layers, and D describes an inheritance that the model does not give you.

Correct answer: D — Deploy an admission policy that verifies the signature of every pod image against the expected Fulcio certificate identity and OIDC issuer, and rejects images that fail.

Signing produces evidence; something still has to check that evidence at the moment a pod is created. That check belongs in an admission controller, such as the Sigstore policy-controller or a Kyverno image verification policy, matching the certificate identity and OIDC issuer recorded in Rekor. Without it nothing in the cluster looks at signatures at all. The kubelet does not verify Cosign signatures, so imagePullPolicy changes nothing. Verifying in the pipeline only covers images the pipeline built, not what a developer deploys by hand. A private registry controls who can push, but it does not prove at deploy time that a given image was signed.

Correct answer: C — A LimitRange that sets default and defaultRequest for memory in the namespace.

A LimitRange is the only object that injects values into a pod that did not declare them: default sets the limit and defaultRequest sets the request, so a forgetful developer still gets a bounded container. A ResourceQuota caps the total for the namespace, but if it sets limits.memory then pods without a memory limit are rejected outright rather than defaulted, which is a different behaviour from the one asked for - in practice you use both together. B only changes who gets evicted first when a node is already under pressure, it does not cap anything. D controls voluntary disruptions such as drains and has no effect on memory pressure evictions.

Correct answer: D — Set automountServiceAccountToken: false on the pod spec, or on the ServiceAccount the pod uses.

Modern tokens are projected volumes: they are bound to the pod, scoped to an audience, expire after about an hour and are refreshed by the kubelet, which is far safer than the old style. Even so, a workload that never talks to the API should carry no identity at all, and automountServiceAccountToken: false is the one-line way to stop the mount. A fails because the control plane recreates the default ServiceAccount and pods referencing a missing ServiceAccount are rejected. B is the worst option - a Secret-based token never expires and is readable by anyone with get on that Secret. C blocks reachability but the credential still sits on disk and can be exfiltrated and replayed from elsewhere.

Correct answer: C — The cluster runs a CNI plugin that does not implement NetworkPolicy, so the API server stores the object but nothing on the data path enforces it.

NetworkPolicy is only an API object. Enforcement is the job of the network plugin, so a plugin without policy support (plain Flannel is the classic example) accepts the object and silently ignores it. Moving to a policy-capable CNI such as Calico or Cilium, or adding a policy engine beside the current plugin, is the fix. A is wrong because kube-proxy handles Service routing, not policy. B is wrong because RBAC controls who may create the object, not enforcement. D is wrong because Pod Security Admission and NetworkPolicy are unrelated controls.

Correct answer: D — Enabling the NodeRestriction admission plugin alongside Node authorization.

Node authorization decides that a kubelet may work with node-related objects, but the NodeRestriction admission plugin is what narrows those writes to the kubelet's own Node and Pod objects and blocks a kubelet from setting labels it must not control, including labels with the node-restriction.kubernetes.io/ prefix. A is the common trap: the Node authorizer alone does not stop a kubelet from touching another Node object. B breaks kubelets, since they legitimately need to update their own node status, and RBAC cannot express per-node ownership. C only affects pod security fields at admission and has nothing to do with Node objects.

Correct answer: C — Search the audit log for events where verb is create and objectRef.resource is cronjobs, daemonsets or mutatingwebhookconfigurations, then read user.username and sourceIPs on each hit.

The audit log is the only record that ties a write to an identity, so filtering on verb=create plus the persistence-friendly resources returns the backdoor object, the user or ServiceAccount that created it, and the source IP - and Metadata level is enough because verb, resource, user and time are all metadata fields. A fails because Kubernetes Events are namespaced, short-lived by default, and describe controller activity rather than who called the API. B fails because the API server's own log does not record per-object create details. D looks for reads of pods, which is reconnaissance, not the creation event the team is hunting.

Correct answer: A, B — With failurePolicy: Fail, every matching API request is rejected until the webhook is healthy, so new Pods cannot be created. · With failurePolicy: Ignore, matching requests are admitted without the check, so the policy is silently bypassed.

failurePolicy decides what the API server does when the webhook call errors or times out. Fail closes the door: matching requests are rejected, which is safe for policy but can take down deployments and, if the rules are too broad, can deadlock the cluster — this is why you scope rules narrowly and exclude critical namespaces with a namespaceSelector. Ignore keeps the cluster running but admits the object unchecked, so a privileged Pod would slip through and nothing obvious tells you it happened. Option C is wrong: there is no queueing, the call has a timeout and then failurePolicy applies. Option D is wrong because admission decisions are not cached. Option E is wrong because only requests matching the webhook's rules are affected.

Correct answer: A — Set --bind-address=127.0.0.1 on kube-scheduler and kube-controller-manager in their static Pod manifests.

Binding to 127.0.0.1 makes both components listen on loopback only, so their serving endpoints are reachable from the node itself and nothing else. This is a one-line change in each static Pod manifest and the kubelet restarts the Pod automatically. Option B is a trap: --port was the old insecure serving port flag and it was removed in Kubernetes 1.23, so the component will fail to start. Option C does not work because static control plane Pods run in the host network namespace, and NetworkPolicy does not govern host network traffic. Option D can work but means writing and maintaining firewall rules on every control plane node, which is far more overhead than one flag.

Correct answer: B — PCI DSS applies. Turn on API server audit logging for access to cardholder data systems, retain the audit history for at least 12 months with the last 3 months immediately available, and make sure the card number is never written into logs.

Card data brings the workload into scope for PCI DSS, which is prescriptive about logging: audit records for access to system components in the cardholder data environment, retention of at least 12 months with the most recent 3 months available for immediate analysis, and no storage of sensitive card data in logs. HIPAA covers protected health information, which this company does not handle. GDPR covers personal data of people in the EU and is about lawfulness, minimisation and subject rights, not a fixed audit retention rule, and it does not require deleting audit logs on request. ISO 27001 is a management standard the company may also certify against, but it does not replace the card scheme requirement here.

Correct answer: A — In the build pipeline, right after the image is built and before the push step, so a non-zero exit code stops the pipeline and the image never reaches the shared registry.

A gate only works where the pipeline can still stop: scanning the built image before the push means a HIGH or CRITICAL finding fails the job and the bad artifact never enters the registry, while --severity HIGH,CRITICAL keeps low-severity noise out of the gate and --ignore-unfixed avoids blocking on issues with no available patch. B detects but never blocks, and finds the problem after production is already running the image. C scans source dependencies only, so it misses vulnerabilities in the base image layers, and gating on LOW and MEDIUM makes the pipeline fail constantly until people disable it. D scans far too late, adds pull and scan time to every pod start, and leaves the vulnerable image sitting in the shared registry.