Question 958 of 997

Minimize Microservice Vulnerabilities →hardMultiple ChoiceObjective-mapped

OPA Gatekeeper Rego Policy to Require runAsNonRoot: true at Pod and Container Levels

This CKS practice question tests your understanding of minimize microservice vulnerabilities. Match the stated requirement to the specific cloud service, access model, or configuration option — many options are valid in isolation but not for this scenario. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.

You are writing a Rego policy for OPA Gatekeeper to deny pods that do not have 'runAsNonRoot: true' set in their security context. The ConstraintTemplate expects an input parameter 'runAsNonRoot' that is a boolean. Which Rego rule correctly denies such pods?

A
violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not container.securityContext.runAsNonRoot msg := "Container must run as non-root" } violation[{"msg": msg}] { pod := input.review.object not pod.spec.securityContext.runAsNonRoot msg := "Pod must run as non-root" }
Why wrong: This checks both, but if either is missing, it will still deny; however, the correct approach is to check that the effective runAsNonRoot is true for each container, considering pod defaults.
B
violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not has_field(container, "securityContext") or not container.securityContext.runAsNonRoot msg := "Container must set runAsNonRoot: true" }
Why wrong: This is a common pattern but still incomplete; the pod-level security context may propagate to containers.
C
violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not container.securityContext.runAsNonRoot msg := "Container must run as non-root" }
Why wrong: This only checks containers, but the security context can also be set at pod level; also, if the field is missing, it may cause an undefined error.
D
violation[{"msg": msg}] { pod := input.review.object not pod.spec.securityContext.runAsNonRoot msg := "Pod must run as non-root" }
Why wrong: This only checks pod-level security context, but containers can override.

Full breakdown with real-world context →

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

Option A is correct because it includes two violation rules: one that checks each container's securityContext for runAsNonRoot, and another that checks the pod-level securityContext. This ensures that the policy denies pods regardless of whether the setting is at the pod or container level. Option B uses a non-existent 'has_field' function and is syntactically incorrect. Option C only checks containers, missing pods that set runAsNonRoot at the pod level. Option D only checks the pod level, missing containers that override it. Therefore, only option A provides comprehensive coverage.

Key principle: ACLs process entries top to bottom and stop at the first match. Entry order and interface direction matter as much as the permit or deny statement.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not container.securityContext.runAsNonRoot msg := "Container must run as non-root" } violation[{"msg": msg}] { pod := input.review.object not pod.spec.securityContext.runAsNonRoot msg := "Pod must run as non-root" }
Why it's wrong here
This checks both, but if either is missing, it will still deny; however, the correct approach is to check that the effective runAsNonRoot is true for each container, considering pod defaults.
✗
violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not has_field(container, "securityContext") or not container.securityContext.runAsNonRoot msg := "Container must set runAsNonRoot: true" }
Why it's wrong here
This is a common pattern but still incomplete; the pod-level security context may propagate to containers.
✗
violation[{"msg": msg}] { container := input.review.object.spec.containers[_] not container.securityContext.runAsNonRoot msg := "Container must run as non-root" }
Why it's wrong here
This only checks containers, but the security context can also be set at pod level; also, if the field is missing, it may cause an undefined error.
✗
violation[{"msg": msg}] { pod := input.review.object not pod.spec.securityContext.runAsNonRoot msg := "Pod must run as non-root" }
Why it's wrong here
This only checks pod-level security context, but containers can override.

Common exam traps

Common exam trap: ACLs stop at the first match

ACLs are processed top to bottom. The first matching entry wins, and an implicit deny usually exists at the end.

Detailed technical explanation

How to think about this question

ACL questions test precision: source, destination, protocol, port and direction. A generally correct ACL can still fail if it is applied on the wrong interface or in the wrong direction.

KKey Concepts to Remember

Standard ACLs match source addresses.
Extended ACLs can match source, destination, protocol and ports.
The first matching ACL entry is used.
There is usually an implicit deny at the end.

TExam Day Tips

Check inbound versus outbound direction.
Read the ACL from top to bottom.
Look for a broader permit or deny above the intended line.

Key takeaway

ACLs process entries top to bottom and stop at the first match. Entry order and interface direction matter as much as the permit or deny statement.

Real-world example

How this comes up in practice

A security administrator must allow nursing staff to reach a patient records server while blocking access from the guest Wi-Fi VLAN. After applying an extended ACL, traffic is still blocked from nursing workstations. The ACL was applied outbound instead of inbound on the wrong interface. Questions like this test ACL direction and placement rules.

What to study next

Got this wrong? Here's your next step.

Review ACL processing order, placement rules (standard near destination, extended near source), and inbound vs outbound direction. Study wildcard masks and implicit deny. Then practise related CKS ACL questions on filtering logic and placement.

Related CKS practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

Monitoring Logging and Runtime Security practice questions

Practise CKS questions linked to Monitoring Logging and Runtime Security.

Cluster Setup and Hardening practice questions

Practise CKS questions linked to Cluster Setup and Hardening.

System Hardening practice questions

Practise CKS questions linked to System Hardening.

Minimize Microservice Vulnerabilities practice questions

Practise CKS questions linked to Minimize Microservice Vulnerabilities.

Supply Chain Security practice questions

Practise CKS questions linked to Supply Chain Security.

Monitoring, Logging and Runtime Security practice questions

Practise CKS questions linked to Monitoring, Logging and Runtime Security.

Cluster Setup practice questions

Practise CKS questions linked to Cluster Setup.

Cluster Hardening practice questions

Practise CKS questions linked to Cluster Hardening.

CKS fundamentals practice questions

Practise CKS questions linked to CKS fundamentals.

CKS scenario practice questions

Practise CKS questions linked to CKS scenario.

CKS troubleshooting practice questions

Practise CKS questions linked to CKS troubleshooting.

Practice this exam

Start a free CKS practice session

Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.

10 questions 20 questions 30 questions 50 questions Timed 30

CKS practice-test guide →Study guide →Browse all practice tests

FAQ

Questions learners often ask

What does this CKS question test?

Minimize Microservice Vulnerabilities — This question tests Minimize Microservice Vulnerabilities — Standard ACLs match source addresses..

What exam trap should I watch out for?

Common exam trap: ACLs stop at the first match: ACLs are processed top to bottom. The first matching entry wins, and an implicit deny usually exists at the end.

What should I do if I get this CKS question wrong?

What is the key concept behind this question?

Standard ACLs match source addresses.

About these practice questions

Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

2 more ways this is tested on CKS

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. You are writing a Rego policy for OPA/Gatekeeper to deny pods that do not have runAsNonRoot set to true. Which Rego statement should the ConstraintTemplate contain?

hard

✓ A.violation[msg] { not input.request.object.spec.securityContext.runAsNonRoot == true }
B.deny[msg] { input.request.object.spec.securityContext.runAsNonRoot == true }
C.allow[msg] { input.request.object.spec.securityContext.runAsNonRoot == false }
D.deny[msg] { input.request.object.spec.containers[_].securityContext.runAsNonRoot == true }

Why A: Option A is correct because the Rego rule `violation[msg]` is the standard pattern for Gatekeeper ConstraintTemplates to deny a resource. The condition `not input.request.object.spec.securityContext.runAsNonRoot == true` triggers a violation when the field is missing or set to false, ensuring pods do not have `runAsNonRoot` set to true. This directly enforces the requirement to deny pods without the security context.

Variation 2. You are implementing a Gatekeeper policy to deny pods that run as root. Which Rego rule should you include in the ConstraintTemplate?

medium

A.allow[{"msg": msg}] { msg := "container runs as root"; input.spec.containers[_].securityContext.runAsNonRoot == false }
✓ B.deny[msg] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }
C.deny[{"msg": msg}] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }
D.deny[msg] { input.spec.containers[_].securityContext.runAsNonRoot == false }

Why B: Option B is correct because it uses the correct Rego logic: it denies the pod when 'runAsNonRoot' is not set to true. The 'not' operator handles both the case where the field is missing or set to false. While Gatekeeper ConstraintTemplates typically expect a rule named 'violation' returning an object with a 'msg' key, the 'deny' rule used in option B is a common OPA pattern that Gatekeeper also accepts. The logic itself is accurate for the requirement to deny pods running as root.

Keep practising

Question Discussion

Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.

Loading comments…

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.