Sample questions
Security Authn AuthzDifficulty 1
What is the core conceptual difference between authentication and authorization?
- aAuthentication verifies who you are; authorization decides what you are allowed to do✓
- bAuthentication decides what you are allowed to do; authorization verifies who you are
- cThey are two names for the same identity-verification step
- dAuthentication applies only to humans, authorization only to machine accounts
Explanation:Authentication (proving identity, e.g. via credentials) and authorization (checking permissions against that established identity) are distinct steps that always happen in that order — a system must know who the caller is before it can decide what they may do.
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 1
In session-based authentication, where does the server typically keep the authoritative record of who is logged in?
- aOnly inside the browser's local storage, never on the server
- bIn server-side session state, referenced by an identifier the client holds✓
- cInside the user's password, re-sent with every request
- dNowhere — session-based authentication has no server-side state by definition
Explanation:Session-based authentication keeps the authoritative login state on the server (in memory, a database, or a shared store); the client only holds an opaque session identifier used to look that state up on each request.
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.