Title: Quiz 3 — Building AI Images with Dockerfiles: Multi-Stage & Image Security
Course: AIINFRA 101: Applied Infrastructure & Containerization > Section: Week 03 — Building AI Images with Dockerfiles: Multi-Stage & Image Security

Q: What is the main purpose of a multi-stage Docker build?
- To run multiple containers from one Dockerfile
- To separate build-time dependencies from runtime dependencies, reducing final image size
- To allow a Dockerfile to build on multiple operating systems at once
- To automatically update base images
A: To separate build-time dependencies from runtime dependencies, reducing final image size

Q: Placing COPY . . (your full application source) before RUN pip install -r requirements.txt is the recommended order for maximizing Docker layer cache efficiency.
- True
- False
A: False

Q: Name one command you would add to a Dockerfile to make a container run as a non-root user instead of root.
Feedback: Sample/expected answer: `RUN useradd -m appuser`** (paired with **`USER appuser`**)

Q: Secrets such as passwords or API keys can be safely placed directly in a Dockerfile as long as the image is never pushed to a public registry.
- True
- False
A: False

Q: In semantic versioning (MAJOR.MINOR.PATCH), which segment should you increment for a backward-compatible bug fix?
Feedback: Sample/expected answer: PATCH

Q: The latest tag always points to the newest, most thoroughly tested version of an image.
- True
- False
A: False

Q: What is the primary purpose of a tool like Trivy?
- Orchestrating multi-container deployments
- Scanning images, Dockerfiles, and Kubernetes manifests for known CVEs
- Building images from a Dockerfile
- Managing Docker Hub billing
A: Scanning images, Dockerfiles, and Kubernetes manifests for known CVEs

Q: In a CI/CD severity gate, which practice is standard for blocking risky deployments while avoiding noise from unfixable issues?
- Failing the build on any finding, regardless of severity or fix availability
- Enforcing a CRITICAL/HIGH threshold combined with `--ignore-unfixed`
- Disabling scanning in CI and only scanning manually before releases
- Only scanning the base OS image, never the application layers
A: Enforcing a CRITICAL/HIGH threshold combined with `--ignore-unfixed`