Artifact Management
Store, version, and promote build outputs through environments reliably.
An artifact is the packaged output of a build — a container image, a .jar, an
npm package, a zip. An artifact repository (Artifactory, Nexus, GitHub
Packages, container registries) stores them with versioning and access control.
The core principle: build once, promote the same artifact through dev → staging → prod. Rebuilding per environment risks subtle differences. Tag artifacts immutably (semantic versions or commit SHAs), record provenance, and scan them for vulnerabilities before promotion.
# Build once, tag immutably by version + commit
docker build -t registry.example.com/app:1.4.2 .
docker push registry.example.com/app:1.4.2
# Promote the SAME image through environments (retag, don't rebuild)
docker tag registry.example.com/app:1.4.2 registry.example.com/app:staging
docker tag registry.example.com/app:1.4.2 registry.example.com/app:prod- Explain why you should build an artifact once and promote it.
- Choose a tagging scheme that supports reliable rollbacks.
- Describe where vulnerability scanning fits in the artifact lifecycle.
- Name three types of artifacts and a repository that stores each.
Cheat Sheet▾
| Concept | Detail |
|---|---|
| Artifact | Packaged build output |
| Artifact repo | Artifactory, Nexus, registries |
| Build once | Promote same artifact |
| Immutable tags | Versions / commit SHAs |
| Provenance | Track what built it |
| Scan | Check CVEs before promotion |
Common Interview Questions▾
Why build an artifact once and promote it across environments?
So the exact thing you tested is what reaches production. Rebuilding per environment can introduce differences, meaning you’d deploy something you never validated.
What is an artifact repository?
A versioned store for build outputs (images, packages, binaries) with access control, retention, and scanning — the source of truth for what gets deployed.