identity

A VPN answers 'are you allowed on the network?'. Zero-trust access asks 'may this user, on this device, reach this application right now?'. The interview tests whether you can explain why the second question is safer.

Mutual TLS proves who connected to whatever terminated the TLS. If that is a load balancer, the application only knows what a header tells it, and headers can be forged.

Ten seconds of definition, then the part that scores: why most access bugs happen to users who logged in perfectly.

Drawing the arrows is half the answer. The other half is pinning an attack to every parameter: state, redirect URI, code, verifier, audience.

Every candidate knows OIDC is 'OAuth plus identity'. Fewer can say which token goes where, and what breaks when they swap.

'JWTs are stateless and scale' is half an answer. The other half is what happens the day you need to log someone out right now.

Documents are shared with people, folders, teams and links. Roles alone collapse under that, and the interviewer wants to see you notice when.

The token tells you which algorithm to use and where to find the key. Believing it is how signature checks become no checks.

Both are 'something you have'. One can be typed into a fake page in real time; the other checks which page is asking.

A service account is the easy answer and the wrong one. The interviewer wants both identities visible in every call, scoped to the task, and revocable by the user.

A 1988 bug report that describes most agent incidents. The answer that scores turns it into a design rule: authority travels with the request.

Static API keys in environment variables are the most common credential leak there is. The answer is platform-issued, short-lived, attested identity.

The signature verifies, and the application reads a different element than the one that was signed. Most SAML bugs are some version of that sentence.

Each token verifies against some trusted key. The bug is that the key belonged to a different issuer than the one the token claims, or the user ID means something different there.

The user never types anything an attacker could replay, and the browser, not the user, decides which site is asking. Those two facts are the whole phishing story; the ceremony is how they are enforced.

Moving passwords from config files into a secret manager helps only if the application's way of logging in to the secret manager is not itself a password in a config file.

Deleting the commit feels like fixing the leak. It isn't: the secret was public the moment it was pushed, and only revoking it ends the exposure.

The victim types a code on the real Microsoft sign-in page, passes MFA, and hands the attacker their tokens. The scored answer explains why nothing looks wrong and which policy actually stops it.

Resetting the password is step four, not step one. Attackers keep access through sessions, app consents and mailbox rules, and the money moves faster than the investigation.

Infostealers turned stolen passwords and cookies into a commodity with sellers, buyers and price lists. The scored answer follows the supply chain and cuts it at the points you control.

Build a permission worksheet for each tool: acting principal, task grant, objects, recipients, bounds and enforcement. Treat reads and reversible writes as potentially consequential.