Test yourself
Advanced container security
Final exam · 62 questions · answers explained as you pick
Container internals
10 questions
01A "container" in the Linux kernel is really…
Incorrect — no guest kernel is involved; that is a VM.
Correct — there is no container object — just a host process in a costume.
Incorrect — the kernel has no "container" primitive.
Incorrect — informal, but internally it is a namespaced/cgrouped process.
02Which namespace is the most security-critical, and why?
Incorrect — hostname isolation is cosmetic, not a security boundary.
Incorrect — useful, but not the one that governs privilege.
Correct — it can make container root a harmless host user, breaking root-equals-root.
Incorrect — helpful isolation, but not the privilege-defining one.
03Namespaces alone are not a security boundary because they…
Correct — they must be paired with capabilities, seccomp, and ideally a user namespace.
Incorrect — Docker enables them for every container.
Incorrect — rootless containers use them too.
Incorrect — isolation is not about encryption.
04cgroups primarily protect against…
Incorrect — that is namespaces/caps/seccomp; cgroups bound resources.
Correct — without limits one container can take down the host.
Incorrect — that is signing/verification, unrelated to cgroups.
Incorrect — a network concern, not a cgroup one.
05Setting --memory without --memory-swap is weak because…
Incorrect — CPU is a separate control.
Incorrect — the memory limit applies; swap is the gap.
Correct — set --memory-swap equal to --memory (or disable swap on container hosts).
Incorrect — PIDs are --pids-limit.
06Linux capabilities exist to…
Correct — so a process gets only the specific powers it needs.
Incorrect — they complement, not replace, DAC permissions.
Incorrect — capabilities gate operations; they do not encrypt.
Incorrect — that is cgroups.
07CAP_SYS_ADMIN is nicknamed "the new root" because…
Incorrect — it is NOT in the default set — and should rarely be added.
Correct — mount alone has been chained into container breakouts.
Incorrect — that is NET_ADMIN; SYS_ADMIN is far broader.
Incorrect — ptrace is SYS_PTRACE; SYS_ADMIN is much more.
08The least-privilege capability pattern is…
Incorrect — backwards — start from nothing, not everything.
Incorrect — the ~14 defaults include more than most apps need.
Correct — usually none, sometimes just NET_BIND_SERVICE.
Incorrect — that grants everything — the opposite of least privilege.
09By default, root (UID 0) inside a container is…
Correct — why a breakout as container root is a host takeover.
Incorrect — only true with a user namespace / rootless.
Incorrect — without userns it writes host bind mounts as real root.
Incorrect — the kernel enforces permissions against it as real UID 0.
10A user namespace helps because it…
Incorrect — it maps UIDs; it does not encrypt.
Correct — the single strongest mitigation for root-equals-root.
Incorrect — capabilities are a separate control.
Incorrect — that is the network namespace / policy.
10 questions · explanations appear as you answer
Minimal & secure images
10 questions
01A multi-stage build improves security mainly by…
Incorrect — it does not encrypt anything.
Correct — the runtime image ships only the artifact — far less to attack.
Incorrect — signing is a separate cosign step.
Incorrect — unrelated to the stage split.
02A distroless image is characterized by…
Correct — most post-exploitation tools are simply absent.
Incorrect — that is the opposite of distroless.
Incorrect — it runs anywhere; it is just a minimal base.
Incorrect — minimal, not encrypted.
03The security benefit of "no shell" in a distroless image is that…
Incorrect — no shell is unrelated to signing.
Incorrect — startup speed is not the security point.
Correct — the attacker is limited to what your binary itself can do.
Incorrect — footprint helps, but the security win is the missing tooling.
04You debug a shell-less production image by…
Incorrect — that reintroduces the surface you removed.
Correct — tools come alongside at runtime; the production image stays inert.
Incorrect — unrelated, and worse for security.
Incorrect — that weakens the container; not a debug method.
05A statically linked binary can run on scratch because it…
Correct — so an empty base works: smallest image, zero OS surface.
Incorrect — scratch has nothing; static binaries need nothing.
Incorrect — static native binaries are not interpreted.
Incorrect — no shell is present or needed.
06On a scratch image, outbound HTTPS fails with an x509 error unless you…
Incorrect — a shell has nothing to do with TLS trust.
Incorrect — privilege is unrelated to CA trust.
Correct — scratch has no trust store; you add what the binary assumes.
Incorrect — never; copy the CA bundle instead.
07Choose scratch vs distroless by…
Incorrect — not a version choice.
Correct — Go/Rust static → scratch; most else → distroless.
Incorrect — scratch fails for dynamically linked or interpreted apps.
Incorrect — scratch is smaller/safer when a static binary allows it.
08A file created and deleted across two separate RUN instructions…
Correct — cleanup only helps inside the same RUN that created the file.
Incorrect — later deletes do not reclaim earlier layers.
Incorrect — layers are not encrypted.
Incorrect — the build succeeds; the bytes just persist.
09You get real CVE results for a scratch image (no package DB) by…
Incorrect — your dependencies still can; you must enumerate them.
Correct — the SBOM lists components so a scanner can match CVEs without an on-disk DB.
Incorrect — scratch has no such file, and it would not list app deps.
Incorrect — there is no package manager on scratch.
10A small image is trustworthy only when you also…
Incorrect — a tag says nothing about origin or contents.
Incorrect — the opposite of what you want.
Correct — minimal reduces surface; provenance proves contents and source.
Incorrect — publishing does not establish trust.
10 questions · explanations appear as you answer
Hardening the container
10 questions
01The single highest-value hardening step is to…
Incorrect — the opposite — you want fewer.
Correct — it turns a breakout from host takeover into an unprivileged nuisance.
Incorrect — bigger means more surface, not more safety.
Incorrect — that increases exposure.
02Prefer USER 10001:10001 over USER app because a numeric UID…
Correct — runAsNonRoot checks the UID and cannot resolve a name to 0.
Incorrect — no performance difference.
Incorrect — names are allowed; numeric is just safer to enforce.
Incorrect — UID and capabilities are unrelated axes.
03A read-only root filesystem is paired with…
Incorrect — the opposite direction entirely.
Incorrect — unrelated; you still drop caps.
Correct — every writable location becomes declared and auditable.
Incorrect — you keep seccomp on.
04no-new-privileges protects by…
Incorrect — it is about privilege escalation, not networking.
Correct — kills a whole class of escalation for free.
Incorrect — that is a separate flag.
Incorrect — that is a minimal-image property.
05cap-drop ALL and running non-root are…
Correct — root-with-no-caps and non-root-with-SYS_ADMIN each leave a path.
Incorrect — UID and capabilities are independent.
Incorrect — they combine; that is the baseline.
Incorrect — both apply to plain Docker too.
06Docker’s default seccomp profile…
Incorrect — it allows most and blocks a curated dangerous set.
Correct — verify Seccomp: 2 in /proc/self/status in production.
Incorrect — the default is applied automatically (except privileged/unconfined).
Incorrect — it is independent of the base image.
07You build a custom seccomp allowlist by…
Incorrect — guessing breaks the app or leaves it loose.
Incorrect — a tight profile denies by default.
Correct — deny-by-default plus an observed allowlist.
Incorrect — syscall needs differ per app.
08An LSM (AppArmor/SELinux) adds what seccomp does not?
Correct — seccomp filters syscalls; the LSM confines resource access.
Incorrect — that is cgroups.
Incorrect — unrelated; that is a supply-chain tool.
Incorrect — not an LSM function.
09When an app hits an AppArmor/SELinux denial, the right fix is to…
Incorrect — that removes a whole defensive layer.
Correct — complain/permissive mode exists to tune without turning it off.
Incorrect — that disables far more than the LSM.
Incorrect — same problem as unconfined.
10Verifying Seccomp: 2 in /proc/self/status confirms…
Incorrect — unrelated to signing.
Incorrect — that is the UID, a different check.
Correct — a quick way to catch a container running without seccomp.
Incorrect — that is /proc/self/attr/current, a different field.
10 questions · explanations appear as you answer
Hardening the daemon & host
10 questions
01Rootless Docker/Podman reduces risk by…
Correct — a daemon or breakout compromise is a user compromise, not host root.
Incorrect — it removes root privilege, not via encryption.
Incorrect — networking still works, with some limits.
Incorrect — containers run normally, just rootless.
02Podman differs from Docker notably in that it is…
Incorrect — its CLI is intentionally Docker-compatible.
Correct — no central root daemon to attack; containers are children of the CLI.
Incorrect — it is Linux-native.
Incorrect — it runs standard OCI images.
03Mounting /var/run/docker.sock into a container grants…
Incorrect — it grants the full API, not read-only image access.
Incorrect — far more than networking.
Correct — the container asks the daemon to hand over the host.
Incorrect — the socket API is unauthenticated at the socket level.
04Exposing the Docker API on tcp://0.0.0.0:2375 is dangerous because…
Correct — use mutual TLS on 2376, firewall it, or do not expose it.
Incorrect — the problem is exposure, not speed.
Incorrect — it does not.
Incorrect — 0.0.0.0 is exactly the problem — it is reachable remotely.
05Being in the docker group is effectively…
Incorrect — it is full socket access.
Correct — socket access can mount / and chroot as root.
Incorrect — no such limit; it is full daemon control.
Incorrect — it is a root-equivalent grant.
06icc: false in daemon.json…
Incorrect — unrelated to caching.
Incorrect — the opposite of hardening; it does not.
Correct — a safer default so containers cannot freely reach each other.
Incorrect — only default-bridge inter-container traffic.
07docker-bench-security is used to…
Correct — it scores dozens of config checks and flags drift.
Incorrect — that is trivy/grype; bench checks configuration.
Incorrect — not a build tool.
Incorrect — that is cosign.
08With userns-remap enabled, container UID 0 maps to…
Incorrect — that is the un-remapped default; remap changes it.
Correct — root inside, harmless user outside.
Incorrect — it maps to a real, unprivileged UID.
Incorrect — the mapping is fixed by /etc/subuid.
09A concrete win of userns-remap is that a "root" container…
Incorrect — not a performance feature.
Incorrect — it still should not; remap is about UID mapping.
Correct — its writes land as the mapped unprivileged UID.
Incorrect — remap does not grant capabilities.
10userns-remap protection is undone by…
Correct — sharing the host user namespace removes the mapping.
Incorrect — that is a complementary control, not a bypass.
Incorrect — that strengthens, not weakens, isolation.
Incorrect — base image choice does not affect the mapping.
10 questions · explanations appear as you answer
Escape paths & defense
10 questions
01Most real-world container escapes come from…
Incorrect — those exist but are the minority.
Correct — which means disciplined config prevents most of them.
Incorrect — not the container-escape mechanism.
Incorrect — not an escape primitive.
02--privileged is so dangerous because it…
Incorrect — it is about privileges, not resources.
Incorrect — far more than that.
Correct — effectively a host root shell with extra steps.
Incorrect — that is --net=host; privileged is much broader.
03The correct alternative to --privileged is usually…
Correct — scope the exact privilege instead of granting everything.
Incorrect — still leaves default caps and misses the real need.
Incorrect — that is another host-takeover path.
Incorrect — weakens security without addressing the need.
04A container with docker.sock mounted can take over the host by…
Incorrect — far more than reading — it controls the daemon.
Correct — the container did not escape the kernel; it used the API.
Incorrect — not the socket-abuse path.
Incorrect — the socket API needs no in-container root.
05If a container legitimately needs limited Docker API access, you should…
Incorrect — that is full control — exactly the risk.
Incorrect — unrelated and worse.
Correct — e.g. docker-socket-proxy; or use rootless DinD / Kaniko so no socket is needed.
Incorrect — that broadens exposure rather than limiting it.
06Dangerous hostPath mounts into an untrusted container include…
Correct — each leaks credentials or kernel interfaces or a persistence path.
Incorrect — that is the safe pattern, not the danger.
Incorrect — volumes are managed and do not expose host system paths.
Incorrect — in-memory scratch is not a host-path leak.
07CAP_SYS_MODULE is catastrophic to grant because it…
Incorrect — that is NET_BIND_SERVICE.
Correct — exactly what cap-drop ALL removes.
Incorrect — that is SYS_PTRACE.
Incorrect — no special cap needed for that.
08There is no in-container fix for a kernel-vulnerability escape, so you…
Incorrect — you mitigate it deliberately.
Incorrect — that widens the surface.
Correct — the shared kernel is the ceiling; these raise the bar and contain the unknown.
Incorrect — the base image does not change the shared host kernel.
09gVisor and Kata reduce escape risk by…
Correct — a kernel-level escape lands in the sandbox, not on the host.
Incorrect — they add a kernel boundary; caps are separate.
Incorrect — not how sandboxes work.
Incorrect — isolation, not encryption.
10On a hardened distroless, non-root container, a Falco "shell in container" alert is high-signal because…
Incorrect — context matters; the point is this container should have none.
Correct — hardening turns the workload into a sharp tripwire.
Incorrect — Falco detects and alerts; it does not block.
Incorrect — signing is unrelated to a runtime shell alert.
10 questions · explanations appear as you answer
Runtime & network hardening
12 questions
01The default Docker bridge is a security concern because it…
Incorrect — encryption is not the issue; reachability is.
Correct — segment with user-defined/internal networks and default-deny egress.
Incorrect — speed is not the concern here.
Incorrect — it does not; DNS works on user-defined networks.
02A batch job that needs no connectivity should run with…
Incorrect — that removes isolation — the opposite of what you want.
Incorrect — that gives it a flat network and open egress it does not need.
Correct — no route anywhere — nothing to pivot to or exfiltrate through.
Incorrect — unrelated, and dangerous.
03Blocking egress to 169.254.169.254 from containers matters because it…
Correct — a compromised container or SSRF can assume the node’s role and pivot into the account.
Incorrect — DNS is elsewhere; this is the link-local metadata address.
Incorrect — the daemon is not on that address.
Incorrect — it is a credential-theft path, not a performance knob.
04The DOCKER-USER iptables chain is the right place for egress rules because it…
Incorrect — there are several; DOCKER-USER is specifically for your rules.
Correct — so your allow/deny survives Docker rewriting its chains.
Incorrect — it is a host firewall chain, not in-container.
Incorrect — it filters traffic; it does not remove the bridge.
05Passing a secret with -e DB_PASSWORD=... is unsafe because it is visible in…
Incorrect — it is exposed far more widely than that.
Incorrect — env vars are not encrypted.
Correct — anyone who can look at the container can read it.
Incorrect — that is a different mistake; -e leaks at runtime.
06The right way to deliver a secret to a read-only container is…
Correct — in memory, read-only, absent from inspect and the environment.
Incorrect — exactly the leak-prone path to avoid.
Incorrect — that ships it in a layer to everyone who can pull.
Incorrect — that lands in the image history.
07An external secrets store (e.g. Vault) improves on a static mounted file by providing…
Incorrect — not the benefit.
Correct — a leaked credential expires on its own and rotation happens in one place.
Incorrect — unrelated to image size.
Incorrect — that is a different control.
08--pid=host is dangerous because the container can…
Incorrect — that is the isolated default; --pid=host removes it.
Incorrect — that is --uts=host, and low risk.
Correct — host /proc exposes secrets in environ and open FDs.
Incorrect — that is NET_BIND_SERVICE, unrelated.
09Host-namespace flags like --net=host and --pid=host should be treated in review as…
Correct — each reopens a wall the rest of your hardening built — like --privileged.
Incorrect — each removes real isolation.
Incorrect — the isolated defaults are correct for almost everything.
Incorrect — they are exposure, not a default optimization.
10The first move when a container is compromised is to…
Incorrect — that destroys the evidence — the worst move.
Correct — contain first, then capture with diff/export/commit, then investigate.
Incorrect — that ships the same vulnerable image back and loses evidence.
Incorrect — the container should be assumed active and contained now.
11docker diff is valuable in an incident because it…
Incorrect — that is not what diff does.
Incorrect — it inspects one container’s changes vs its image.
Correct — a well-behaved container changes little, so attacker artifacts stand out.
Incorrect — rotation is a separate remediation step.
12After capturing evidence, correct remediation is to…
Correct — assume all reachable secrets are compromised; never restart the popped container.
Incorrect — that reintroduces the vulnerable image and the intrusion path.
Incorrect — the entry vector remains and the image is still vulnerable.
Incorrect — the root cause and exposed secrets still need action.
12 questions · explanations appear as you answer