Match each Kubernetes object or feature to its primary security purpose.
Drag a concept onto its matching description — or click a concept then click the description.
Provides an identity for processes running in a pod
Stores sensitive data such as passwords, OAuth tokens, and ssh keys
Stores non-sensitive configuration data in key-value pairs
Specifies security settings for a pod or container
Limits resource consumption per namespace to prevent resource exhaustion
Answer choices
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
NetworkPolicy: Controls network traffic to and from pods
Correct matches: NetworkPolicy controls network traffic; RBAC controls permissions; SecurityContext defines security settings. Common confusions: ServiceAccount is for identity, not encryption; PodSecurityPolicy is for security constraints, not resource limits.
Answer analysis
For each option: why learners choose it and why it is or isn't the right answer here.
NetworkPolicy: Controls network traffic to and from pods
Why this is correct
NetworkPolicy is a namespaced Kubernetes resource that governs pod-level communication by selecting pods through labels and defining ingress/egress rules with ipBlock, podSelector, or namespaceSelector peers. It enforces zero-trust segmentation at the network layer, but only if a compatible CNI plugin (e.g., Calico, Cilium, or Antrea) actually implements it. Without such a plugin, NetworkPolicy objects are ignored, so it does not control traffic by itself.
RBAC: Controls access permissions to Kubernetes resources
Why this is correct
RBAC (Role-Based Access Control) authorizes API server requests by binding subjects — users, groups, or ServiceAccounts — to Roles or ClusterRoles that specify permitted verbs (get, list, create, delete) on resources like pods, secrets, and deployments. It does not influence data plane traffic or container runtime privileges; rather, it determines who can call kubectl or the Kubernetes API to read or modify cluster state. This is the primary mechanism for least-privilege access to control plane objects.
SecurityContext: Defines privilege and security settings for pods/containers
Why this is correct
A SecurityContext is a pod-level or container-level field that configures discretionary access control: it can set runAsUser/runAsGroup, fsGroup, seLinuxOptions, privileged, allowPrivilegeEscalation, capabilities (such as dropping NET_RAW or adding NET_ADMIN), and readOnlyRootFilesystem. These settings directly constrain the Linux process privileges of the workload inside the node's kernel. It is distinct from authorization and networking because it defines what a single workload is allowed to do at the OS level.
ServiceAccount: Encrypts secrets at rest
Why it's wrong here
ServiceAccounts are Kubernetes identities that pods use to authenticate to the API server; they do not perform any encryption or decryption of stored data. Encryption at rest is handled independently by etcd encryption configuration (encryption-provider-config) using KMS, AES-CBC, or secretbox, and by volume encryption mechanisms in cloud providers. Saying ServiceAccount encrypts secrets conflates identity with cryptographic protection.
PodSecurityPolicy: Defines CPU and memory limits for pods
Why it's wrong here
PodSecurityPolicy (now deprecated in favor of Pod Security Admission) is a cluster-level admission controller that enforces security constraints on pod creation, such as preventing privileged containers, restricting host namespaces, requiring seccomp/AppArmor profiles, and constraining volume types. It has never controlled CPU or memory requests/limits; resource bounds are managed separately by ResourceQuota and LimitRange objects. This option misattributes resource governance to a policy designed for privilege and hardening.
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
About these practice questions
One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.