Caches improve speed but must not become hidden correctness dependencies. Cache keys should follow the inputs that determine cached output.
Before you start
You should understand commits, branches, the working tree and the staging area. Draw the commit graph before changing history. Try commands in a disposable repository with a clean working tree so you can observe exactly which references and files each operation changes.
The practical goal is to reason through this situation: Dependency caches include lockfile and runtime information where relevant. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Define complete inputs
Cache keys should track lockfiles, runtime and relevant build settings.
Step 2: Treat misses as performance
A clean build must still succeed without cached output.
Step 3: Compare reproducibility
Investigate differences caused by stale or missing cache dependencies.
Worked scenario
Dependency caches include lockfile and runtime information where relevant.
A cached dependency directory contains an undeclared package, so CI succeeds until the cache is cleared. Clean installation reveals that the manifest is incomplete. Fix the declared inputs rather than extending cache retention; cache should accelerate a correct build, not provide hidden required state.
Common mistake
A stale cache can make a failing clean build appear successful.
Verify the behavior
Run cached and clean builds from the same source and compare outcomes.
Interview exercise
Verify reproducibility.
Answer and reasoning
Run a clean build with documented inputs and compare outcomes; treat cache misses as slower, not incorrect.
Continue learning
Compare the scenario with the Git and CI/CD interview questions and test your understanding with the Git and CI/CD MCQs. For terminology and implementation details, consult the reference material.