CNCF · Free Practice Questions · Last reviewed May 2026
36real 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.
A security team is hardening a Kubernetes cluster. They need to ensure that all control plane components run with the least privilege. Which approach should they take?
Use seccomp profiles to block privilege escalation syscalls
Apply AppArmor profiles to all control plane pods
Configure control plane containers to run as non-root user and with read-only root filesystem
This directly reduces privileges by avoiding root execution and preventing writes to the filesystem.
Enable PodSecurityPolicy with 'MustRunAsNonRoot' for control plane namespaces
An administrator wants to restrict pods from running as root. Which admission controller should be enabled?
NodeRestriction
AlwaysPullImages
ServiceAccount
PodSecurity
PodSecurity enforces the Pod Security Standards, including 'restricted' profile which prevents running as root.
A cluster has been compromised due to a container running with privileged escalation. The team wants to prevent any container from gaining new privileges. Which configuration should be applied?
Set securityContext.runAsUser: 1000
Set securityContext.readOnlyRootFilesystem: true
Drop all capabilities with securityContext.capabilities.drop: ["ALL"]
Set securityContext.allowPrivilegeEscalation: false
This directly prevents privilege escalation, which is a key security control.
During a security audit, it was found that some pods have access to the host network. How can an administrator restrict host network access for all pods in the cluster?
Set --allow-privileged=false in kubelet configuration
Enable PodSecurity admission controller with baseline or restricted profile
The baseline and restricted profiles forbid host networking, effectively restricting it cluster-wide.
Enable PodSecurityPolicy with 'hostNetwork: false'
Create NetworkPolicies that deny traffic to host network
A DevOps team wants to ensure that all container images are pulled from a trusted registry only. Which cluster-level configuration should be applied?
Configure kubelet with --pod-manifest-path pointing to a whitelist
Enable PodSecurity with restricted profile
Use NetworkPolicy to block traffic to untrusted registries
Enable ImagePolicyWebhook admission controller
ImagePolicyWebhook can reject images from untrusted registries based on external policy.
A developer wants to run a container that needs to modify kernel parameters. What is the secure way to achieve this?
Run the container with privileged: true
Add SYS_ADMIN capability to the container
Use allowedUnsafeSysctls in pod securityContext for safe sysctls like net.ipv4.tcp_syncookies
Namespaced sysctls can be set without full privileges if allowed by the cluster.
Modify kubelet's --sysctl-whitelist to include the needed sysctl
Want more System Hardening practice?
Practice this domain20% of exam · 6 sample questions below
A microservice running as a Deployment in a Kubernetes cluster needs to authenticate to a third-party API using a static API key. Which is the most secure way to store and inject this secret into the container?
Store the API key in a ConfigMap and expose it as an environment variable
Hardcode the API key in the container image
Store the API key in a Kubernetes Secret and mount it as a volume inside the container
Secrets are designed for sensitive data; volume mounts avoid exposure in environment variable listings.
Store the API key in a Kubernetes Secret and expose it as an environment variable
During a security audit, a team discovers that their microservice application, deployed on Kubernetes, is vulnerable to container breakout attacks. The containers run as root and have many Linux capabilities. Which set of Pod Security Standards (PSS) enforcement modes and policies would best mitigate this risk?
Use 'privileged' PSS with Warn mode
Use 'baseline' PSS with Audit mode
Use 'restricted' PSS with Enforce mode
Restricted profile requires non-root and drops all capabilities except net bind service.
Use 'baseline' PSS with Enforce mode
A DevOps engineer wants to ensure that all microservice containers run with a read-only root filesystem to prevent unauthorized writes. What is the simplest way to enforce this at the Pod level?
Set `securityContext.runAsNonRoot: true` in the Pod spec
Mount an emptyDir volume to the container's writable directories
Set `securityContext.readOnlyRootFilesystem: true` in the Pod spec
This directly enforces a read-only root filesystem for all containers in the Pod.
Set `securityContext.privileged: false` in the Pod spec
A security scanner reports that a microservice container image contains a critical vulnerability (CVE-2024-1234) in a system library. The team cannot immediately rebuild the image. What is the most effective temporary mitigation at the Kubernetes level?
Apply a NetworkPolicy to block egress traffic from the Pod
Apply a custom seccomp profile that blocks the vulnerable syscall
Seccomp can filter system calls, directly mitigating exploitation of syscall-related CVEs.
Apply an AppArmor profile to the Pod
Use a PodSecurityPolicy to drop all capabilities
Which TWO of the following are effective measures to minimize the impact of a compromised microservice container in a Kubernetes cluster? (Choose two.)
Set resource limits (CPU/memory) on the container
Resource limits prevent a compromised container from exhausting cluster resources.
Set the container's root filesystem as read-only
Apply a NetworkPolicy that restricts egress traffic to only necessary services
Network policies limit the ability of a compromised container to communicate with other services.
Run the container as root to simplify debugging
Use hostNetwork: true to share the host's network namespace
Which THREE of the following practices help protect microservice applications against supply chain attacks? (Choose three.)
Use images from any public registry for flexibility
Use minimal base images (e.g., distroless or scratch) to reduce attack surface
Smaller images have fewer packages that could contain vulnerabilities.
Always use the latest tag to get the most recent patches
Scan images for vulnerabilities using tools like Trivy or Clair
Regular scanning identifies known CVEs in images.
Enable image verification using digital signatures (e.g., Notary or Cosign)
Signature verification ensures the image hasn't been tampered with.
Want more Minimize Microservice Vulnerabilities practice?
Practice this domain20% of exam · 6 sample questions below
Which TWO of the following are best practices for securing the container supply chain?
Scan images for vulnerabilities in a CI pipeline before deploying.
Scanning helps catch known vulnerabilities early.
Use image signing and verification (e.g., with cosign) to ensure image integrity.
Signing images ensures they have not been tampered with.
Embed API keys directly in container images for authentication.
Allow all images from any registry without verification to speed up development.
Use mutable tags like 'latest' for easier updates.
Which THREE of the following are required to implement a secure software supply chain using Kubernetes native features?
Use vulnerability scanning tools like Trivy or Grype in the CI/CD pipeline.
Scanning prevents deployment of images with known vulnerabilities.
Disable admission controllers to reduce latency in pod creation.
Integrate image signature verification into the admission webhook (e.g., using cosign and Kyverno).
Verification ensures images are signed by trusted parties.
Run all containers as root inside the pod to avoid permission issues.
Enforce policies using OPA Gatekeeper or Kyverno to restrict allowed registries and image constraints.
Policy enforcement ensures only trusted images are used.
A DevOps team wants to ensure that only signed images from a trusted registry are deployed in the cluster. They plan to use a webhook to intercept pod creation. Which tool is best suited for this task?
kubectl with --validate flag
Helm with signed charts
etcd with encryption at rest
Kyverno with a verifyImages rule
Kyverno supports image signature verification via cosign.
Prometheus with alerting rules
A security audit reveals that a container image running in production contains a critical vulnerability (CVE-2024-1234). The image was built from a base image that had the vulnerability. What is the MOST effective long-term solution to prevent such issues?
Use a runtime security tool like Falco to detect exploitation attempts.
Patch the vulnerability by installing a security update inside the running container.
Add an admission controller that rejects images with vulnerabilities.
Rebuild the image using a patched base image and integrate vulnerability scanning into the CI pipeline.
Fixing the base image and scanning prevent vulnerable images from being built.
Switch to a different container runtime that is immune to the vulnerability.
An organization uses a private container registry and wants to ensure that only images built from a specific CI/CD pipeline are deployed. Which combination of measures provides the strongest guarantee?
Implement network policies to restrict egress from pods to the registry.
Grant registry write access only to the CI system's service account.
Use a static analysis tool to check the Dockerfile before building.
Use a unique registry path and restrict access via firewall rules.
Generate signed attestations with in-toto during the CI pipeline and verify them using an admission webhook like Kyverno.
Attestations provide non-repudiation and can be verified at admission time.
You are the lead security engineer for a large financial institution. The organization runs a Kubernetes cluster with 500+ microservices. The supply chain security team has implemented the following measures: (1) All images are built from a minimal base image (distroless) and scanned with Trivy before being pushed to a private registry. (2) Images are signed using cosign with a key stored in a hardware security module (HSM). (3) Kyverno policies enforce that only signed images from the private registry can run, and also enforce that containers run as non-root. (4) A binary authorization (binauthz) style admission controller verifies attestations. Recently, a critical vulnerability (CVE-2024-0001) was discovered in a popular open-source library used by several microservices. The library is included as a dependency in the base image. The vulnerability is remotely exploitable and has a CVSS score of 9.8. The security team needs to remediate this quickly. They have already patched the library and updated the base image. What is the BEST course of action to ensure all running pods use the new image?
Update the image tag in each Deployment's spec to point to the new patched image, then perform a rolling update. The admission controller will verify signatures and attestations for the new image.
This ensures all pods are updated with a verified, patched image in a controlled manner.
SSH into each node, pull the new image, and use kubectl exec to update the library inside running containers.
Temporarily disable the admission controller that verifies signatures and then update the image tags.
Delete all running pods and let the ReplicaSets recreate them from the existing image.
Want more Supply Chain Security practice?
Practice this domain20% of exam · 6 sample questions below
You are investigating a pod that is suspected of being compromised. You need to preserve the container's filesystem for forensic analysis. Which `crictl` command should you use to export the container's filesystem as a tar archive?
crictl logs <container-id>
crictl export <container-id>
Correct: crictl export exports the container's filesystem as a tar archive.
crictl inspect <container-id>
crictl exec <container-id> tar cvf /tmp/fs.tar /
A Falco rule is written to detect when a shell is spawned inside a container. The rule condition is: `spawned_process and container and proc.name = bash`. The rule is not triggering. Which of the following is the most likely reason?
The rule is missing `proc.name in (bash, sh, zsh)` because only bash is checked
Falco is not running with the required syscall capabilities
The `spawned_process` macro may not match because the process was inherited (not spawned), e.g., from an entrypoint
`spawned_process` typically checks for newly created processes; inherited processes may not match.
The priority is set to `ERROR` but the output is being filtered
You have deployed a pod and set `securityContext.readOnlyRootFilesystem: true`. The pod is failing to start with an error about writing to `/tmp`. What is the most likely cause?
The `securityContext` is misspelled
The pod is missing an emptyDir volume mounted at `/tmp`
An emptyDir volume provides a writable location on an otherwise read-only root filesystem.
The container image does not have `/tmp` directory
The container is running as a non-root user
An administrator runs `kubectl exec -it nginx-pod -- sh` and inside the container runs `curl http://example.com`. This succeeds. However, the administrator wants to detect such outbound connections using Falco. Which syscall should Falco monitor to detect this network connection?
open
connect
The `connect` syscall is used to initiate a connection to a remote socket, which is exactly what curl does when making an HTTP request.
execve
bind
You are writing a Falco rule to detect when a container tries to read the file `/etc/shadow`. Which condition in the Falco rule correctly matches this event?
container.name=shadow and evt.type=open
evt.type=read and fd.name=/etc/shadow
proc.name=cat and fd.name=/etc/shadow
evt.type=open and fd.name=/etc/shadow
The open syscall is used to open files, and fd.name contains the file path. This correctly detects attempts to open /etc/shadow.
You are responding to a security incident where a pod named `compromised-pod` in namespace `default` is suspected of being used for cryptocurrency mining. You need to immediately isolate the pod from the network while preserving evidence. Which command sequence should you use?
kubectl cordon <node-of-compromised-pod>
kubectl label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml
Ly identifies the need to label the pod and apply a deny-all NetworkPolicy. The command sequence is impractical (busybox lacks kubectl), but the concept is what the exam tests. In a real scenario, you would label the pod directly and then apply the policy.
kubectl delete pod compromised-pod && kubectl describe pod compromised-pod
kubectl exec compromised-pod -- killall miner-process
Want more Monitoring, Logging and Runtime Security practice?
Practice this domainA team needs to set up a highly available Kubernetes control plane across three availability zones. What is the minimum number of etcd members required to achieve fault tolerance against one zone failure?
5
1
3
3 members tolerate one member failure, maintaining majority.
7
A security audit reveals that the kube-apiserver is using the default insecure port 8080 on a production cluster. Which is the most secure and recommended remediation?
Change the --insecure-port flag to 0
Set --insecure-port=0 and ensure --secure-port=6443 is configured
Setting insecure-port to 0 disables it, and secure-port=6443 uses TLS.
Set --insecure-port=6443
Set --secure-port=8080
During a cluster upgrade, the kubelet on a worker node fails to start after updating the kubelet binary. The kubelet logs show: 'failed to load bootstrap client certificate: open /var/lib/kubelet/pki/kubelet-client-current.pem: no such file or directory'. What is the most likely cause?
The kubelet's node IP has changed
The kubelet's certificate has expired
The kubelet is using an outdated kubeconfig
The bootstrap kubeconfig file is missing or misconfigured
The bootstrap kubeconfig is used to initially request a client certificate; missing file leads to this error.
Which TWO of the following are valid methods to secure the etcd cluster in a Kubernetes setup?
Enable encryption at rest for etcd data
Configure RBAC on etcd
Enable TLS with peer certificates for etcd member communication
Peer certificates secure inter-etcd communication.
Enable TLS with client certificates for etcd client communication
Client certificates secure communication between API server and etcd.
Apply NetworkPolicies to etcd pods
Which THREE of the following are required when setting up a Kubernetes control plane with kubeadm for a production environment?
Ensure the Kubernetes version is not downgraded
kubeadm prevents downgrading.
Specify --pod-network-cidr to define the pod network range
Required for pod networking.
Specify --control-plane-endpoint for high availability
Required for HA control plane setup.
Specify --apiserver-advertise-address
Generate a bootstrap token with kubeadm token create
A cluster is using kubeadm and the control plane components are running as static pods. Where are the static pod manifests for the API server located by default?
/var/lib/kubelet/
/etc/kubernetes/manifests/
Default static pod manifest directory.
/etc/kubernetes/admin.conf
/etc/kubernetes/
Want more Cluster Setup practice?
Practice this domainA security team wants to ensure that all pods in a namespace run with a restricted seccomp profile. Which Pod Security Standard admission controller mode should be used to enforce this without blocking necessary pods?
Enable the PodSecurity admission plugin with the 'restricted' policy and 'enforce' mode
'enforce' blocks non-compliant pods, and 'restricted' requires seccomp.
Use a mutating admission webhook to automatically add seccomp profiles
Enable the PodSecurity admission plugin with the 'baseline' policy and 'enforce' mode
Enable the PodSecurity admission plugin with the 'restricted' policy and 'warn' mode
A cluster uses RBAC and a ServiceAccount 'monitor' in namespace 'observability'. The account needs to list pods in all namespaces. Which ClusterRole and binding should be created?
Role with 'list' on pods, RoleBinding in observability
ClusterRole with 'get' on pods, ClusterRoleBinding
ClusterRole with 'list' on pods, RoleBinding in observability
ClusterRole with 'list' on pods, ClusterRoleBinding
Correct scope and verb for listing pods across all namespaces.
An administrator wants to prevent pods from running as root. Which SecurityContext field should be set at the pod level?
fsGroup: 2000
runAsGroup: 3000
runAsUser: 1000
runAsNonRoot: true
Explicitly prevents root.
A company uses kube-bench to scan their cluster. The report shows a warning: 'Ensure that the --authorization-mode argument is set to Node,RBAC'. What is the best way to fix this?
Add --authorization-mode=AlwaysDeny to the API server
Restart the API server with --authorization-webhook-config-file
Set --authorization-mode=RBAC only
Edit the kube-apiserver manifest to add --authorization-mode=Node,RBAC
Sets both Node and RBAC as required.
A pod is failing to start with: 'Error: container has runAsNonRoot and image will run as root'. The pod spec sets securityContext.runAsNonRoot: true. The container image is 'nginx:latest' which runs as root. Which change allows the pod to run while maintaining security?
Remove runAsNonRoot: true
Add a PodSecurityPolicy that allows root
Set runAsUser: 1000 in the container securityContext
Runs as non-root user, satisfying runAsNonRoot.
Use a mutating webhook to change the image
Which Kubernetes resource should be used to restrict egress traffic from pods?
NetworkPolicy with egress rules
Directly restricts egress.
PodSecurityPolicy
iptables rules on nodes
NetworkPolicy with ingress rules
Want more Cluster Hardening practice?
Practice this domainThe CKS exam is performance-based — there are no multiple-choice questions. It is a hands-on lab exam completed within 120 minutes. You complete practical tasks in a live or simulated environment. Courseiva practice questions cover the underlying concepts.
Hands-on Kubernetes security tasks in a live cluster environment.
The exam covers 6 domains: System Hardening, Minimize Microservice Vulnerabilities, Supply Chain Security, Monitoring, Logging and Runtime Security, Cluster Setup, Cluster Hardening. 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 CKS 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.