Note: the answer key below is for instructor reference only and is hidden from the student-facing view of this exam. This exam covers all material from Weeks 1–6: containerization fundamentals, Docker images and Dockerfiles, container registries, Docker Compose, container networking/storage, and core Kubernetes concepts (cluster architecture, Pods, and scheduling basics).
You're supporting a small team that has been running a FastAPI-based iris-classifier inference service (from Week 3) as a single Docker container on one developer's laptop using docker run. The team wants to hand this off to you to containerize properly and get it running reliably on a small Kubernetes cluster, in preparation for adding replicas and a stable network endpoint next week. Describe, step by step, how you would take this from "container running ad hoc on a laptop" to "image built, pushed to a registry, and a single Pod running on the cluster," and explain what could go wrong at each step and how you'd verify it worked. → Model answer: (1) Write/confirm a Dockerfile with a minimal base image, copy in the FastAPI app and dependencies, expose the correct port, and set the correct CMD/entrypoint — verify by building locally with docker build and running with docker run -p to confirm the API responds. (2) Tag the image appropriately (e.g., registry/iris-classifier:v1) and push it to a container registry — verify by pulling it fresh on another machine or docker rmi + re-pulling to confirm it's not relying on local build cache. (3) Write a Pod manifest (or minimal Deployment) referencing the pushed image, apply it with kubectl apply -f, and use kubectl get pods / kubectl describe pod / kubectl logs to confirm it reaches Running status and the app logs show successful startup. Common failure points: forgetting to expose/bind the right port, pushing to a registry the cluster can't authenticate to or pull from (ImagePullBackOff), and forgetting resource requests, which the course has emphasized are needed for the scheduler to place the Pod sensibly.
a) Containers require a full guest OS; VMs don't b) Containers share the host OS kernel; VMs each run their own full OS c) Containers are always slower to start than VMs d) There is no meaningful difference → b
→ False — an image is the immutable template; a container is a running (or stopped) instance created from that image.
→ CMD (or ENTRYPOINT)
a) To make builds slower for security b) To keep the final image small by excluding build-time-only dependencies c) To run multiple containers at once d) To avoid using a registry → b
→ True
→ It stores and distributes container images so they can be pulled and run on other machines/clusters.
docker-compose.yml?a) It removes the need for images b) It lets you define and run a multi-container application together with shared networking/volumes as one unit c) It replaces Kubernetes entirely d) It only works for databases → b
→ True
→ The Pod
a) kubelet b) etcd c) the scheduler d) the Service → c
localhost.→ True
→ Because any data written to a container's writable layer is lost when the container/Pod is deleted or rescheduled; a volume decouples data from the Pod's lifecycle so it survives restarts/rescheduling.