A development team adopting a secure SDLC for a cloud application asks where threat modeling belongs in its sequence of requirements, design, development, testing, deployment and maintenance. In which phase should threat modeling first be performed?
Select an answer to reveal the explanation.
Short Explanation
Threat modeling is how you find the weak spots on the blueprint before the concrete's poured. That means design phase, while you can still move a wall for the price of an eraser. Do it in testing or deployment and you're finding problems you have to tear out.
Full Explanation
Threat modeling examines a system's architecture, components, trust boundaries and data flows to identify what could go wrong and which mitigations are needed. It belongs first in the design phase, once requirements are known and an architecture has been proposed, because that is when design changes are cheapest and when missing controls can still be built in rather than retrofitted. The model is then revisited whenever the design changes significantly. Doing it during development narrows the view to individual functions; developers reviewing their own code can catch implementation flaws, but they will not see architectural threats such as an unprotected trust boundary between services or an exposed management interface. Using dynamic scan results in testing reverses the logic: scanners find implementation defects in what was built, while threat modeling is meant to decide what should be built and tested in the first place. Waiting until deployment means the architecture is already fixed and running, so any significant finding forces rework in production. Exam caveat: threat modeling is iterative, and updating the model during later phases is good practice, but the exam expects the first and most valuable pass to be in design. Operational check: confirm the design review checklist requires a current threat model with data flow diagrams, and that identified threats are tracked to mitigations and test cases.