# Knowledge Check: Security Model & SecurityContext --- **1. A container is hardened with `capabilities: drop: ["ALL"]` and then fails because it genuinely needs to bind to a low-numbered network port, which requires `NET_BIND_SERVICE`. What's the least-privilege fix?** *Answer:* Add back only `NET_BIND_SERVICE` specifically (`capabilities: add: ["NET_BIND_SERVICE"]` alongside the drop-all), not remove the blanket drop entirely. Least privilege means granting exactly what's needed, not reverting to granting everything. --- **2. True or false: setting `runAsNonRoot: true` fixes a vulnerability inside the application itself.** *Answer:* False. It doesn't fix anything about the application's code — it limits what a compromise of that code could DO, by ensuring the process never has root privileges to begin with. This is the defense-in-depth distinction: reducing blast radius, not eliminating bugs. --- **3. Why might `runAsNonRoot: true` cause a Pod to fail to start entirely, and is that a problem with the setting?** *Answer:* If the container image was built assuming it runs as root (e.g. it tries to bind a privileged port, or write to a root-owned directory), the Pod will fail to start under `runAsNonRoot`. This is NOT a problem with the setting — it's valuable, actionable information that the image itself makes an assumption that should probably be fixed. --- **4. A container has `readOnlyRootFilesystem: true` and needs to write temporary cache files. What's the correct way to allow that without abandoning the read-only filesystem entirely?** *Answer:* Mount an explicit `emptyDir` volume (ROOT 08) at the specific path the application needs to write to. This keeps the rest of the filesystem read-only while allowing the one legitimately-needed writable location. ## Instructor Notes **Facilitation:** Question 1 and question 4 both reinforce the same "narrow the exception, don't remove the protection" pattern — worth calling out that they're the same principle applied twice. **Approximate timing:** 5-7 minutes.