Courseiva
← CKS
Full test
Minimize Microservice Vulnerabilities →mediumMultiple Select

CKS Minimize Microservice Vulnerabilities Practice Question

Which THREE of the following security context settings help mitigate container breakout attacks? (Select 3)

⚠ Common exam trap

A common misconception in the CKS exam is that `privileged: true` is a security hardening option, when in reality it is the most permissive setting and directly enables breakout attacks; candidates may also mistakenly think adding capabilities like `NET_ADMIN` is a mitigation, but it actually expands the attack surface.

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

✓

readOnlyRootFilesystem: true

Option A (readOnlyRootFilesystem: true) is correct because mounting the container's root filesystem read-only prevents an attacker who gains code execution from writing malicious binaries, scripts, or modifying system files needed to escalate or persist during a breakout attempt. Option C (allowPrivilegeEscalation: false) is correct because it sets the kernel's no_new_privs flag on the container process, blocking setuid/setgid binaries and file capabilities from granting the process more privileges than its parent — a key vector for escaping to the host. Option E (runAsNonRoot: true) is correct because it forces the container to run as a non-root UID, so even if the process escapes the container boundary it lacks root privileges on the host, dramatically reducing the impact of a breakout. Option B (privileged: true) is not correct because privileged containers get all Linux capabilities and direct device access, which is precisely what enables breakouts rather than mitigating them. Option D (capabilities: add: ['NET_ADMIN']) is not correct because adding NET_ADMIN expands the container's kernel attack surface (e.g., manipulating network interfaces, iptables), increasing breakout risk instead of reducing it.

Answer analysis

Option-by-option breakdown

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

  • ✓

    readOnlyRootFilesystem: true

    Why this is correct

    Setting `readOnlyRootFilesystem: true` mounts the container’s root filesystem as read-only, preventing any process inside the container from writing to or modifying system binaries, libraries, or configuration files. This directly mitigates container breakout attacks by blocking a common vector: overwriting a setuid binary or injecting a malicious shared object (e.g., via `LD_PRELOAD`) to escalate privileges or escape the container’s namespace isolation.

  • ✗

    privileged: true

    Why it's wrong here

    Setting privileged to true grants the container nearly all host capabilities, which increases breakout risk rather than mitigating it. It is tempting when a workload needs kernel-level access, but least privilege requires dropping capabilities and enabling readOnlyRootFilesystem and runAsNonRoot instead.

  • ✓

    allowPrivilegeEscalation: false

    Why this is correct

    Setting `allowPrivilegeEscalation: false` blocks the setuid and setgid mechanisms, plus file capabilities, preventing a process inside the container from gaining more privileges than its parent. This directly satisfies the stem's container breakout mitigation by denying the privilege gain that exploits such as Dirty COW or sudo misconfigurations rely on.

  • ✗

    capabilities: add: ['NET_ADMIN']

    Why it's wrong here

    Adding NET_ADMIN grants extra kernel capabilities, widening the attack surface and enabling network reconfiguration, so it increases breakout risk rather than mitigating it. It is tempting because some workloads legitimately need NET_ADMIN to manage interfaces, routes or iptables inside the pod, but that is a functional requirement, not a hardening control.

  • ✓

    runAsNonRoot: true

    Why this is correct

    Setting `runAsNonRoot: true` in a Pod’s security context forces the container to run with a user ID above 0, preventing the process from having root privileges inside the container. This directly mitigates container breakout attacks because if an attacker exploits a kernel vulnerability, they cannot escalate to root on the host, as the container already lacks the root UID required for such privilege escalation.

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 →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

1 more way 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 deploying a microservice that must run as a non-root user and have a read-only root filesystem. Which two fields must be set in the PodSecurityContext or container SecurityContext?

medium
  • A.allowPrivilegeEscalation: false
  • B.seLinuxOptions
  • C.runAsUser: 1000
  • ✓ D.readOnlyRootFilesystem: true
  • ✓ E.runAsNonRoot: true

Why D: To meet the requirements, readOnlyRootFilesystem: true (D) is required for a read-only root filesystem. For running as a non-root user, either runAsUser: 1000 (C) or runAsNonRoot: true (E) is sufficient. Setting both is allowed but not mandatory. Therefore the two fields that must be set are D and one of {C, E}, not a unique pair.

JA

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.