CISSP Identity and Access Management (IAM): 63 practice questions

12 of the 63 Identity and Access Management (IAM) questions in the Certsqill CISSP bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for CISSP? Take the free 5-min readiness check →

1. A password combined with a 6-digit numeric PIN: Which combination is NOT multi-factor authentication?

1. A password (Type 1) combined with a 6-digit numeric PIN (Type 1), because both are knowledge factors the user memorizes and recalls at login ✓

   MFA requires two or more DIFFERENT factor types. A password and a PIN are both Type 1 factors (something you know). Combining two of the same factor type is multi-step authentication, not multi-factor authentication. True MFA must span different categories (know + have, know + are, etc.).
2. A password (Type 1) combined with location verification from the corporate IP range (Type 4), pairing something the user knows with somewhere they are

   Password (something you know) + location verification (somewhere you are) represents two different factor types — this IS valid MFA, though Type 4 (location) is considered a weaker factor.
3. A smart card (Type 2) combined with a fingerprint scan (Type 3), pairing a token the user carries with a biometric trait unique to them

   Smart card (something you have) + fingerprint (something you are) represents two different factor types — this IS valid MFA. Many high-security systems use this combination.
4. A password (Type 1) combined with a TOTP code from an authenticator app (Type 2), pairing something known with a rotating code from a device held

   Password (something you know) + TOTP from authenticator app (something you have) represents two different factor types — this IS valid MFA. The authenticator app is the physical/digital possession (Type 2).

MFA requires factors from DIFFERENT categories — password + PIN are both Type 1 (something you know), so this is multi-step, not multi-factor authentication.

2. System A; its lower FAR means fewer impostors are: Which system should be selected, and why?

1. Neither system qualifies; for a high-security government facility the crossover error rate must be driven to 0.0% before any biometric deployment can be approved for use

   No biometric system achieves 0% error rates — all biometric systems have inherent variability. The selection should be based on acceptable tradeoffs between FAR and FRR relative to the security requirements. A CER of 0% is not achievable with any current biometric technology.
2. System A; its lower FAR (0.01%) means fewer impostors are incorrectly accepted, which prioritizes security over user convenience despite the higher false rejection rate ✓

   FAR (False Acceptance Rate) is the security-critical metric — it measures how often impostors are incorrectly accepted. A lower FAR means fewer unauthorized people gain access. System A's FAR is 10x lower than System B's (0.01% vs 0.1%), providing better security. The higher FRR (5% vs 0.5%) means more legitimate users are inconvenienced, but the facility explicitly accepts this tradeoff.
3. System B; its far lower FRR of 0.5% means authorized staff are rarely rejected, delivering the smoother user experience that should drive the selection decision here

   FRR measures how often legitimate users are incorrectly rejected — this is a usability metric, not a security metric. The scenario explicitly states the primary concern is preventing unauthorized access (FAR), with tolerance for user inconvenience (FRR). Optimizing for FRR would trade away the security requirement.
4. System B; because it posts the lower crossover error rate of the two, it is the more accurate system overall and therefore the safer choice for this facility

   Both systems have the same CER (1%). CER represents the crossover point where FAR=FRR — it is a measure of overall system accuracy at the theoretical balance point, not at the operating threshold actually used. The deployed system operates at a chosen sensitivity threshold, not necessarily at CER.

FAR (False Acceptance Rate) is the security-critical metric — lower FAR means fewer impostors accepted. System A's 0.01% FAR prioritizes security over the higher FRR inconvenience.

3. Mandatory Access Control: Which access control model is most appropriate?

1. Attribute-Based Access Control (ABAC), where access is computed from combinations of subject, object, and environmental attributes evaluated by a policy engine

   ABAC is the most flexible model, using multiple attributes for access decisions. While it can implement label-based policies, the scenario specifically describes the classic MAC model characteristics. ABAC is more associated with fine-grained modern cloud environments.
2. Discretionary Access Control (DAC), where each resource owner sets and can change the permissions governing who may read or modify their own objects

   In DAC, the resource owner sets permissions. Users CAN override access permissions for resources they own. This violates the requirement that users cannot change access decisions and creates the Trojan horse vulnerability — malicious software running as the user can access everything the user can access.
3. Mandatory Access Control (MAC), where system-enforced security labels on subjects and objects drive every access decision and users cannot alter them ✓

   MAC uses security labels (classifications) on both subjects (users) and objects (data). The system enforces access decisions based on label comparisons — users cannot modify permissions. This rigidity enforces need-to-know by ensuring subjects can only access objects at or below their clearance level. MAC is standard in government/military classified systems.
4. Role-Based Access Control (RBAC), where permissions are bundled into job roles and users receive access by virtue of the role assigned to them

   RBAC assigns permissions based on job roles. While it enforces need-to-know through role definitions, access decisions are not based on security labels attached to objects. RBAC is most common in commercial environments, not classified government systems requiring label-based access control.

MAC enforces access based on security labels that users cannot modify — the system makes all decisions based on subject and object labels, enforcing strict need-to-know.

4. OpenID Connect: Which protocol is designed specifically for this use case?

1. OAuth 2.0, an authorization framework that issues access tokens delegating permission to call provider APIs on the user's behalf after they consent

   OAuth 2.0 is an authorization framework — it delegates access to resources (API calls) on behalf of a user. OAuth 2.0 issues access tokens that grant permission to call APIs, NOT identity tokens that identify who the user is. Using OAuth 2.0 alone for authentication is a security anti-pattern.
2. Kerberos, a ticket-granting authentication protocol that issues session tickets to network services within a single organization's domain

   Kerberos is a ticket-based authentication protocol for network services within a single organization (primarily Windows Active Directory). It does not support cross-organization identity federation or consumer-facing 'login with [provider]' scenarios.
3. SAML 2.0, an XML assertion framework that federates identity through browser redirects, chiefly for enterprise single sign-on to applications

   SAML 2.0 also supports SSO and identity federation, but it uses XML-based assertions and browser redirects designed for enterprise SSO scenarios. SAML is less commonly used for consumer-facing 'login with Google' integrations and is more complex to implement than OIDC's JWT-based approach.
4. OpenID Connect (OIDC), an identity layer built on OAuth 2.0 that issues signed ID tokens carrying the user's name, email, and profile for login ✓

   OIDC is an authentication layer built on top of OAuth 2.0. It provides identity tokens (JWT ID tokens) containing user identity claims (sub, name, email). It is specifically designed for 'login with [provider]' use cases — verifying WHO the user is. OAuth 2.0 alone only delegates access to APIs, not user identity.

OIDC adds an authentication layer (ID tokens with user claims) on top of OAuth 2.0 — OAuth alone provides API access delegation, not user identity verification.

5. Pass-the-ticket attack: Which attack is described, and what is a key mitigation?

1. Pass-the-ticket attack; mitigation includes restricting privileged account logons to dedicated admin workstations and using Protected Users security group to prevent TGT caching ✓

   Pass-the-ticket uses a stolen Kerberos TGT to request Service Tickets as the victim user without the password. Key mitigations: Protected Users group (prevents NTLM fallback, limits ticket lifetime), Privileged Access Workstations (PAWs) that restrict where privileged accounts can log in, and limiting TGT lifetime.
2. Kerberoasting; the mitigation is to enforce long, random passwords on every service account that has an SPN, so the service ticket hashes an attacker requests cannot be cracked offline

   Kerberoasting targets Service Tickets for accounts with SPNs (Service Principal Names) — the attacker requests a service ticket and cracks the service account's hash offline. This is different from pass-the-ticket, which steals and reuses an existing TGT without cracking.
3. Golden ticket attack; the mitigation is to reset all end-user account passwords so the forged ticket-granting tickets held by the attacker are immediately invalidated

   A golden ticket forges a TGT using the KRBTGT account's hash — it does not require stealing a real TGT. Pass-the-ticket uses a real stolen TGT from a compromised user session. Also, resetting user passwords doesn't help against golden tickets — the KRBTGT password must be reset (twice) to invalidate existing golden tickets.
4. Pass-the-hash attack; the mitigation is to enable NTLMv2 across the domain so captured password hashes can no longer be replayed to authenticate as the compromised user

   Pass-the-hash uses an NTLM hash to authenticate without knowing the plaintext password. The scenario describes using a Kerberos TGT — this is pass-the-ticket. Pass-the-hash is an NTLM-specific attack; pass-the-ticket is Kerberos-specific.

Pass-the-ticket reuses a stolen Kerberos TGT on a different machine to impersonate the user; mitigations include Protected Users group and Privileged Access Workstations.

6. Separation of duties: Which security principle is violated, and what is the primary risk?

1. Least privilege; the employee holds far more access than any single job function requires, and trimming those excess rights would have removed the ability to run the whole process

   While least privilege is also violated (the employee likely only needs one of these capabilities), the primary control failure is separation of duties. Least privilege addresses the 'how much access' question; SoD addresses the 'how many steps in a critical process can one person control' question. The exam distinguishes these principles — SoD is the primary answer for fraud prevention in financial processes.
2. Separation of duties; a single employee controlling an entire financial transaction process can commit undetected fraud by creating fictitious vendors and approving fraudulent payments ✓

   Separation of duties (SoD) requires that no single person have end-to-end control over a critical process. In financial controls, vendor creation, invoice approval, and payment authorization should be assigned to different individuals. Without SoD, one person can commit fraud without requiring collusion — the classic insider threat vector.
3. Need-to-know; the employee can reach financial information well beyond what the accounts payable role legitimately requires, exposing sensitive vendor and payment records

   Need-to-know is a confidentiality principle limiting access to information on a need basis. The financial fraud scenario is primarily about transaction process control, not unauthorized information access. Separation of duties is the correct principle for preventing fraud in transactional processes.
4. Dual control; the primary risk is that no second employee is required to act together with the first, and mandating simultaneous authorization on every transfer would have blocked the fraud

   Dual control requires two people to simultaneously be present or act together (e.g., two keys to open a vault). Separation of duties requires different people for different stages of a process. While dual control could be applied to high-value transactions, SoD is the more general and applicable principle for the described multi-step process.

Separation of duties prevents any single person from controlling an entire critical process end-to-end — in finance, vendor creation, invoice approval, and payment must be segregated.

7. Immediately disable all of the employee's system accounts: Which action takes the highest priority?

1. Conduct a thorough exit interview to document knowledge transfer and capture undocumented processes before the administrator's institutional knowledge leaves with them

   Knowledge transfer is important but is a separate HR process with no bearing on the security risk from active system access. The security team's first priority is access revocation, not knowledge documentation.
2. Perform a full access recertification review to enumerate every account and entitlement the employee holds across all systems before deciding what to disable

   An access recertification review is a periodic process for validating access rights. On the day of separation, there is no time for a full review. All accounts should be disabled immediately — identifying the complete list can happen as part of the disablement process, but urgency of disablement outweighs completeness of discovery.
3. Immediately disable all of the employee's system accounts and revoke every active session and access token so no privileged access survives the separation ✓

   Immediate account disablement is the highest priority offboarding action. A disgruntled departing employee with active privileged access poses a critical insider threat risk. All accounts must be disabled on or before the last day — ideally at the moment of separation announcement, or at minimum by end of last day. This prevents unauthorized access after employment ends.
4. Recover all company-issued hardware, including the laptop, badge, and hardware tokens, from the employee before any of their system accounts are disabled

   Hardware recovery is important but secondary. An employee can cause damage from home using network-accessible systems before hardware is physically recovered. Account disablement must happen immediately — hardware recovery can follow but should not delay account disablement.

Immediate account disablement is the highest-priority offboarding action — a departing employee with active privileged access represents an immediate insider threat risk.

8. The SAML assertion's digital signature: What does the SaaS application validate to trust this assertion?

1. The employee's source IP address, which the SaaS application verifies falls within the corporate network's registered public IP range before it trusts the login attempt

   IP address validation is not part of the SAML assertion validation process. While some SPs implement additional contextual checks, the cryptographic trust mechanism is the digital signature on the assertion, not IP verification.
2. A real-time API callback to the Identity Provider on each access, confirming the user's session remains active before the assertion is honored

   SAML is not a real-time verification protocol for each access attempt. The SP validates the assertion's signature and checks the assertion's validity period (NotBefore, NotOnOrAfter). Real-time session verification at each access is more characteristic of OAuth token introspection or session management, not SAML.
3. The employee's username and password, which the Identity Provider forwards inside the assertion so the SaaS application can independently re-verify them

   Forwarding credentials to the SP is precisely what SSO/federation avoids — the SP never sees the user's credentials. The user authenticates only to the IdP; the SP trusts the IdP's assertion about the user's identity.
4. The SAML assertion's digital signature, verified against the Identity Provider's public key certificate that the two parties exchanged during federation setup ✓

   SAML assertions are XML documents signed with the Identity Provider's private key. The Service Provider (SaaS application) has pre-configured the IdP's public key certificate during federation setup. The SP validates the digital signature to confirm the assertion was issued by the trusted IdP and has not been modified.

The SP validates the SAML assertion's digital signature using the IdP's public key certificate — this cryptographic trust was established during the federation setup.

9. Identification: Which sequence of access control steps does this represent?

1. Identification (badge ID presented at the reader), authentication (badge ID verified as genuine), authorization (access list checked for entry permission) ✓

   The three-step IAM process: Identification = claiming an identity (badge presented, ID number read). Authentication = verifying the claimed identity is genuine (card reader validates badge is not forged/cloned, or checks cryptographic features). Authorization = determining what the authenticated identity is permitted to do (checking the access control list for server room entry permission).
2. Authentication (badge swiped and read by the card reader), authorization (badge ID checked against the access list), identification (entry finally granted)

   The sequence is wrong. Identification always comes first (presenting an identity claim), authentication second (verifying the claim), and authorization third (granting permissions based on verified identity). Entry granted is the result of authorization, not a step in itself.
3. Authentication (badge swiped at the reader), identification (badge ID matched to a stored record), authorization (the door lock releases and opens)

   Identification precedes authentication. The badge presents an identity claim first (identification), which is then verified (authentication), before permissions are checked (authorization).
4. Authorization (badge checked against the list), authentication (room unlocked electronically), identification (the person then enters the server room)

   This reverses the order. You cannot authorize an identity before first identifying and authenticating it. Authorization (checking permissions) must follow successful authentication (verifying identity).

IAM sequence: Identification (claim an identity) → Authentication (verify the claim) → Authorization (check permissions). Badge swipe = identification; badge validation = authentication; ACL check = authorization.

10. Attribute-Based Access Control: Which access control model best supports this requirement?

1. Discretionary Access Control (DAC), which lets each resource owner grant or revoke permissions on the objects they own entirely at their own discretion

   DAC allows resource owners to set permissions — it is the most flexible for individual owner decisions but cannot enforce organization-wide multi-attribute policies. DAC lacks centralized policy enforcement across complex attribute combinations.
2. Attribute-Based Access Control (ABAC), which evaluates subject, object, and environmental attributes together in a policy to reach each access decision ✓

   ABAC evaluates multiple attributes simultaneously: subject attributes (department, location, device compliance), object attributes (document sensitivity), and environmental attributes (time of day). Policies express complex conditions combining these attributes — far more flexible than RBAC's role-based assignments.
3. Mandatory Access Control (MAC), which compares system-assigned security labels on subjects and objects against a fixed lattice model to decide every access

   MAC uses security labels and lattice-based access decisions. It does not natively support dynamic environmental attributes like time-of-day, device compliance state, or location — these are ABAC concepts.
4. Role-Based Access Control (RBAC), which grants permissions through predefined job roles that users are assigned according to their function

   RBAC grants permissions based on job roles. For time-of-day, device compliance, and location constraints, RBAC would require creating an explosion of roles (e.g., 'FinanceManagerMobileDeviceCompliantBusinessHours') — this becomes unmanageable. ABAC handles these multi-dimensional policies elegantly.

ABAC evaluates multiple attribute types simultaneously (subject, object, environment) enabling complex policies that RBAC's role explosion cannot handle cleanly.

11. Access creep: Which IAM process failure does this represent, and what control would have prevented it?

1. Separation of duties violation; developers should never be granted any database administrator access because it lets one person both write and run production code

   Separation of duties addresses dividing critical process steps across multiple people to prevent fraud. The scenario describes retained temporary elevated access — this is an access lifecycle management issue, not a SoD violation. Developers may legitimately need database access during specific projects.
2. Identity federation failure; the developer's identity was never synchronized across the connected systems, so stale accounts lingered after the project concluded

   Identity federation synchronizes identity across systems. The scenario describes a permission lifecycle issue — the access was provisioned but not deprovisioned when the project ended. Identity synchronization would not automatically remove permissions when a project concludes.
3. Access creep (privilege creep); periodic access recertification by data owners or managers would have flagged and removed the stale elevated DBA access ✓

   Access creep (privilege creep) occurs when users accumulate permissions over time that are no longer needed. Project-based elevated access should be time-limited or reviewed upon project completion. Periodic access recertification — where managers/owners review and certify that access remains appropriate — would catch and remove stale entitlements.
4. Inadequate authentication; the developer's retained DBA access should have required stronger multi-factor authentication to reduce the exposure

   Authentication strength (MFA, strong passwords) is a separate concern from the appropriateness of access rights. The issue is that unneeded access was retained — stronger authentication for unnecessary access doesn't address the root cause.

Access creep occurs when temporary elevated permissions are not removed after the need ends; periodic recertification by managers/owners identifies and removes stale entitlements.

12. Discretionary Access Control: Which access control model's fundamental weakness does this scenario exploit?

1. Attribute-Based Access Control (ABAC); the problem arises because the policy engine evaluates user attributes at request time, so malware silently inherits those attribute grants and reads every file the user's attributes authorize

   Under ABAC, attributes gate access, but the Trojan horse flaw is that a process inherits the launching user's rights regardless of attributes. That inheritance weakness is specific to DAC's discretionary permissions, not to attribute evaluation.
2. Mandatory Access Control (MAC); the problem arises because label systems let a process read any object at or below the user's clearance, so malware freely exfiltrates all data that shares that classification level

   MAC assigns labels to subjects and objects, but its write-down (*-property) and read constraints actually limit a Trojan's ability to leak data across classifications. The Trojan horse problem is a recognized weakness of DAC, not of MAC.
3. Role-Based Access Control (RBAC); the problem arises because a single role bundles many entitlements together, so malware executing under that role automatically acquires the union of every permission the role contains

   RBAC constrains permissions to role entitlements and is more resistant than DAC, but the Trojan horse problem is specifically tied to DAC's per-user discretionary permissions that any launched process inherits.
4. Discretionary Access Control (DAC); the Trojan horse problem arises because processes run with the same permissions as the user who launched them, allowing malicious software to access all user-accessible resources ✓

   DAC grants permissions based on user identity — processes inherit the user's access rights. A Trojan horse (malicious code embedded in legitimate software) runs with the launching user's full permissions, giving it access to everything the user can access. This is DAC's fundamental limitation — it cannot distinguish the user's intent from the process's actions.

DAC's Trojan horse problem: processes run with the launching user's permissions, so malicious code embedded in user-run applications gains full access to all user-accessible resources.

Other CISSP domains

• Security and Risk Management — 89 questions →
• Security Architecture and Engineering — 87 questions →
• Communication and Network Security — 63 questions →
• Software Development Security — 59 questions →
• Security Operations — 48 questions →
• All 497 CISSP questions →