3.1. Container Application Hosting
💡 First Principle: A container image is a frozen, portable promise: the same bytes run identically on a laptop, in App Service, or across an AKS cluster. Everything in this section — registries, automated builds, runtime configuration — exists to manage that promise's life cycle: create it reproducibly, version it immutably, and configure it at runtime rather than baking environment-specific details into the frozen artifact.
Why care? Because in an AI system, reproducibility is your defense against dependency chaos — Python AI stacks pin dozens of native libraries, and "works on my machine" dies in production. The image freezes the whole stack. The exam tests whether you keep the promise: images that are versioned (not latest-roulette), rebuilt when their foundations rot, and configured from outside.
The mental model: ACR is a versioned artifact warehouse. Every shippable build gets a labeled shelf slot (repository:tag); ACR Tasks are the warehouse's robots, restocking shelves automatically when source code or base images change; App Service is the showroom floor where a shelved artifact goes live with its runtime configuration attached.
⚠️ Common Misconception: "Environment variables for a containerized app must be baked into the image at build time." App Service injects app settings as environment variables at runtime, overriding image-defined values — and can resolve them from Key Vault. Baking config (worse, secrets) into images makes one environment's build unusable in another and freezes credentials into an artifact anyone with pull access can inspect.
