Container Security: Docker u0026 Kubernetes Essentials Quiz Quiz

Explore fundamental container security concepts with this quiz focused on best practices and common vulnerabilities in Docker and Kubernetes environments. Strengthen your understanding of risks and mitigation strategies relevant to container orchestration and deployment.

1. Image Source Trustworthiness

   Which approach best ensures you reduce security risks when obtaining container images for your deployments?

   1. Trust images shared through email or messaging platforms
   2. Use any readily available public image with the correct tag
   3. Download images from official and verified repositories only
   4. Select images with the lowest download count to avoid popular vulnerabilities

   Explanation: Downloading images from official and verified repositories significantly minimizes the chance of including malicious code or outdated software, thus improving security. Using any public image (option B) may expose your systems to risks if the image isn't maintained or verified. Receiving images via email or messaging (option C) is insecure and could introduce tampered files. Opting for images with the lowest download count (option D) doesn't guarantee security and may mean those images are untested or outdated.

2. Kubernetes Role-Based Access Control

   What is the primary benefit of implementing role-based access control (RBAC) within a Kubernetes cluster?

   1. It scans container images for malware before scheduling them
   2. It prevents the deployment of all pods from untrusted namespaces
   3. It restricts user and service actions based on assigned permissions
   4. It encrypts all communication between pods automatically

   Explanation: RBAC enables administrators to finely control which users and services can perform specific actions, reducing the risk of unauthorized changes or privilege escalation. While blocking pods from untrusted namespaces (option A) is not the main function of RBAC, nor does RBAC automatically encrypt communication between pods (option C). Scanning images (option D) is handled by other tools, not RBAC.

3. Least Privilege Principle

   Why is it important to run containers with the least required privileges, for example by avoiding running as the root user?

   1. It automatically reduces CPU and memory usage for each container
   2. It ensures all containers start faster on cluster nodes
   3. It helps minimize the potential damage if a container is compromised
   4. It guarantees logs are always collected centrally

   Explanation: Running containers with minimal privileges reduces the impact if an attacker gains access, as they have limited capabilities inside and outside the container. Option A is incorrect since privileges do not directly affect resource usage. Faster starts (option C) and central logging (option D) are unrelated to privilege levels.

4. Network Security Controls

   What is a recommended method for restricting traffic between pods in a Kubernetes environment?

   1. Set environment variables to block network traffic
   2. Implement network policies to control allowed connections
   3. Disable persistent storage mounting in pods
   4. Configure pod resource limits in the deployment YAML

   Explanation: Network policies offer granular control over which pods can communicate with each other, enabling strong security boundaries. Setting resource limits (option A) focuses on CPU and memory, not networking. Environment variables (option C) do not enforce network rules, and disabling storage mounts (option D) is unrelated to traffic control.

5. Container Vulnerability Patching

   When a critical vulnerability is discovered in a running container image, what is the most secure remediation step?

   1. Stop the container and remove it from the cluster immediately
   2. Update the image with a patch and redeploy affected containers
   3. Change the container’s entrypoint command to avoid the vulnerability
   4. Increase the container's resource limits to ensure stability

   Explanation: Patching the image and redeploying ensures the vulnerability is addressed while maintaining service continuity. Simply stopping and removing containers (option A) stops the service but doesn't fix the vulnerability for future deployments. Raising resource limits (option C) doesn't mitigate security flaws. Altering the entrypoint command (option D) is unlikely to eliminate the underlying issue unless the vulnerability is never triggered, which isn't a reliable method.