Match each Kubernetes security component to its description.
Drag a concept onto its matching description — or click a concept then click the description.
Admission controller that enforces security constraints on pods
Defines how groups of pods can communicate with each other and other network endpoints
Role-based access control for authorization within the cluster
Linux security facility to restrict system calls from a container
Mandatory access control system that confines programs to a limited set of resources
Answer choices
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
RBAC: Role-based access control for managing permissions.
RBAC controls permissions, Pod Security Admission enforces pod security, Network Policies manage traffic, and ServiceAccounts provide identity. Distractors confuse these functions.
Answer analysis
For each option: why learners choose it and why it is or isn't the right answer here.
RBAC: Role-based access control for managing permissions.
Why this is correct
RBAC is the authorization mechanism in the Kubernetes API server that maps subjects—users, groups, or ServiceAccounts—to Roles or ClusterRoles through bindings, controlling which verbs (get, list, create, delete) may be performed on which resources, such as pods, secrets, or namespaces. It makes allow/deny decisions based on the requester's identity but has no involvement in data-plane traffic or storage-level encryption. As a cluster administrator, you define least-privilege policies as YAML manifests, and the API server enforces them on every request.
Pod Security Admission: Enforces pod security standards.
Why this is correct
Pod Security Admission is a built-in admission controller that evaluates Pod specs against the Pod Security Standards—Privileged, Baseline, and Restricted—at creation and update time, effectively replacing the deprecated PodSecurityPolicy (PSP). You control it with namespace labels such as pod-security.kubernetes.io/enforce=restricted, and it can operate in enforce, audit, or warn modes. It acts before the object is persisted, blocking or flagging workloads that contain unsafe securityContext settings, capabilities, host namespaces, or seccomp profiles.
Network Policies: Controls traffic flow between pods.
Why this is correct
A NetworkPolicy is a namespaced Kubernetes resource that declares which pods may communicate with each other and external endpoints based on podSelector, namespaceSelector, and ipBlock rules under Ingress and Egress policyTypes. Its enforcement is delegated to the CNI plugin in use—such as Calico, Cilium, or Weave Net—which programs the dataplane using iptables, eBPF, or IPVS. By default, pods are non-isolated and all traffic is permitted, so you must intentionally define default-deny policies to create network segmentation.
ServiceAccount: Identity for processes running in a pod.
Why this is correct
A ServiceAccount is an API object that provides workload identity to processes inside a Pod, distinct from regular users in the cluster's authentication model. The kubelet mounts a signed ServiceAccount token, typically through a projected volume, into the container filesystem; that token is used to authenticate API calls, and by default every Pod gets the default ServiceAccount of its namespace unless overridden. This identity can be bound to RBAC roles and also serves as the basis for cloud IAM integrations like IRSA or Workload Identity, but it has no network responsibilities.
RBAC: Encrypts data at rest.
Why it's wrong here
Encrypting data at rest is handled earlier in the storage path: the kube-apiserver can be launched with an EncryptionConfiguration file and the --encryption-provider-config flag to encrypt resources such as Secrets into etcd, or the backend disk itself may be encrypted at the OS or volume level. RBAC is purely an authorization mechanism that answers questions like 'can this ServiceAccount delete pods?' and never transforms or protects the actual bytes stored in etcd. Confusing RBAC with encryption is common because both appear in hardening checklists, but RBAC prevents unauthorized access while encryption protects confidentiality at rest.
ServiceAccount: Manages network rules.
Why it's wrong here
Network rules are enforced separately from workload identity: a ServiceAccount is not a firewall, ACL, or routing component, so it cannot allow, deny, or filter pod-to-pod traffic. Instead, NetworkPolicy objects—selected by pod labels and namespace selectors—are translated into dataplane rules by the CNI plugin, which actually controls traffic flow in the cluster. ServiceAccounts only provide an identity and credential for API server authentication, and their tokens are mounted into containers for that purpose, which is why using them for network ACLs is both unsupported and ineffective.
Quick reference
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Learn chapter
Supply Chain Security: Policy Enforcement and Admission Controllers
Key term
Pod Security Admission
Pod Security Admission is a Kubernetes feature that enforces security standards on pods at creation time to prevent running containers with dangerous privileges.
Key term
Service Account Hardening
Service Account Hardening is the set of security practices to restrict and protect Kubernetes service accounts from unauthorized access or misuse.
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.