IAM and SailPoint Interview Questions

"Authentication answers 'who are you?' and authorization answers 'what are you allowed to do?'. When I log in with my password and an authenticator code, the system is authenticating me. Once it knows it's me, it checks my roles or group memberships to decide whether I can open the payroll report. That second check is authorization. Authentication always comes first, because you can't make an access decision about someone you haven't identified. On the web it shows up in the status codes: a 401 really means 'I don't know who you are', and a 403 means 'I know who you are, and you can't have this'. In IAM work the split matters because the tools differ too. SSO and MFA are about authentication, while roles, access requests and reviews are about authorization."

"MFA means combining at least two different kinds of factor: something you know, like a password or PIN, something you have, like a phone or a security key, and something you are, like a fingerprint. A password plus a security question is not MFA. Both are things you know, so an attacker who phishes one can usually phish the other, and security answers are often guessable from social media. That's really two-step, single-factor login. A password plus a code from an authenticator app is MFA, because the code proves you hold a device. I'd also point out that not all MFA is equal. A code can still be typed into a fake login page, while a security key or passkey is tied to the real site's domain, so it's much harder to phish. For admins I'd push for the phishing-resistant kind."

"Say a user opens the expense app without a session. The app, the service provider, builds a SAML authentication request and redirects the browser to the identity provider. The IdP checks whether the user already has a session with it. If not, it prompts for credentials and MFA. Then it builds an assertion saying who the user is, usually as the NameID plus some attributes like email and groups, signs it with its private key, and sends it back through the browser as a form POST to the app's assertion consumer service URL. The app validates it: signature against the IdP certificate it trusts, the audience is really this app, the time window hasn't passed, and the response matches the request it sent. Only then does it find the local user and start a session. With the usual redirect and POST bindings, the browser carries everything and the two servers never talk directly during the login."

"OAuth 2.0 is about delegated authorization. It lets an app call an API on my behalf with limited rights, like 'read my calendar', without ever seeing my password. What it hands out is an access token, and that token is for the API, not for the app to read. OAuth on its own doesn't define how the app learns who I am. OpenID Connect fills that gap. The app asks for the openid scope and, alongside the access token, gets an ID token. That's a signed JWT with claims like the issuer, the subject identifier, the audience and an expiry, and the app validates it to log me in. So the rule I follow is simple: the ID token is proof of login for the client, the access token is a key for the API. Using an access token as proof of who logged in is a classic mistake."

"A mobile app or a single-page app is a public client. Anything shipped to the device can be pulled out, so a client secret there protects nothing. The risk is that the authorization code, which comes back through a redirect, gets intercepted, say by another app registered for the same custom URL scheme. PKCE closes that. Before the login, the app generates a long random string called the code verifier and keeps it in memory. It sends a SHA-256 hash of it, the code challenge, with the authorization request. The server remembers that challenge against the code it issues. When the app swaps the code for tokens, it sends the original verifier, and the server hashes it and compares. Someone who stole only the code can't produce the verifier, so the swap fails. Current guidance recommends PKCE for every client, not just public ones, and the old implicit flow is no longer recommended."

"A signature error for everyone right after a certificate renewal almost always means the app still trusts the old certificate. I'd confirm it first: capture the SAML response with a browser tracer, decode it, and compare the certificate in the signature with the one configured in the app. If they differ, that's the cause. The fix is to upload the new certificate or re-import the IdP metadata in the app. Some apps accept two certificates, so I'd add the new one next to the old one. To stop it happening again, I'd keep a list of every SAML app with its certificate expiry and owner, alert well before expiry, use a metadata URL for apps that can refresh it themselves, and for manual apps agree a rollover window with the owner. Many identity providers also let you add the new certificate ahead of time, so both sides are ready before the switch."

"SSO only deals with the login. When someone leaves and we disable them in the identity provider, they can't sign in through SSO any more, but their account inside the app still exists. If the app also allows a local password, or the user created API tokens, that account can still be used. SSO with just-in-time provisioning can even create accounts at first login, but it never removes them. SCIM, the System for Cross-domain Identity Management, is the standard that fixes this. It's a REST API with JSON, with standard endpoints for users and groups, so the identity platform can create an account, update attributes when someone moves, and set the account to inactive when they leave. So for any important app I want both: SSO for the login, and SCIM or a connector for the account lifecycle."

"At my last company we had to bring a finance reporting app onto SSO and quarterly reviews, because an audit had flagged it for local passwords. The app owner pushed back hard. Month-end was close, and a previous SSO change on another app had locked users out for a day. So I took the risk off her plate. I set up the SAML integration in a test environment myself, got two of her power users to test it, and kept local login open for a named admin as a fallback. We went live the week after month-end, early in the morning, with me on a call. It worked, and a month later we turned off local passwords. For reviews, I built the account export with her team so it came from a report they already ran. After that, I wrote an onboarding checklist and test plan that we reused for every app, and onboarding went faster."

"With role-based access, I bundle permissions into roles like 'accounts payable clerk' and assign people to roles. It's easy to explain and easy to review, because a manager can look at a role and say yes or no. The weakness is that every exception tends to become a new role, and you end up with thousands of them. Attribute-based access evaluates a rule at the moment of the request, using attributes: the user's department and location, the record's region or sensitivity, the time or device. A rule like 'managers can see salary records only for their own cost centre' is natural in ABAC and painful in RBAC. The trade-off is that ABAC is harder to audit, because you can't just list who has access; you have to evaluate the policy. In practice I'd use roles for coarse, job-based access and attributes for fine-grained rules inside the app."

"I'd start from data, not from a workshop. I'd pull entitlements for everyone and mine them by department, job code and location to find the access that almost everyone in a group shares. That common core becomes a role. Everything else stays as requestable access. I'd layer it. Birthright roles are assigned automatically from HR attributes, like email and the intranet for everyone. Business roles describe a job and are owned by a business person. Those contain IT roles, which hold the technical entitlements for each application. Every role gets a named owner, a description a manager can understand, and a regular review of what's inside it. I'd also set a rule: an exception only becomes a role when enough people need it for a lasting reason. And I'd retire roles with no members or no recent use. Explosion usually comes from missing ownership, so the governance matters as much as the design."

"Joiner, mover, leaver is the lifecycle of a person's access, and it should be driven by the HR system as the authoritative source, not by someone remembering to raise a ticket. When a new hire is entered in HR, the identity platform creates the identity and gives birthright access, like email, the directory account and the tools every employee needs, based on attributes such as department and location. Anything extra goes through a request. When HR records a move, like a new department or manager, the person gets the new job's access and the old job's access is removed, sometimes after a short overlap for handover. When HR records a termination, the accounts are disabled at the termination time and active sessions are ended. Later, after the retention period, accounts are deleted. The point is that access follows the HR record automatically, so nothing depends on memory."

"Joiners and leavers are loud events. Someone can't work without access, or they're gone. Movers are quiet. They get the new access they ask for, nobody complains about the old access they still have, and after three or four moves a long-serving person can hold far more than anyone in their current job. That's privilege creep, and it's what shows up as toxic combinations in a segregation-of-duties scan. I'd fix it in the lifecycle. When HR changes someone's department or job code, the role-based access is recalculated straight away: new birthright roles added, old ones removed. For access that was requested by hand, I'd schedule removal after a short grace period, so the person can finish handover work. Before that date, the new manager gets a task to confirm anything the person genuinely still needs. And I'd run a small targeted review of everyone who moved in the last quarter."

"The core problem is that the normal lifecycle hangs off HR, and a service account has no HR record, so nothing ever triggers its removal. I start with an inventory: aggregate accounts from the directory, databases and cloud, and flag anything that looks like a service or application account. Each one then needs a named human owner and a stated purpose, recorded in the identity platform, so it can be reviewed like anything else. For credentials, I block interactive login, store the secret in a vault that rotates it, and where the platform supports it, move to a managed identity so there's no stored secret at all. Permissions get cut to what the job needs. The owner certifies it on a regular cycle. And when the owner leaves or moves, ownership passes to their manager with a task to confirm or retire the account, so it never becomes orphaned."

"First I'd confirm the list. I'd check each account against the HR record, because a few may be rehires, name clashes or service accounts. For the confirmed ones, I'd disable them the same day. Disable, not delete, so the evidence and any owned data survive. Next I'd pull last-login dates and activity logs. Any login after someone's leaving date becomes a security incident, and I'd bring in the security team. Then the root cause. Usually it's one of three things: the app isn't connected to the identity platform, its accounts don't correlate to identities so the leaver never reaches them, or contractors aren't in HR at all. I'd fix that for this app, connect it or add it to the export process, and check other apps for the same gap. For the auditor, I'd provide the disabled list with timestamps, the root cause, the fix, and a later orphan report showing it stays clean."

"A certification campaign is a scheduled review where the right person confirms, item by item, that someone's access is still needed. Auditors ask for it because it's proof the company doesn't just grant access, it also checks it. There are a few common types. A manager review shows each manager their team's access. An application or entitlement owner review shows the owner of a system everyone who can use it, which is better for technical access a manager may not understand. Role reviews check both who holds a role and what's inside it. And targeted reviews focus on something specific, like privileged access or recent movers. When a reviewer clicks revoke, that decision has to turn into real removal. In an identity governance tool it becomes a provisioning request through a connector, or a manual task for disconnected apps. I'd only call the campaign closed once removals are confirmed, because a revoke that never happened is a finding."

"Separation of duties means no one person should be able to run a sensitive process from start to finish on their own, because then they could commit fraud or a serious error with nobody noticing. A classic finance conflict is someone who can create a new supplier and also approve payments to suppliers. They could set up a fake supplier and pay it. In IT, it's one person who can both change code and push it to production without review. In an identity governance tool I define these as policies: this entitlement or role conflicts with that one. Then I check them twice. Preventively, when someone requests access, the tool flags the conflict before approval, so the approver sees it. Detectively, a regular scan checks everyone's current access, because conflicts also come from moves, role changes or access granted outside the tool. Each violation then needs a fix or a documented exception."

"I'd treat it as a design problem first. If a manager gets three hundred lines of cryptic group names, approving everything is the rational thing to do. I'd start by measuring: time spent per item, revoke rate per reviewer, and how many managers approved everything. That gives me evidence for the compliance lead. Then I'd shrink the reviews. Access covered by a reviewed role, or birthright access, doesn't need line-by-line review. I'd give every entitlement a plain-English description, show the last-used date, and flag access that no one else in the team holds. Technical access goes to the application owner, who understands it, not the manager. For high-risk items I'd run smaller, more frequent targeted reviews. And I'd add a check afterwards: sample some approvals, and where approved access turns out to be unused or wrong, go back to that reviewer. Managers engage when they can see the review is read."

"I wouldn't just block it, and I wouldn't quietly grant it. First I'd check the conflict is real. Sometimes the person only needs a narrower permission, or a colleague in another team could approve instead. If the conflict truly can't be avoided, I'd design a compensating control with finance. For example, a monthly report of every supplier the person created and every payment they approved goes to their manager or to internal audit, who reviews and signs it. Then it becomes a formal exception. The business owner of the process signs a risk acceptance that names the conflict, the control and an end date, say six months, and the SoD violation is marked as mitigated in the governance tool with that expiry. When it expires, it comes back for review. That way the business keeps running, the risk is owned by someone with the authority to accept it, and the auditor sees a controlled decision, not a gap."

"Identity governance answers who should have what, and it works on a cycle: requests, approvals, reviews. Privileged access management controls how the most powerful credentials are actually used, every time. The heart of it is a vault. Admin passwords, root accounts and SSH keys are stored there instead of in spreadsheets or people's heads. An admin checks a credential out, often with an approval or a ticket number, and the tool rotates the password afterwards, so a copied password is useless. The second piece is session management. The admin connects through the PAM tool, which injects the credential so they never see it, and records the session so there's a trail of exactly what was done. PAM tools also discover privileged accounts across servers, so you know what you're protecting. I see the two as partners: governance decides who's allowed to be an admin, and PAM controls and records what admins do."

"With vault checkout, the privileged account exists all the time with its full rights. The vault protects the password: you request it, maybe get approval, use it, and it's rotated afterwards. The risk is that the powerful account is always there, so if the vault or the account is bypassed, the privilege is ready to use. Just-in-time access removes the standing privilege itself. My normal account has no admin rights. When I need them, I request elevation for a task, it's approved or auto-approved by policy, I'm added to the admin role for, say, one hour, and then the role is taken away automatically. Cloud platforms support this well with role activation. The goal is zero standing privilege: most of the time nobody holds admin at all. I'd use JIT wherever the platform supports it, and keep vaulting for shared accounts like root, local administrator and old systems that can't grant rights on demand."

"The Digital Vault is the core. It's a hardened server that stores the credentials, grouped into safes, and each safe has its own members and permissions. PVWA, the Password Vault Web Access, is the web interface. Admins log in there, find the account they need, and request or use it. The CPM, the Central Policy Manager, is the piece that talks to target systems. It changes passwords on a schedule or after use, according to the platform policy for that account type, and it verifies and reconciles them if they drift. PSM, the Privileged Session Manager, is the jump point. So in one session, I log in to PVWA, pick a server account, and click connect. PSM opens the session to the target, injects the password from the vault so I never see it, and records everything. When I'm done, CPM can rotate that password, so even a leaked copy is useless."

"At my last company, a senior finance director asked for permanent admin rights on the production accounting system, because reports from the IT team were slow. Giving that would have created a separation-of-duties conflict with his approval rights, and it broke our admin policy. I didn't just say no. I asked what he was actually trying to do, and it turned out he needed to run two specific reports on demand. So I worked with the app team to give him a read-only reporting role that covered exactly those, which he had the same afternoon. He was still a bit annoyed at first, so I explained the conflict in plain terms: if he could both change and approve, an auditor would flag it against him personally. He accepted that. I recorded the decision in the request so the reasoning was there for the next review."

"IdentityIQ is the product the customer installs and runs themselves, on their own servers or their own cloud. It's a Java web application with its own database, and you customise it heavily with rules, custom workflows and config objects. That means you also own upgrades, patching and performance. IdentityNow is SailPoint's SaaS offering, which newer material calls Identity Security Cloud. SailPoint runs the platform and upgrades it for you. To reach systems inside your network, you run a virtual appliance that the connectors work through. Customisation is more configuration-led: you shape attributes with transforms, use the APIs, and custom rules are more restricted than in IIQ, with cloud rules reviewed by SailPoint before they're deployed. So on IIQ, a lot of my day is BeanShell rules, workflows and deployments between environments. On the SaaS side it's more configuration, transforms and API integrations, with less code but less freedom."

"In SailPoint, an identity is the person. It's built from the authoritative source, usually HR, through aggregation of that source. The accounts that person holds in each application, like their directory account or their database login, are separate objects linked to the identity. Aggregation is the task that reads accounts and their entitlements from an application through its connector. Correlation is the matching step: for each account, SailPoint tries to find which identity owns it, usually by an attribute like employee ID or email, using correlation configuration or a correlation rule for trickier logic. When an account matches nothing, it's uncorrelated. That matters a lot. An uncorrelated account has no owner, so it won't show up in a manager's review and won't be disabled when anyone leaves. So I treat the uncorrelated list as a work queue: fix the matching logic, link genuine accounts, and chase the rest as possible orphans."

"A correlation rule runs for each account during aggregation. It gets the account as a resource object, and it returns a map telling IdentityIQ how to find the owner. Here I read the employee number from the account, clean it, and return the identity attribute name and value to search on. If there's no number, I return an empty map, so the account stays uncorrelated instead of being matched wrongly. What goes wrong is mostly data. Some systems store the number with leading zeros and HR doesn't. Test and admin accounts have no number. And if the identity attribute isn't unique, for example an ID reused after a rehire, the match can land on the wrong person, which is worse than no match. So I normalise formats, make sure the identity attribute is searchable and unique, and check the uncorrelated count after every change."

"It starts with the HR aggregation. The HR record now shows the person as terminated, so the identity's status attribute changes. Next, the identity refresh task runs with event processing turned on. It compares the identity with the snapshot saved at the last refresh, and a lifecycle event configured as the leaver trigger, say status changed from active to inactive, matches. That event launches its workflow. The workflow builds a provisioning plan: disable the directory account, remove entitlements, maybe move the account to a disabled container. IdentityIQ's provisioning engine compiles that plan into a project and splits it by application. For applications with a read-write connector, the connector makes the change directly. For disconnected applications, it creates a manual work item or a ticket for the app team. When I debug a missed leaver, I walk that same chain: did the HR data change, did refresh run with events on, did the trigger match, did the workflow fail, or did provisioning error out."

"I split it into reading and writing. For reading, almost every app can produce a list of users and their roles, even if it's a report someone runs. I'd agree a scheduled export in a fixed format, drop it somewhere secure, and aggregate it as a delimited file application, or read a view if the database is reachable. That alone gets the app into reviews and orphan checks. For writing, the identity platform can't change the app directly, so provisioning becomes a manual task. When access is approved or revoked, it creates a work item or a ticket for the app team with a due date. The important part is closing the loop. The next aggregation shows whether the change really happened, and if a revoke is still there after the deadline, it escalates. Later, if the app gets an API or supports SCIM, I'd upgrade it to a real connector."

"At my last company, our HR feed arrived one morning with only part of the employees in it, because an upstream export had timed out. The aggregation treated the missing people as gone, and the leaver events started disabling directory accounts. The service desk called about twenty minutes later when people couldn't log in. I stopped the scheduled tasks first, so nothing else ran. Then I pulled the list of identities that had a leaver event that morning, checked it against the previous day's HR file, and re-enabled those accounts through the tool, so everything stayed logged. I sent updates to the service desk every half hour. Access was back in about two hours. Afterwards, I added a check that stops aggregation if the file is much smaller than the day before and alerts us, and I added a delay on leaver events from bulk changes. We tested it with a truncated file before it went live."

"Conditional access is a set of if-then rules evaluated at sign-in. The 'if' uses signals like who the user is, which app they're opening, their location, the device and its health, and the sign-in risk. The 'then' is a control: allow, require MFA, require a compliant or managed device, or block. In Entra ID it's literally called Conditional Access, and Okta covers the same idea with its own sign-on policies. For admins, I'd target everyone holding an admin role, across all apps, and require phishing-resistant MFA like a security key or passkey, from a managed, compliant device. Sign-ins flagged as high risk would be blocked, and admin sessions would get a shorter sign-in lifetime. For rollout, I'd run it in report-only mode first to see who would be affected. I'd exclude two emergency break-glass accounts with strong, separately stored credentials, and alert whenever they're used, so a bad policy can't lock us out."

"In all three, users and groups are synced to the cloud by a sync tool like Entra Connect or Cloud Sync. What differs is where the password is checked. With password hash sync, a hash derived from the AD password hash is synced, and the cloud checks sign-ins itself. It's the simplest and it keeps working if the on-premises site is down. It also allows leaked credential detection. With pass-through authentication, the cloud sends the check to lightweight agents on-premises, which validate against AD. That keeps password checks inside the company and applies AD account states like disabled, locked out or outside logon hours straight away, but sign-in depends on those agents being up. Federation redirects sign-in to an on-premises service like AD FS. It gives full control but adds servers to run and patch, and a single point of failure. I'd normally choose password hash sync, and if policy demands one of the others, I'd still enable hash sync as a backup."