Certified Kubernetes Security Specialist Free Practice Questions
This practice bank covers 15 questions focusing on foundational Kubernetes security topics for the CKS exam. It exercises knowledge of control plane components, network policies, container hardening, RBAC, service accounts, secrets, image signing, etcd security, admission controllers, namespace isolation, API server protection, host network risks, and audit logging. Use this set to reinforce your understanding of key security decisions and configurations. It is not the official exam blueprint but a targeted review of common security patterns.
What this CKS practice set measures
This is an analysis of the practice bank, not a claim about the vendor's live exam blueprint. Use it to identify the knowledge, judgment, and recall patterns exercised here, then verify your coverage against the current official exam guide.
Control Plane & API Security
The practice bank emphasizes that the kube-apiserver is the central component for validating and configuring cluster state. Protecting it requires short-lived client certificates and network restrictions. Etcd, which stores all cluster data, must be secured with client certificate authentication and encryption at rest. Audit logging records all API requests and is essential for detecting unauthorized changes. The NodeRestriction admission controller helps prevent privilege escalation on nodes. Understanding these components' security roles is critical.
- kube-apiserver validates and configures cluster state
- Protect API server with short-lived certificates and source IP restrictions
- etcd requires client certificate auth and encryption at rest
- Audit logs record all API requests for forensic analysis
- NodeRestriction prevents kubelet privilege escalation
Pod & Container Hardening
The practice bank addresses reducing container breakout impact by enabling read-only root filesystems. This limits attackers from modifying binaries or configurations. PodSecurity admission controllers enforce standards like run-as-non-root and restricted capabilities. Avoiding host network namespace is recommended; using dedicated pod networks with NetworkPolicy provides controlled ingress/egress. These measures implement least privilege at the container and pod level.
- Read-only root filesystem limits persistence after breakout
- PodSecurity admission enforces security context standards
- Avoid host network namespace; use NetworkPolicy for isolation
- Dedicated service accounts minimize permission scope
- Secrets should be mounted as files or env vars, not in images
Network Policies & Access Control
The practice bank covers NetworkPolicy resources that define allowed communication between pods using label selectors. This enables micro-segmentation. For access control, Roles and ClusterRoles define actions on resources (verbs, resources, API groups). Default service accounts often have broader permissions than needed; dedicated service accounts limit blast radius. ImagePolicy webhook ensures only signed images from approved registries are deployed, enhancing supply chain security.
- NetworkPolicy specifies ingress/egress rules using labels
- Role/ClusterRole define actions on API resources
- Avoid default service accounts; use minimal-scope dedicated ones
- ImagePolicy webhook enforces signed images and registry restrictions
- Namespaces provide logical isolation for RBAC and network policies
Secrets Management & Monitoring
Sensitive configuration should be injected using Kubernetes Secrets mounted as environment variables or volumes, keeping data out of image layers. For monitoring, periodic review of audit logs detects unauthorized changes to critical components. The practice bank highlights that audit logging records all requests to the API server, providing a trail for security analysis. Namespace isolation via RBAC and network policies further contains sensitive workloads.
- Use Secrets mounted as files or env vars to avoid embedding in images
- Encrypt Secrets at rest where possible
- Regular audit log review detects anomalies
- Dedicated namespaces for sensitive workloads enable finer controls
- Audit logs are primary for monitoring API server activity
Practice Certified Kubernetes Security Specialist with real flashcards
Read the prompt, commit to an answer, then flip the card. Move through the deck at your own pace and repeat any topic that does not come back quickly.
Card 1 of 20
1 reviewed this session
Static practice bank
Start the 15-question diagnostic
The complete question bank is embedded in this pre-rendered page. There is no database request or second content download when you begin.
Which control plane component validates and configures cluster state?
Show hint
Understand the role of API server in cluster operations and security
Study workflow
Turn one CKS attempt into a study plan
- 1
Secure etcd
Enable client certificate authentication for etcd peers and clients. Encrypt etcd data at rest using the encryption provider configuration. Restrict network access to etcd to only the API server and etcd cluster members. Use firewalls or network policies to limit exposure.
- 2
Enforce Pod Security Standards
Enable the PodSecurity admission controller in the API server. Define policies using the built-in profiles (privileged, baseline, restricted). Apply policies per namespace using labels like pod-security.kubernetes.io/enforce. Test with dry-run first.
- 3
Configure NetworkPolicy
Start with a default-deny-all policy for each namespace. Then create ingress and egress rules using podSelector and namespaceSelector. Specify ports and protocols. Use kubectl describe networkpolicy to verify. Test connectivity with temporary debugging pods.
- 4
Implement ImagePolicyWebhook
Deploy a webhook server that validates image references against a policy. Configure the API server with an admission webhook configuration file. Require signatures via tools like cosign. Use the ImagePolicyWebhook admission controller to reject unsigned images.
- 5
Set Up Audit Logging
Enable audit logging in the API server with --audit-policy-file and --audit-log-path. Define a policy that logs metadata for all requests or specific resources. Rotate logs using --audit-log-maxbackup and --audit-log-maxsize. Regularly review logs using centralized tools like Falco or ELK.
FAQ
Questions about this CKS practice page
Clear boundaries on what the bank covers, how to use it, and where official vendor information still matters.
What is the difference between Role and ClusterRole in RBAC?+
A Role grants permissions within a specific namespace. A ClusterRole grants permissions cluster-wide, including non-namespaced resources (like nodes) and can be used across namespaces via RoleBinding. Both contain rules with verbs, resources, and API groups.
Why should I avoid running containers as root?+
Running as root inside a container gives the process elevated privileges on the host in case of a breakout. Using a read-only root filesystem and running as non-root limits the damage an attacker can do. PodSecurity standards enforce runAsNonRoot.
How does the NodeRestriction admission controller work?+
NodeRestriction limits the kubelet's ability to modify node and pod objects. It prevents kubelets from setting node status to unschedulable or modifying pods not bound to itself. This reduces the attack surface if a node is compromised.
What is the purpose of an ImagePolicy webhook?+
An ImagePolicy webhook validates container images before they are admitted into the cluster. It can enforce policies like requiring images to be signed, from a trusted registry, or have no critical vulnerabilities. This prevents deployment of malicious or tampered images.
Can NetworkPolicy block all traffic within a namespace?+
Yes, by default all traffic is allowed if no NetworkPolicy selects the pod. To block all traffic, apply a NetworkPolicy that selects all pods and has no ingress or egress rules. This effectively isolates the pod until explicit rules are added.
Build the next review session
Browse another free bank or use the study strategy guide to turn your misses into spaced review.