TL;DR: An artifact repository manager stores build outputs and controls access to dependencies. Hosted repositories keep your releases, proxies cache upstream packages, and groups provide a shared read endpoint. A cache helps with availability, but cannot supply a dependency it never fetched or no longer retains.
How to approach it
Start with the build and release path. Where do dependencies come from, where does CI publish its output, and how does production select the tested version? Explain the repository's responsibilities at each step, then discuss the failure cases it introduces.
A strong answer
An artifact repository stores versioned outputs such as packages, archives and container images. A repository manager adds repository configuration, access controls and dependency proxying. Artifactory and Nexus use different names for similar roles:
| Responsibility | Nexus terminology | Artifactory terminology | Example |
|---|---|---|---|
| Store what your team publishes | Hosted | Local | CI uploads a versioned application package |
| Fetch and cache another repository | Proxy | Remote | Resolve a dependency from Maven Central |
| Expose several repositories through one endpoint | Group | Virtual | Developers use one read URL for internal and upstream packages |
Sonatype documents proxy, hosted and grouped repositories and Maven group resolution. JFrog describes its repository types. Format support and optional security features depend on the product and deployment.
A proxy cache is not an upstream backup. Suppose a build needs packages A and B. A is cached, but B has never been requested. If the upstream is unavailable, the proxy may serve A and still fail the build on B. Metadata expiry, revalidation, access rules and cleanup can also affect the result. Test an upstream outage with the dependencies your release actually uses, including a deliberate cache miss. Keep required release artifacts under an explicit retention policy.
Promote an identified artifact. In this example, CI builds an image once, records its manifest digest and tests that digest. Production receives the same digest, with environment configuration supplied separately. A tag such as release is a convenient name, but it may be moved unless the registry enforces immutability.
| Step | Evidence to retain | Check before proceeding |
|---|---|---|
| Build | Commit, dependencies, build identity and artifact digest | Output uploaded successfully |
| Test | Results tied to that digest | Tested bytes match the proposed release |
| Promote | Approval and destination artifact identity | Any copy preserves the intended artifact |
| Deploy | Running artifact identity and configuration version | Production uses the approved release |
| Roll back | Previous compatible digest and recovery procedure | Artifact is retained and application/data remain compatible |
Rebuilding the same branch for production can produce different bytes when dependencies, base images or build inputs change. A repository helps retain the tested output; it does not make the build reproducible by itself. The artifact as the release unit explains why promotion should preserve the tested output.
Control namespaces and permissions. Repository ordering alone is insufficient protection against dependency confusion. Package-manager resolution rules matter. Reserve internal namespaces, prevent those names from resolving through a public proxy, and test a same-name collision. Give CI permission to publish only where needed, and give deployment identities read access to approved releases.
Scanning and policy checks can be integrated into this path, but they require suitable tooling and configuration. A checksum identifies bytes; it does not prove those bytes are safe. Retain an SBOM or dependency inventory and build provenance so a newly discovered vulnerability can be traced to deployed releases.
The manager also becomes a delivery dependency. Plan backup, restore, availability and storage capacity. Cleanup must preserve artifacts needed by active deployments and rollback windows. Compare products by required formats, authentication, promotion workflow, recovery needs and operating cost; avoid choosing from a generic feature ranking.
What interviewers probe next
"How is this different from a container registry?" A container registry stores images and may support other OCI artifacts. A repository manager can expose several package formats as well as container repositories. Choose the formats and controls your build path needs.
"Will a cache keep every build working offline?" No. Test cached dependencies, missing dependencies and expired metadata. Decide which release inputs need durable retention rather than opportunistic caching.
"How do you protect rollback artifacts?" Identify the versions still referenced by deployments, exempt them from cleanup, restrict deletion and rehearse restoration. Also verify deployment compatibility; having an old image does not reverse a database migration.
Common mistakes
Claiming that a proxy guarantees availability after an upstream deletion, without checking cache contents and retention.
Promoting a mutable tag without recording the tested digest, or rebuilding separately for each environment.
Treating repository order as complete dependency-confusion protection.
Applying cleanup by age alone and deleting the version an active deployment needs to roll back.