Certified Kubernetes Security Specialist (CKS) Exam Questions

Domain 1: Cluster Setup (15%)

---

Two microservices in the same namespace should only be able to reach each other on their required ports, and neither should be reachable from any other Pod in the cluster by default. What implements this?

⬜ A. A ResourceQuota scoping the namespace
✅ B. NetworkPolicies that default-deny ingress/egress and then explicitly allow only the required Pod-to-Pod traffic
⬜ C. A Horizontal Pod Autoscaler
⬜ D. Labels alone, with no NetworkPolicy objects

Explanation:
NetworkPolicy objects are the mechanism for microsegmentation between Pods; a common CKS pattern is a default-deny-all policy for the namespace, followed by narrowly scoped policies that allow only the specific Pod-to-Pod, port-level traffic a service actually needs.
Why other options are incorrect:
A: A ResourceQuota constrains object counts/compute usage, not network reachability.
C: An HPA scales replicas based on metrics and has no effect on traffic segmentation.
D: Labels are only meaningful to NetworkPolicy when a policy’s selector references them — labels with no policy enforce nothing on their own.
Source: Network Policies

---

During cluster setup, which tool is purpose-built to run automated checks of a cluster’s configuration against the CIS Kubernetes Benchmark?

⬜ A. kubectl top
✅ B. kube-bench
⬜ C. kubeadm upgrade
⬜ D. etcdctl

Explanation:
kube-bench runs the checks defined by the CIS Kubernetes Benchmark against a running cluster’s control-plane and node configuration, flagging any setting that deviates from the recommended hardened baseline — a standard first step when securing a cluster at setup time.
Why other options are incorrect:
A: kubectl top reports resource usage metrics; it has no security-benchmarking capability.
C: kubeadm upgrade performs version upgrades of a kubeadm-managed cluster; it doesn’t audit configuration against CIS controls.
D: etcdctl is etcd’s administrative CLI (snapshots, member management); it doesn’t run benchmark checks.
Source: CIS Benchmarks / kube-bench

---

kube-bench flags a kubelet running with --authorization-mode=AlwaysAllow. Why is this a finding, and what should it be changed to?

⬜ A. It isn’t a real finding — AlwaysAllow is the recommended kubelet setting
✅ B. AlwaysAllow lets any authenticated request to the kubelet API succeed regardless of permissions; it should be set to Webhook so requests are checked against the cluster’s RBAC rules
⬜ C. It should be changed to AlwaysDeny, which blocks all kubelet API access entirely
⬜ D. Authorization mode only affects the API server, not the kubelet, so the finding is a false positive

Explanation:
--authorization-mode=AlwaysAllow on the kubelet bypasses any permission check for requests reaching its API; setting it to Webhook delegates authorization decisions to the API server’s RBAC rules, so a request to the kubelet is only allowed if RBAC actually permits it.
Why other options are incorrect:
A: AlwaysAllow is explicitly the insecure setting CIS benchmarks flag, not the recommendation.
C: AlwaysDeny would break all legitimate kubelet API access, not just unauthorized requests.
D: The kubelet has its own authorization mode setting, independent of the API server’s.
Source: Kubelet authentication/authorization

---

Which practice most directly reduces the risk exposed by leaving the Kubernetes Dashboard deployed on a cluster?

✅ A. Avoid deploying the Dashboard where it isn’t needed, and if it must run, restrict access via RBAC, disable its skip-login option, and expose it only through an authenticated proxy
⬜ B. Deploy the Dashboard with a wildcard ClusterRoleBinding to cluster-admin so any user can self-service
⬜ C. Expose the Dashboard on a NodePort reachable from the public internet for convenience
⬜ D. Disable TLS on the Dashboard to simplify troubleshooting

Explanation:
The Dashboard has repeatedly been a real-world attack vector when left publicly reachable with permissive access; CKS-aligned hardening means minimizing use of GUI elements like this one, and when it is needed, binding it to a least-privilege RBAC identity, disabling anonymous/skip-login access, and fronting it with authenticated, TLS-protected access.
Why other options are incorrect:
B: Binding the Dashboard to cluster-admin is the opposite of least privilege and is exactly how Dashboard compromises escalate to full cluster takeover.
C: A public NodePort removes the network-level barrier that limits who can even reach the login page.
D: Disabling TLS exposes credentials and session data in plaintext over the network.
Source: Kubernetes Dashboard security considerations

---

An administrator is provisioning a new cluster and wants to ensure etcd’s client-to-server and peer-to-peer traffic cannot be read or tampered with on the network. What should be configured?

⬜ A. Nothing — etcd traffic is encrypted by default with no configuration required
✅ B. TLS certificates for both etcd client-server and peer communication
⬜ C. A NetworkPolicy denying all egress from the etcd Pods
⬜ D. Running etcd with --insecure-transport for simplicity

Explanation:
etcd holds the entirety of cluster state, so both its client-to-server API traffic and its inter-member peer traffic must be configured with TLS certificates (--cert-file/--peer-cert-file and related flags) to prevent eavesdropping or tampering on the network.
Why other options are incorrect:
A: TLS for etcd is not automatic — it must be explicitly configured with certificates during cluster setup.
C: A NetworkPolicy can restrict which Pods talk to etcd but does nothing to encrypt or authenticate the traffic itself.
D: --insecure-transport deliberately disables the very TLS protection this scenario requires.
Source: Operating etcd clusters for Kubernetes

---

A Service is exposed externally through an Ingress resource. Which combination best reflects setting up that Ingress with appropriate security control?

✅ A. Terminate TLS at the Ingress with a valid certificate, avoid wildcard/overly broad host rules, and restrict it to only the specific paths and backends it needs to expose
⬜ B. Leave the Ingress on plain HTTP since TLS can always be added later
⬜ C. Route all traffic for every hostname to every Service in the cluster by default, to save configuration effort
⬜ D. Grant the Ingress controller’s ServiceAccount cluster-admin so it can never be blocked by RBAC

Explanation:
An Ingress is often a cluster’s actual internet-facing edge, so CKS-aligned setup means terminating TLS properly, scoping host/path rules narrowly to what should actually be reachable, and never widening the controller’s own permissions beyond what routing requires.
Why other options are incorrect:
B: Plain HTTP exposes traffic (including credentials) in cleartext to anyone on the network path.
C: A catch-all routing rule needlessly exposes every Service, including ones never meant to be public.
D: The Ingress controller only needs permission to read Ingress/Service/Secret objects it manages, not cluster-wide admin rights.
Source: Ingress

---

A Pod running in a cloud-hosted cluster is compromised. The attacker’s process tries to reach 169.254.169.254 from inside the Pod. What is this address, and how should CKS-aligned setup prevent this from being useful to the attacker?

✅ A. It’s the cloud provider’s instance metadata service, which can expose node/IAM credentials; a NetworkPolicy (or metadata-service hardening) should block Pods from reaching it unless explicitly required
⬜ B. It’s a private DNS resolver that all Pods must reach to function, so it should never be restricted
⬜ C. It’s a Kubernetes internal Service IP that only the API server itself may reach
⬜ D. It’s an unused, non-routable address with no security relevance

Explanation:
169.254.169.254 is the well-known link-local address most cloud providers use for their instance metadata service, which can hand back node credentials or IAM role tokens — a classic pivot point after a container compromise. Protecting node metadata and endpoints means blocking unauthenticated or unnecessary Pod access to it, typically via NetworkPolicy or provider-side metadata hardening (e.g. requiring hop-limited/IMDSv2-style access).
Why other options are incorrect:
B: General DNS resolution uses cluster DNS (CoreDNS), not the cloud metadata address.
C: This address belongs to the cloud provider’s metadata service, not a Kubernetes-internal Service.
D: It is very much reachable and has been used in real-world credential-theft incidents — it is not without security relevance.
Source: CNCF Kubernetes Curriculum — Cluster Setup

---

Before installing kubeadm, kubelet, and kubectl binaries on a new node, what should be verified to ensure the downloaded platform binaries haven’t been tampered with?

✅ A. Their checksums/signatures against the official published values before installing them
⬜ B. Nothing — binaries downloaded over HTTPS are automatically trusted and require no further verification
⬜ C. Only the file size, since a matching size guarantees an unmodified binary
⬜ D. The binary’s creation timestamp on disk

Explanation:
“Verify platform binaries before deploying” means checking downloaded kubeadm/kubelet/kubectl (and container runtime) binaries against their official checksums or signatures, so a compromised mirror or a tampered download is caught before it’s ever installed on a node.
Why other options are incorrect:
B: TLS during download only protects transport-layer integrity; it says nothing about whether the source file itself is authentic and untampered.
C: File size can coincidentally or trivially match even for a modified binary — it is not a security verification.
D: A timestamp is metadata about when a file was written locally; it has no relation to the binary’s authenticity.
Source: Installing kubeadm

Domain 2: Cluster Hardening (15%)

---

On a self-managed node, which kubelet flag should be disabled to prevent unauthenticated requests from being treated as an anonymous user with default (often overly broad) permissions?

⬜ A. --read-only-port=10255 left enabled
✅ B. --anonymous-auth=false
⬜ C. --kubeconfig unset
⬜ D. --cgroup-driver=systemd

Explanation:
By default, older kubelet configurations may accept anonymous requests; setting --anonymous-auth=false forces every request to the kubelet API to be authenticated, closing off a well-known avenue for unauthorized node-level access.
Why other options are incorrect:
A: The read-only port (10255) being left enabled is itself a hardening gap, but the option as phrased describes leaving it enabled, not disabling anonymous auth.
C: --kubeconfig configures the kubelet’s own client credentials to talk to the API server; it’s unrelated to anonymous requests reaching the kubelet.
D: --cgroup-driver is a resource-management setting with no bearing on kubelet authentication.
Source: Kubelet authentication/authorization

---

A team wants to grant a CI/CD ServiceAccount permission to create and delete Deployments, but only within the staging namespace, and nothing else. What is the correct, least-privilege RBAC approach?

⬜ A. Bind the ServiceAccount to the built-in cluster-admin ClusterRole
✅ B. Create a Role in the staging namespace with the needed verbs on deployments, and bind it to the ServiceAccount with a RoleBinding in that namespace
⬜ C. Create a ClusterRoleBinding granting the permissions cluster-wide
⬜ D. Add the ServiceAccount to the system:masters group

Explanation:
A namespace-scoped Role listing exactly the needed verbs (e.g. get, list, create, update, delete on deployments) bound via a RoleBinding in the staging namespace grants exactly the access required and nothing more — textbook least privilege, and the core of “use RBAC to minimize exposure.”
Why other options are incorrect:
A: cluster-admin grants unrestricted access to every resource in every namespace, far beyond what’s needed.
C: A ClusterRoleBinding would apply the permission across all namespaces, not just staging.
D: system:masters is a superuser group baked into the API server’s authorization logic and should never be assigned to a workload identity.
Source: RBAC Good Practices

---

By default, every Pod gets a ServiceAccount token mounted into it, even if the application inside never calls the Kubernetes API. What is the recommended hardening step for Pods that don’t need API access?

⬜ A. Leave the default token mounted; unused tokens carry no risk
✅ B. Set automountServiceAccountToken: false on the Pod or its ServiceAccount, and avoid relying on the namespace’s default ServiceAccount for workloads that do need one
⬜ C. Rotate the ServiceAccount token every 5 minutes instead
⬜ D. Grant the default ServiceAccount cluster-admin so any future need is already covered

Explanation:
An auto-mounted token an application never uses is pure attack surface — if the container is compromised, that token can be exfiltrated and used against the API server. “Exercise caution in using service accounts” means disabling auto-mount where it isn’t needed, and creating dedicated, narrowly scoped ServiceAccounts per workload instead of relying on the namespace’s implicit default one.
Why other options are incorrect:
A: An unused, exfiltratable credential is exactly the kind of risk CKS hardening targets — it is not risk-free.
C: Faster rotation reduces the window of misuse but doesn’t address a token that shouldn’t exist in the Pod in the first place.
D: Granting broader permissions to an unused default identity increases risk rather than removing it.
Source: Configure Service Accounts for Pods

---

Which practice best supports “restrict access to Kubernetes API” as part of cluster hardening, beyond RBAC alone?

✅ A. Place the API server behind a network boundary (firewall/security group) that only allows traffic from trusted administrative networks, in addition to RBAC and authentication controls
⬜ B. Expose the API server on a public load balancer with no IP restrictions, relying on RBAC alone
⬜ C. Disable TLS on the API server to simplify client configuration
⬜ D. Grant every authenticated user the view ClusterRole by default so nothing is ever accidentally denied

Explanation:
Cluster hardening layers controls: RBAC decides what an authenticated identity can do, but network-level restrictions (firewalls, security groups, private endpoints) decide who can even reach the API server in the first place — defense in depth rather than relying on any single control.
Why other options are incorrect:
B: Removing IP restrictions widens the attack surface to the entire internet, undermining defense in depth.
C: TLS protects API traffic confidentiality and integrity; disabling it is a direct hardening regression.
D: Granting broad default access to every authenticated identity violates least privilege.
Source: Authenticating to the API server

---

A cluster is still running a Kubernetes minor version that reached end-of-life and no longer receives security patches. From a hardening standpoint, what is the most important remediation?

⬜ A. Add more replicas to compensate
✅ B. Upgrade the cluster to a supported, patched minor version
⬜ C. Increase the RBAC scope of the cluster-admin role
⬜ D. Disable audit logging to reduce noise

Explanation:
An unsupported minor version stops receiving fixes for newly discovered vulnerabilities, so upgrading to a version still within the supported skew is the direct remediation — “update Kubernetes frequently” is a named Cluster Hardening competency for exactly this reason.
Why other options are incorrect:
A: Additional replicas increase capacity, not patch coverage — the vulnerability exists in every replica.
C: Broadening cluster-admin scope increases, not decreases, risk and has nothing to do with patch status.
D: Disabling audit logging removes visibility and does not address the underlying unpatched vulnerability.
Source: Kubernetes Version Skew Policy

---

A user was mistakenly added to the system:masters group instead of being given a scoped Role. Why is this a serious finding during a cluster hardening review?

✅ A. system:masters is a hard-coded superuser identity that bypasses RBAC authorization entirely — it cannot be constrained by any Role or ClusterRole
⬜ B. It’s a low-severity finding since system:masters only grants read access
⬜ C. system:masters only affects that one user’s own namespace
⬜ D. system:masters is simply a naming convention with no special permissions attached

Explanation:
system:masters is recognized directly by the API server’s authorization logic as a superuser group whose requests bypass RBAC checks entirely — membership in it cannot be scoped down by any Role, making it one of the most dangerous group memberships a hardening review can find.
Why other options are incorrect:
B: It grants unrestricted access to every action on every resource, not read-only access.
C: Its authority is cluster-wide, not namespace-scoped.
D: It carries a real, hard-coded authorization bypass — it is not just a label.
Source: Using RBAC Authorization — user-facing roles

---

A newly created namespace still uses its auto-generated default ServiceAccount for several Deployments, none of which call the Kubernetes API. What’s the recommended hardening step, beyond disabling auto-mount?

✅ A. Create purpose-specific ServiceAccounts per workload that actually needs API access, and treat the default ServiceAccount as something workloads should not casually rely on
⬜ B. Grant the default ServiceAccount cluster-admin so every workload in the namespace is covered no matter what it later needs
⬜ C. Delete RBAC entirely for the namespace so there’s nothing to misconfigure
⬜ D. Rename the default ServiceAccount, which alone resolves the underlying risk

Explanation:
Relying on the implicit default ServiceAccount makes it hard to reason about which workload actually needs which permission; creating a dedicated ServiceAccount per workload (bound to only the RBAC it needs) keeps blast radius contained if any single workload is compromised.
Why other options are incorrect:
B: Granting cluster-admin to a shared, implicit identity is the opposite of minimizing exposure.
C: Removing RBAC entirely would leave the API server with no authorization control at all.
D: A rename changes the object’s identity but does nothing about the least-privilege problem of shared, over-scoped ServiceAccounts.
Source: Configure Service Accounts for Pods

Domain 3: System Hardening (10%)

---

A team wants to reduce the attack surface of the underlying host OS that Kubernetes nodes run on. Which action best supports this goal?

✅ A. Run a minimal, purpose-built node OS, remove unnecessary packages and services, and keep only what’s required for the container runtime and kubelet to operate
⬜ B. Install a full desktop environment on every node for easier troubleshooting
⬜ C. Grant every node’s root user password to the whole platform team for convenience
⬜ D. Disable the host firewall so container traffic is never blocked

Explanation:
System hardening starts with minimizing what’s installed and running on the host: a minimal node OS with unnecessary packages, services, and open ports removed shrinks the set of things an attacker who reaches the host can exploit.
Why other options are incorrect:
B: A full desktop environment adds unnecessary packages, services, and listening ports — the opposite of a minimal attack surface.
C: Broadly shared root credentials undermine accountability and least privilege at the host level.
D: Disabling the host firewall removes a network-level control rather than reducing exposed surface.
Source: Kubernetes Security Checklist — Node Security

---

Which Linux kernel-level mechanism restricts what system calls a container’s process is permitted to make, reducing the impact of a container-breakout attempt?

⬜ A. A Kubernetes NetworkPolicy
✅ B. A seccomp profile
⬜ C. A LimitRange
⬜ D. A HorizontalPodAutoscaler

Explanation:
seccomp (secure computing mode) profiles restrict the set of Linux syscalls a container’s process may invoke; Kubernetes can apply a seccomp profile via the Pod’s securityContext.seccompProfile, meaningfully narrowing what a compromised container process can attempt at the kernel level.
Why other options are incorrect:
A: A NetworkPolicy governs network traffic, not syscall access.
C: A LimitRange constrains compute resource requests/limits within a namespace; it has no relation to syscall filtering.
D: A HorizontalPodAutoscaler scales replica count based on metrics; it has no security function.
Source: Restrict a Container’s Syscalls with seccomp

---

Which kernel hardening mechanism uses named profiles to restrict a container’s access to specific files, network operations, and capabilities on the host, and is applied via a Pod’s securityContext on supported Linux distributions?

⬜ A. seccomp
✅ B. AppArmor
⬜ C. NetworkPolicy
⬜ D. PodDisruptionBudget

Explanation:
AppArmor uses per-profile rules (path access, capabilities, network access) attached to a container via securityContext.appArmorProfile (or historically an annotation) to confine what the containerized process can do on the host, complementing seccomp’s syscall-level restrictions.
Why other options are incorrect:
A: seccomp restricts syscalls, not file paths, capabilities, or named profile rules — the two are complementary, not the same mechanism.
C: NetworkPolicy is a Kubernetes-native object for network traffic control, unrelated to AppArmor’s host-level profile mechanism.
D: A PodDisruptionBudget has nothing to do with kernel-level access control.
Source: Restrict a Container’s Access to Resources with AppArmor

---

A node’s instance profile (cloud IAM role) currently grants broad admin-level permissions across the cloud account, though the node only needs to pull from one container registry and write its own logs. What should be done?

✅ A. Scope the node’s IAM role down to only the specific permissions it needs (e.g. registry pull, log write), following least privilege
⬜ B. Leave it as-is — broad IAM roles simplify future changes and should be preferred
⬜ C. Remove the IAM role entirely so the node has no cloud permissions at all, even ones it needs
⬜ D. Share that same broad role across every node and every workload identity for consistency

Explanation:
“Minimize IAM roles” means each node (and workload identity) should hold only the specific cloud permissions it actually needs; a broad admin-level role attached to a node is a major escalation path if that node or a Pod on it is ever compromised.
Why other options are incorrect:
B: Broad roles are precisely what least-privilege hardening seeks to eliminate, not preserve for convenience.
C: Removing all permissions would break the node’s legitimate needs (e.g. pulling images), rather than scoping the role correctly.
D: Sharing one broad role everywhere maximizes blast radius instead of containing it.
Source: CNCF Kubernetes Curriculum — System Hardening

---

Beyond kernel hardening tools, which additional action reduces a node’s exposure at the network layer, in line with “minimize external access to the network”?

✅ A. Close or firewall off unnecessary open ports on the node (including restricting direct SSH access to only what’s required, ideally via a bastion/allow-listed source), rather than leaving the host broadly reachable
⬜ B. Open every port on every node to the internet so troubleshooting is never blocked
⬜ C. Disable the kubelet’s TLS entirely to simplify connectivity
⬜ D. Use the same SSH key across every node and hand it out to the whole engineering org

Explanation:
System hardening extends past the kernel to the node’s network exposure: unnecessary open ports and broadly reachable SSH access both widen what an external attacker can directly reach on the host, so both should be closed off or tightly restricted to trusted sources.
Why other options are incorrect:
B: Opening every port to the internet is the direct opposite of minimizing external network access.
C: Disabling kubelet TLS removes an important confidentiality/integrity control and isn’t a network-exposure fix.
D: A single shared SSH key with broad distribution undermines both least privilege and accountability.
Source: Kubernetes Security Checklist — Node Security

Domain 4: Minimize Microservice Vulnerabilities (20%)

---

An organization wants every Pod deployed in the prod namespace to be denied if it requests privileged mode, host networking, or runs as root. What is the CKS-aligned way to enforce this cluster-wide?

⬜ A. Rely on developers manually reviewing each other’s manifests before every deployment
✅ B. Apply the restricted Pod Security Standard to the namespace via Pod Security Admission (or an equivalent policy engine like Kyverno/OPA Gatekeeper)
⬜ C. Add a comment in the README asking teams not to do this
⬜ D. Set a ResourceQuota limiting the number of Pods in the namespace

Explanation:
Pod Security Admission enforces the built-in restricted Pod Security Standard at the namespace level (via a namespace label), automatically rejecting Pods that request privileged mode, host networking, or root — exactly the kind of “set up appropriate OS-level security domains” enforcement this domain expects, in place of manual review.
Why other options are incorrect:
A: Manual review doesn’t scale and isn’t enforced by the platform — it’s a process, not a control.
C: Documentation has no enforcement mechanism whatsoever.
D: A ResourceQuota limits object counts/compute, not the security posture of the Pods it allows.
Source: Pod Security Standards

---

A cluster needs a custom policy beyond what the built-in Pod Security Standards cover — for example, rejecting any Pod that doesn’t set a specific label required for cost tracking. What kind of tool is designed for this?

⬜ A. A LimitRange
✅ B. A policy engine such as OPA Gatekeeper or Kyverno, enforcing custom admission-time constraints
⬜ C. A HorizontalPodAutoscaler
⬜ D. A PriorityClass

Explanation:
Pod Security Standards cover a fixed set of security-relevant fields; for arbitrary custom rules (required labels, allowed image registries, naming conventions, and more), a general-purpose policy engine like OPA Gatekeeper or Kyverno evaluates admission requests against organization-defined constraints (written as Rego or Kyverno policies).
Why other options are incorrect:
A: A LimitRange only constrains resource requests/limits, not arbitrary custom policy.
C: An HPA handles scaling, not admission-time policy enforcement.
D: A PriorityClass affects scheduling preemption, unrelated to custom policy rules.
Source: OPA Gatekeeper documentation

---

A Pod’s container needs to run as a specific non-root UID and must never be allowed to escalate privileges, even if the image’s Dockerfile specifies USER root. Where should this be enforced?

⬜ A. In the image’s Dockerfile only, since Kubernetes always trusts the image’s declared user
✅ B. In the Pod’s securityContext, setting runAsNonRoot: true, runAsUser, and allowPrivilegeEscalation: false
⬜ C. In a ConfigMap read by the application at startup
⬜ D. In an Ingress annotation

Explanation:
Kubernetes lets the Pod/container securityContext override the image’s declared user and explicitly forbid privilege escalation regardless of what the image itself specifies — this is the enforced control point, not a convention left to the image author.
Why other options are incorrect:
A: Trusting the Dockerfile alone is exactly the gap CKS hardening closes — an image can be built or altered to ignore that convention.
C: A ConfigMap only supplies configuration data to an application; it has no security-enforcement capability.
D: Ingress annotations affect routing/TLS termination at the edge, not container-level identity or privilege settings.
Source: Configure a Security Context for a Pod or Container

---

A container image runs as non-root and can’t escalate privileges, but it still carries Linux capabilities like NET_RAW and SYS_ADMIN that it never actually uses. What further hardens this container’s securityContext?

✅ A. Drop all capabilities by default (capabilities.drop: ["ALL"]) and add back only the specific ones the container genuinely needs
⬜ B. Leave the full default capability set attached, since running as non-root already removes all risk
⬜ C. Add every available capability explicitly so nothing is ever unexpectedly denied
⬜ D. Capabilities can only be managed at the node level, not per-container

Explanation:
Even a non-root, non-escalating process can still abuse unnecessary Linux capabilities (e.g. NET_RAW for packet crafting, SYS_ADMIN for a wide range of privileged operations); dropping all capabilities and explicitly adding back only what’s required is the least-privilege pattern for container capabilities.
Why other options are incorrect:
B: Running as non-root reduces but does not eliminate the risk that unnecessary capabilities present.
C: Adding every capability is the opposite of minimizing exposure and reintroduces powerful, unneeded permissions.
D: Capabilities are configured per-container via securityContext.capabilities, not only at the node level.
Source: Configure a Security Context for a Pod or Container

---

Which Kubernetes object is specifically designed to store sensitive values such as passwords or API keys somewhat more safely than a ConfigMap, and should further be protected with encryption at rest and RBAC restrictions?

⬜ A. A ConfigMap
✅ B. A Secret
⬜ C. A LimitRange
⬜ D. An Endpoint

Explanation:
Secrets are the Kubernetes object intended for sensitive data; on their own they are only base64-encoded (not encrypted), so CKS hardening pairs them with encryption of Secret data at rest in etcd and RBAC rules that limit which identities may read them.
Why other options are incorrect:
A: A ConfigMap is meant for non-sensitive configuration data and has no special handling for confidentiality.
C: A LimitRange constrains resource requests/limits; it stores no application data at all.
D: An Endpoint object tracks the network addresses backing a Service; it isn’t a data-storage object for credentials.
Source: Secrets

---

To prevent Secret data from being readable in plaintext directly from the etcd data store on disk, what should a cluster administrator configure?

⬜ A. Nothing — etcd never persists Secret data to disk
✅ B. Encryption at rest for the Secrets resource, via an EncryptionConfiguration passed to the API server
⬜ C. A NetworkPolicy blocking traffic to etcd
⬜ D. A larger etcd disk volume

Explanation:
By default, Secret data is stored in etcd as base64 (not encrypted); configuring an EncryptionConfiguration resource and passing it to the API server via --encryption-provider-config ensures Secret data is encrypted before being written to etcd’s underlying storage.
Why other options are incorrect:
A: etcd does persist all cluster objects, Secrets included, to disk by default.
C: A NetworkPolicy restricts network reachability to etcd but does nothing about the format the data is stored in on disk.
D: Disk size has no bearing on whether the data stored on it is encrypted.
Source: Encrypting Confidential Data at Rest

---

A workload runs untrusted, third-party code and the team wants stronger isolation than the default container runtime provides, up to and including isolating the workload’s kernel interface from the host kernel. What CKS-aligned control addresses this?

⬜ A. A resource limits.cpu setting
✅ B. A sandboxed runtime (e.g. gVisor or Kata Containers) selected via a Kubernetes RuntimeClass
⬜ C. A PodDisruptionBudget
⬜ D. A HorizontalPodAutoscaler

Explanation:
RuntimeClass lets a Pod opt into an alternate container runtime such as gVisor (a user-space kernel that intercepts syscalls) or Kata Containers (lightweight VM isolation), providing a much stronger isolation boundary than the default shared-kernel container runtime for workloads that can’t be fully trusted — the recommended approach in multi-tenant environments.
Why other options are incorrect:
A: A CPU limit constrains resource consumption; it provides no additional kernel-level isolation.
C: A PodDisruptionBudget protects availability during voluntary disruptions, not workload isolation.
D: A HorizontalPodAutoscaler adjusts replica count based on load; it’s unrelated to sandboxing.
Source: Runtime Class

---

Two microservices exchange sensitive data over the cluster network. Beyond NetworkPolicy segmentation, the team wants the traffic itself encrypted and both sides mutually authenticated at the connection level. What implements this?

✅ A. Mutual TLS (mTLS) between the services, typically provided by a service mesh (e.g. Istio, Linkerd) that automatically encrypts and authenticates Pod-to-Pod traffic
⬜ B. A ResourceQuota on both namespaces
⬜ C. A HorizontalPodAutoscaler shared between the two Services
⬜ D. Renaming both Services to use HTTPS-sounding names

Explanation:
NetworkPolicy controls which Pods may talk to which, but not whether that traffic is encrypted or the identities on each end are verified; mTLS — commonly provided transparently by a service mesh — encrypts Pod-to-Pod traffic and authenticates both sides using certificates, directly implementing “implement pod-to-pod encryption by use of mTLS.”
Why other options are incorrect:
B: A ResourceQuota governs resource/object counts, not traffic encryption.
C: An HPA is a scaling mechanism unrelated to transport security.
D: A Service’s name has no bearing on whether its traffic is actually encrypted.
Source: Istio — Mutual TLS Authentication

---

A Pod definition includes hostPID: true and hostNetwork: true. From a security-hardening standpoint, what is the concern, and what should generally be done?

✅ A. These settings let the container see host processes and use the host’s network namespace directly, significantly widening what a compromised container can reach; they should be avoided unless there’s a specific, justified need and should be blocked by policy otherwise
⬜ B. These settings are purely cosmetic and have no security implication
⬜ C. These settings only affect how the Pod is billed for compute, not its access
⬜ D. These settings are required on every Pod for the cluster to function

Explanation:
hostPID and hostNetwork remove key namespace isolation boundaries between the container and the host, letting a compromised container observe host processes or interact directly with the host’s network stack — Pod Security Standards (baseline/restricted) explicitly disallow these fields, and CKS hardening enforces that via admission policy rather than convention.
Why other options are incorrect:
B: These fields have direct, significant security implications — they are not cosmetic.
C: They affect isolation and access, not billing/metering.
D: The vast majority of workloads run correctly without either field; they are not a general requirement.
Source: Pod Security Standards

---

An organization has multiple teams sharing a single cluster and wants strong isolation guarantees between their workloads without provisioning separate physical clusters for each. What CKS-relevant concept addresses this trade-off directly?

⬜ A. HorizontalPodAutoscaler tuning
✅ B. Multi-tenancy isolation techniques (namespaces + RBAC + NetworkPolicy + resource quotas, and where needed, sandboxed runtimes or virtual clusters)
⬜ C. Increasing the etcd disk size
⬜ D. Disabling RBAC to simplify cross-team access

Explanation:
Kubernetes multi-tenancy is achieved by layering several controls together — namespace-scoped RBAC, NetworkPolicy segmentation, ResourceQuotas, and where isolation needs to be stronger, sandboxed runtimes (RuntimeClass) or dedicated virtual clusters — rather than any single feature providing full tenant isolation on its own.
Why other options are incorrect:
A: HPA tuning addresses scaling behavior, not tenant isolation.
C: etcd disk sizing is a capacity concern unrelated to isolating tenants from one another.
D: Disabling RBAC removes the primary access-control layer and would weaken, not strengthen, multi-tenant isolation.
Source: Multi-tenancy

Domain 5: Supply Chain Security (20%)

---

A cluster administrator wants to restrict which container registries workloads in a cluster are allowed to pull images from, rejecting any Pod that references an untrusted registry. Which mechanism enforces this at admission time?

⬜ A. A NetworkPolicy scoped to egress traffic
✅ B. An admission controller (e.g. ImagePolicyWebhook or a policy engine like OPA Gatekeeper/Kyverno) that validates the image reference against an allow-list of registries
⬜ C. A ResourceQuota on the namespace
⬜ D. A PodDisruptionBudget

Explanation:
Whitelisting allowed registries is an admission-time decision, enforced by an admission controller such as ImagePolicyWebhook or a policy engine (OPA Gatekeeper, Kyverno) with a constraint that rejects any image reference outside an allow-listed set of registries.
Why other options are incorrect:
A: A NetworkPolicy controls Pod-to-Pod and Pod-to-external network traffic; it has no visibility into which registry an image was pulled from.
C: A ResourceQuota limits aggregate compute/object counts in a namespace, not image provenance.
D: A PodDisruptionBudget protects application availability during voluntary disruptions; it plays no role in admission control.
Source: Controlling Access to the Kubernetes API

---

Before deploying a set of Kubernetes YAML manifests to a cluster, a security-conscious pipeline should run which type of check to catch insecure configuration before it ever reaches the API server?

⬜ A. A live penetration test against the running Pods
✅ B. Static analysis of the manifests (e.g. with kubesec, kube-score, or conftest/OPA policies) as a pre-deployment pipeline step
⬜ C. A kubectl get events --watch session after deployment
⬜ D. Manual review of node /var/log files post-deployment

Explanation:
Static analysis tools evaluate manifests (privileged containers, missing resource limits, host namespace usage, and similar) before they’re ever applied, catching insecure configuration at the earliest and cheapest point — the “static analysis of user workloads” practice named directly in the Supply Chain Security domain.
Why other options are incorrect:
A: Penetration testing evaluates a running system; it doesn’t catch problems before manifests are ever deployed.
C: Watching events reacts to what’s already running, not to configuration before deployment.
D: Log review is a post-hoc, reactive check, not a pre-deployment gate.
Source: Kubernetes Security Checklist

---

Which of the following is the most effective way to minimize the vulnerabilities present in a container image before it’s ever deployed?

⬜ A. Add a readinessProbe to the Pod spec
✅ B. Build from a minimal, actively maintained base image, keep it updated, and remove build-time tools/package managers from the final image
⬜ C. Increase the Pod’s memory limit
⬜ D. Add more application replicas

Explanation:
Minimizing the base image’s footprint (using a minimal or distroless base, applying security patches, and not shipping compilers/package managers/shells that aren’t needed at runtime) directly shrinks the number of known CVEs and available attack tools present in the final image.
Why other options are incorrect:
A: A readinessProbe affects traffic routing/health, not what’s present inside the image.
C: A larger memory limit affects resource allocation, not image contents.
D: More replicas increase availability, not image security.
Source: CNCF Kubernetes Curriculum — Supply Chain Security

---

A pipeline needs to fail the build automatically if a container image contains any package with a known Critical-severity CVE. What kind of tool should be integrated into the CI pipeline?

⬜ A. A load testing tool
✅ B. A container image vulnerability scanner (e.g. Trivy or Grype) run against the built image
⬜ C. A DNS resolver
⬜ D. A log aggregator

Explanation:
Image vulnerability scanners inspect an image’s installed packages against known-CVE databases and can be wired into CI to fail the pipeline above a chosen severity threshold, stopping vulnerable images before they’re pushed to a registry — the standard “scan images for known vulnerabilities” control.
Why other options are incorrect:
A: Load testing evaluates performance under load, not package-level vulnerabilities.
C: A DNS resolver has no role in image inspection.
D: A log aggregator collects runtime logs; it doesn’t inspect image contents before deployment.
Source: Trivy documentation

---

An organization wants to guarantee that only images built by their own trusted CI pipeline — and not an image with the same tag pushed by someone else — are ever deployed to production. Which practice most directly supports this?

⬜ A. Always use the :latest tag so the newest image is automatically used
✅ B. Cryptographically sign images at build time and enforce signature verification at admission via a policy controller (e.g. Sigstore/cosign with Kyverno or Gatekeeper)
⬜ C. Rely on the registry’s search feature to manually eyeball image names before deploying
⬜ D. Store all images in a public, anonymous-write registry for convenience

Explanation:
Image signing (e.g. with cosign/Sigstore) at build time, combined with an admission-time policy that rejects any image lacking a valid, trusted signature, is what actually guarantees provenance — it cryptographically ties a deployed image back to the pipeline that built it, closing the gap a naming convention alone can’t close.
Why other options are incorrect:
A: The :latest tag says nothing about who built the image or whether it’s trustworthy — tags are mutable and easily spoofed.
C: Manual name inspection can’t detect a maliciously substituted image with an identical name/tag.
D: An anonymous-write registry makes it trivial for anyone to push a look-alike image, the opposite of provenance guarantees.
Source: Sigstore / cosign documentation

---

A Deployment manifest currently pins its image with a mutable tag (e.g. myapp:v2), which could later be overwritten in the registry to point at different image content. What change makes the reference immutable?

✅ A. Pin the image by its content digest (e.g. myapp@sha256:...) instead of, or in addition to, the tag
⬜ B. Switch to the :latest tag, which is guaranteed never to change
⬜ C. Remove the image reference from the manifest entirely
⬜ D. Pin the image by its file size instead

Explanation:
A tag is just a mutable pointer that can be repushed to reference different image content later; pinning by digest (the content hash) guarantees the exact same image bytes are pulled every time, which matters for both reproducibility and supply-chain integrity.
Why other options are incorrect:
B: :latest is, if anything, the most mutable and frequently overwritten tag in common use.
C: A Deployment without an image reference has nothing to pull and won’t run.
D: File size is not a supported or reliable way to pin image content in Kubernetes.
Source: Image names — digests

---

A team currently pulls all images directly from public Docker Hub with no internal scanning step. What change most directly improves their supply-chain posture?

✅ A. Mirror or proxy approved images through a private, scanning-enabled registry (e.g. Harbor) so every image is scanned and policy-checked before it’s available for deployment
⬜ B. Continue pulling directly from public registries, since public images are inherently trustworthy
⬜ C. Disable image pull authentication so deployments never fail due to registry access issues
⬜ D. Increase the Deployment’s replica count to reduce reliance on any single image pull

Explanation:
Routing images through a private registry with built-in scanning and policy enforcement (Harbor is a common CNCF-hosted choice) gives an organization a consistent choke point to catch vulnerable or non-compliant images before they can be deployed, rather than trusting whatever a public registry currently serves.
Why other options are incorrect:
B: Public images vary enormously in maintenance and trustworthiness and cannot be assumed safe.
C: Disabling pull authentication removes a control rather than adding scanning.
D: Replica count affects availability, not whether the image content itself has been vetted.
Source: Harbor documentation

---

A team wants a machine-readable record of exactly which components, libraries, and versions went into a container image, to support vulnerability tracing later. What artifact should be generated as part of the build?

⬜ A. A kubectl get events dump
✅ B. A Software Bill of Materials (SBOM)
⬜ C. A HorizontalPodAutoscaler manifest
⬜ D. An Ingress resource

Explanation:
An SBOM enumerates every package and dependency (with versions) that make up a built artifact; generating one during the build (e.g. with syft or similar tooling) lets a team later trace which images are affected when a new CVE is disclosed in a specific library.
Why other options are incorrect:
A: An events dump reflects cluster runtime activity, not an image’s build-time component inventory.
C: A HorizontalPodAutoscaler manifest configures scaling behavior and has nothing to do with build provenance.
D: An Ingress resource configures external routing; it carries no information about image contents.
Source: CNCF Kubernetes Curriculum — Supply Chain Security

---

A team is about to adopt a third-party Helm chart from a public chart repository to deploy a component into production. What should they verify before trusting it, beyond simply reading its values.yaml?

✅ A. The chart’s provenance/signature (if published) and the images it references, confirming both come from a trustworthy, verifiable source before installing it
⬜ B. Nothing further — any chart published publicly can be assumed safe to install as-is
⬜ C. Only that the chart’s name doesn’t contain any unusual characters
⬜ D. Only that the chart has a high download count, regardless of its contents

Explanation:
A Helm chart can reference arbitrary images and apply arbitrary RBAC/manifests to a cluster, so checking its provenance (Helm supports chart signing/provenance files) and the images it pulls is part of securing the supply chain, not just the images built in-house.
Why other options are incorrect:
B: Public availability alone says nothing about a chart’s trustworthiness or safety.
C: A chart’s name has no bearing on its actual contents or safety.
D: Popularity is a weak, gameable signal and no substitute for verifying provenance and contents.
Source: Helm — Provenance and Integrity

---

An attacker compromises a CI runner’s credentials and pushes a malicious commit that gets built and deployed automatically, even though every image the pipeline has ever produced passed its vulnerability scan. What supply-chain gap does this expose?

✅ A. The build pipeline itself — its credentials, runner integrity, and who can trigger or approve a deployment — is part of the supply chain and must be secured, not just the resulting image
⬜ B. This scenario is impossible if every produced image passes vulnerability scanning
⬜ C. Vulnerability scanning after the fact would have prevented this regardless of pipeline security
⬜ D. Only the final production cluster’s RBAC matters; the CI system is out of scope for supply chain security

Explanation:
A clean vulnerability scan only says a given image has no known-CVE packages — it says nothing about whether the pipeline that built it was itself compromised. Securing the supply chain has to include the build system: restricting who can trigger builds, protecting CI credentials/runners, and requiring review/approval before a build reaches production, since a compromised pipeline can produce a “clean” but malicious image on demand.
Why other options are incorrect:
B: Compromised CI credentials leading to an unauthorized, automatically-built-and-deployed change is a well-documented real-world attack pattern (e.g. build-system compromises), not a hypothetical impossibility.
C: A vulnerability scan checks known-CVE packages; it has no way to detect a maliciously introduced code change that isn’t a known vulnerability.
D: Cluster-side RBAC doesn’t help if the compromised pipeline has legitimate deploy credentials of its own — pipeline security has to be addressed directly.
Source: CNCF Kubernetes Curriculum — Supply Chain Security

Domain 6: Monitoring, Logging and Runtime Security (20%)

---

A security team wants to detect unusual behavior at runtime — for example, a container unexpectedly spawning a shell or writing to a sensitive host path — as it happens, not after the fact in application logs. Which class of tool is purpose-built for this?

⬜ A. A container image vulnerability scanner
✅ B. A runtime behavioral-analytics/threat-detection tool such as Falco
⬜ C. A HorizontalPodAutoscaler
⬜ D. A NetworkPolicy

Explanation:
Falco (and similar runtime security tools) observes kernel-level events (syscalls) in real time and matches them against rules describing suspicious behavior — an unexpected shell spawned inside a container, a write to a sensitive path, a process making an unexpected outbound connection — alerting as the activity happens.
Why other options are incorrect:
A: An image scanner evaluates a static image before deployment; it has no visibility into live runtime behavior.
C: An HPA reacts to resource metrics for scaling decisions, not behavioral security events.
D: A NetworkPolicy is a preventive network control, not a detection/alerting mechanism for runtime behavior.
Source: Falco documentation

---

Which Kubernetes-native feature records who did what, to which resource, and when, against the API server — essential for after-the-fact incident investigation?

⬜ A. kubectl top nodes
✅ B. Kubernetes audit logging
⬜ C. LivenessProbe results
⬜ D. The Horizontal Pod Autoscaler’s metrics history

Explanation:
Kubernetes audit logging records a structured trail of every request made to the API server — who made it, what verb/resource, and the outcome — configured via an audit policy and audit backend, and is the primary data source investigators use to reconstruct what happened during and after a security incident.
Why other options are incorrect:
A: kubectl top nodes shows point-in-time resource usage, not a historical record of API requests.
C: Liveness probe results reflect container health checks, not who accessed the API and when.
D: HPA metrics history tracks scaling-relevant metrics, not API request auditing.
Source: Auditing

---

The default audit policy logs every request at Metadata level, but the security team wants full request AND response bodies captured specifically for secrets access, without generating that much data for every other resource. What should be configured?

✅ A. An audit policy with a specific rule matching secrets resources set to RequestResponse level, while lower-sensitivity resources stay at a lighter level such as Metadata
⬜ B. Set the entire cluster’s audit level to None so no sensitive data is ever logged
⬜ C. There is no way to vary audit detail by resource type — it’s all-or-nothing
⬜ D. Enable RequestResponse for every resource in the cluster regardless of sensitivity

Explanation:
Kubernetes audit policies support per-rule levels (None, Metadata, Request, RequestResponse) scoped by resource, verb, or namespace, so a policy can capture full request/response bodies for sensitive resources like secrets while keeping lighter, cheaper logging for everything else.
Why other options are incorrect:
B: None disables logging entirely for the matched requests, the opposite of the stated goal.
C: Audit policies are explicitly designed to be scoped per rule/resource, not all-or-nothing.
D: Full RequestResponse logging for every resource generates significant log volume and captures unnecessary detail for low-sensitivity resources.
Source: Auditing — audit policy

---

After a container is deployed, a policy states that its filesystem should not be modifiable at runtime, reducing the chance a compromised process can persist malicious changes. Which Pod setting enforces this?

⬜ A. resources.limits.memory
✅ B. securityContext.readOnlyRootFilesystem: true
⬜ C. restartPolicy: Always
⬜ D. terminationGracePeriodSeconds

Explanation:
Setting readOnlyRootFilesystem: true in the container’s securityContext mounts the container’s root filesystem as read-only, so a compromised process cannot write new files or modify existing binaries/scripts on disk — directly supporting “ensure immutability of containers at runtime.”
Why other options are incorrect:
A: A memory limit constrains resource consumption; it has no effect on filesystem writability.
C: restartPolicy controls what happens when a container exits; it doesn’t make the filesystem immutable while running.
D: terminationGracePeriodSeconds affects shutdown timing, not filesystem mutability.
Source: Configure a Security Context for a Pod or Container

---

An investigator notices repeated, unexpected kubectl exec sessions into a production Pod outside normal deployment hours, followed by outbound connections to an unfamiliar IP. Which type of detection made both of these observable, and what do they together suggest?

✅ A. Runtime behavioral monitoring (e.g. Falco rules on exec events) combined with network/audit visibility surfaced a likely lateral-movement or data-exfiltration attempt, not two unrelated events
⬜ B. Both events are routine and require no further investigation
⬜ C. Only application logs could have shown this, since Kubernetes has no way to observe exec sessions
⬜ D. This pattern can only be detected after the cluster is fully rebuilt

Explanation:
kubectl exec events can be captured both in Kubernetes audit logs and by runtime tools like Falco (which ships default rules for exactly this), and unusual outbound connections following an unexpected exec session is a textbook lateral-movement/exfiltration pattern — correlating the two, rather than viewing them as isolated events, is what “detect all phases of an attack” is about.
Why other options are incorrect:
B: Unexpected interactive access outside normal hours followed by unfamiliar outbound traffic is a strong anomaly, not routine activity.
C: Kubernetes audit logging captures exec sub-resource requests; it is directly observable, not invisible.
D: Detection and investigation should happen without waiting for a full rebuild — that destroys evidence needed for the investigation itself.
Source: Falco documentation

---

During incident response, a compromised Pod is discovered. What should generally happen before the Pod is deleted or the node is rebooted?

✅ A. Preserve evidence — capture logs, a process/memory snapshot if possible, and relevant audit trail — so the incident can be properly investigated, rather than destroying state that the investigation needs
⬜ B. Immediately delete the Pod and move on, since evidence preservation isn’t relevant in Kubernetes environments
⬜ C. Immediately reboot the node to “clean” it before anyone looks at it
⬜ D. Grant the compromised Pod additional permissions so it can be observed more easily

Explanation:
Deleting a compromised Pod or rebooting its node destroys in-memory state, running-process evidence, and often local logs before they can be captured — proper incident response captures that evidence first (or isolates the workload rather than terminating it outright), supporting deep analytical investigation and identification of what actually happened.
Why other options are incorrect:
B: Evidence preservation is a standard, important step in any Kubernetes incident response, not something to skip.
C: Rebooting before investigation destroys volatile evidence the investigation depends on.
D: Granting more permissions to a compromised workload increases risk rather than aiding safe observation.
Source: CNCF Kubernetes Curriculum — Monitoring, Logging and Runtime Security

---

A team wants Kubernetes audit logs correlated with node-level and application logs in a central system, so a security analyst can investigate an incident across all three sources at once. What supports this?

✅ A. Configure an audit backend (e.g. webhook) to forward audit events to a central log aggregation/SIEM system alongside node and application logs
⬜ B. Keep audit logs only on the API server’s local disk with no forwarding, since correlation isn’t possible in Kubernetes
⬜ C. Disable node and application logging so only audit logs need to be reviewed
⬜ D. Manually copy log files between systems once a year

Explanation:
Kubernetes supports a webhook audit backend that forwards audit events to an external system in near real time; routing audit events into the same log aggregation/SIEM platform as node and application logs is what actually enables cross-source correlation during an investigation.
Why other options are incorrect:
B: Leaving logs local and unforwarded prevents exactly the kind of centralized correlation the scenario asks for.
C: Disabling other log sources removes visibility rather than enabling correlation across sources.
D: Infrequent manual copying is far too slow to support timely incident investigation.
Source: Auditing — audit backends

---

A Pod was deployed from an image that passed vulnerability scanning and has readOnlyRootFilesystem: true, yet a runtime tool alerts that a new, unexpected binary appeared inside one of its writable volume mounts. What does this most likely indicate, and what kind of control caught it?

✅ A. Runtime integrity/behavioral monitoring caught a likely compromise or drift from the container’s expected, immutable state — exactly the kind of detection that build-time scanning alone cannot provide
⬜ B. This is expected behavior and requires no investigation, since read-only root filesystem guarantees full immutability everywhere in the Pod
⬜ C. It means the vulnerability scan must have been run incorrectly and should simply be re-run
⬜ D. Writable volume mounts cannot be monitored at runtime, so this alert should be ignored

Explanation:
readOnlyRootFilesystem only protects the container’s root filesystem — a writable volume mount is still writable, and an unexpected new binary appearing there at runtime is a classic sign of compromise or drift that only runtime monitoring (not a one-time build-time scan) can catch, illustrating why runtime security is a distinct domain from Supply Chain Security.
Why other options are incorrect:
B: A read-only root filesystem does not make writable volume mounts immutable — this is not expected, benign behavior.
C: A clean build-time scan says nothing about what happens to a running container afterward; re-running the scan wouldn’t explain a runtime change.
D: Writable mounts absolutely can and should be monitored at runtime by tools like Falco watching filesystem events.
Source: Falco documentation

---

A platform team wants to proactively verify, before granting access, exactly what a given ServiceAccount is authorized to do against the API — as a preventive check rather than waiting to detect misuse after the fact. Which command/approach supports this?

✅ A. kubectl auth can-i --as=system:serviceaccount:<ns>:<sa> <verb> <resource> to check authorization before an incident, distinct from runtime detection tools that catch misuse after it happens
⬜ B. Reviewing Falco alerts only, since that is the only way to know what a ServiceAccount can do
⬜ C. Waiting for an audit log entry showing misuse, since permissions can’t be checked in advance
⬜ D. Assuming every ServiceAccount has the same permissions as cluster-admin

Explanation:
kubectl auth can-i --as=... is a preventive, RBAC-review tool that answers “what is this identity actually allowed to do” before anything runs — complementary to, and distinct from, detective controls like Falco or audit logs that surface what already happened; CKS expects candidates to be comfortable with both preventive and detective layers.
Why other options are incorrect:
B: Falco reports observed runtime behavior; it doesn’t answer what an identity is authorized to do in advance.
C: RBAC permissions are queryable ahead of time via kubectl auth can-i — waiting for misuse defeats the purpose of a preventive check.
D: Assuming uniform cluster-admin-level access is both inaccurate and the opposite of least-privilege review.
Source: Checking API Access

---

Which statement best captures why “detect threats within physical infrastructure, apps, networks, data, users, and workloads” is framed as a single, cross-cutting competency rather than several separate ones?

✅ A. Real incidents rarely stay confined to one layer — an attacker can pivot through infrastructure, network, or identity weaknesses just as easily as an application bug, so effective detection has to span every layer together
⬜ B. It means only application-level logging is necessary, since Kubernetes secures the rest automatically
⬜ C. It means physical hardware never needs to be considered once workloads are containerized
⬜ D. It means every alert should be routed only to the application development team

Explanation:
A leaked credential (identity), a misconfigured NetworkPolicy (network), an unpatched node (infrastructure), or a vulnerable dependency (application) can each be an entry point, so monitoring and detection are only effective when they cover infrastructure, network, identity, data, and workload layers together, not just the application.
Why other options are incorrect:
B: Kubernetes does not automatically secure or monitor every layer on a team’s behalf; layered monitoring must be deliberately built.
C: Physical/infrastructure security remains relevant even when workloads are containerized — the host and hardware are still part of the attack surface.
D: Different layers typically need routing to the teams who can actually act on them (platform, network, security, application), not a single team regardless of layer.
Source: CNCF Kubernetes Curriculum — Monitoring, Logging and Runtime Security