Cover multi-tenant specifics: tenant isolation, federated identities across orgs
0 / 5 completed
1 / 5
The interviewer asks: "Walk me through implementing OAuth 2.0 Authorization Code Flow with PKCE for a single-page application." Which answer demonstrates both security awareness and implementation depth?
Option B is strongest: it explains why PKCE is needed for SPAs (no client secret), walks through each step with correct technical vocabulary (code_verifier → SHA-256 → code_challenge), names the attack PKCE prevents (code interception), specifies token lifetimes and storage security (httpOnly cookie prevents XSS), and adds CSRF protection (state parameter) and signature validation. Option D is dangerously wrong — Implicit Flow was deprecated in OAuth 2.1 because it exposes tokens in URLs. Option C is correct but shallow. Key pattern for OAuth questions: name why this flow is appropriate → walk each step precisely → cover the security properties of each step → name what attacks it prevents.
2 / 5
The interviewer asks: "RBAC vs. ABAC — walk me through when you would choose each, with a concrete example." Choose the answer that best demonstrates practical design experience.
Option C is strongest: it gives concrete examples for each model, shows the ABAC policy syntax, articulates the trade-off (power vs. auditability), gives a pragmatic hybrid recommendation, and names real implementation tools (OPA, Cedar). Option D demonstrates awareness of ReBAC/Zanzibar which is advanced and correct but it doesn't answer the RBAC vs. ABAC question directly — it sidesteps to a third model. Option A is correct but too abstract. Design comparison question structure: concrete use case for each option → tradeoff → practical recommendation → implementation tool.
3 / 5
The interviewer asks: "A service account key was committed to GitHub and is now public. Walk me through your response." Which answer demonstrates a complete incident response approach for an IAM incident?
Option D is strongest for several reasons: it distinguishes revoke from rotate (a common interview trap), sequences the steps correctly (revoke first, then investigate — not the other way around), identifies the risk of lateral movement (key may have had permissions to create new credentials), emphasises evidence preservation, and covers both immediate and long-term remediation including the pre-commit hook. Option B's first step (delete the service account) is wrong — you might need the account for audit purposes and should revoke the key, not delete the account. Option A is correct but leaves out lateral movement, blast radius assessment, and evidence preservation. Incident response structure: contain → investigate → assess → notify → remediate → prevent recurrence → post-mortem.
4 / 5
The interviewer asks: "Design an IAM system for a multi-tenant SaaS product where each tenant can configure their own SSO." Choose the answer that best covers the design dimensions.
Option A is strongest: it covers all critical design dimensions — per-tenant IdP federation with both SAML and OIDC support, tenant isolation mechanism (tenant_id in tokens), configuration storage (encrypted), the emergency access fallback (often missed), JIT provisioning, and the separation of tenant vs. platform admin privilege domains. Option D describes the correct flow but is shallow and misses JIT provisioning, emergency fallback, and isolation guarantee details. Option B outsources the decision to a vendor but a design question expects you to describe how it works, not just which vendor. Option C describes subdomain routing but stops at routing — doesn't address the isolation, provisioning, or security properties. Multi-tenant IAM design checklist: federation model (SAML/OIDC) → tenant isolation mechanism → configuration storage → emergency access → provisioning strategy → privilege domain separation.
5 / 5
The interviewer asks: "How would you migrate from a custom in-house authentication system to a managed IdP without user disruption?" Which answer best demonstrates migration engineering experience?
Option B is strongest: it describes the lazy migration pattern (industry-standard for zero-disruption auth migration), covers the critical password handling constraint (no raw password export), specifies a gradual rollout strategy with monitoring signals, plans the legacy system deprecation timeline, and identifies the 2FA re-enrollment edge case that's commonly missed. Option D's maintenance window approach causes user-visible downtime and the "send everyone a reset email" forces disruption for 100% of users. Option C describes a reasonable high-level approach but doesn't specify the lazy migration mechanism or gradual rollout percentage. Option A is dangerously wrong — "hash the passwords to the new system's format" is not possible; you cannot re-hash existing bcrypt hashes without the plaintext. Auth migration structure: parallel run → lazy migration with credential capture → gradual rollout → deprecation timeline → edge cases (2FA, SSO users).