What are Build Artifacts in CI/CD?
Learn what build artifacts are, why teams build once and promote the same artifact through every stage, and how it enables reliable rollback.
Expected Interview Answer
A build artifact is the versioned, immutable output produced by a CI pipeline's build stage — such as a compiled binary, a Docker image, or a packaged archive — that gets stored once and then promoted unchanged through later test and deployment stages.
Instead of rebuilding the application separately for staging and production, which risks subtle differences between what was tested and what ships, a pipeline builds once, tags the resulting artifact with a unique identifier such as a commit SHA or version number, and pushes it to an artifact repository like Docker Hub, Artifactory, or a cloud storage bucket. Every subsequent stage — integration tests, staging deploy, production deploy — pulls that exact same artifact rather than regenerating it, guaranteeing what was tested is bit-for-bit what runs in production. This build-once-promote-many-times pattern also speeds up pipelines since compilation only happens once, and it gives teams a reliable rollback path by simply redeploying a previous artifact version. Artifact retention policies typically keep recent builds and prune old ones to control storage cost.
- Guarantees the exact tested binary is what gets deployed
- Avoids redundant rebuilds at every pipeline stage
- Enables fast rollback by redeploying a prior artifact version
- Provides traceability from a deployed version back to its exact source commit
AI Mentor Explanation
A build artifact is like a single prepared cricket bat that gets knocked-in once at the factory and then used unchanged through practice nets, a warm-up match, and the actual tournament — the same physical bat, not a freshly made one at each stage. If the bat performs well in the warm-up, the team trusts the exact same bat in the final, rather than risking a newly made one behaving differently. Each bat gets a serial number so the team always knows exactly which bat played which match. If a bat cracks, they simply pull out the previous serial-numbered bat from storage.
Step-by-Step Explanation
Step 1
Build once
Compile or package the application a single time in the build stage of the pipeline.
Step 2
Tag and publish
Assign a unique version (commit SHA, semver tag) and push the artifact to a repository like Artifactory or a registry.
Step 3
Promote unchanged
Test, staging, and production stages pull the exact same artifact rather than rebuilding it.
Step 4
Retain for rollback
Keep recent artifact versions so a bad deploy can be reverted by redeploying a prior version.
What Interviewer Expects
- Understanding of “build once, deploy many times” as the core principle
- Awareness of artifact repositories (Artifactory, Docker registries, S3)
- Knowledge of why rebuilding at each stage is risky
- Ability to explain how artifacts enable fast rollback
Common Mistakes
- Rebuilding the application separately for each environment
- Not tagging artifacts with a traceable version identifier
- Confusing a build artifact with source code
- Forgetting to define a retention/cleanup policy for old artifacts
Best Answer (HR Friendly)
“A build artifact is the actual packaged output of our build — like a compiled app or a Docker image — that we build exactly once and then move through testing and into production unchanged. That way we know for certain the thing we tested is the exact same thing running live, and if something goes wrong we can instantly roll back to a previous version instead of rebuilding under pressure.”
Code Example
jobs:
build:
steps:
- run: docker build -t registry.example.com/app:${{ github.sha }} .
- run: docker push registry.example.com/app:${{ github.sha }}
deploy-staging:
needs: build
steps:
- run: kubectl set image deployment/app app=registry.example.com/app:${{ github.sha }} -n staging
deploy-prod:
needs: deploy-staging
steps:
- run: kubectl set image deployment/app app=registry.example.com/app:${{ github.sha }} -n prodFollow-up Questions
- Why is “build once, deploy many” preferred over rebuilding per environment?
- What tools are commonly used as artifact repositories?
- How would you design an artifact retention and cleanup policy?
- How does artifact versioning support fast rollback?
MCQ Practice
1. What is a build artifact?
A build artifact is the packaged, versioned output produced once by the build stage and promoted through later stages.
2. Why is “build once, promote many times” preferred?
Reusing the same built artifact across stages avoids discrepancies between what was tested and what is deployed.
3. What commonly identifies a specific build artifact version?
Artifacts are typically tagged with a commit SHA or version number for traceability and rollback.
Flash Cards
What is a build artifact? — The versioned, immutable output of a build stage, like a binary or Docker image.
What pattern do artifacts enable? — Build once, promote the same artifact through every later stage.
Why tag artifacts? — For traceability back to source and to enable rollback to a prior version.
Name an artifact repository tool. — JFrog Artifactory or a Docker container registry.