A municipal development team packages a permitting microservice into a container image for consistent deployment. Which application hosting approach does that packaging represent?
Select an answer to reveal the explanation.
Short Explanation
A container image is a packed lunch for the app — code plus dependencies travel together. That is the containers hosting path, not SQL rows or file shares pretending to be runtimes. Keep the packaging story on containers.
Full Explanation
Containers as an application hosting option package the application and its dependencies into an image so the same artifact can run consistently across environments. A municipal permitting microservice packaged this way represents that containers approach: the image carries runtime libraries with the code, reducing environment drift when promoting builds from lab to production. Azure SQL stores relational data; container images are not defined as SQL rows, and hosting the microservice is not accomplished by storing it as table rows. Azure Files exposes managed file shares; SMB locks are not how container images execute workloads. Azure Advisor offers recommendations for cost, reliability, security, and performance; it does not convert recommendation text into running containers on its own. The describe-level skill is recognizing packaging-and-hosting intent, not memorizing every orchestrator SKU. Exam caveat: AZ-900 expects the conceptual packaging story—images and consistent deployment—not deep Kubernetes versus Container Apps versus ACI configuration details. Operational check: build or pull the permitting image, run it in a chosen Azure container host, and confirm the same image tag yields the same dependency set in test and production before exposing the microservice to other city systems.