CNCF / Linux Foundation · Free Practice Questions · Last reviewed May 2026
36 real exam-style questions organised by domain, each with the correct answer highlighted and a plain-English explanation of why it's right — and why the others are wrong.
Under the Pod Security Standards, a developer attempts to deploy a pod with 'privileged: true' in a namespace labeled with 'pod-security.kubernetes.io/enforce=baseline'. What will happen?
The admission controller will reject the pod creation request with an error.
The Baseline policy explicitly prohibits privileged containers, so the Pod Security admission controller blocks the request at admission time and returns an error. Enforcement occurs before the pod is persisted, meaning no workload is scheduled — satisfying the stem's enforced baseline constraint rather than merely warning or auditing the violation.
The pod will run in a restricted sandbox environment automatically.
The pod will be created successfully, but a warning will be logged in the audit log.
The kubelet will automatically strip the 'privileged: true' setting and run the pod safely.
You need to restrict network traffic so that only pods with the label 'tier=frontend' can communicate with pods labeled 'tier=backend' in the same namespace. Which Kubernetes resource should you create?
NetworkPolicy
A NetworkPolicy selects pods via label selectors and enforces ingress rules at the pod level, permitting traffic only from pods labelled tier=frontend to those labelled tier=backend within the namespace. This directly satisfies the stem's requirement for label-based, namespace-scoped traffic restriction, which Kubernetes NetworkPolicy is purpose-built to provide.
Ingress
FirewallRule
Service
You are auditing a Kubernetes cluster and notice that a specific ServiceAccount has been granted the 'impersonate' verb on users. What security risk does this permission introduce?
It automatically generates valid X.509 client certificates for cluster nodes.
It allows the pod to intercept network traffic of other pods on the same node.
It permits the ServiceAccount to bypass the Kubernetes API server and write directly to etcd.
It allows the ServiceAccount to act as any user or service account, leading to privilege escalation.
The `impersonate` verb lets a ServiceAccount assume another identity's privileges via the Kubernetes API, bypassing its own RBAC restrictions. Granting it on users enables full privilege escalation, since the account can act as any user or service account — directly satisfying the risk described in the stem.
An application pod requires read access to secrets in the 'production' namespace. You need to bind a pre-existing ClusterRole named 'secret-reader' to a service account named 'app-sa' in that namespace. Which RBAC resource accomplishes this?
ClusterRoleBinding referencing the Role 'secret-reader'
NamespaceRoleBinding referencing the ClusterRole
RoleBinding referencing the ClusterRole 'secret-reader'
A RoleBinding grants permissions within a single namespace, so binding the existing ClusterRole 'secret-reader' to 'app-sa' in 'production' satisfies the requirement for namespace-scoped secret read access. Unlike a ClusterRoleBinding, which would grant cluster-wide access, this confines the permissions correctly.
ServiceAccountBinding referencing the ClusterRole
You have deployed a NetworkPolicy in a namespace that selects backend pods, defining an 'ingress' rule with a 'from' block. No other NetworkPolicies exist in the namespace. What is the default behavior for traffic from pods not matched by the 'from' selector?
All ingress traffic remains allowed by default.
The policy fails to apply because an egress rule must also be defined.
Only traffic from other namespaces is denied; same-namespace traffic is still allowed.
All ingress traffic from unmatched pods is denied.
Once a NetworkPolicy selects a pod for ingress, that pod becomes isolated, so only traffic matching a 'from' selector is permitted. Connections from unmatched pods are therefore denied by default, even though no other policies exist.
A security engineer wants to apply Pod Security Standards globally across an entire namespace using the modern built-in admission mechanism. Which approach should be used?
Create a MutatingWebhookConfiguration that injects security contexts into every pod spec.
Apply labels such as 'pod-security.kubernetes.io/enforce=restricted' to the namespace metadata.
Pod Security Admission is built into the API server and enforces Pod Security Standards per namespace via labels such as pod-security.kubernetes.io/enforce. Labelling namespace metadata applies the restricted profile globally across that namespace, satisfying the stem's modern built-in mechanism requirement.
Modify the kubelet configuration file on every worker node to enable restricted mode.
Deploy a custom PodSecurityPolicy object targeting the namespace selector.
Want more Kubernetes Security Fundamentals practice?
Practice this domainUnder the cloud native shared responsibility model, who is responsible for ensuring that the underlying physical servers and hardware security modules (HSMs) are secure and compliant?
The container registry administrator
The application developer
The Kubernetes administrator
The cloud service provider
Under the cloud native shared responsibility model, the cloud service provider owns security of the cloud: physical servers, hardware, and HSMs in its data centres. This satisfies the requirement, as customers cannot secure hardware they do not control.
An enterprise is deploying a zero-trust architecture across their Kubernetes environments. They mandate that all container images must be signed using Cosign and verified at admission time using Kyverno. This technical control directly hardens which of the 4Cs layers?
Code layer
Cloud layer
Container layer
Cosign signing and Kyverno admission verification operate on the image artefact itself, validating its signature and provenance before it runs. This hardens the Container layer of the 4Cs model, which covers image integrity and supply chain trust.
Cluster layer
An administrator is designing a security posture for a microservices application deployed in a Kubernetes cluster. According to the 4Cs of Cloud Native Security, which component falls under the 'Code' layer?
Container base images like Alpine Linux
Application dependency libraries in package.json
Application dependency libraries declared in package.json sit at the Code layer, since the 4Cs model places source code, its dependencies and build artefacts there. This satisfies the stem's constraint: identifying which component belongs to Code rather than Cluster, Container or Cloud, where runtime orchestration and host controls instead reside.
Kubernetes API server authorization policies
Cloud provider IAM roles
A security incident response team discovers that a vulnerability in a third-party Python library allowed remote code execution inside a pod. In the context of defense-in-depth and the 4Cs, which layer primarily failed or was unmitigated, requiring remediation at the source?
Cloud layer
Cluster layer
Container layer
Code layer
The vulnerable Python library executes within the container's application code, so the flaw originates at the Code layer of the 4Cs. Remediation belongs at source: patching or upgrading the dependency, since node, cluster and cloud layers did not introduce the remote code execution flaw.
A security auditor is evaluating a cloud-native deployment. The team states they practice 'shift-left' security. Which of the 4Cs does this practice primarily target?
Container
Cluster
Code
Shift-left security moves testing, scanning and secure coding earlier into development, so it primarily targets the Code layer of the 4Cs. This addresses vulnerabilities at their origin rather than relying on runtime or host controls later in the pipeline.
Cloud
An organization uses AWS IAM to restrict access to their EKS cluster control plane endpoints. According to the shared responsibility model, configuring and maintaining these access entries and cluster RBAC roles is the responsibility of whom?
The Linux kernel maintainers
The cloud provider only
The CNCF security committee
The customer
AWS secures the managed control plane infrastructure, but access entries and Kubernetes RBAC roles governing who may reach that endpoint are customer-configured identity controls. The customer therefore owns this configuration under the shared responsibility model.
Want more Overview OF Cloud Native Security practice?
Practice this domainAn auditor is assessing compliance with NIST SP 800-53 controls for access control (AC) within a managed Kubernetes cluster. Which API object enforces fine-grained authorization decisions directly at the Kubernetes API server?
ValidatingWebhookConfiguration
NetworkPolicy
ClusterRoleBinding
ClusterRoleBinding grants a subject (user, group, or service account) the permissions defined in a ClusterRole across the entire cluster, and the API server's authorisation chain evaluates it for every request, satisfying NIST SP 800-53 AC controls.
ResourceQuota
An enterprise is adopting the Cloud Native Security Framework to map their controls. Which of the 4Cs of Cloud Native Security represents the outermost layer encompassing physical data centers and hardware?
Clusters
Cloud
The Cloud layer is the outermost of the 4Cs, covering the physical data centres, hardware, and underlying infrastructure that hosts everything above it. Controls here address physical security and provider-level protections, forming the foundation beneath clusters, containers, and code.
Code
Containers
According to the CIS Kubernetes Benchmark, anonymous requests to the Kubernetes API server should be disabled. Which kube-apiserver flag enforces this setting?
--authorization-mode=Node,RBAC
--anonymous-auth=false
Setting `--anonymous-auth=false` on the kube-apiserver rejects unauthenticated requests to the API server, satisfying the CIS Kubernetes Benchmark control that requires anonymous access to be disabled. Requests without valid credentials then receive a 401 Unauthorised response rather than being mapped to the `system:anonymous` user and `system:unauthenticated` group.
--enable-admission-plugins
--insecure-port=0
A compliance officer wants to continuously audit Kubernetes resource manifests for misconfigurations against security best practices before they are applied. Which tool type is best suited for this shift-left compliance approach?
Log shippers
Packet analyzers
Static code analysis and admission controllers
Static analysis scans manifests in CI before they reach the cluster, catching misconfigurations at build time, while admission controllers enforce policy at apply time. Together they satisfy the stem's shift-left requirement to audit continuously before resources are applied.
Kernel debuggers
A security team is implementing NIST SP 800-190 guidelines for container runtime security. Which kernel feature is leveraged by container runtimes to restrict system calls and meet least-privilege execution requirements?
Seccomp profiles
Seccomp profiles restrict the system calls a container process may invoke, enforcing least-privilege execution at the kernel level. NIST SP 800-190 recommends this syscall filtering to reduce the container attack surface, satisfying the runtime restriction requirement.
cgroups v2
AppArmor MAC profiles
Namespaces
An auditor notices that kubelet authentication is set to always allow anonymous access in a cluster configuration. According to the CIS Benchmark, what should the kubelet configuration parameter "authentication.anonymous.enabled" be set to?
strict
auto
true
false
Setting `authentication.anonymous.enabled` to false disables unauthenticated requests to the kubelet API, satisfying the CIS Benchmark requirement that anonymous access be eliminated. This closes the exposure the auditor identified, forcing every request to authenticate via client certificates or bearer tokens before the kubelet processes it.
Want more Compliance And Security Frameworks practice?
Practice this domainYou are hardening a production Kubernetes control plane. You need to ensure that etcd client-to-server and peer communications are strictly encrypted in transit and require mutual TLS (mTLS). Which etcd configuration flag combination enforces this requirement?
--auto-tls=true for all endpoints.
--client-cert-auth=true and --peer-client-cert-auth=true along with valid CA and key pair paths.
Setting `--client-cert-auth=true` and `--peer-client-cert-auth=true` forces etcd to verify client and peer certificates against the configured CA, delivering the mutual TLS the stem demands. Supplying the CA and key pair paths enables that verification for both client-to-server and peer traffic, so all control plane communication is encrypted and mutually authenticated.
--insecure-transport=false combined with HTTP proxy routing.
--cipher-suites=TLS_RSA_WITH_AES_128_CBC_SHA
When configuring the Kubernetes API server authorization modes, which mode evaluates requests against Kubernetes RBAC policies?
RBAC
RBAC authorises requests by evaluating them against Role and ClusterRole bindings defined in Kubernetes RBAC policies, satisfying the stem's requirement for the mode that checks RBAC rules. Enabled via the API server's authorization-mode flag, it grants permissions based on subjects, verbs, resources and namespaces.
Webhook
Node
AlwaysAllow
You are auditing the Kubernetes control plane and notice that the API server is configured with an insecure port (--insecure-port=8080). What is the primary security implication of leaving this port enabled?
It bypasses all authentication and authorization modules, granting full administrative access to anyone who reaches the port.
The insecure port serves requests without passing them through authentication or authorization, so any client reaching port 8080 obtains full administrative API access. Disabling it removes this unauthenticated bypass of the control plane's access controls.
It prevents the kubelet from communicating with the control plane nodes.
It restricts API access exclusively to read-only operations.
It forces all clients to downgrade their TLS encryption cipher suites to plaintext.
A security auditor discovers that anonymous authentication is accidentally enabled on the Kubernetes API server, allowing unauthenticated read access to cluster health endpoints. Which API server flag must be modified to disable anonymous requests?
--secure-port=0
--authorization-mode=AlwaysAllow
--anonymous-auth=false
Setting `--anonymous-auth=false` on the kube-apiserver forces every request to present valid credentials, rejecting unauthenticated calls to health endpoints such as `/healthz` and `/livez`. This directly satisfies the auditor's requirement to disable anonymous access, since the flag governs whether requests lacking authentication are treated as the `system:anonymous` user.
--disable-anonymous=true
An administrator needs to restrict kubelets so they can only modify resources associated with their own node (such as their own Node object and Pods bound to them). Which authorization mode must be enabled alongside RBAC?
Node
The Node authorizer grants kubelets permission only for API operations relating to their own node, including their Node object and Pods scheduled there. Enabling it alongside RBAC enforces the node-scoped restriction the stem requires, rather than cluster-wide access.
ABAC
AlwaysDeny
PodSecurity
An administrator needs to secure access to the Kubernetes API server from an external CI/CD pipeline. Which mechanism should be used to authenticate the pipeline using an existing external identity provider without embedding long-lived static tokens?
Store the administrative kubeconfig file in a public ConfigMap.
Configure the API server with --oidc-issuer-url and related flags to validate JSON Web Tokens issued by the IDP.
Configuring the API server with `--oidc-issuer-url` lets it validate JSON Web Tokens issued by the external identity provider, so the CI/CD pipeline authenticates with short-lived, federated credentials rather than embedded static tokens. This directly satisfies the requirement to use an existing external IDP without long-lived secrets.
Enable anonymous requests on the API server for the CI/CD CIDR block.
Create a shared static password file and pass it via --basic-auth-file.
Want more Kubernetes Cluster Component Security practice?
Practice this domainAn auditor is evaluating the Kubernetes control plane attack surface. Which component exposes the primary interface for cluster management and must be protected with strong authentication and authorization?
CoreDNS
kube-proxy
kube-scheduler
kube-apiserver
The kube-apiserver is the sole entry point for control plane operations, serving the REST API that kubectl, controllers and nodes use. Every management request passes through it, so strong authentication and authorisation there protects the entire cluster.
A cluster administrator wants to mitigate supply chain risks stemming from vulnerable base images used by developers. Where in the software lifecycle should vulnerability scanning ideally be integrated first to shift-left security?
Manual inspection of etcd database backups
Configuring kube-dns forwarding rules to external resolvers
Setting up PersistentVolume backup retention policies
CI/CD pipeline build and image registry push stages
Integrating scanning at the CI/CD build and registry push stages catches vulnerable base images before deployment, satisfying the shift-left constraint. This prevents flawed images entering the registry, unlike runtime scanning which detects issues only after workloads are already running.
In a zero-trust Kubernetes architecture, an attacker attempts to exploit the Kubernetes API server via a Server-Side Request Forgery (SSRF) flaw in a poorly written custom controller. Which defense-in-depth mechanism specifically protects against unauthorized API requests originating from inside the cluster network?
Configuring Horizontal Pod Autoscalers to limit request rates
Enabling Pod Security Standards in baseline mode across all namespaces
Mandatory client certificate authentication and rigorous RBAC authorization on API endpoints
Client certificate authentication forces every caller to prove identity cryptographically, and RBAC then authorises each verb on each resource. An SSRF flaw in a controller cannot forge a valid certificate, so requests from inside the cluster network are rejected before reaching API logic.
Disabling the Kubelet read-only port on all worker nodes
A security engineer is analyzing supply chain risks for container images. An unsigned image from an untrusted public registry is pulled into a secure cluster. Which Admission Controller plugin can be leveraged to prevent the deployment of unsigned container images?
NamespaceLifecycle admission plugin
ValidatingAdmissionWebhook executing a policy engine integrated with Cosign image signature verification
A ValidatingAdmissionWebhook calls an external policy engine that verifies Cosign signatures against trusted keys, rejecting any image lacking a valid signature. This enforces the stem's requirement to block unsigned images from untrusted registries before pods are admitted to the cluster.
DefaultStorageClass admission controller
LimitRanger
A developer configures a Kubernetes Pod with `hostNetwork: true`. Under the STRIDE threat model, which threat category is most directly introduced or elevated by this configuration?
Denial of Service via CPU exhaustion
Tampering of container image layers at rest
Elevation of Privilege and Information Disclosure
Sharing the host network namespace removes isolation, letting the Pod sniff node traffic and reach loopback-bound services, which is Information Disclosure. Combined with root or privileged capabilities, it also permits spoofing and bypassing network policy, elevating privilege on the node.
Repudiation of database audit logs
A security team discovers that an application container running as root has successfully mounted the host's Docker socket (`/var/run/docker.sock`). What is the primary attack vector enabled by this misconfiguration?
Bypassing Kubernetes NetworkPolicies across different worker nodes
Direct modification of the etcd database state via local unix socket tunneling
Container escape and full node takeover by orchestrating new sibling containers with host mounts
Mounting the Docker socket grants the container control over the host's Docker daemon, enabling creation of sibling containers with host filesystem mounts. This escapes the container boundary and achieves full node takeover, directly satisfying the stem's root-container-with-socket constraint.
Automatic escalation of RBAC roles assigned to the API server
Want more Kubernetes Threat Model practice?
Practice this domainA security engineer is configuring a seccomp profile for a critical application pod running in a hardened Kubernetes cluster to restrict system calls. The pod requires access to the networking stack but must block module loading. Where must this custom JSON seccomp profile be placed on a worker node running containerd so that it can be referenced via the pod security spec?
/var/log/containers/
/etc/kubernetes/manifests/
/var/lib/kubelet/seccomp/
Placing the profile under /var/lib/kubelet/seccomp/ satisfies the kubelet's default seccomp root path, which is where containerd resolves local profiles referenced by the pod's securityContext. The pod spec then cites it relatively, such as localhost/profiles/block-modules.json, blocking module loading while permitting networking syscalls.
/etc/containerd/certs.d/
When configuring a container to run securely in a Kubernetes cluster, you want to ensure that the container process cannot gain any new privileges during its lifecycle, even if it runs as root or exploits a setuid binary. Which Linux kernel feature should be enabled in the container security context?
readOnlyRootFilesystem: false
allowPrivilegeEscalation: false
Setting `allowPrivilegeEscalation: false` applies the kernel's `no_new_privs` flag to the container process, preventing it from gaining additional privileges through setuid or setgid binaries, file capabilities, or similar mechanisms. This satisfies the stem's requirement that no new privileges can be acquired during the container's lifecycle, even when running as root.
privileged: true
runAsNonRoot: false
You are troubleshooting a container image vulnerability scan report that flagged a high-severity CVE in a base image layer. The development team wants to ensure that vulnerable container images are automatically prevented from being deployed to any namespace in the cluster. Which Kubernetes mechanism should you implement?
Enable resource quotas on the default namespace
Rotate the cluster certificate authority
Add network policies to restrict outbound CVE database queries
Configure a validating admission webhook to inspect image metadata and reject deployments with known CVEs
A validating admission webhook intercepts pod creation requests, queries image metadata against vulnerability data, and rejects any workload whose image contains known CVEs. This enforces prevention cluster-wide at admission time, satisfying the requirement to block deployment automatically.
Your security team has discovered that an application container image contains outdated packages with known remote code execution vulnerabilities. Which phase of the software development lifecycle is the most effective place to initially scan and remediate these vulnerabilities?
Node OS package manager updates
Kubelet container startup phase
CI/CD pipeline build stage
Scanning at the CI/CD build stage catches vulnerable packages before the image is published, so remediation happens once rather than per deployment. This satisfies the requirement to fix outdated packages at the earliest effective point in the lifecycle.
Kubernetes API server audit logging
You are configuring an Ingress resource using the NGINX Ingress Controller to expose a sensitive internal application. To prevent unauthorized clients from connecting, you want to enable mutual TLS authentication at the ingress layer. Which annotation is required in the Ingress resource definition to specify the Kubernetes Secret containing the trusted Client CA certificate?
ingress.kubernetes.io/backend-protocol
nginx.ingress.kubernetes.io/auth-tls-secret
The auth-tls-secret annotation names the Kubernetes Secret holding the trusted Client CA bundle, enabling the NGINX Ingress Controller to verify client certificates during the mutual TLS handshake, satisfying the stem's requirement to authenticate clients at the ingress layer.
kubernetes.io/ingress.class
nginx.ingress.kubernetes.io/ssl-redirect
An organization requires that all container images pulled into a Kubernetes cluster are cryptographically signed and verified before execution. Which tool integrates with Kubernetes admission control to enforce signature verification using Cosign?
Cilium CNI plugin
Metrics-server
Kyverno policy engine
Kyverno acts as a validating admission webhook, evaluating policies against pod specifications and rejecting workloads whose images lack valid Cosign signatures. This enforces cryptographic verification before execution, directly satisfying the stem's requirement that only signed images run in the cluster.
Helm package manager
Want more Platform Security practice?
Practice this domainThe KCSA exam is performance-based — there are no multiple-choice questions. It is a hands-on lab exam completed within 90 minutes. You complete practical tasks in a live or simulated environment. Courseiva practice questions cover the underlying concepts.
Hands-on labs and command-line tasks in a live Kubernetes cluster.
The exam covers 6 domains: Kubernetes Security Fundamentals, Overview OF Cloud Native Security, Compliance And Security Frameworks, Kubernetes Cluster Component Security, Kubernetes Threat Model, Platform Security. Questions are weighted by domain — higher-weight domains appear more on your actual exam.
No. These are original exam-style practice questions written against the official CNCF / Linux Foundation KCSA exam objectives. They are not copied from the real exam. Courseiva focuses on genuine understanding, not memorisation of braindumps.
Courseiva tracks your accuracy per domain and routes you toward weak areas automatically. Free, no account required.