Transit operations wants a scheduled rebuild of the service-alert agent image whenever the base Python image is patched. Which approach fits Azure Container Registry?
Select an answer to reveal the explanation.
Short Explanation
When the base Python image gets a security patch, you do not want the transit alert agent stuck on last month's flour. A scheduled or base-image-triggered ACR Task rebuilds the agent image so the registry always has a freshly layered, still versioned build.
Full Explanation
ACR Tasks support schedules and base-image update triggers so dependent images rebuild when underlying layers change. Transit operations can configure a Task that rebuilds the service-alert agent whenever the base Python image is patched, then pushes the new agent image to ACR. That keeps the registry’s versioned civic image aligned with patched bases without waiting for resident-reported vulnerabilities. The rebuild still produces a tagged or digest-pinned artifact that hosts can pull through the normal container lifecycle.
Disabling all rebuilds and waiting for residents to report outdated packages fails proactive patching and leaves known base CVEs in production until complaints arrive. Editing production containers in place with apt-get upgrade overnight fails immutability: changes vanish on restart, diverge from the registry image, and break the “rebuild and redeploy” model Azure container exams emphasize. Replacing the container with an unmanaged VM scale set and patching only the guest OS fails the containerized ACR workflow the question asks for—it abandons image-based promotion of the agent.
Exam caveat: Base-image triggers depend on ACR knowing the base relationship (for example, images built with ACR Tasks that track bases). Scheduled rebuilds are the broader, always-available pattern. Either satisfies “rebuild when the base is patched”; in-place mutation of running containers does not.
Operational check: After a base Python patch appears, verify the ACR Task ran, a new service-alert agent tag or digest landed in the registry, and transit hosts were redeployed to that image. Confirm running containers’ image IDs match the registry artifact—not a locally apt-upgraded filesystem that differs from ACR.