Kubernetes and Cloud Native Associate (KCNA)Cloud Native DeliveryMedium
A company is using a private container registry to store its Docker images. They have a CI/CD pipeline that builds new images for their microservices. After an image is built, it needs to be made available for deployment to Kubernetes clusters in various environments (dev, staging, prod). What is the next logical step in the CI/CD pipeline after a container image is successfully built and tagged?
- ADeploy the application directly to production.
- BPush the image to the container registry.
- CGenerate a Helm chart for the application.
- DRun unit tests on the application code.
Show answer & explanationAnswer & explanation
Correct answer: B. Push the image to the container registry.
After a container image is successfully built and tagged, the next logical step in the CI/CD pipeline is to push it to a container registry. This makes the image persistently stored, versioned, and accessible to other parts of the pipeline (like deployment tools) and different environments.
Why the other options are wrong
- A. Direct deployment to production usually happens much later, after further testing and validation, and is not the immediate next step after building.
- C. Generating a Helm chart is often done *before* or in parallel with image building, defining how the application will be deployed.
- D. Unit tests are typically run *before* or during the image build process, not after.
Container Image Push
The action of uploading a built and tagged container image to a container registry, making it available for storage, distribution, and subsequent deployment to runtime environments.
- Stores the immutable image in a centralized repository.
- Enables versioning and tracking of images.
- Makes images accessible to Kubernetes clusters and other deployment tools.
- Often requires authentication to the registry.
Memory trick: After building your image, 'push' it to the cloud library.