CKS practice questions and answers
All 60 questions from Full Practice Test 1 for Certified Kubernetes Security Specialist (CKS), with the correct answer and a full explanation for each — including why the other options are wrong. Free to read, no signup.
What this set covers
Questions are weighted to match the official CKS exam guide. The real exam is Hands-on performance-based tasks (count not published; CKA/CKAD guidance states 15-20 tasks) questions in 120 minutes with a pass mark of 67%.
- Cluster Setup9 q · 15%
- Cluster Hardening9 q · 15%
- System Hardening6 q · 10%
- Minimize Microservice Vulnerabilities12 q · 20%
- Supply Chain Security12 q · 20%
- Monitoring, Logging and Runtime Security12 q · 20%
Which statement about Kubernetes Events as a security signal is accurate?
- AEvents are short-lived and incomplete, so they supplement rather than replace audit logs✓
- BEvents are a complete record of all API activity
- CEvents are retained indefinitely by default
- DEvents include the request and response bodies of API calls
Correct answer: A — Events are short-lived and incomplete, so they supplement rather than replace audit logs
Events expire after a short TTL and only cover what controllers choose to emit, so audit logging remains the authoritative record. They are neither complete, permanent, nor inclusive of request and response payloads.
Kubernetes — AuditingWhich registry credential practice is appropriate for Kubernetes nodes pulling from a private registry?
- AAn imagePullSecret scoped to the namespace, or workload identity integration with the registry✓
- BA shared registry password baked into the node image
- CAnonymous pull access enabled on the private registry
- DRegistry credentials committed to the application repository
Correct answer: A — An imagePullSecret scoped to the namespace, or workload identity integration with the registry
Namespaced pull secrets or federated workload identity keep registry credentials scoped and rotatable. Baking a password into node images, enabling anonymous pull, and committing credentials all leak or over-share the secret.
Kubernetes — Pull an image from a private registryWhich securityContext combination best matches the restricted Pod Security Standard for a typical stateless service?
- ArunAsNonRoot true, allowPrivilegeEscalation false, capabilities drop ALL, seccompProfile RuntimeDefault✓
- Bprivileged true with hostNetwork true
- CrunAsUser 0 with capabilities add NET_ADMIN
- DhostPID true with allowPrivilegeEscalation true
Correct answer: A — runAsNonRoot true, allowPrivilegeEscalation false, capabilities drop ALL, seccompProfile RuntimeDefault
That combination is exactly what the restricted profile requires: non-root, no escalation, no capabilities, and the default seccomp filter. The other options request privileged execution, host namespaces, or added capabilities, all of which the profile forbids.
Kubernetes — Pod Security StandardsWhich two RBAC practices reduce risk in a shared cluster? (Select TWO.)
- APrefer namespaced Roles over ClusterRoles when access is confined to one namespace✓
- BAvoid granting wildcard verbs and resources✓
- CBind cluster-admin to every developer group
- DUse the default service account for all workloads with broad permissions
- EGrant escalate and bind verbs widely so teams can self-serve
Correct answer: A, B — Prefer namespaced Roles over ClusterRoles when access is confined to one namespace · Avoid granting wildcard verbs and resources
Scoping to a namespace and avoiding wildcards keep permissions close to what is actually needed. Cluster-admin for developers, broad default service accounts, and handing out escalate and bind all enable privilege escalation.
Kubernetes — RBAC good practicesWhich imagePullPolicy should be avoided with a mutable tag because it can silently run different content across nodes?
- AIfNotPresent combined with a mutable tag such as latest✓
- BAlways combined with an immutable digest
- CNever combined with a preloaded digest-pinned image
- DAlways combined with a versioned release tag
Correct answer: A — IfNotPresent combined with a mutable tag such as latest
With IfNotPresent, a node that already cached an older image for the same mutable tag will keep running it, so different nodes can serve different code. Digest pinning removes the ambiguity entirely, and Always with a versioned tag at least refetches on each start.
Kubernetes — Image pull policyWhich NetworkPolicy configuration establishes a default-deny posture for all ingress traffic in a namespace?
- AA policy with an empty podSelector, policyTypes Ingress, and no ingress rules✓
- BA policy with an empty podSelector and an ingress rule allowing all sources
- CDeleting all NetworkPolicies in the namespace
- DA ResourceQuota limiting the number of Services
Correct answer: A — A policy with an empty podSelector, policyTypes Ingress, and no ingress rules
An empty podSelector selects every Pod in the namespace, and declaring Ingress in policyTypes with no rules means nothing is allowed. Allowing all sources is the opposite, deleting policies restores the permissive default, and quotas do not affect traffic.
Kubernetes — Default deny all ingressA multi-tenant cluster must ensure one tenant's Pods cannot reach another tenant's Pods. Which control implements this?
- ANetworkPolicies per namespace with a default deny and explicit allows using namespace selectors✓
- BSeparate ResourceQuotas per tenant
- CSeparate LimitRanges per tenant
- DDifferent container image registries per tenant
Correct answer: A — NetworkPolicies per namespace with a default deny and explicit allows using namespace selectors
Pod-to-Pod reachability is governed by NetworkPolicies, so a default-deny baseline with explicit selectors is what isolates tenants at the network layer. Quotas and LimitRanges govern resource consumption, and registry choice does not affect traffic.
Kubernetes — Network policiesWhich behaviour should trigger a high-severity runtime alert in a typical production namespace?
- AA shell process starting inside a container that normally runs a single application process✓
- BA container writing to its own log stream
- CA readiness probe succeeding
- DA Deployment scaling from three to four replicas
Correct answer: A — A shell process starting inside a container that normally runs a single application process
An interactive shell in a container that should only run one application process is a classic post-exploitation signal. Log writes, successful probes, and routine scaling are normal operations.
CNCF — Falco rulesA service account token is mounted into every Pod by default, but a workload never calls the Kubernetes API. What should be configured?
- ASet automountServiceAccountToken to false on the Pod or the service account✓
- BDelete the default service account in the namespace
- CGrant the service account the view ClusterRole
- DSet hostNetwork to true
Correct answer: A — Set automountServiceAccountToken to false on the Pod or the service account
Disabling automatic token mounting removes a credential the workload does not need, shrinking what an attacker gains from a container compromise. Deleting the default service account breaks Pod admission, granting view adds unnecessary access, and host networking increases exposure.
Kubernetes — Configure service accountsA cluster must keep an immutable record of who performed each API action. Which feature provides this?
- AAPI server audit logging with an audit policy and a durable log backend✓
- Bkubectl get events
- CContainer stdout logs
- DPrometheus metrics
Correct answer: A — API server audit logging with an audit policy and a durable log backend
Audit logging records the requester, verb, resource, and outcome for API requests according to the configured policy. Events are short-lived and incomplete, container logs cover application output, and metrics are aggregate numbers.
Kubernetes — AuditingWhich kubelet setting prevents unauthenticated access to the kubelet's read-write API?
- ASet authentication anonymous enabled to false and authorization mode to Webhook✓
- BSet readOnlyPort to 10255
- CSet failSwapOn to false
- DSet maxPods to a higher value
Correct answer: A — Set authentication anonymous enabled to false and authorization mode to Webhook
Disabling anonymous authentication and delegating authorisation to the API server via webhook mode is the standard kubelet hardening. Enabling the read-only port exposes data without authentication, and swap and pod limits are unrelated to access control.
Kubernetes — Kubelet authentication and authorizationWhich node hardening practice most directly limits lateral movement from a compromised container?
- ARemove unnecessary packages and services from the node image and disable unused ports✓
- BInstall additional debugging tools on every node
- CAllow SSH from any address for operational convenience
- DRun all workloads as privileged so they behave consistently
Correct answer: A — Remove unnecessary packages and services from the node image and disable unused ports
A minimal node image gives an attacker fewer tools and fewer listening services to pivot through. Extra tooling, open SSH, and privileged workloads all make lateral movement easier.
Kubernetes — Securing a clusterWhich runtime provides stronger workload isolation by running each Pod inside a lightweight virtual machine?
- AKata Containers, selected through a RuntimeClass✓
- Bcontainerd with the default runc handler
- CCRI-O with default settings
- DDocker with host networking
Correct answer: A — Kata Containers, selected through a RuntimeClass
Kata Containers runs Pods in micro virtual machines so the kernel is not shared with the host, and Kubernetes selects it through a RuntimeClass. runc-based runtimes share the host kernel, and host networking removes network isolation rather than adding any.
Kubernetes — Runtime classWhich two steps reduce the attack surface of the Kubernetes API server? (Select TWO.)
- ARestrict network access to the API server endpoint to known ranges or private networks✓
- BKeep the cluster version patched and upgrade regularly✓
- CEnable the insecure port for troubleshooting
- DSet authorization mode to AlwaysAllow
- EDisable TLS to simplify client configuration
Correct answer: A, B — Restrict network access to the API server endpoint to known ranges or private networks · Keep the cluster version patched and upgrade regularly
Limiting who can reach the endpoint and staying patched are two of the highest-value control plane protections. An insecure port, AlwaysAllow authorisation, and disabling TLS each remove a fundamental security control.
Kubernetes — Securing a clusterAn immutable container should never have new binaries written to it at runtime. Which setting enforces this?
- AreadOnlyRootFilesystem set to true, with writable emptyDir volumes only where needed✓
- Bprivileged set to true
- ChostPath mounted at the container root
- DallowPrivilegeEscalation set to true
Correct answer: A — readOnlyRootFilesystem set to true, with writable emptyDir volumes only where needed
A read-only root filesystem prevents an attacker from dropping tools into the container, with narrowly scoped writable volumes for legitimate scratch space. Privileged mode, host mounts, and permitted escalation all increase what an attacker can do.
Kubernetes — Security contextWhich tool scans container images for known vulnerabilities and can be run as a pipeline gate?
- ATrivy✓
- Betcdctl
- Ckube-proxy
- Dkubectl port-forward
Correct answer: A — Trivy
Trivy scans images, filesystems, and manifests for known CVEs and misconfigurations and returns a non-zero exit code for gating. etcdctl administers etcd, kube-proxy handles Service networking, and port-forward tunnels a port.
Trivy — Container image scanningWhich statement about encrypting Secrets at rest in etcd is correct?
- AIt requires an EncryptionConfiguration on the API server, and existing Secrets must be rewritten to be encrypted✓
- BIt is enabled by default in every Kubernetes distribution
- CBase64 encoding of Secret values provides the encryption
- DIt is configured on the kubelet rather than the API server
Correct answer: A — It requires an EncryptionConfiguration on the API server, and existing Secrets must be rewritten to be encrypted
Encryption at rest is configured on the API server, and already-stored Secrets stay in their previous form until they are rewritten. It is not universally on by default, base64 is only an encoding, and the kubelet is not where this is configured.
Kubernetes — Encrypting data at restWhich audit policy level records request metadata plus the request and response bodies?
- ARequestResponse✓
- BMetadata
- CRequest
- DNone
Correct answer: A — RequestResponse
RequestResponse is the most verbose level and captures metadata, the request body, and the response body. Metadata records only who did what and when, Request adds the request body, and None omits the event entirely.
Kubernetes — Audit policyWhich practice most reduces the vulnerability count of a production image?
- AUse a minimal or distroless base image containing only the runtime dependencies✓
- BUse a full server distribution so all tools are available
- CInstall debugging utilities in every image
- DPin the base image to a years-old release for stability
Correct answer: A — Use a minimal or distroless base image containing only the runtime dependencies
Fewer packages means fewer CVEs, which is why minimal and distroless bases dramatically reduce findings. Full distributions and extra utilities add packages, and pinning to a very old base accumulates unpatched vulnerabilities.
Kubernetes — Image best practicesWhich authorization mode should a production cluster use so that permissions are explicitly granted rather than universally allowed?
- ARBAC, optionally combined with Node and Webhook modes✓
- BAlwaysAllow
- CAlwaysDeny only
- DNo authorization mode configured
Correct answer: A — RBAC, optionally combined with Node and Webhook modes
RBAC grants permissions explicitly and is typically combined with the Node authorizer for kubelets and optionally a webhook. AlwaysAllow removes authorisation, AlwaysDeny alone would break the cluster, and leaving it unset is not a secure posture.
Kubernetes — Authorization overviewWhich Ingress configuration reduces exposure of an internal service that must not be reachable from the internet?
- ADo not create an Ingress for it and restrict access with a ClusterIP Service plus NetworkPolicies✓
- BCreate an Ingress with a wildcard host rule
- CExpose it as a NodePort Service on every node
- DUse a LoadBalancer Service with no annotations
Correct answer: A — Do not create an Ingress for it and restrict access with a ClusterIP Service plus NetworkPolicies
An internal service should stay on a ClusterIP with NetworkPolicies restricting which Pods may reach it, and never be published through an ingress controller. Wildcard Ingress rules, node ports, and public load balancers all create external reachability.
Kubernetes — Network policiesWhich mechanism restricts the system calls a container process may make to a defined allowlist?
- AA seccomp profile applied through the Pod's securityContext✓
- BA NetworkPolicy
- CA ResourceQuota
- DA PodDisruptionBudget
Correct answer: A — A seccomp profile applied through the Pod's securityContext
seccomp filters syscalls at the kernel level, and the RuntimeDefault profile or a custom profile can be set in the security context. NetworkPolicies filter traffic, quotas cap resources, and disruption budgets limit evictions.
Kubernetes — Restrict syscalls with seccompWhich practice ensures the image running in production is exactly the one that was scanned and approved?
- AReference images by immutable digest rather than by mutable tag✓
- BAlways deploy the latest tag
- CRebuild the image at deploy time from the source branch
- DAllow the registry to overwrite existing tags
Correct answer: A — Reference images by immutable digest rather than by mutable tag
A digest is a content hash, so pinning to it guarantees identical bits between scan and runtime. Mutable tags, deploy-time rebuilds, and tag overwriting all break the link between what was approved and what runs.
Kubernetes — ImagesWhich practice limits the damage of a stolen service account token?
- AUse short-lived projected service account tokens with an audience and expiry rather than long-lived Secret-based tokens✓
- BCreate a permanent token Secret for each service account
- CShare one service account across all namespaces
- DGrant every service account the edit role
Correct answer: A — Use short-lived projected service account tokens with an audience and expiry rather than long-lived Secret-based tokens
Projected tokens are bound to a Pod, scoped to an audience, and expire, so a leaked token has a small window and narrow use. Permanent token Secrets, shared identities, and broad roles all increase what a stolen credential is worth.
Kubernetes — Service account token volume projectionWhich two signals would help determine whether a compromised Pod exfiltrated data? (Select TWO.)
- AEgress connection records from the Pod to unexpected external destinations✓
- BRuntime alerts for unexpected process execution and file reads in the container✓
- CThe Deployment's revision history
- DThe container image's build date
- EThe namespace's ResourceQuota usage
Correct answer: A, B — Egress connection records from the Pod to unexpected external destinations · Runtime alerts for unexpected process execution and file reads in the container
Outbound connection records and runtime process and file activity are what reveal data leaving the workload. Revision history, image build dates, and quota usage say nothing about exfiltration.
Kubernetes — Security checklistWhich Linux security module can confine a container's file and capability access through a loaded profile referenced by an annotation or security context field?
- AAppArmor✓
- Biptables
- Ccgroups v2
- Dsystemd
Correct answer: A — AppArmor
AppArmor profiles restrict file paths, capabilities, and other operations for a confined process, and Kubernetes can apply a named profile to a container. iptables filters packets, cgroups limit resources, and systemd manages services.
Kubernetes — Restrict container access with AppArmorWhich two static analysis practices apply to Kubernetes manifests in a pipeline? (Select TWO.)
- AReject manifests that request privileged containers or host namespaces✓
- BFail the build when containers omit resource limits or run as root✓
- CAutomatically grant cluster-admin to fix permission errors
- DSkip analysis for manifests in the production overlay
- EDisable admission control because static analysis already ran
Correct answer: A, B — Reject manifests that request privileged containers or host namespaces · Fail the build when containers omit resource limits or run as root
Static analysis catches dangerous specifications before they reach a cluster, and privileged execution and missing limits or root users are the classic checks. Granting cluster-admin, skipping production, and disabling admission control all remove protection rather than adding it.
Kubernetes — Security checklistWhich audit configuration choice keeps the log volume manageable while still capturing sensitive activity?
- AAn audit policy with per-resource rules, such as RequestResponse for Secrets and Metadata for routine reads✓
- BRequestResponse for every request in the cluster
- CNone for all resources
- DMetadata only, with Secrets excluded entirely
Correct answer: A — An audit policy with per-resource rules, such as RequestResponse for Secrets and Metadata for routine reads
A tiered policy records full detail where it matters and minimal detail elsewhere, which is how audit stays both useful and affordable. Logging everything at full detail is expensive and can capture secret material broadly, and excluding Secrets or logging nothing removes the most important signal.
Kubernetes — Audit policyWhich two data sources together give the clearest picture of a suspicious Pod's activity? (Select TWO.)
- AAPI server audit logs showing what the Pod's service account requested✓
- BRuntime security alerts showing what processes ran inside the container✓
- CThe Pod's resource requests and limits
- DThe container image size
- EThe node's kernel version
Correct answer: A, B — API server audit logs showing what the Pod's service account requested · Runtime security alerts showing what processes ran inside the container
Audit logs cover what the workload asked the cluster to do and runtime alerts cover what it did inside the container, which together span both planes. Resource settings, image size, and kernel version are configuration facts rather than activity records.
Kubernetes — AuditingWhich mechanism cryptographically proves that an image was produced by a trusted build system?
- AImage signing and attestation verified at admission✓
- BApplying a Kubernetes label to the Deployment
- CStoring the image in a private registry
- DUsing a longer image tag name
Correct answer: A — Image signing and attestation verified at admission
Signatures and build attestations, checked by an admission policy, provide verifiable provenance. Labels are unverified metadata, a private registry restricts access without proving origin, and tag naming carries no cryptographic meaning.
Sigstore — Signing container imagesWhy should base images be rebuilt and redeployed periodically even when application code has not changed?
- ABecause newly disclosed vulnerabilities in base image packages are only fixed by rebuilding on a patched base✓
- BBecause Kubernetes expires images after 30 days
- CBecause image digests change automatically over time
- DBecause the scheduler prefers newer images
Correct answer: A — Because newly disclosed vulnerabilities in base image packages are only fixed by rebuilding on a patched base
An unchanged image accumulates vulnerabilities as CVEs are published against its packages, so periodic rebuilds on a patched base are the remedy. Kubernetes does not expire images, digests are immutable, and the scheduler does not consider image age.
Kubernetes — ImagesWhich two measures protect etcd in a self-managed cluster? (Select TWO.)
- ARequire client certificate authentication and TLS for all etcd connections✓
- BEnable encryption at rest for Secrets in the API server's encryption configuration✓
- CExpose etcd on a public interface for easier maintenance
- DAllow anonymous read access to etcd for monitoring
- EDisable etcd backups to reduce data copies
Correct answer: A, B — Require client certificate authentication and TLS for all etcd connections · Enable encryption at rest for Secrets in the API server's encryption configuration
Mutual TLS restricts who can talk to etcd, and API server encryption at rest means Secret values are not stored in plaintext. Public exposure and anonymous access hand the cluster's entire state to an attacker, and disabling backups trades recoverability for nothing.
Kubernetes — Encrypting Secret data at restWhich two practices help ensure security telemetry survives a compromise of a worker node? (Select TWO.)
- AShip logs off the node to a central, access-controlled backend in near real time✓
- BRestrict who can modify or delete the log backend's data✓
- CKeep logs only on the node's local filesystem
- DGive every workload write access to the log store
- EDisable audit logging when disk usage grows
Correct answer: A, B — Ship logs off the node to a central, access-controlled backend in near real time · Restrict who can modify or delete the log backend's data
Getting logs off the compromised host quickly and protecting the destination are what keep evidence intact. Local-only logs are deleted by an attacker, broad write access lets logs be tampered with, and disabling audit logging removes the record when it matters most.
Kubernetes — AuditingWhich RBAC review command shows whether a specific service account may delete Pods in a namespace?
- Akubectl auth can-i delete pods --as=system:serviceaccount:ns:sa -n ns✓
- Bkubectl get rolebindings -A
- Ckubectl describe pod
- Dkubectl api-versions
Correct answer: A — kubectl auth can-i delete pods --as=system:serviceaccount:ns:sa -n ns
auth can-i with impersonation evaluates the effective permissions for that identity, which is far more reliable than reading bindings by hand. Listing bindings requires manual correlation, describing a Pod shows its status, and api-versions lists API groups.
Kubernetes — Checking API accessWhich approach keeps application secrets out of the cluster's etcd while still delivering them to Pods?
- AAn external secrets manager accessed through a CSI driver or an operator that injects values at runtime✓
- BBase64 encoding the secret and committing it to Git
- CStoring the secret in a ConfigMap
- DPassing the secret as a container command-line argument in the manifest
Correct answer: A — An external secrets manager accessed through a CSI driver or an operator that injects values at runtime
An external store with a CSI driver or injecting operator keeps the authoritative secret outside the cluster and delivers it to the Pod at runtime. Committed base64 is plaintext to anyone with repository access, ConfigMaps are not for sensitive data, and command-line arguments are visible in the manifest and process list.
Kubernetes — Secrets Store CSI driverWhich configuration ensures audit events are not lost if the audit log backend is temporarily unavailable?
- AA webhook backend with buffering and appropriate batch settings, plus a local log backend as a durable fallback✓
- BDisabling audit logging when the backend is down
- CSetting all audit rules to level None
- DWriting audit events to an emptyDir volume
Correct answer: A — A webhook backend with buffering and appropriate batch settings, plus a local log backend as a durable fallback
Buffered delivery plus a durable local log means transient backend outages do not silently drop events. Disabling auditing and setting every rule to None stop recording entirely, and an emptyDir volume disappears with the Pod.
Kubernetes — Audit backendsA workload needs one specific Linux capability, NET_BIND_SERVICE, and nothing else. Which securityContext expresses this correctly?
- Acapabilities: drop [ALL], add [NET_BIND_SERVICE]✓
- Bprivileged: true
- Ccapabilities: add [ALL]
- DrunAsUser: 0 with no capability configuration
Correct answer: A — capabilities: drop [ALL], add [NET_BIND_SERVICE]
Dropping all capabilities and adding back exactly one gives the process the minimum kernel privilege it needs. Privileged mode grants everything, adding ALL is the opposite of least privilege, and running as root without capability configuration keeps the default set.
Kubernetes — Set capabilities for a containerA Falco rule fires when a container writes to a directory below /etc. What is the most appropriate first response?
- AInvestigate the alerting Pod and the process that performed the write before deciding to isolate or tune the rule✓
- BImmediately delete every Pod in the namespace
- CDisable the rule so the alert stops
- DRestart the whole cluster
Correct answer: A — Investigate the alerting Pod and the process that performed the write before deciding to isolate or tune the rule
Triage comes first: identify the Pod and process so you can tell a genuine compromise from a legitimate but noisy behaviour that warrants a tuned rule. Mass deletion and cluster restarts destroy evidence and cause outages, and silencing the rule removes the detection.
CNCF — Falco rulesWhich two mechanisms enforce mutual TLS between microservices without changing application code? (Select TWO.)
- AA service mesh sidecar proxy that terminates and originates mTLS✓
- BA mesh policy that requires strict mTLS for the namespace✓
- CA NetworkPolicy allowing traffic on port 443
- DA ResourceQuota on the namespace
- EAn Ingress annotation for TLS passthrough
Correct answer: A, B — A service mesh sidecar proxy that terminates and originates mTLS · A mesh policy that requires strict mTLS for the namespace
Sidecar proxies plus a strict mTLS policy give encryption and workload identity transparently to the application. A NetworkPolicy only permits or denies traffic without encrypting it, quotas govern resources, and ingress annotations concern north-south traffic.
Istio — Mutual TLSWhich Kubernetes upgrade practice reduces the risk of running with known vulnerabilities?
- ATrack supported minor versions and apply patch releases promptly, testing in a non-production cluster first✓
- BStay on the version the cluster was installed with indefinitely
- CUpgrade production first to find problems quickly
- DSkip several minor versions in one step
Correct answer: A — Track supported minor versions and apply patch releases promptly, testing in a non-production cluster first
Staying within supported versions and applying patches after testing keeps known CVEs closed without surprising production. Never upgrading accumulates vulnerabilities, upgrading production first exposes users to regressions, and skipping minor versions is unsupported.
Kubernetes — Version skew policyWhich Kubernetes feature enforces a security profile such as restricted on all Pods created in a namespace?
- APod Security Admission with namespace labels in enforce mode✓
- BA LimitRange in the namespace
- CA ResourceQuota in the namespace
- DA node taint
Correct answer: A — Pod Security Admission with namespace labels in enforce mode
Pod Security Admission reads namespace labels to apply the privileged, baseline, or restricted profile, and enforce mode rejects non-conforming Pods. LimitRanges and quotas govern resources, and taints influence scheduling.
Kubernetes — Pod Security AdmissionWhich admission control approach blocks images from registries other than an approved internal one?
- AA policy engine rule that rejects Pods whose image reference does not start with the approved registry prefix✓
- BA NetworkPolicy denying egress to other registries only
- CA LimitRange on container count
- DA node label restricting scheduling
Correct answer: A — A policy engine rule that rejects Pods whose image reference does not start with the approved registry prefix
Validating admission policy inspects the image reference and rejects non-approved sources before the Pod is created. Egress policy can help defence in depth but does not prevent object creation, and limits and labels do not evaluate image references.
Kubernetes — Admission controlWhich registry configuration prevents an existing image tag from being repointed to different content?
- AImmutable tags enabled on the repository✓
- BAnonymous pull access enabled
- CAutomatic deletion of untagged images
- DA larger storage quota
Correct answer: A — Immutable tags enabled on the repository
Immutable tags reject a push that would overwrite an existing tag, which preserves the meaning of a tag over time. Anonymous pull affects access, untagged cleanup is garbage collection, and quota is capacity.
Kubernetes — Image pull policy and tagsWhich two are valid reasons to avoid mounting the container runtime socket into a Pod? (Select TWO.)
- AIt allows the Pod to start privileged containers on the node✓
- BIt effectively grants root-equivalent access to the host✓
- CIt prevents the Pod from writing logs
- DIt disables the Pod's DNS resolution
- EIt stops the scheduler from placing the Pod
Correct answer: A, B — It allows the Pod to start privileged containers on the node · It effectively grants root-equivalent access to the host
Access to the runtime socket lets a container create arbitrary containers, including privileged ones with host mounts, which is equivalent to owning the node. It has no effect on logging, DNS, or scheduling.
Kubernetes — Pod Security StandardsWhich two controls belong in a CI pipeline to protect the software supply chain? (Select TWO.)
- AScan dependencies and the built image, failing the build above an agreed severity✓
- BSign the built artefact and publish provenance attestations✓
- CAllow builds to pull arbitrary scripts from the internet at build time
- DStore the signing key in the repository so any job can use it
- EDisable branch protection to speed up releases
Correct answer: A, B — Scan dependencies and the built image, failing the build above an agreed severity · Sign the built artefact and publish provenance attestations
Scanning with a failure threshold and signing with provenance are the two controls that make an artefact both assessed and attributable. Fetching arbitrary scripts, committing signing keys, and removing branch protection each open a supply chain attack path.
Which control plane setting should be verified to ensure anonymous requests to the API server are rejected?
- A--anonymous-auth=false on kube-apiserver✓
- B--allow-privileged=true on kube-apiserver
- C--insecure-port=8080 on kube-apiserver
- D--authorization-mode=AlwaysAllow
Correct answer: A — --anonymous-auth=false on kube-apiserver
Disabling anonymous authentication ensures unauthenticated requests are not mapped to the system anonymous user. Allowing privileged containers weakens workload isolation, an insecure port would bypass authentication entirely, and AlwaysAllow disables authorisation.
Kubernetes — AuthenticatingWhich control prevents a workload from reading Secrets belonging to another team in a different namespace?
- ARBAC that grants Secret access only within the workload's own namespace✓
- BA NetworkPolicy denying cross-namespace traffic
- CA LimitRange on the other namespace
- DNode taints on the other team's nodes
Correct answer: A — RBAC that grants Secret access only within the workload's own namespace
Secret access is an API authorisation question, so namespaced RBAC is what enforces the boundary. NetworkPolicies control Pod-to-Pod traffic rather than API reads, and LimitRanges and taints govern resources and scheduling.
Kubernetes — RBACWhich Kubernetes object should hold a TLS certificate and private key used by an Ingress?
- AA Secret of type kubernetes.io/tls✓
- BA ConfigMap
- CAn annotation on the Ingress
- DA PersistentVolume
Correct answer: A — A Secret of type kubernetes.io/tls
TLS Secrets are the designated object for certificate and key material and are referenced by the Ingress tls section. ConfigMaps are for non-sensitive data, annotations are metadata, and PersistentVolumes are storage.
Kubernetes — Ingress TLSWhich admission mechanism allows custom policy such as "images must come from an approved registry" to be evaluated before objects are persisted?
- AA validating admission webhook or a policy engine such as OPA Gatekeeper or Kyverno✓
- BA CronJob that deletes non-compliant Pods afterwards
- CA LimitRange
- DA PodDisruptionBudget
Correct answer: A — A validating admission webhook or a policy engine such as OPA Gatekeeper or Kyverno
Validating admission control rejects non-compliant objects at creation time, which is prevention rather than cleanup. A CronJob deleting Pods afterwards means the workload ran, and LimitRanges and disruption budgets govern resources and evictions.
Kubernetes — Dynamic admission controlWhich two practices reduce the risk of an exposed Kubernetes dashboard or similar admin UI? (Select TWO.)
- ARequire authentication and bind it to a minimally privileged service account✓
- BKeep it off the public internet, reachable only through port-forward or an internal path✓
- CGrant it cluster-admin so it can display everything
- DExpose it through a public LoadBalancer for convenience
- EDisable audit logging around it to reduce noise
Correct answer: A, B — Require authentication and bind it to a minimally privileged service account · Keep it off the public internet, reachable only through port-forward or an internal path
Authentication with least privilege and no public exposure are the two controls that matter for an admin UI. Cluster-admin turns a UI compromise into a cluster compromise, public exposure invites it, and disabling audit logs removes the evidence.
Kubernetes — Securing a clusterWhich Pod Security Standard profile forbids privilege escalation, requires running as non-root, and restricts volume types most tightly?
- Arestricted✓
- Bbaseline
- Cprivileged
- Ddefault
Correct answer: A — restricted
The restricted profile is the hardened standard and enforces non-root execution, no privilege escalation, dropped capabilities, and a limited set of volume types. Baseline blocks only known privilege escalations, privileged is unrestricted, and there is no profile named default.
Kubernetes — Pod Security StandardsWhich practice makes it possible to detect a container that has drifted from its published image at runtime?
- ARuntime monitoring that alerts when new executables appear or are run inside a container✓
- BReading the Deployment manifest
- CChecking the Service selector
- DVerifying the namespace labels
Correct answer: A — Runtime monitoring that alerts when new executables appear or are run inside a container
Drift detection needs a runtime view of what is actually executing, which is what behavioural monitoring provides. Manifests, selectors, and labels describe intended configuration rather than what is running inside the container.
CNCF — FalcoA container is suspected of being compromised. Which first action preserves evidence while containing the incident?
- AApply a NetworkPolicy isolating the Pod, then capture logs and a filesystem snapshot before deleting it✓
- BDelete the Pod immediately so the Deployment recreates it
- CRestart the node
- DScale the Deployment to zero and back
Correct answer: A — Apply a NetworkPolicy isolating the Pod, then capture logs and a filesystem snapshot before deleting it
Isolating first stops further damage while the container is still available for evidence collection. Deleting, rebooting, and scaling all destroy the running state before anything has been captured.
Kubernetes — Security checklistWhich RuntimeClass use case is appropriate for running untrusted third-party workloads on a shared cluster?
- ASchedule those Pods to a sandboxed runtime such as gVisor or Kata through a dedicated RuntimeClass✓
- BRun them privileged so they cannot interfere with other Pods
- CGive them the node's service account
- DDisable seccomp for compatibility
Correct answer: A — Schedule those Pods to a sandboxed runtime such as gVisor or Kata through a dedicated RuntimeClass
A sandboxed runtime interposes an extra isolation boundary between untrusted code and the host kernel, which is the point of RuntimeClass here. Privileged execution, node credentials, and disabled seccomp all weaken the boundary instead.
Kubernetes — Runtime classWhich two are true about a software bill of materials for a container image? (Select TWO.)
- AIt lists the components and versions the image contains✓
- BIt enables rapid impact assessment when a new CVE is published✓
- CIt guarantees the image contains no vulnerabilities
- DIt replaces the need for runtime security controls
- EIt is only useful for operating system packages, not application libraries
Correct answer: A, B — It lists the components and versions the image contains · It enables rapid impact assessment when a new CVE is published
An SBOM is an inventory that makes it possible to answer whether a newly disclosed vulnerability affects an image. It does not certify that an image is vulnerability free, it does not replace runtime controls, and modern SBOM formats cover application dependencies as well as OS packages.
CNCF — Software supply chain securityWhich practice reduces the risk that a compromised Pod can call the cloud provider's metadata endpoint to steal instance credentials?
- ABlock egress to the metadata IP with a NetworkPolicy and use per-workload identity instead of node credentials✓
- BGive every Pod the node's instance role
- CEnable hostNetwork on all Pods
- DDisable NetworkPolicies to simplify troubleshooting
Correct answer: A — Block egress to the metadata IP with a NetworkPolicy and use per-workload identity instead of node credentials
Blocking the metadata address and issuing workload-scoped identities removes the path by which a container inherits the node's cloud permissions. Sharing the node role, host networking, and removing policies all make the exposure worse.
Kubernetes — Network policiesWhich RBAC verbs are particularly dangerous because they allow a user to grant themselves additional permissions?
- Aescalate and bind on roles and rolebindings✓
- Bget and list on pods
- Cwatch on configmaps
- Dpatch on events
Correct answer: A — escalate and bind on roles and rolebindings
escalate lets a principal create a role with permissions beyond its own, and bind lets it attach an existing powerful role, so both are privilege escalation paths. Reading Pods, watching ConfigMaps, and patching events are comparatively low risk.
Kubernetes — Privilege escalation preventionWhich seccomp profile value applies the container runtime's default syscall filter to a Pod?
- Atype: RuntimeDefault in seccompProfile✓
- Btype: Unconfined in seccompProfile
- Cprivileged: true
- DallowPrivilegeEscalation: true
Correct answer: A — type: RuntimeDefault in seccompProfile
RuntimeDefault applies the runtime's curated syscall allowlist, which blocks many dangerous calls with little compatibility risk. Unconfined disables filtering, and the other two settings expand privilege rather than restricting syscalls.
Kubernetes — SeccompWhich two settings reduce a container's ability to affect the host? (Select TWO.)
- ADrop all capabilities and add back only the ones required✓
- BSet readOnlyRootFilesystem to true✓
- CSet hostPID to true
- DMount /var/run/docker.sock into the container
- ERun the container as UID 0
Correct answer: A, B — Drop all capabilities and add back only the ones required · Set readOnlyRootFilesystem to true
A minimal capability set and an immutable root filesystem both constrain what a compromised process can do. Sharing the host PID namespace, mounting the container runtime socket, and running as root each provide a direct path to host compromise.
Kubernetes — Security contextWhich tool checks a cluster against the CIS Kubernetes Benchmark and reports failing controls?
- Akube-bench✓
- Bkube-proxy
- Ckubeadm
- Dkubectl top
Correct answer: A — kube-bench
kube-bench runs the CIS Benchmark checks against control plane and node configuration and reports pass, fail, and warn results. kube-proxy programs Service networking, kubeadm bootstraps clusters, and kubectl top shows resource usage.
CIS Kubernetes Benchmark toolingReady to try it under exam conditions?
Reading answers is not the same as recalling them with a clock running. Take the same 60 questions as a timed mock exam — 120 minutes, no feedback until you submit, then a score broken down by exam domain so you know what to study.
Start the timed CKS test →