Sample questions
Security Authn AuthzDifficulty 2
A user successfully logs in with a valid password but then tries to open another user's private order history by changing an ID in the request. The request is blocked. Which security control caught this?
- aAuthentication, because the password was checked again on the second request
- bAuthorization, because the system checked permissions for the requested resource✓
- cEncryption, because the ID in the request was unreadable
- dRate limiting, because too many requests were sent in a short time
Explanation:The user was already authenticated (login succeeded); the block happened when the system evaluated whether that authenticated identity was permitted to access the specific resource — that check is authorization, independent of how many requests were made.
Security Authn AuthzDifficulty 2
Why can a system technically authenticate a user correctly but still make a wrong security decision?
- aBecause authentication and authorization always fail together
- bBecause correct authentication automatically grants full access to every resource
- cBecause authorization can fail independently of correct authentication✓
- dBecause passwords expire faster than authorization rules
Explanation:Authentication and authorization are separately implemented checks. A perfectly correct login flow says nothing about whether the code that follows correctly restricts what the now-known identity can do — that is a separate, commonly buggy layer.
Security Authn AuthzDifficulty 2
A backend team switches from session-based auth to self-contained tokens that carry identity claims and are verified without a server-side lookup. What is the main trade-off they accept?
- aEasier horizontal scaling, but harder immediate revocation of an issued credential✓
- bHarder horizontal scaling, but instant revocation of any issued credential
- cNo change in scaling or revocation, only a different wire format
- dTokens eliminate the need for authentication entirely
Explanation:Self-contained tokens avoid a server-side session store lookup, so any stateless server can validate them — good for scaling. The cost is that a token remains valid until it expires unless the system adds extra revocation machinery (denylist, short lifetimes, etc.), unlike a session that can be deleted server-side immediately.
Security Authn AuthzDifficulty 3
Which statement correctly compares session-based and token-based identity management?
- aSession-based approaches are inherently insecure and token-based approaches are inherently secure
- bToken-based approaches never expire, session-based approaches always expire
- cSession-based approaches cannot work across multiple servers under any circumstance
- dEach has different trade-offs around scaling and revocation; neither is universally superior✓
Explanation:Neither model is categorically 'more secure' — the choice is an engineering trade-off between server-side state (easy revocation, needs shared session storage to scale) and self-contained tokens (easy scaling, harder immediate revocation). Security depends on correct implementation in either case.
Security Authn AuthzDifficulty 2
An attacker steals a user's password through a phishing page and then also convinces the user, via a fake support call, to read out a one-time code from their MFA app. What does this scenario illustrate about MFA?
- aMFA is useless because passwords can be phished
- bMFA reduces risk but is not immune to social engineering targeting the human factor✓
- cMFA only fails when the second factor is a hardware device
- dThis scenario is impossible because MFA codes cannot be shared verbally
Explanation:MFA meaningfully raises the bar against automated or password-only attacks, but it is not immune to social-engineering that targets the human handling the second factor (e.g. tricking someone into revealing a one-time code); it shifts the weak point rather than removing it entirely.
Security Authn AuthzDifficulty 2
A login endpoint checks the password, and if correct, sets mfa_verified = true in the session immediately without asking for the second factor. What weakness does this introduce?
- aThe MFA step is effectively bypassed by trusting the flag before verification✓
- bNone — setting the flag right after password check is the standard correct pattern
- cThis only matters if the password is also weak
- dThis is safe as long as the session cookie is marked secure
Explanation:If the session is marked as MFA-verified before the second factor is actually confirmed, downstream code that trusts that flag treats the login as fully multi-factor when only the password check has happened — a logic bug that silently defeats the purpose of MFA.