What is an artifact repository and why not just a shared filesystem?

WHAT THIS TESTS: The interviewer wants to know if you understand that a CI/CD pipeline is a supply chain, not just a script. Artifact repositories are the backbone of that supply chain. The question probes your grasp of immutability, security boundaries, metadata-driven automation, and the operational differences between structured artifact management and flat file storage.

A GOOD ANSWER COVERS: First, define an artifact repository as a versioned, metadata-aware system for storing binaries, container images, and packages, such as Nexus, Artifactory, or cloud-native equivalents. Second, explain immutability and integrity: once published, an artifact should never be overwritten in place, and repositories enforce checksum validation so downstream stages can verify what they consume. Third, cover access control and auditability: repositories offer role-based access control down to the package level, plus audit logs for compliance, which a shared filesystem rarely provides without significant custom engineering. Fourth, discuss API-driven workflows: repositories expose REST or CLI interfaces that support hundreds of concurrent pulls without file locking issues, let pipelines query versions, promote artifacts from dev to staging to production, and pull dependencies without manual file copying. Fifth, mention performance and caching: modern repositories use content-addressable storage and edge caching to deduplicate layers and speed up distributed builds across multiple agents or regions.

COMMON WRONG ANSWERS: A major red flag is saying a shared filesystem like NFS or SMB is simpler and therefore good enough. Another is conflating an artifact repository with source control, claiming Git can store binaries at scale. Some candidates focus only on storage capacity and ignore the governance layer entirely. Saying you can just version folders on a filesystem by naming them v1 or v2 shows a lack of understanding about concurrent access, locking, and integrity guarantees.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle artifact promotion across environments without rebuilding, how to sign artifacts for supply chain security, or how to clean up old artifacts while maintaining reproducibility. They might also probe disaster recovery, asking how you replicate an artifact repository across regions, or how you pin exact artifact versions in Kubernetes manifests to avoid drift.

ONE CONCRETE EXAMPLE: Imagine a Java microservice built with Maven. The pipeline compiles code, runs tests, and publishes a 75 MB JAR and its POM to an internal Artifactory instance. The repository assigns immutable coordinates and a SHA-256 checksum. A downstream deployment job uses an API call to request the exact version tagged staging-20240605, verifies the checksum, and deploys it. If the artifact sat on a shared filesystem, any user with mount access could overwrite the JAR, a second job might read a partially written file, and there would be no native audit trail showing who promoted what and when.