Teams store approved application images in a central place so deploy jobs can pull them during rollouts. What component fulfills that role?
Select an answer to reveal the explanation.
Short Explanation
An image registry is the city's approved parts warehouse—tagged builds sit there until deploy pulls them. Without it, every team invents a private stash and drift creeps in. Central store, controlled pulls, happier rollouts.
Full Explanation
A container image registry stores versioned images and serves them to deploy jobs and cluster nodes that pull during rollouts, acting as the central source of approved application artifacts for the municipality. Teams that keep approved images in one place so automation can pull consistently are using a registry. A cold-site generator that powers on after a regional disaster declaration is a facility readiness concept, not an image distribution system. A hypervisor host-affinity rule constrains VM placement onto particular hosts and does not hold container layers for pull. A relational OLTP database storing each container layer as SQL BLOB rows is not how production image distribution works and would cripple pull performance and layer reuse. Exam caveat: registries are about secure, versioned distribution—pair them with vulnerability scanning, signing, and promotion between tags rather than copying images ad hoc from engineer laptops. Operational check: push scanned images to a private municipal registry, restrict who can promote production tags, configure clusters to pull only from approved registries, monitor pull failures and rate limits during rollouts, and retain image digests for change audit.