What is Git LFS and what are its CI/CD trade-offs?

WHAT THIS TESTS: This question evaluates whether you understand why Git's content-addressable object store performs poorly with large immutable binaries, and whether you can weigh operational fixes against architectural alternatives in automated build environments. Interviewers want to see that you distinguish between repository size problems and pipeline artifact management problems.

A GOOD ANSWER COVERS: A good answer hits four things in order. First, define Git LFS as an extension that replaces large files with small text pointers inside the repository while storing the actual binary content on a dedicated remote server. Second, explain the mechanics: clean filters upload binaries and write pointers on commit, while smudge filters read pointers and download binaries on checkout, which keeps the Git object graph small and clone times fast. Third, address the CI trade-offs: runners still pay the download cost, often on every ephemeral build, so you shift history bloat to bandwidth usage; you also introduce an external dependency and authentication step that can fail or rate-limit. Fourth, mention that for truly large or frequently changing binaries, an artifact store or model registry is often better than versioning binaries in Git at all.

COMMON WRONG ANSWERS: Common wrong answers include recommending shallow clones or sparse checkouts as the primary solution without explaining pointer indirection, claiming that LFS eliminates large file downloads from CI, or ignoring the authentication and caching implications for ephemeral runners. Another red flag is suggesting gitignore without acknowledging that the requirement is to version the assets, or proposing to store binaries in Git if they are over a few hundred megabytes without discussing history growth.

LIKELY FOLLOW-UPS: Interviewers may ask how you would cache LFS objects between CI runs, how to migrate an existing repository to LFS without breaking open pull requests, or how you would design a replacement using S3 and checksum files. They may also probe whether you would enforce LFS via hooks or server-side rules, and how you handle LFS billing or bandwidth quotas at scale.

ONE CONCRETE EXAMPLE: Imagine a repository with a two-gigabyte machine learning model. In native Git, every version of that model is a permanent blob, so a fresh clone could pull dozens of gigabytes of unreachable history. With LFS, the repository stores only a hundred-byte pointer per version, but a CI runner performing a checkout must still download the two-gigabyte file from the LFS server unless it uses a persistent local cache. If the team runs twenty builds per day, that is forty gigabytes of daily LFS bandwidth per model version, which makes caching or switching to an artifact store with range requests an immediate operational concern.