PrincipalSecurity

How do you threat model a new system? Walk me through how you think about what could go wrong.

What they are really testing: Principal-level: do you have a structured, repeatable way to reason about attack surface and risk before building, rather than bolting on security after. They want a method, not a checklist of tools.

A real interview question

How do you threat model a new system? Walk me through how you think about what could go wrong.

What most people say

drag me

I would think about how a hacker might attack the system and add protections for those cases.

Ad hoc and unstructured, "think about how a hacker might attack" misses things. Principal-level threat modeling is a repeatable method: map trust boundaries, apply STRIDE, prioritize by risk, which this answer lacks.

The follow-ups they ask next

  • What is a trust boundary and why focus threat modeling there?

    A point where data or control crosses between different trust levels (internet/app, app/DB, tenant/tenant). Most vulnerabilities live at boundaries because that is where assumptions about who is calling break down.

  • You cannot mitigate every threat you find. How do you decide?

    Risk = likelihood x impact. Mitigate the high-risk realistic ones, and for the rest make a conscious decision to accept, transfer (insurance/third party), or defer, documented, not silently ignored.

What the interviewer is listening for

  • Maps data flows and trust boundaries
  • Uses a framework like STRIDE for breadth
  • Prioritizes by risk and treats it as living

What sinks the answer

  • Ad hoc "think like a hacker"
  • No notion of trust boundaries or a method
  • Tries to fix everything or nothing

If you genuinely do not know

Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.

I make it structured, not a brainstorm. First [map components, data flows, and trust boundaries]. Then [name the assets worth protecting]. Enumerate threats with [STRIDE at each boundary, for breadth]. Prioritize by [likelihood x impact], [design controls for the top risks and explicitly accept/transfer the rest], and [revisit as the system changes]. Goal: [design security in, not bolt it on].

Keep going with security

All 336 cloud engineer questions

Knowing the answer is not the same as recalling it under pressure

Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.

Start free