An organization is setting up an automated CI/CD pipeline for machine learning. Where should the pipeline upload the built Docker images containing the models to make them available for deployment?
Select an answer to reveal the explanation.
Short Explanation
Check this out: once you've built your Docker image with your model inside, you need a place to put it so your deployment servers can grab it. Think of a container registry like an app store, but for your custom Docker containers. Systems like Amazon ECR or Docker Hub store these massive images securely. When your Kubernetes cluster or cloud service needs to launch the model, it reaches out to the container registry, pulls down the exact image version, and spins it up. It doesn't store your raw database text or your training data—it stores the executable images. Simple as that!
Full Explanation
In an MLOps pipeline, a container registry is a dedicated service designed to store, manage, and distribute container images (most commonly Docker images). After a model is trained and packaged along with its application code and dependencies into a container image, that image must be hosted in a location that is highly accessible to the orchestration and deployment infrastructure (such as Kubernetes, Amazon ECS, or Google Cloud Run).
The container registry serves as the intermediary in this process: 1. Centralized Storage: It hosts the built images, keeping track of image tags (e.g., :latest, :v1.2, :sha-256abc). 2. Access Control and Security: It manages permissions, ensuring only authorized deployment pipelines or production clusters can pull specific images. Many registries also run automated vulnerability scans on the images. 3. Distribution: It is optimized for high-throughput distribution, allowing deployment servers to pull down large image layers quickly to scale instances horizontally.
Let's review the incorrect options: - Option A is incorrect because SQL databases are designed for relational tables and transactional query data, not for storing large binary container images. - Option B is incorrect because git repositories (like GitHub) are designed for tracking changes in source code (text files). Storing large compiled binary container images in git leads to performance issues and is not supported by standard workflows. - Option D is incorrect because data lakes/lake houses are specialized for storing raw, semi-structured, or unstructured datasets (like CSVs, Parquet, or JSON) for data engineering and model training, not for application runtimes.