CNCF · Free Practice Questions · Last reviewed May 2026
48real 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 wants to detect anomalous process executions in containers without modifying the container images or requiring agents inside containers. Which approach is most suitable?
Configure CRI-O to log all container process starts to syslog.
Deploy Falco as a DaemonSet using eBPF probe to monitor system calls.
Falco on the host can detect container process anomalies without modifying images.
Enable Kubernetes audit logging and parse the logs for process events.
Use OPA Gatekeeper to enforce allowed process lists in pod specs.
An organization uses Kubernetes with multiple namespaces and wants to ensure that containers running as non-root cannot escalate to root via setuid binaries. Which combination of security contexts and Pod Security Standards achieves this?
Use an AppArmor profile to block setuid syscalls.
Apply the 'restricted' Pod Security Standard at the namespace level.
Restricted enforces runAsNonRoot and disallows privileged escalation.
Set 'securityContext.runAsUser: 1000' on each pod spec.
Apply the 'baseline' Pod Security Standard with 'seccompProfile: RuntimeDefault'.
A DevOps engineer notices that a container's stdout logs are not appearing in the `kubectl logs` output. The container runs a legacy application that writes logs to a file inside the container. What is the most efficient way to capture these logs without modifying the application?
Configure the kubelet to rotate logs from the container's filesystem.
Add a sidecar container that reads the log file and outputs to stdout.
The sidecar pattern streams file logs to stdout for kubectl logs.
Use `kubectl cp` to periodically copy logs from the container.
Install a syslog daemon in the container to forward logs.
A security auditor requires that all container images used in the cluster are scanned for vulnerabilities before deployment. The team uses a private registry with image signing. Which solution enforces that only signed and scanned images are deployed?
Use Cosign to sign images and deploy a webhook that verifies signatures.
Cosign admission controller can enforce signature verification at pod creation.
Run Trivy in a CronJob to scan images and update a ConfigMap with allowed images.
Use OPA Gatekeeper to verify that the image comes from the private registry.
Enable Binary Authorization on the cluster to enforce image attestation.
A cluster administrator wants to monitor network traffic between pods for security analysis. Which tool is designed specifically for this purpose and integrates with Kubernetes?
Configure Fluentd to collect network logs from each node.
Use Prometheus to scrape network metrics from kube-proxy.
Run kube-bench to audit network policies.
Deploy Cilium with Hubble for network flow visibility.
Cilium/Hubble provides pod-level network monitoring.
Which TWO actions are effective for detecting and preventing container breakout attempts using runtime security tools?
Set 'securityContext.seccompProfile.type: Unconfined' to allow all syscalls.
Enable Kubernetes audit logging to capture exec commands.
Use PodSecurityPolicy to deny privileged containers.
Deploy Falco with rules that alert on 'syscall' events like 'clone' or 'unshare'.
Falco can detect breakout attempts via syscall monitoring.
Apply a seccomp profile that blocks unneeded syscalls for each container.
Seccomp restricts syscalls, making breakout harder.
Want more Monitoring Logging and Runtime Security practice?
Practice this domainDuring a security audit, you discover that a container running as root inside a pod has been compromised. The pod uses the default service account. Which two measures should you implement to harden the cluster? (Select TWO)
Apply a PodSecurityPolicy that restricts containers from running as root.
Create a new service account with no roles bound and assign it to the pod.
Edit the default service account to set automountServiceAccountToken: false.
Prevents automatic mounting of the default SA token in pods that do not specify a service account.
Set automountServiceAccountToken: false in the pod spec.
Add securityContext: runAsNonRoot: true to the pod spec.
Ensures the container runs as a non-root user, reducing impact of compromise.
A cluster uses Kubernetes v1.24 with Pod Security Admission enabled. The cluster administrator wants to enforce that all pods in the 'production' namespace run with the 'restricted' policy level, but some existing deployments use privileged containers. Which approach ensures that only new pods violating the policy are rejected, while existing pods continue to run?
Patch existing deployments to remove privileged containers, then add the label 'pod-security.kubernetes.io/enforce=restricted' to the namespace.
Add the namespace label 'pod-security.kubernetes.io/enforce=restricted' and leave existing pods unchanged; new pods violating the policy will be rejected.
Correctly enforces the policy on new pods without affecting existing ones.
Create a PodSecurityPolicy that restricts privileged containers and bind it to all service accounts in the namespace.
Set the namespace label 'pod-security.kubernetes.io/enforce=restricted' and use the 'inform' mode to allow existing pods.
A security engineer needs to ensure that all communication between nodes and the control plane is encrypted. Which component must be configured with a TLS certificate to achieve this?
kube-proxy
etcd
kube-scheduler
kube-apiserver
The API server serves HTTPS; configuring its TLS certificate encrypts all communication to/from it.
After a security incident, you need to restrict which pods can communicate with each other in the 'finance' namespace. You want to allow only pods with label 'app: api' to connect to pods with label 'app: db' on TCP port 5432, and deny all other traffic. Which NetworkPolicy should you create?
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db namespace: finance spec: podSelector: matchLabels: app: api ingress: - from: - podSelector: matchLabels: app: db ports: - port: 5432
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db namespace: finance spec: podSelector: matchLabels: app: api egress: - to: - podSelector: matchLabels: app: db ports: - port: 5432
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db namespace: finance spec: podSelector: matchLabels: app: db ingress: - from: - podSelector: matchLabels: app: api
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db namespace: finance spec: podSelector: matchLabels: app: db ingress: - from: - podSelector: matchLabels: app: api ports: - port: 5432
Correctly targets db pods, allows ingress from api pods on port 5432, and implicitly denies all other ingress.
A cluster has been configured with the NodeRestriction admission plugin. A developer tries to create a pod that uses a hostPath volume pointing to /var/log. The pod's nodeSelector is set to 'kubernetes.io/hostname: worker-1'. Which statement is true?
The pod will be created only if the node label matches the nodeSelector; the hostPath volume is irrelevant.
The pod will be rejected because hostPath volumes are not allowed by NodeRestriction.
The pod will be created because NodeRestriction does not restrict hostPath volumes.
NodeRestriction only restricts node self-updates, not hostPath.
The pod will be rejected because the nodeSelector conflicts with the NodeRestriction plugin.
Which THREE of the following are valid methods to secure etcd in a Kubernetes cluster? (Select THREE)
Apply a NetworkPolicy to block traffic to etcd pods.
Use RBAC to restrict access to etcd.
RBAC can limit which users/service accounts can access etcd via the API server.
Enable TLS peer and client authentication.
TLS ensures encrypted communication and mutual authentication.
Expose the etcd client port (2379) to the public internet for monitoring.
Set file permissions on etcd data directory to 700.
Restricts access to the etcd user only.
Want more Cluster Setup and Hardening practice?
Practice this domainA 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.
An attacker exploited a container escape vulnerability. The team wants to mitigate such attacks by restricting containers from accessing the host's kernel capabilities. Which set of capabilities should be dropped from all containers?
SYS_ADMIN, SYS_MODULE, SYS_PTRACE
These capabilities allow kernel module loading, system administration, and process tracing, which can be exploited for escape.
CHOWN, DAC_OVERRIDE, FOWNER
KILL, SETPCAP, SYS_CHROOT
NET_RAW, NET_ADMIN, NET_BIND_SERVICE
Want more System Hardening practice?
Practice this domainA 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
A microservice container needs to perform DNS lookups using TCP rather than UDP. Which Kubernetes security context setting should be configured to allow this?
Add `DAC_OVERRIDE` capability
Add `NET_RAW` capability
TCP DNS may require raw socket access on some configurations.
Add `NET_ADMIN` capability
Add `NET_BIND_SERVICE` capability
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
Want more Minimize Microservice Vulnerabilities practice?
Practice this domainWhich 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 domainYou 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 are configuring Kubernetes audit logging. You want to log all requests to the `secrets` resource in the `kube-system` namespace at the `RequestResponse` level, while logging all other requests at the `Metadata` level. Which audit policy configuration achieves this?
rules: [- level: RequestResponse, resources: [group: '', resources: [*]], - level: Metadata]
rules: [- level: RequestResponse, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: Metadata]
Correct: first rule matches secrets in kube-system with RequestResponse, second rule catches all other requests with Metadata.
rules: [- level: Metadata, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: RequestResponse]
rules: [- level: Metadata, resources: [group: '', resources: [secrets]], namespaces: [kube-system], omitStages: [RequestReceived], - level: RequestResponse]
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, making it appropriate for detecting outbound connections.
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.
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 8 domains: Monitoring Logging and Runtime Security, Cluster Setup and Hardening, 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.