Cybersecurity Interview Questions — Part 10: Identity & Access Management
Fifteen identity and access management interview questions covering IAM programme structure, phishing-resistant authentication, passwordless, RBAC and ABAC, role explosion, entitlement right-sizing, privileged access management, single sign-on, federation, OpenID Connect, identity lifecycle, access certification, non-human identities, identity attack detection, and programme prioritisation.
# Cybersecurity Interview Questions — Part 10: Identity & Access Management
## Fifteen identity and access management interview questions covering IAM programme structure, phishing-resistant authentication, passwordless, RBAC and ABAC, role explosion, entitlement right-sizing, privileged access management, single sign-on, federation, OpenID Connect, identity lifecycle, access certification, non-human identities, identity attack detection, and programme prioritisation.
Part 9 ended with a point that this part expands into a whole domain: in modern environments, identity is the control plane. The network perimeter constrains less every year, endpoints are increasingly unmanaged, and applications live in dozens of places — but every one of those still asks the same question before doing anything. Who is this, and what are they allowed to do?
That is why identity and access management has moved from an IT administration function to one of the most consequential security disciplines, and why IAM questions now appear in interviews for roles that have nothing to do with running a directory. Getting identity right prevents entire categories of incident. Getting it wrong makes every other control conditional.
This part is deliberately vendor-neutral. Parts 8 and 9 covered the mechanics in two specific platforms; this one covers the discipline — the models, the lifecycle, the governance, and the failure modes that recur regardless of which products are involved.
I’m Karanam Shrivasta. This series is written as public study notes.
— -
# Cybersecurity Interview Questions — Part 10
## Question 1: What are the components of an identity and access management programme, and how do they fit together?
**Answer:**
An identity source of truth and lifecycle process; authentication, including factors and single sign-on; authorisation, expressed through an access model; privileged access management for high-risk accounts; governance covering certification, segregation of duties, and audit; and coverage of non-human identities. They fit together as a chain: an identity is created from an authoritative source, proven at authentication, granted entitlements by a model, monitored while it exists, and removed when the underlying relationship ends.
**Explanation:**
| Component | Question it answers | Common failure |
| — — | — — | — — |
| Identity lifecycle | Who exists, and why? | Accounts outliving the person’s relationship with the organisation |
| Authentication | Are they who they claim? | Non-phishing-resistant factors on high-value accounts |
| Authorisation model | What may they do? | Entitlements granted by copying a colleague |
| Privileged access | Who holds elevated rights, and when? | Standing privilege that is never withdrawn |
| Governance | Is this still correct? | Certification treated as a formality |
| Non-human identity | What do machines and services hold? | Untracked, unrotated, over-privileged service credentials |
| Monitoring | Is this identity behaving normally? | Identity telemetry not collected or not correlated |
Two structural points worth making:
- **An authoritative source is a prerequisite for everything else.** If nobody can say definitively who works here, in what role, reporting to whom, then no downstream control can be correct. In most organisations that source is the human resources system for employees, and the gap is contractors, partners, and machine identities — which is exactly where the untracked accounts live.
- **Governance is what stops entropy.** Every other component degrades over time without review: entitlements accumulate, roles blur, privileged membership grows. A programme without certification is a programme that was correct once.
The maturity progression is worth naming: from manual administration, to centralised authentication, to a defined access model, to automated lifecycle, to continuous risk-based access decisions. Most organisations are somewhere in the middle and are trying to do the last one before finishing the second.
**Example / Scenario:**
An assessment finds that a company has strong authentication and no authoritative source for contractors. Contractors are created manually by whoever needs them, and nothing triggers their removal. Multi-factor authentication is protecting a population of accounts that nobody can enumerate — a good control on an unknown denominator, which is the least measurable position to be in.
**Interview Tip:**
Start with the authoritative source rather than with authentication. Most candidates open with multi-factor authentication because it is the visible control, but an interviewer assessing IAM thinking wants to hear that you would first establish who should exist. “Strong authentication on accounts you cannot enumerate is unmeasurable” is a line worth having ready.
— -
## Question 2: What makes an authentication method phishing-resistant, and why are most multi-factor methods not?
**Answer:**
A method is phishing-resistant when the credential is cryptographically bound to the legitimate site or service, so it cannot be replayed against a different destination, and when there is no shared secret or code that a person can be persuaded to reveal or approve. Codes, push approvals, and one-time passwords all fail this test because they can be relayed in real time through an intermediary site or approved by a confused user.
**Explanation:**
The distinction is not about how many factors are used but about whether the exchange is bound to an origin.
| Method | Phishing-resistant | Why |
| — — | — — | — — |
| Password only | No | Directly disclosable |
| SMS or email code | No | Relayable in real time; also exposed to number-porting abuse |
| Time-based one-time code | No | Relayable within its validity window |
| Push approval | No | Approvable by a user under pressure or fatigue |
| Push with number matching | Partially | Raises effort and reduces accidental approval, but still relayable in principle |
| Certificate-based authentication | Yes | Bound cryptographically, no transferable secret |
| Hardware security key or platform passkey | Yes | Origin-bound challenge-response; the credential will not respond to the wrong origin |
The mechanism behind origin binding: the authenticator signs a challenge that includes the identity of the site requesting it. A relay site is, by definition, a different origin, so the signature it obtains is not valid for the real service. Nothing the user can be persuaded to do changes that, which is why this class of method removes the human decision from the security boundary rather than relying on the human making it correctly.
Practical deployment points: prioritise phishing-resistant methods for privileged accounts and anyone with access to sensitive data; keep weaker factors only as a transitional measure with a defined end date; and — critically — secure the recovery path, because an account protected by a hardware key and recoverable by an email code is protected by an email code.
**Example / Scenario:**
An organisation enforces hardware-backed authentication for all administrative roles, and keeps one-time codes for general staff during a phased rollout. A review then identifies that the self-service account recovery flow accepts a code sent by email for every account, including administrative ones. Recovery is changed to require a second registered hardware credential or a verified in-person process, closing the path that would otherwise have made the strong factor irrelevant.
**Interview Tip:**
Make the recovery point yourself. “An account is only as strong as its weakest recovery path” is a sentence that lands, and it is the gap that exists in a very large proportion of real deployments. It also shows you think about the whole identity lifecycle rather than the login screen in isolation.
— -
## Question 3: How does passwordless authentication work, and what problems does it not solve?
**Answer:**
The user’s device holds a private key created during registration; the service holds the corresponding public key. At sign-in the service sends a challenge, the device unlocks the key with a local gesture — biometric or PIN — and returns a signature bound to the service’s origin. It removes shared secrets, password reuse, credential stuffing, and phishing of the credential itself. It does not solve authorisation, session theft after sign-in, account recovery, device loss, or insider misuse.
**Explanation:**
The mechanics that matter:
- **No shared secret.** The service stores only a public key, so a breach of the service discloses nothing usable. This alone eliminates an entire category of incident.
- **The local gesture is local.** The biometric or PIN unlocks the key on the device; it is never transmitted. This is the point candidates most often get wrong — the fingerprint does not go to the server.
- **Origin binding** makes the credential unusable against a relay site.
- **Device-bound versus synced credentials.** Some credentials remain on one hardware authenticator; others sync across a user’s devices through a platform account. Synced credentials are far more usable and shift part of the trust to that platform account, which is a real trade-off worth naming for high-assurance use cases.
What remains unsolved:
- **Session security.** Once authenticated, the session token is still a bearer credential. Token theft and session hijacking are unaffected, which is why token binding, short sessions, and continuous evaluation still matter.
- **Authorisation.** Proving identity says nothing about entitlement. Passwordless does not reduce over-privilege by a single permission.
- **Recovery and enrolment.** These become the weakest links. Registering a new authenticator, and recovering after losing all of them, must be as strong as the primary method — and initial enrolment must be identity-proofed properly, because an attacker who can enrol a credential does not need to phish one.
- **Device loss and shared devices**, and workflows where a user must authenticate from a machine that is not theirs.
- **Legacy applications** that cannot use modern authentication and keep a password path alive underneath, which quietly negates the whole programme.
- **Insider misuse**, which authentication of any strength does not address.
**Example / Scenario:**
A rollout in a lab environment registers hardware authenticators for administrative staff, requires two registered authenticators per person so loss of one is not an outage, disables password authentication for those accounts entirely rather than leaving it as a fallback, and routes recovery through a verified process with a second approver. The last two decisions are what make it a security improvement rather than an additional option.
**Interview Tip:**
Say that leaving the password as a fallback removes most of the benefit. It is the most common implementation mistake — organisations deploy passwordless as an alternative rather than a replacement, and the account remains phishable through the path nobody disabled. Naming that shows you understand deployment reality, not just the protocol.
— -
## Question 4: Compare role-based and attribute-based access control. When would you use each?
**Answer:**
Role-based access control grants permissions through named roles that users are assigned to, which is simple, auditable, and easy to certify. Attribute-based access control evaluates policy against attributes of the user, the resource, the action, and the context, which is far more expressive and handles fine-grained and dynamic decisions. In practice most mature environments use roles for coarse structural access and attributes for conditions and fine-grained rules on top.
**Explanation:**
| Dimension | Role-based | Attribute-based |
| — — | — — | — — |
| Decision input | Role membership | User, resource, action, and environment attributes |
| Strength | Simple, auditable, easy to certify and explain | Expressive, dynamic, fine-grained |
| Weakness | Role proliferation; poor at context and exceptions | Hard to audit, test, and explain; depends on attribute quality |
| Answering ‘who has access to X?’ | Straightforward | Requires policy evaluation across the population |
| Typical use | Job-function access to applications and systems | Data-level rules, conditional access, delegation, context |
The hybrid pattern, which is the answer most interviewers are looking for: roles establish the baseline — what a claims handler or a database administrator can reach at all — while attributes and conditions refine it, such as restricting a record to the user’s own region, requiring a compliant device, requiring a recent multi-factor challenge, or limiting an action to business hours.
Two practical cautions worth raising:
- **Attribute-based control depends entirely on attribute quality.** If departmental data is stale, the policy is wrong in ways nobody notices until an audit. Data quality is a security control here.
- **Auditability is the hidden cost.** With roles, you can answer “who can approve payments?” by listing members. With attribute policies, you have to evaluate the policy against every identity, which requires tooling that many organisations do not have. Regulated environments often prefer roles for exactly this reason.
Related models worth naming if asked: relationship-based access control, which expresses permissions as relationships between objects and suits collaborative and hierarchical data; and policy-based control, which is essentially attribute-based control with the policy externalised into a dedicated decision engine.
**Example / Scenario:**
A lab design gives an underwriting team a role granting access to the underwriting application, and layers an attribute rule so that a user may open a case only if the case’s region matches their own and the case value is within their approval limit. The role answers “may they use this system” and is certified quarterly; the attribute rules answer “which records” and are unit-tested with the application.
**Interview Tip:**
Do not present these as competing options — present the hybrid and explain the division of labour. Then raise auditability as the reason organisations retreat from pure attribute-based models: being able to answer “who has access to this?” quickly is a regulatory and operational requirement, not a nicety, and any design that makes it hard will be resisted for good reasons.
— -
## Question 5: What is role explosion, and how would you prevent it?
**Answer:**
Role explosion is the proliferation of narrowly defined roles until there are nearly as many roles as users, at which point roles provide no abstraction and certification becomes meaningless. It is prevented by separating business roles from technical entitlements, deriving roles from actual entitlement data rather than from organisational charts, handling exceptions as time-bounded grants rather than new roles, and reviewing and consolidating roles on a schedule.
**Explanation:**
Why it happens is more useful than the definition:
- Every exception becomes a new role, because creating one is easier than negotiating the model.
- Roles are defined per application rather than per business function, so a person needs a dozen roles to do one job.
- Nobody is allowed to remove a role in case something breaks, so roles only ever accumulate.
- Roles are named after people or teams rather than functions, so reorganisations orphan them.
- Temporary access is granted as permanent role membership because there is no time-bounded mechanism.
Prevention:
- **Two layers.** Business roles describe job functions and are what managers certify; technical entitlements are the underlying application permissions, mapped to business roles. Users are assigned business roles only.
- **Role mining.** Derive candidate roles from what people actually have and use, rather than designing them top-down from an organisational chart that does not reflect real work.
- **A birthright baseline.** A small set of entitlements everyone gets, so roles do not have to encode the obvious.
- **Time-bounded exceptions.** Request-based, approved, expiring access for anything outside the standard role, so the exception never becomes structural.
- **Naming and ownership standards.** Every role has an owner responsible for its definition, and a name that describes a function rather than a person or a project.
- **Periodic consolidation.** Report on roles with one member, overlapping roles, and roles with no members, and retire them deliberately.
- **Measure it.** Track the ratio of roles to users over time. A rising ratio is the early warning; by the time certification is painful, the problem is years old.
**Example / Scenario:**
A lab review of an environment with four thousand users finds three thousand two hundred roles, of which nine hundred have exactly one member. The remediation defines forty business roles from mined entitlement data, maps technical entitlements beneath them, and converts single-member roles into time-bounded exception grants with owners and expiry dates. Certification becomes possible for the first time in years.
**Interview Tip:**
Give the roles-to-users ratio as a metric. It is concrete, it is easy to measure, and it turns a vague governance complaint into something an interviewer can picture being reported to a steering committee. Then add that every exception must have an expiry date — the single mechanism that most reliably stops the count climbing again.
— -
## Question 6: How would you actually right-size access across an organisation that already has years of accumulated entitlements?
**Answer:**
Establish visibility first — a complete picture of who holds what, from which system, and when it was last used — then remove the unambiguous excess: dormant accounts, unused entitlements, orphaned accounts, and standing privilege. Then restructure with a role model, introduce request-and-approve with expiry for anything outside it, and finally maintain it with recertification and continuous unused-access reporting.
**Explanation:**
The sequence matters, because attempting the restructure before the cleanup means modelling roles around access nobody needed.
- **Discover.** Aggregate entitlement data from every significant system. This is the hardest and least glamorous step, and it is where the programme usually stalls. Prioritise by system criticality rather than trying to cover everything at once.
- **Add usage data.** Entitlement without usage is only half the picture. Last-used timestamps convert “this person can do X” into “this person has never done X in eighteen months,” which is what makes removal defensible.
- **Remove the uncontroversial.** Disabled and dormant accounts, orphaned accounts with no owner, duplicate accounts, entitlements unused beyond a defined threshold, and membership of groups nobody can explain. This produces measurable risk reduction quickly and builds credibility for the harder work.
- **Attack standing privilege.** Convert permanent elevated access to time-bounded elevation. This is usually the single largest risk reduction available.
- **Model.** Build business roles from the cleaned data, not from the original state.
- **Introduce flow control.** Request, approve, provision, expire. Without an easy legitimate path, people will route around the model.
- **Maintain.** Recertification for high-risk entitlements more often than for low-risk ones, continuous reporting on unused access, and automatic revocation where the organisation has the confidence to enable it.
Two realities to acknowledge, because interviewers respect candidates who name them: removal breaks things, so a rollback path and a fast re-grant process are essential to keeping business support; and the effort is unglamorous and long, so the programme needs visible early wins and an executive sponsor to survive.
**Example / Scenario:**
A lab programme starts with the eight most critical systems, aggregates entitlements, joins them to last-used data, and removes entitlements unused for twelve months after a two-week notification window with an immediate re-grant path. Roughly a third of entitlements are removed. Eleven re-grant requests arrive, all handled within a day, and the low number becomes the evidence used to justify extending the programme.
**Interview Tip:**
Lead with “visibility first, then remove the uncontroversial, then restructure.” Candidates who jump straight to designing a role model are describing the step that fails. Then mention the notification window and fast re-grant path — that operational detail is what makes large-scale removal politically survivable, and it signals that you have thought about how the work actually lands on people.
— -
## Question 7: What does privileged access management actually provide, and what does it not solve?
**Answer:**
It provides a controlled path to elevated access: credentials held in a vault rather than known by individuals, automatic rotation, session brokering with recording, just-in-time elevation with approval and justification, and a complete audit trail. It does not solve over-privilege inside the sessions it brokers, does not cover privileged access outside its scope, and creates a single high-value target that must itself be protected to the highest standard.
**Explanation:**
What a mature capability includes:
- **Credential vaulting.** Privileged credentials are stored centrally and checked out rather than known, with automatic rotation after use.
- **Session brokering.** The administrator connects through a broker, so the target credential is never exposed on their workstation — the credential exposure principle from Part 8, implemented as a product.
- **Just-in-time elevation.** Access granted for a bounded window with approval and recorded justification, rather than standing membership.
- **Session recording and keystroke logging** for high-risk sessions, with defined access controls on the recordings themselves.
- **Discovery.** Finding privileged accounts across the estate, including the local and service accounts nobody documented.
- **Automatic rotation** of service account and local administrator credentials.
- **Break-glass.** A documented, alarmed, tested emergency path — because the day the vault is unavailable is the day it matters most.
What it does not solve:
- **Excess privilege within the session.** Brokering access to an account that holds far more rights than the task requires controls *who* and *when*, not *what*. Least privilege still has to be done separately.
- **Coverage gaps.** Cloud roles, application-level administrative functions, database superusers, SaaS administration, and developer access to production frequently sit outside the deployment. The privileged access nobody enrolled is the privileged access nobody controls.
- **Insider misuse by an authorised administrator**, who is doing exactly what the system permits. Recording provides evidence after the fact, not prevention.
- **Its own risk.** The vault holds the keys to the estate and must be treated as tier zero: isolated, phishing-resistant authentication, independent monitoring, and a tested recovery plan.
**Example / Scenario:**
A lab deployment vaults domain and server administrative credentials with session brokering and just-in-time elevation. A follow-up review finds that cloud administrative roles, three database superuser accounts, and the SaaS administration consoles are all outside its scope. Those become the second phase, on the grounds that the highest-risk privileged access is whatever the programme has not yet enrolled.
**Interview Tip:**
Make the coverage point the centre of your answer. Any candidate can describe vaulting and session recording. Saying “the risk is not what the tool covers, it is what nobody enrolled — cloud roles, database superusers, SaaS admin consoles, and developer access to production” is the observation that sounds like it came from doing the work.
— -
## Question 8: How does single sign-on work, and what risks does it introduce?
**Answer:**
A central identity provider authenticates the user once and issues assertions or tokens that participating applications trust, so each application delegates authentication rather than performing it. The risks are concentration — compromise of the provider or of one session grants access to everything — plus session lifetime issues, incomplete logout across applications, misconfigured trust relationships, and applications that keep a local authentication path alive underneath.
**Explanation:**
The security case for it is strong and worth stating first: one place to enforce strong authentication, one place to apply conditional policy, one set of logs, one lifecycle event to disable an account everywhere, and fewer passwords for users to reuse or be phished for. Most organisations reduce risk substantially by adopting it.
The risks that come with the benefit:
- **Concentration.** The provider becomes the most critical system in the organisation, for both security and availability. It needs tier-zero treatment and a documented plan for its own outage.
- **Session as a bearer credential.** A stolen session token grants access to every connected application without any further authentication. This is the reason token theft has become such a prominent technique and why short lifetimes, device binding, and continuous evaluation matter.
- **Logout is not global by default.** Signing out of one application frequently leaves other sessions alive. Single logout must be configured deliberately and tested.
- **Trust misconfiguration.** Overly permissive assertion mapping, weak or long-lived signing keys, missing audience restrictions, and unvalidated attribute claims all allow an assertion to be accepted where it should not be.
- **Local authentication paths.** An application integrated with the provider that still accepts direct local login bypasses every conditional policy. Finding and closing these is essential.
- **Over-broad application access.** Adding an application to single sign-on frequently grants it to everyone by default rather than to those who need it.
- **Consent and application registration.** In cloud identity platforms, users granting permissions to third-party applications is a real attack path, which is why administrative consent policies matter.
**Example / Scenario:**
A lab review of a single sign-on deployment finds that sixteen of twenty-two integrated applications still accept direct local authentication, and that single logout is configured for four. The remediation disables local authentication paths and configures logout properly. Neither change adds a product; both close gaps that made the deployment less protective than it appeared.
**Interview Tip:**
Raise the session token point explicitly: after single sign-on, the session becomes the credential, so token theft yields everything. That framing explains why phishing-resistant authentication alone is not the end of the story and leads naturally to short sessions, device binding, and continuous access evaluation — which is exactly where a good interviewer will want to take the conversation.
— -
## Question 9: What is federation, and what can go wrong when establishing a trust relationship with another organisation?
**Answer:**
Federation lets one organisation’s identity provider be trusted to authenticate users for another organisation’s resources, so partners and acquired entities can access systems without duplicate accounts. What goes wrong: overly broad trust scope, weak assertion validation, unconstrained attribute mapping, signing key management failures, no agreement about lifecycle, and no clarity about who is accountable when an account in the partner’s directory is compromised.
**Explanation:**
The essential mechanism is that the resource organisation stops authenticating the user and instead accepts a signed assertion from an identity provider it has chosen to trust. Everything that can go wrong follows from the size and strength of that trust.
Risks to name:
- **Scope.** A trust should grant access to specific applications for specific user populations, not everything to everyone. Broad trusts are established for convenience during a migration and rarely narrowed afterwards.
- **Assertion validation.** Signature verification against a pinned or properly discovered key, audience restriction, issuer validation, replay protection, and time-window enforcement all matter. Missing audience validation is a recurring real-world defect.
- **Attribute mapping.** If the partner controls an attribute that maps to a role or group on your side, they control authorisation on your side. Map only attributes you are prepared to be governed by, and never map free-text attributes into privilege.
- **Key management.** Signing certificates expire, causing outages, and rotate, causing acceptance failures. A documented rotation process and expiry monitoring are operational necessities.
- **Lifecycle.** When someone leaves the partner organisation, does your access end? That depends entirely on the partner’s own joiner-mover-leaver discipline, which you do not control and should therefore contract for and periodically verify.
- **Assurance mismatch.** If you require phishing-resistant authentication and the partner authenticates with passwords, your policy is only as strong as theirs unless you require assertions to carry an authentication context you check.
- **Accountability.** Agree in advance who investigates, who notifies whom, and how quickly, when an identity on either side is compromised.
On protocols: SAML remains common for enterprise applications and uses signed XML assertions; OpenID Connect is the modern choice, particularly for cloud and mobile, and is covered in the next question. New integrations should generally prefer the latter.
**Example / Scenario:**
A lab federation with a partner is scoped to two applications, restricted to a named group in the partner’s directory, requires an authentication context indicating multi-factor, validates issuer and audience strictly, and monitors the signing certificate for expiry. The agreement also specifies that the partner notifies within a defined period when an account with access is disabled — the control that keeps the lifecycle honest.
**Interview Tip:**
Get Karanam Shrivasta’s stories in your inbox
Join Medium for free to get updates from this writer.
Ask the lifecycle question out loud: “when someone leaves their organisation, how does my access end?” It is the question that most federation designs cannot answer, it is a governance problem rather than a technical one, and raising it demonstrates that you think about the trust relationship as an ongoing arrangement rather than a one-time configuration.
— -
## Question 10: Explain OpenID Connect. What is the difference between an ID token and an access token, and how should each be validated?
**Answer:**
OpenID Connect is an identity layer built on OAuth 2.0 that adds authentication and a standard way to obtain information about the authenticated user. The ID token is a signed statement to the client that a user authenticated, and it is consumed by the client; the access token is a credential presented to a resource server to authorise API calls. Each must be validated by its intended audience, and neither should be used in the other’s role.
**Explanation:**
| | ID token | Access token |
| — — | — — | — — |
| Purpose | Proves a user authenticated | Authorises access to a resource |
| Audience | The client application | The resource server |
| Consumed by | The client | The API |
| Format | Always a signed JWT | Opaque or JWT, depending on the provider |
| Must not be used to | Call an API | Establish who the user is at the client |
Validation of an ID token by the client: verify the signature against the provider’s published keys, confirm the issuer, confirm the audience matches this client, check expiry and issued-at, verify the nonce matches the one sent in the request, and check the authentication context and time if the application has assurance requirements.
Validation of an access token by the resource server: the same signature, issuer, audience, and expiry checks described in Part 6, plus scope and claim checks appropriate to the operation. Where the token is opaque, the resource server introspects it with the provider instead.
Mistakes that come up as follow-up questions:
- **Sending an ID token to an API as authorisation.** It is addressed to the client, not the API, and the API accepting it means audience validation is not being done.
- **Trusting an unverified token’s contents**, including the very common case of decoding a token in front-end code and treating the claims as authoritative for authorisation decisions. Display purposes only.
- **Skipping the nonce**, which is what binds the token to the specific authentication request.
- **Assuming a claim is unique and permanent.** Email addresses change and are reassigned; the provider’s subject identifier is the stable key.
- **Confusing scopes with permissions.** A scope describes what a client was granted on the user’s behalf; the resource server must still apply its own authorisation.
**Example / Scenario:**
A lab application receives an ID token, validates signature, issuer, audience, expiry, and nonce, and establishes a local session keyed on the subject identifier rather than the email address. When a user’s email later changes, their account and history remain correctly linked — a small design choice that avoids a class of account-merging problem.
**Interview Tip:**
State the audience rule crisply: “the ID token is for the client, the access token is for the API, and using one in the other’s place means someone is not checking audience.” It is precise, it is the most common real defect in these integrations, and it connects directly to the token validation discussion from Part 6.
— -
## Question 11: Describe the identity lifecycle. Which stage causes the most problems and why?
**Answer:**
Joiner, mover, and leaver: access is provisioned when a relationship begins, adjusted when the person’s role changes, and removed when the relationship ends. The mover stage causes the most problems, because organisations reliably add access on role change and reliably fail to remove the access that is no longer needed — producing privilege accumulation that no single event ever triggers a review of.
**Explanation:**
- **Joiner.** Triggered by the authoritative source, ideally provisioning a defined birthright set automatically plus role-based access on approval. Failure modes: manual creation outside the process, copying another person’s access as a shortcut, and contractors created ad hoc with no source record.
- **Mover.** The hard one. A person changes team, and their new access is added because they need it to work. The old access is not removed because nobody is accountable for removing it, nothing breaks when it stays, and the person may still occasionally use it. After several moves, someone holds a combination of entitlements that no role was ever meant to grant — which is also how segregation-of-duties conflicts arise without anyone approving one.
- **Leaver.** Conceptually simple and operationally leaky: the corporate account is usually disabled promptly, and what remains is local accounts, SaaS applications outside single sign-on, shared credentials the person knew, personal devices with cached access, external collaboration invitations, and service accounts they personally owned. Immediate session and token revocation matters too, since disabling an account does not always terminate an active session.
Making mover work:
- Treat a role change as a leaver plus a joiner: remove the previous role’s access and grant the new one, rather than adding to what exists.
- Trigger a mandatory targeted review at every role change, owned by the new manager, with a short deadline.
- Time-bound any transitional access explicitly, since handover access is legitimate and should expire.
- Report on entitlement drift per user — the difference between what their role model says they should have and what they actually hold — which makes accumulation visible as a number rather than as an anecdote.
- Run automated segregation-of-duties checks at the point of grant, not only at audit time.
**Example / Scenario:**
A lab report compares each user’s actual entitlements against their current role model. Users who have moved teams two or more times hold, on average, substantially more entitlements than their role defines. The remediation makes role change a removal-and-grant event with a required manager review, and adds a monthly drift report by department so the accumulation is visible to the people who can act on it.
**Interview Tip:**
Name mover as the answer and explain why: nothing breaks when old access is left in place, so there is no feedback signal. Then offer entitlement drift as a measurable metric. Interviewers hear “joiner, mover, leaver” recited constantly; hearing which stage fails, why it fails, and how you would measure it is what makes the answer memorable.
— -
## Question 12: How would you make access certification meaningful rather than a rubber-stamping exercise?
**Answer:**
Reduce the volume so reviewers can think, give them information they can actually judge — plain-language descriptions, usage data, risk indicators, and peer comparison — make the reviewer someone who genuinely knows the person’s work, require an explicit action rather than allowing bulk approval, act on revocations quickly, and measure the quality of reviews rather than only their completion rate.
**Explanation:**
The reason certification fails is structural: a manager receives hundreds of cryptic entitlement names with a deadline and no way to assess any of them. Approving everything is the rational response.
What changes the outcome:
- **Reduce scope.** Certify high-risk entitlements frequently and low-risk ones rarely or never. Certifying everything at the same cadence guarantees that nothing is examined properly.
- **Translate.** Present business-meaningful descriptions written by the entitlement owner, not raw technical group names.
- **Show usage.** “Not used in eleven months” is decision-grade information. Without it, the reviewer is guessing.
- **Flag risk.** Highlight privileged entitlements, segregation-of-duties conflicts, and access that is unusual for the person’s peer group.
- **Compare with peers.** “Three of forty people in this role hold this entitlement” is one of the most effective prompts available.
- **Pick the right reviewer.** The line manager for business context, the entitlement owner for technical appropriateness. For heavily delegated environments, both.
- **Remove bulk approve**, or at minimum require justification for it and report on its use.
- **Close the loop.** Revocations must actually be executed and verified. Certification that produces decisions nobody implements is worse than none, because it creates documented false assurance.
- **Measure quality.** Track revocation rate per reviewer, time spent, and how often revoked access is re-requested shortly afterwards. A reviewer with a zero revocation rate across thousands of items is not reviewing.
And the structural point: certification is a detective control. Reducing standing access through time-bounded, request-based grants reduces how much there is to certify in the first place, which is a better answer than making the review process more efficient.
**Example / Scenario:**
A lab campaign is redesigned to cover only privileged and sensitive-data entitlements, presents each with a plain-language description, last-used date, and the percentage of the person’s peer group holding it, and disables bulk approval. Review volume drops by roughly four-fifths, the revocation rate rises substantially, and revocations are executed automatically within a day.
**Interview Tip:**
Say that a zero revocation rate is a red flag, not a clean result. It reframes certification metrics in a way most organisations have not considered, and it demonstrates that you distinguish between a process being completed and a control being effective. Then add the structural point — less standing access means less to certify — because the best governance answer is always to reduce the population rather than to review it faster.
— -
## Question 13: Why are non-human identities such a significant risk, and how would you manage them?
**Answer:**
Service accounts, workload identities, API keys, automation credentials, and integration tokens typically outnumber human identities by a large multiple, are rarely enrolled in any lifecycle process, frequently hold broad standing privilege, cannot use multi-factor authentication, and often have no identifiable owner. Managing them requires discovery and inventory, assigned ownership, least privilege, automated rotation or elimination through platform identity, and behavioural monitoring.
**Explanation:**
The reason this has become the leading identity gap: every control built over the last decade — multi-factor authentication, conditional access, phishing-resistant credentials, joiner-mover-leaver automation, certification — is designed around a human. None of it applies to a service account, and the population of service accounts has grown far faster than the human one.
A management approach:
- **Discover.** Enumerate across directories, cloud platforms, applications, databases, pipelines, and secret stores. You cannot govern an unknown population, and discovery invariably finds more than expected.
- **Assign ownership.** Every non-human identity has a named owning team, recorded and enforced at creation. Ownerless credentials are the ones nobody dares to remove and nobody monitors.
- **Classify by risk.** Privilege held, systems reached, and data accessible. A build pipeline identity with production deployment rights is a different risk from a monitoring account with read access.
- **Eliminate where possible.** Platform workload identity with short-lived credentials removes the credential entirely — the strongest answer, as in Part 9.
- **Rotate what remains**, automatically, with rotation actually tested rather than assumed.
- **Least privilege**, reviewed against actual usage. Service identities are the easiest population to right-size because their behaviour is narrow and observable.
- **Certify them.** Include them in access reviews, reviewed by the owning team, with the same removal path as human access.
- **Monitor behaviourally.** A service identity should do the same small set of things forever; deviation is a high-quality signal, as noted in Part 9.
- **Decommission properly.** When an application is retired, its identities must be retired too — a step that is very frequently missed.
**Example / Scenario:**
A lab discovery exercise finds that non-human identities outnumber staff accounts several times over, that a substantial minority have no recorded owner, and that a number hold privileged group membership. The programme assigns ownership first, then removes privileged membership where it is not justified, then converts everything that can use platform identity, and finally rotates the remainder on a schedule. Ownership comes first because nothing else can proceed without someone to ask.
**Interview Tip:**
Say that every identity control built in the last decade assumes a human, and that non-human identities have quietly become the larger population. That single framing explains why this is the current frontier. Then name ownership as the first step, because the practical blocker to remediation is almost always that nobody knows what a credential is for or who will be affected if it stops working.
— -
## Question 14: How would you detect identity-based attacks such as multi-factor fatigue, session token theft, and malicious application consent?
**Answer:**
Monitor authentication telemetry for patterns rather than individual events: repeated multi-factor challenges followed by an approval, sign-ins whose context changes mid-session, tokens presented from a different device or network than the one they were issued to, impossible travel and unfamiliar-location sign-ins, sudden registration of new authentication methods, and consent grants to applications that request broad permissions or are newly registered.
**Explanation:**
Signals per technique:
| Technique | Detection signal |
| — — | — — |
| Multi-factor fatigue | Multiple challenges in a short window, especially outside working hours, ending in an approval; challenges from an unfamiliar location |
| Session token theft | A session used from a different device, network, or geography than the one it was issued to; token replay after the user’s device went offline |
| Authentication method registration | A new factor registered shortly after a sign-in from an unusual context — a very high-confidence signal |
| Malicious application consent | Consent granted to a newly registered application, an application requesting broad or offline-access permissions, or consent by many users to the same unfamiliar application |
| Credential stuffing at scale | Many accounts attempted from few sources with a low success ratio, as covered in Part 6 |
| Federation abuse | Assertions with unexpected authentication context, or issued for users outside the agreed population |
| Privilege change | Role or group elevation shortly after an anomalous sign-in — the correlation is far stronger than either alone |
What makes these detections work:
- **Correlate, do not threshold.** The strongest indicators are sequences: unusual sign-in, then new factor registered, then privilege change. Any one alone is noisy; the chain is not.
- **Bind sessions where the platform allows it**, so a stolen token is not usable from another device — prevention that makes the detection less critical.
- **Continuous access evaluation.** Re-evaluate an active session when risk signals change rather than only at sign-in, so revocation takes effect in minutes rather than at token expiry.
- **Restrict consent by policy**, requiring administrative approval for anything beyond low-risk permissions — again, prevention beating detection.
- **Use number matching and challenge context** to defeat fatigue approvals structurally, and treat repeated denials as an alert rather than a non-event.
- **Educate on the specific behaviour**, since a user who knows that unexpected prompts should be reported rather than dismissed is a genuine sensor.
**Example / Scenario:**
A lab detection correlates three events within a two-hour window for the same identity: a sign-in from an unfamiliar network, registration of a new authentication method, and addition to a privileged group. Individually each occurs legitimately every week. In sequence, within two hours, it has occurred once in six months — and that occurrence was the exercise it was built to catch.
**Interview Tip:**
Emphasise sequence correlation over single-event thresholds, and give the sign-in then new-factor then privilege-change chain as your example. It is concrete, it reflects how identity intrusions actually unfold, and it shows you can design a detection that survives production rather than one that fires constantly. Then note that repeated *denied* multi-factor prompts are an alert most organisations never configure.
— -
## Question 15: You have been asked to improve identity and access management across an organisation with limited budget and competing priorities. What would you do first, and how would you justify it?
**Answer:**
Establish visibility and an authoritative source, then close the highest-consequence gaps in order: phishing-resistant authentication for privileged and high-value accounts, elimination of standing privilege, reliable leaver and mover processes, and ownership of non-human identities. Justify each by the incident scenario it prevents and by measurable indicators, and sequence so that early work produces visible results that fund the later work.
**Explanation:**
A defensible prioritisation, with the reasoning:
- **Visibility and authoritative source.** Nothing else can be measured or trusted without it. This is unglamorous and must be framed honestly as an enabler rather than as a control.
- **Phishing-resistant authentication for privileged and high-value accounts.** Highest risk reduction per unit of effort, and scoped to a small population so it is achievable quickly.
- **Remove standing privilege.** Convert permanent elevated access to time-bounded elevation with approval. This shrinks the window in which any credential compromise matters, across the whole estate.
- **Fix leaver, then mover.** Leaver is the more obvious risk and the easier to automate; mover is the larger accumulated problem and follows naturally.
- **Non-human identity ownership and inventory.** The largest ungoverned population, and ownership is cheap to establish relative to its value.
- **Then**: role model, certification redesign, and conditional access refinement — real value, but they depend on the foundations above.
How to justify it:
- **Tie each item to a scenario**, not to a framework clause. “If an administrator’s credentials are phished today, this is what happens; here is what changes if we do this.” That is a conversation leadership can engage with.
- **Use measurable indicators**: number of accounts with standing privilege, percentage of privileged accounts on phishing-resistant factors, mean time from termination to full access removal, number of ownerless non-human identities, entitlement drift. Report the trend, not the absolute.
- **Prefer changes that reduce friction as well as risk** — single sign-on and self-service access requests are easier to fund because they help people work.
- **Sequence for visible wins.** Dormant account removal and leaver automation produce numbers within weeks and buy credibility for the two-year role model work.
- **Name what you are consciously deferring**, with the residual risk stated. A plan that claims to do everything is not believed; a plan that says what it is not doing, and why, is.
**Example / Scenario:**
A lab plan sets three ninety-day objectives: phishing-resistant authentication for every privileged account, standing privileged membership converted to just-in-time elevation, and termination-to-revocation time reduced to under an hour through automation. Each has a single number reported monthly. The role model and certification redesign are explicitly deferred to the following year, with the residual risk documented and accepted by name.
**Interview Tip:**
Show that you can prioritise and that you can say no. Interviewers asking this at a senior level are assessing judgement and communication far more than technical knowledge. Naming what you would defer, and stating the residual risk that leaves, is more impressive than an ambitious plan — because everyone has seen the ambitious plan fail, and few candidates volunteer the trade-off.
— -
# Conclusion
Part 10 treated identity as a discipline rather than as a set of products. The consistent finding across all fifteen questions is that identity failures are rarely failures of authentication technology. They are failures of lifecycle, ownership, and governance — access that was correct when granted and was never revisited.
The patterns worth carrying forward:
- An account is only as strong as its weakest recovery path.
- Phishing resistance comes from origin binding, not from counting factors.
- Mover is the stage that fails, because nothing breaks when old access stays.
- After single sign-on, the session becomes the credential — which is why token theft matters as much as credential theft.
- Every identity control of the last decade assumes a human, and non-human identities are now the larger population.
To prepare with this part: take an organisation you know and try to answer question eleven about it — what actually happens to someone’s access when they change teams. The gap between the documented process and the real one is where the most useful interview stories come from.
Everything here is about governing access you are responsible for. Never attempt to enumerate, test, or access identity systems you do not administer.
Part 11 turns to the mathematics underneath much of this — cryptography and PKI, covering symmetric and asymmetric encryption in practice, hashing and password storage, digital signatures, certificates and certificate authorities, TLS, key management and rotation, and encryption at rest and in transit.
# ⚠️ Ethical & Legal Disclaimer
This article is published strictly for educational purposes and for cybersecurity interview preparation. It is study material. It is not an operational guide, a testing authorisation, or a substitute for professional, legal, or compliance advice.
Cybersecurity knowledge carries responsibility. Everything described here must be applied ethically and lawfully. Security testing of any kind — scanning, enumeration, exploitation, credential testing, configuration review, or traffic capture — must be performed only against systems, networks, applications, accounts, devices, or environments that you personally own, or for which you hold explicit, documented, and current authorisation from the owner. Purpose-built laboratories, CTF platforms, sandboxes, and training ranges are acceptable environments when you are permitted to use them and you stay inside their stated scope.
Nothing in this article may be used for any of the following, and none of it is endorsed by the author:
- Unauthorised access to any system, account, network, or device.
- Unauthorised scanning, enumeration, reconnaissance, or traffic interception.
- Credential theft, credential harvesting, or the use of credentials you were not issued.
- Development, distribution, or deployment of malware or ransomware.
- Unauthorised exploitation, privilege escalation, or lateral movement.
- Data theft, data exfiltration, or unauthorised disclosure of information.
- Surveillance or monitoring of individuals without a lawful basis and appropriate consent.
- Service disruption of any kind, including denial-of-service and distributed denial-of-service activity.
- Bypassing security controls, authentication, or security products for unauthorised purposes.
All offensive concepts referenced in this series are presented from a defensive, detection, and mitigation perspective. Explanations deliberately stop short of operational attack procedures, weaponised code, and step-by-step exploitation instructions. Every example is fictional, defensive, educational, or set in an authorised laboratory scenario, and every identifier used is a documentation-reserved placeholder rather than a real address, host, domain, organisation, account, or person.
Readers are solely responsible for complying with all applicable laws, regulations, organisational policies, employment agreements, client contracts, and terms of service in their own jurisdiction and in the jurisdiction of any system they interact with. This article does not grant permission to test, access, or interact with any system, and it confers no legal protection, defence, or authorisation of any kind. If you do not have written permission, you do not have permission.
The author does not endorse, encourage, or accept responsibility for any malicious, unethical, or unlawful use of the information presented here.
# About the Author
Karanam Shrivasta is a cybersecurity learner who enjoys studying cybersecurity concepts and sharing educational interview-preparation content.
This series is written as public study notes. Corrections and additional perspectives are genuinely welcome in the responses.
Author: Karanam Shrivasta
LinkedIn: https://www.linkedin.com/in/karanam-shrivasta/
GitHub: https://github.com/mrshrivasta
# Publishing Metadata
**SEO Title:**
Cybersecurity Interview Questions — Part 10: Identity & Access Management (15 Questions and Answers)
**SEO Description:**
15 identity and access management interview questions and answers covering IAM programme components, phishing-resistant authentication, passwordless and passkeys, RBAC versus ABAC, role explosion, entitlement right-sizing, privileged access management, single sign-on risks, federation, OpenID Connect tokens, joiner-mover-leaver, access certification, non-human identities, identity attack detection, and IAM prioritisation.
**Primary Keyword:**
identity and access management interview questions
**Secondary Keywords:**
- IAM interview questions and answers
- RBAC vs ABAC interview question
- privileged access management interview questions
- single sign-on interview questions
- OpenID Connect interview questions
- passwordless authentication interview questions
- access review interview questions
- cybersecurity interview questions and answers
- identity security interview questions
- federation SAML OIDC interview questions
**Suggested Medium Topics (5):**
- Cybersecurity
- Identity
- Information Security
- Interview Questions
- Technology
**Suggested Canonical Keywords:**
- cybersecurity interview questions part 10
- identity and access management interview questions and answers
- phishing resistant authentication explained
- rbac vs abac when to use
- role explosion prevention
- privileged access management limitations
- joiner mover leaver process
- access certification best practices
- non human identity security
- identity attack detection mfa fatigue
# LinkedIn Promotional Post
Identity is the control plane now. The perimeter constrains less every year, but every system still asks the same two questions first: who is this, and what are they allowed to do? 🔑
Cybersecurity Interview Questions — Part 10 is live: Identity & Access Management.
Parts 8 and 9 covered identity inside two specific platforms. Part 10 covers the discipline itself:
→ What makes an authentication method phishing-resistant — and why do most MFA methods fail that test?
→ Which stage of the identity lifecycle actually fails, and why does nobody notice?
→ Why does a zero revocation rate in an access review mean the review is broken, not clean?
→ Why has every identity control of the last decade quietly missed the larger population?
→ You have limited budget and competing priorities. What do you fix first, and what do you consciously defer?
Plus IAM programme components, passwordless and what it does not solve, RBAC vs ABAC, role explosion, right-sizing years of accumulated entitlements, what PAM does not cover, single sign-on risks, federation trust, OpenID Connect token validation, and detecting MFA fatigue, token theft, and consent abuse.
15 questions. Each with a direct answer, an explanation, a defensive scenario, and one interview tip. Vendor-neutral throughout.
Written as study notes, shared in case they help someone else preparing.
Which identity gap do you think is most underestimated? Comments are open.
#CyberSecurity #IdentitySecurity #IAM #InfoSec #CyberSecurityInterview #ZeroTrust #AccessManagement #Authentication #InterviewPreparation #CyberSecurityCareer
