Learn the vocabulary of verifying exactly how a software artifact was built.
0 / 5 completed
1 / 5
At standup, a dev mentions attaching a signed, verifiable record of exactly how a software artifact was built, including the source commit and build system used, so a consumer can confirm its origin. What is this record called?
Build provenance, as defined by the SLSA framework, is a signed, verifiable record of exactly how a software artifact was built, including details like the exact source commit and the build system that produced it, letting a consumer cryptographically confirm the artifact's true origin. A manually written changelog entry carries no cryptographic guarantee and could be inaccurate or tampered with. This verifiable provenance record is a core building block for establishing real trust in a software supply chain.
2 / 5
During a design review, the team wants their build process to run in an isolated, ephemeral environment so a compromised prior build can't tamper with a later one. Which capability supports this?
An isolated, ephemeral build environment runs each build in a fresh, temporary environment that's discarded afterward, so a compromised or tampered prior build state can't carry over and affect a later, separate build. Reusing the same persistent build environment across every build risks a contamination or tampering issue from one build silently affecting subsequent ones. This isolation is a key requirement at the higher SLSA levels for establishing genuinely trustworthy build provenance.
3 / 5
In a code review, a dev notices the build pipeline configuration itself is stored in version control and requires the same review process as any other code change, rather than being editable directly on the build server. What does this represent?
Treating build pipeline configuration as reviewed, version-controlled code requires the same review process as any other code change, preventing an unreviewed, undocumented modification to the build process itself. Allowing direct edits on the build server with no review creates an unaudited path for someone to tamper with how artifacts get built. This discipline extends the supply-chain trust boundary to include the build process's own configuration, not just the source code it builds.
4 / 5
An incident report shows a compromised build server injected malicious code into an artifact during the build step, and no provenance record existed to reveal the tampering had occurred. What practice would prevent this?
Generating and verifying signed build provenance for every artifact gives a consumer a way to detect an unexpected or invalid build origin, such as an artifact that doesn't match its claimed source commit or build system. Skipping provenance generation and simply trusting the build server removes the very mechanism that could have revealed the tampering. This verification step is exactly what the SLSA framework's provenance requirement exists to enable, turning an invisible compromise into a detectable one.
5 / 5
During a PR review, a teammate asks why the team generates a signed provenance record for every build instead of just trusting that their existing build pipeline works correctly. What is the reasoning?
Simply trusting that a build pipeline works correctly provides no way for a downstream consumer to independently verify that trust, especially if the pipeline itself were ever compromised. A signed provenance record lets that consumer cryptographically confirm the artifact's real origin rather than relying on unverifiable assumptions. The tradeoff is the added infrastructure needed to generate, sign, and distribute this provenance data alongside every build artifact.
What does the "SLSA Build Provenance Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to slsa build provenance vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.