Learn the vocabulary of systematically enumerating a system's assets, entry points, and attackers before writing code.
0 / 5 completed
1 / 5
A teammate describes a structured process run early in a design phase that systematically enumerates a system's assets, entry points, and potential attackers, then ranks the resulting risks before any code is written. What practice is being described?
Threat modeling is exactly this: a structured process, often run during design, that systematically enumerates a system's assets, entry points, trust boundaries, and potential attackers, then ranks the resulting risks so mitigations can be designed in before any code is written. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This enumerate-and-rank-risks-before-coding approach is exactly why threat modeling is a standard step in secure design review rather than something done only after an incident.
2 / 5
During a design review, the team runs a threat-modeling session for a new payments API, specifically to identify entry points an attacker could exploit and rank them by impact before any implementation begins. Which capability does this provide?
Threat modeling here provides early, structured identification of the system's highest-risk attack surface, since the process ranks concrete entry points and attacker capabilities before code exists that would be expensive to change later. Waiting for a penetration test after the API ships finds vulnerabilities only after implementation choices are already baked in, making fixes costlier. This identify-risks-before-implementation behavior is exactly why threat modeling is favored during design rather than after release.
3 / 5
In a code review, a dev notices a new payments API shipped without any documented entry-point or trust-boundary analysis, and the only security review happens via an external penetration test scheduled months after launch. What does this represent?
This is a missed threat-modeling opportunity, since enumerating entry points and trust boundaries during design would surface high-risk issues before implementation instead of relying solely on a delayed penetration test. A cache eviction policy is an unrelated concept about discarded cache entries. This ship-without-analysis pattern is exactly the kind of gap a reviewer flags once a sensitive system like a payments API is involved.
4 / 5
An incident report shows a payments API's most severe vulnerability, an unauthenticated internal admin endpoint, was only discovered by a penetration test three months after launch, because no structured entry-point analysis happened during design. What practice would prevent this?
Running a threat-modeling session during design lets entry points like the internal admin endpoint be enumerated and their exposure risk ranked before implementation ships. Continuing to rely solely on a delayed penetration test regardless of how severe an undiscovered entry point might be is exactly what let the vulnerability go unnoticed for months in this incident. This design-time-enumeration approach is the standard fix once relying only on post-release testing is confirmed to be too slow to catch severe issues.
5 / 5
During a PR review, a teammate asks why the team runs formal threat modeling instead of just relying on a penetration test after each release, given that penetration tests are already budgeted and scheduled. What is the reasoning?
Threat modeling trades some upfront design-time effort for catching high-risk issues before implementation is locked in, while a penetration test is valuable but only runs after release, when fixes to architectural issues are far more expensive. This is exactly why threat modeling is favored during design for sensitive systems, while a post-release penetration test remains a useful, complementary check rather than a substitute for design-time analysis.
What does the "Threat Modeling Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to threat modeling 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.