Top identity Interview Questions & Answers

IAM is the discipline of managing digital identities and their access to resources. It covers authentication, authorisation, lifecycle, and audit.

Something you know (password, PIN), something you have (phone, hardware token), something you are (biometric). MFA requires evidence from at least two families.

Authentication proves who you are. Authorisation decides what you can do. You can authenticate and still be unauthorised.

Role-Based Access Control. Permissions are grouped into roles, and users are assigned roles. Simple, predictable, and easy to audit.

SAML 2.0 — XML assertions, enterprise-friendly. OIDC — JSON / JWT-based, built on OAuth 2.0, modern web and mobile apps. Both are federation protocols; OIDC is preferred for new builds.

A governance model that ties access changes to the employee lifecycle:

• Joiner — provision accounts and group memberships on day one.
• Mover — update memberships when the employee changes roles.
• Leaver — disable / delete accounts on the day of departure.

MFA that an attacker cannot bypass even if the user is tricked. Examples: FIDO2 / WebAuthn hardware keys, platform-bound passkeys, and smart cards. SMS, voice, and basic push are not phishing-resistant.

ABAC evaluates access decisions against attributes of the user, resource, action, and environment. More flexible than RBAC but harder to reason about. Often implemented as policy-as-code using a policy engine like OPA or Cedar.

A typical design:

• Pick one IdP (Entra ID, Okta, Google Workspace) as the authoritative source.
• Federate to all 30 apps via SAML or OIDC.
• Group-based access: assign groups to apps, drive group membership from HR attributes via SCIM.
• Conditional Access / authentication policy: enforce MFA + managed device + trusted IP for sensitive apps.
• Just-in-time provisioning for apps that support it.
• Stream all IdP and app audit logs to a SIEM.
• Quarterly access reviews per app owner.

Containment → investigation → eradication → recovery → lessons learned:

• Contain: disable the suspect account, revoke active sessions, force MFA re-registration.
• Investigate: pull IdP and target-app audit logs, correlate by user ID and session token.
• Eradicate: remove any backdoor accounts, rotate any credentials the suspect may have seen.
• Recover: restore any data the attacker modified; communicate to affected stakeholders.
• Lessons learned: document the attack chain, close the root cause, update runbook.

Each user and service gets the minimum permissions needed to do the job. Enforce by:

• Start with zero access and add only what’s needed.
• Use just-in-time elevation for admin tasks (PAM tools, Entra ID PIM).
• Run quarterly access reviews to remove drift.
• Split admin accounts from daily-driver accounts; require step-up MFA for admin actions.

Configure MFA so the user must take an action that proves they are not on autopilot:

• Number matching: the push notification contains a 2-digit code the user must type in.
• FIDO2 / WebAuthn replaces push entirely.
• Conditional Access: only send push to trusted IPs / managed devices.
• Rate limiting on the IdP side: deny N failed push attempts in M minutes.