Pod Security Admission Restricted Profile Requirements
Which THREE configurations are part of Pod Security Admission's 'restricted' profile? (Select THREE.)
Quick Answer
The answer is that the restricted profile requires capabilities to drop ALL, runAsNonRoot to be true, and seccompProfile to be set to RuntimeDefault or Localhost. This profile enforces the most stringent Pod Security Admission standards by preventing privilege escalation at multiple layers: dropping all Linux capabilities removes granular kernel permissions, forcing non-root execution eliminates the most common attack vector, and mandatory seccomp profiles restrict system calls to a safe subset. On the CKAD exam, this appears as a multi-select question testing your ability to distinguish the restricted profile from the baseline or privileged profiles—a common trap is confusing the baseline requirement to drop only NET_RAW with the restricted requirement to drop ALL capabilities. The key memory tip is to think of the restricted profile as a triple lock: no root, no caps, no extra syscalls.
⚠ Common exam trap
Watch out — candidates often confuse the 'restricted' profile with the 'baseline' profile, mistakenly thinking that options like `allowPrivilegeEscalation: true` or privileged containers are acceptable, when in fact the restricted profile explicitly prohibits them.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
runAsNonRoot: true
Option A (runAsNonRoot: true) is correct because the restricted profile requires containers to run as a non-root user, enforcing runAsNonRoot=true in the security context. Option B (seccompProfile.type: RuntimeDefault) is correct because restricted mandates a seccomp profile, and RuntimeDefault is the minimum accepted value. Option C (capabilities must drop ALL) is correct because restricted requires dropping all Linux capabilities, allowing only NET_BIND_SERVICE to be added back. Option D is incorrect because allowPrivilegeEscalation must be false under restricted, not true. Option E is incorrect because privileged containers are explicitly disallowed by the restricted profile.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
runAsNonRoot: true
Why this is correct
Setting `runAsNonRoot: true` forces the kubelet to refuse container startup if the image resolves to UID 0, satisfying the restricted profile's mandate that containers never run as root. This directly enforces the non-root user constraint, one of the three baseline hardening controls the restricted profile requires.
- ✓
seccompProfile.type: RuntimeDefault
Why this is correct
Seccomp profiles are a Linux kernel feature restricting system calls, and the restricted profile mandates `RuntimeDefault` (or `Localhost`) to block dangerous syscalls. This satisfies the restricted profile's syscall-filtering requirement, unlike the baseline profile, which leaves seccomp unset by default.
- ✓
capabilities must drop ALL
Why this is correct
Dropping ALL Linux capabilities is mandatory under the restricted profile, which enforces the most hardened Pod Security Standard. This satisfies the stem's requirement for a restricted-profile configuration, alongside running as non-root and seccomp profiles. Privileged escalation and added capabilities are prohibited, so containers retain no kernel privileges.
- ✗
allowPrivilegeEscalation: true
Why it's wrong here
Incorrect. allowPrivilegeEscalation must be false in restricted profile.
- ✗
Privileged containers allowed
Why it's wrong here
Incorrect. The restricted profile does not allow privileged containers.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 826 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 →
Same concept, more angles
8 more ways this is tested on CKAD
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A cluster administrator wants to prevent all pods in a namespace from running with privileged escalation. Which Pod Security Admission standard enforces this?
medium- A.baseline
- ✓ B.restricted
- C.privileged
- D.high
Why B: The 'restricted' Pod Security Admission (PSA) standard enforces the most stringent security controls, including preventing privileged escalation by setting `securityContext.AllowPrivilegeEscalation` to `false` and requiring containers to run as non-root. This directly addresses the cluster administrator's goal of blocking privilege escalation in all pods within a namespace.
Variation 2. An administrator wants to enforce that all pods in namespace 'secured' must run with a seccomp profile set to 'RuntimeDefault' at the container level. Which Pod Security Admission policy standard achieves this?
hard- A.Set the namespace label 'pod-security.kubernetes.io/enforce=privileged'
- B.Set the namespace label 'pod-security.kubernetes.io/enforce=baseline'
- ✓ C.Set the namespace label 'pod-security.kubernetes.io/enforce=restricted'
- D.Set the namespace label 'pod-security.kubernetes.io/enforce=seccomp'
Why C: The 'restricted' Pod Security Admission (PSA) policy standard enforces the most stringent security controls, including requiring that pods use a seccomp profile set to 'RuntimeDefault' at the container level. This is defined in the Kubernetes Pod Security Standards documentation, where the restricted profile mandates 'seccomp: RuntimeDefault' as a baseline requirement. Therefore, option C is correct because it directly matches the policy that enforces this specific seccomp constraint.
Variation 3. An administrator wants to enforce that all Pods in a namespace run with a read-only root filesystem. Which admission controller should be configured?
medium- A.LimitRange
- B.ResourceQuota
- C.MutatingAdmissionWebhook
- ✓ D.Pod Security Admission (PSA)
Why D: Pod Security Admission (PSA) is the correct choice because it enforces Pod Security Standards (PSS) at the namespace level, including the `Restricted` profile which mandates a read-only root filesystem (`readOnlyRootFilesystem: true`). PSA is a built-in admission controller that evaluates pod specifications against predefined security policies and rejects pods that violate them, making it the appropriate tool for this requirement.
Variation 4. Which annotation is used to enforce Pod Security Admission at the 'restricted' level on a namespace?
medium- ✓ A.pod-security.kubernetes.io/enforce: restricted
- B.pod-security.kubernetes.io/warn: restricted
- C.pod-security.kubernetes.io/enforce: baseline
- D.pod-security.kubernetes.io/audit: restricted
Why A: The `pod-security.kubernetes.io/enforce` annotation enforces Pod Security Standards (PSS) at the namespace level, and setting it to `restricted` blocks any pod that violates the most stringent set of security controls (e.g., running as root, privileged containers). This is the only annotation that actively prevents non-compliant pods from being created, rather than just warning or logging violations.
Variation 5. You apply a Pod Security Admission label 'pod-security.kubernetes.io/enforce: restricted' to a namespace. A pod with the following securityContext is created: securityContext: runAsUser: 1000 runAsNonRoot: true capabilities: drop: ["ALL"] seccompProfile: type: RuntimeDefault allowPrivilegeEscalation: false readOnlyRootFilesystem: true Will the pod be admitted?
hard- ✓ A.Yes, the pod satisfies all restricted profile requirements
- B.No, because runAsUser must not be set
- C.No, because seccompProfile type must be 'Localhost'
- D.No, because the pod must not set capabilities at all
Why A: The Pod Security Admission (PSA) restricted profile requires that pods drop all capabilities, set `runAsNonRoot: true`, set `seccompProfile.type` to `RuntimeDefault` or `Localhost`, set `allowPrivilegeEscalation: false`, and restrict `runAsUser` to a non-root user (which is satisfied by `runAsUser: 1000`). The provided pod meets all these requirements, so it will be admitted. The `runAsUser` field is allowed as long as the user ID is not 0 (root), and the `seccompProfile.type` is correctly set to `RuntimeDefault`, which is one of the permitted values.
Variation 6. You want to apply a Pod Security Admission (PSA) policy that enforces the 'restricted' profile in the 'dev' namespace, but only for Pods that are not exempt. Which TWO steps are required? (Select TWO)
hard- ✓ A.Set the label 'pod-security.kubernetes.io/enforce=restricted' on the namespace
- B.Add a 'securityContext' field to the Pod template with 'runAsUser: 1000'
- C.Set the label 'pod-security.kubernetes.io/enforce=baseline' on the namespace
- D.Set the label 'pod-security.kubernetes.io/warn=restricted' on the namespace
- ✓ E.Configure Pods to meet the restricted profile requirements, such as setting runAsNonRoot and seccompProfile
Why A: Option A is correct because PSA enforcement is enabled per-namespace by applying the label 'pod-security.kubernetes.io/enforce=restricted' to the 'dev' namespace, which tells the Pod Security Admission controller to reject Pods that violate the restricted profile. Option E is correct because the restricted profile imposes strict requirements — such as runAsNonRoot: true, allowPrivilegeEscalation: false, dropping ALL capabilities, and setting seccompProfile.type to RuntimeDefault or Localhost — so workloads must be configured to satisfy these controls to be admitted. Option B is incorrect because merely setting runAsUser: 1000 does not satisfy the restricted profile, which specifically requires runAsNonRoot rather than a fixed UID. Option C is incorrect because 'baseline' is a less restrictive profile than 'restricted' and would not enforce the required policy. Option D is incorrect because the 'warn' label only produces warnings and does not enforce the restricted profile; enforcement requires the 'enforce' label.
Variation 7. A PodSecurityPolicy (PSP) has been replaced by Pod Security Admission. Which of the following commands applies a baseline pod security standard to the namespace 'dev'?
medium- A.kubectl label ns dev pod-security.kubernetes.io/warn=baseline
- B.kubectl label ns dev pod-security.kubernetes.io/enforce=privileged
- C.kubectl label ns dev pod-security.kubernetes.io/audit=baseline
- ✓ D.kubectl label ns dev pod-security.kubernetes.io/enforce=baseline
Why D: Pod Security Admission uses labels on namespaces to enforce pod security standards. The label `pod-security.kubernetes.io/enforce=baseline` applies the baseline standard, which prevents known privilege escalations while allowing the default minimal pod configuration. This replaces the deprecated PodSecurityPolicy (PSP) with a built-in admission controller.
Variation 8. Which THREE of the following are characteristics of Pod Security Admission (PSA) standards? (Select three.)
hard- ✓ A.PSA can be configured to warn or audit violations without blocking
- ✓ B.There are three predefined security levels: privileged, baseline, restricted
- C.PSA requires Open Policy Agent (OPA) Gatekeeper to function
- ✓ D.A namespace can be labeled to enforce a security level for all pods in that namespace
- E.PSA is a CustomResourceDefinition (CRD) that must be installed separately
Why A: Pod Security Admission (PSA) supports three modes: enforce (blocks violations), audit (logs violations in audit logs), and warn (returns a warning to the user). This allows administrators to test or monitor PSA policies without immediately blocking pod creation, which is critical for gradual adoption.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD 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 CKAD exam.