CISSP Identity and Access Management practice questions
7-day money-back guarantee — full refund within 7 days of purchase if you've completed under 20% of the questions. See pricing →
Certifications Tools Flashcards Career Paths Exam Guides Blog Pricing For Teams About

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

CISSP 156 questions 12 shown free

12 of the 156 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. Password plus a phone authenticator: Which design should be selected?

Medium
An online retailer requires two authentication factors for account recovery. The proposed design combines a password with a security question, while the customer-experience team argues that adding a phone authenticator will increase abandonment. The security owner must approve a design consistent with independent-factor requirements. Which design should be selected?
  1. Security question plus account profile information.
    Both responses depend on remembered or discoverable information rather than an independent possession factor.
  2. Password plus a phone authenticator. ✓
    A password supplies knowledge and a phone authenticator supplies possession, creating independent factor categories.
  3. Two different passwords stored in separate password managers.
    Separate storage does not change that both credentials are knowledge factors controlled by the user.
  4. Password plus a second security question.
    Both credentials are knowledge factors, so they do not provide independent factor categories.
The trap
Additional personal information remains knowledge-based authentication. Storage separation does not create factor independence. Two knowledge credentials remain one factor type.

Independent factors require different categories; knowledge plus possession satisfies the retailer’s stated requirement.

2. Reject it because its audience does not identify this: What should the grants service do?

Hard
An international nonprofit receives a SAML assertion for its grants application. The assertion signature validates against the trusted identity provider certificate, the subject is an active employee, and the assertion has not expired. However, its audience value identifies the payroll application rather than the grants service. What should the grants service do?
  1. Accept it after checking the employee’s current department.
    Department authorization cannot correct an assertion whose intended relying party is a different application.
  2. Reject it because its audience does not identify this service. ✓
    Audience restriction prevents a valid assertion issued for one service from being replayed at another.
  3. Accept it because the signature and subject are valid.
    A valid signature authenticates issuer integrity but does not make an assertion intended for another service acceptable.
  4. Request a new signature while retaining the payroll audience value.
    Resigning the assertion leaves its recipient restriction unchanged and therefore preserves the underlying validation failure.
The trap
Cryptographic renewal cannot fix the wrong audience. Business attributes do not repair an audience mismatch. Confuses issuer validation with intended recipient validation.

The assertion is cryptographically valid but addressed to another relying party, so the grants service must reject it.

3. Use approved evidence to proof identity before issuing: Which approach resolves the requirement?

Medium
A telecommunications provider is onboarding contractors to administer network equipment. Management proposes accepting an existing email address and password as proof that each contractor is the claimed individual. The assurance policy requires identity proofing before issuing privileged administrative credentials, while authentication is required for every later login. Which approach resolves the requirement?
  1. Authenticate the email account and issue limited credentials until identity review is complete.
    Email authentication verifies account control, not the claimed identity, and issuance still occurs before required proofing.
  2. Use approved evidence to proof identity before issuing credentials, then authenticate each login. ✓
    Identity proofing establishes the contractor's claimed real-world identity before issuance; authentication subsequently verifies each login.
  3. Verify the claimed identity before issuing credentials.
    This is directionally correct but does not explicitly require approved evidence or authentication for later logins.
  4. Require a stronger password and manager approval after the first administrative login, then complete identity review.
    Password strength, manager approval, and delayed review do not satisfy pre-issuance identity proofing.
The trap
Omits the required evidence and continuing authentication step. Defers mandatory proofing after access is granted. Improves credential controls while missing the required sequence.

Proof identity with approved evidence before issuance, then authenticate every later login.

4. Synchronize authoritative HR changes with automated: Which approach is best?

Hard
A professional services firm's HR system records employee transfers within one day, but several applications process role changes only during a weekly batch. A consultant moved from billing to advisory work and retained billing access for six days. The firm must preserve legitimate new access while preventing residual privileges, and it may not rely on managers remembering manual requests. Which approach is best?
  1. Disable transferred employees until application owners manually approve all replacement access.
    This removes residual access but unnecessarily interrupts legitimate work and does not provide scalable lifecycle handling.
  2. Send managers weekly reminders to submit transfer-related access requests.
    Reminders depend on human follow-through and leave residual privileges during the documented processing delay.
  3. Keep billing access until each application owner confirms the transfer.
    Retaining old access knowingly extends the demonstrated excessive-privilege window.
  4. Synchronize authoritative HR changes with automated revocation and approved exception handling. ✓
    Automated lifecycle events promptly remove obsolete entitlements while controlled exceptions preserve legitimate replacement access.
The trap
Confirmation delay perpetuates residual access. Awareness does not provide timely, reliable deprovisioning. Overbroad disabling sacrifices required business access.

Automated lifecycle synchronization removes obsolete access promptly while preserving approved replacement entitlements.

5. Revoke application privilege separately from physical: Under the organization’s separate physical and logical

Medium
A food distributor transfers a warehouse employee into a purchasing role. Facilities changes the employee’s physical badge profile, but the purchasing application still grants the former warehouse inventory-administrator privilege. The employee needs continued building access and ordinary purchasing functions. Under the organization’s separate physical and logical access authorities, which action is most appropriate?
  1. Revoke application privilege separately from physical badge access. ✓
    Physical entry and application authorization are separate entitlements requiring independent lifecycle updates.
  2. Disable the badge and application account together.
    This removes necessary building access and does not reflect the employee’s legitimate purchasing responsibilities.
  3. Replace the badge with a stronger credential while retaining application permissions.
    Stronger badge authentication does not reduce the employee’s obsolete application privilege.
  4. Leave both unchanged until the next quarterly access review.
    Delayed review leaves excessive application privilege active despite the known role transfer.
The trap
Improves physical authentication while ignoring logical authorization. Conflates physical access changes with logical privilege changes. Periodic review is too slow for a known entitlement change.

Badge access and application privileges are distinct entitlements, so only the obsolete logical privilege requires revocation.

6. Use attribute-based rules for department: Which control best addresses the demonstrated failure?

Medium
A hospital consortium’s RBAC design has separate roles for each department, shift, facility, device type, and treatment specialty. Adding one new specialty requires dozens of combinations, and reviews find inconsistent permissions among nearly equivalent roles. The consortium needs authorization based on changing context without abandoning accountable policy decisions. Which control best addresses the demonstrated failure?
  1. Assign all clinicians one broad role and review permissions annually.
    A broad role removes granularity and permits excessive access between departments, shifts, and specialties.
  2. Give department managers discretionary permission to edit every role.
    Discretionary role editing increases inconsistency and weakens centralized, reviewable authorization governance.
  3. Use attribute-based rules for department, shift, facility, and specialty. ✓
    Attributes express changing context directly, reducing role combinations while preserving explicit authorization policy.
  4. Add more narrowly defined roles for each new specialty.
    Additional roles increase administrative complexity and worsen the demonstrated role-explosion problem.
The trap
Expands the failing mechanism instead of reducing combinations. Reduces roles by sacrificing least privilege and contextual separation. Adds uncontrolled variation to an already inconsistent model.

Attribute-based authorization represents changing contextual properties directly, avoiding proliferating combinations of narrowly defined roles.

7. The configured failed-attempt rate limit is not being: What control failure is demonstrated?

Medium
A logistics operator policy rejects passwords on a compromised/common-secret blocklist and applies a delay after five failed attempts in 15 minutes. Exhibit: a known compromised password is rejected immediately; six incorrect attempts against another account receive identical immediate responses, and the account remains usable. What control failure is demonstrated?
  1. The password blocklist is not rejecting common secrets consistently.
    The known compromised password was rejected immediately, demonstrating blocklist operation for the tested secret.
  2. The account lockout threshold is configured above the policy's five-attempt limit.
    The evidence shows the required delay was not enforced, but it does not establish that the configured threshold is above five.
  3. The configured failed-attempt rate limit is not being enforced. ✓
    Six immediate failures without delay directly contradict the stated five-attempt rate-limit requirement.
  4. The account provisioning process bypasses password screening during enrollment.
    The exhibit tests authentication behavior, not whether enrollment bypassed screening during account provisioning.
The trap
Suggests one possible configuration cause without evidence. Mistakes successful blocklist evidence for a demonstrated blocklist failure. Changes the tested lifecycle stage without supporting evidence.

The evidence confirms blocklisting but directly shows that the required failed-attempt delay is absent.

8. Add OpenID Connect so the client receives and validates: What corrective action best addresses the failed test

Medium
A municipal water operator’s partner portal uses OAuth authorization to obtain an access token for a maintenance API. During testing, the portal accepts the token for API access but cannot establish who signed in because no authentication assertion is supplied. What corrective action best addresses the failed test?
  1. Add OpenID Connect so the client receives and validates an identity assertion. ✓
    OpenID Connect adds authentication over OAuth2, addressing identity while preserving delegated API authorization.
  2. Grant the OAuth access token broader API permissions to identify the operator.
    Broader API authorization changes permissions, not whether the token establishes the signing-in user’s identity.
  3. Replace OAuth with LDAP authentication for every portal user.
    LDAP is a directory access protocol and does not specifically add the missing federated authentication assertion.
  4. Require single sign-on and assume it automatically supplies multifactor authentication.
    Single sign-on reduces repeated sign-ins but does not automatically mean multifactor authentication or identity assertions.
The trap
It expands authorization instead of correcting missing authentication. It confuses directory access with delegated authorization and identity. It treats a convenience mechanism as proof of authentication strength.

OAuth delegates authorization; OpenID Connect adds authentication needed to identify the signed-in operator.

9. Use phishing-resistant cryptographic authentication bound: Which conclusion is justified?

Medium
A government records office requires multifactor authentication for remote administrators. A phishing simulation captures an administrator’s password and one-time passcode through a proxy, although the login technically used two factors. Which conclusion is justified?
  1. Increase the one-time passcode length and retain the same workflow.
    A longer passcode remains relayable because the workflow does not bind authentication to the legitimate verifier.
  2. Use phishing-resistant cryptographic authentication bound to the verifier. ✓
    Cryptographic verifier binding prevents the captured password and proxied one-time passcode from authenticating elsewhere.
  3. Require two passwords so the login uses additional knowledge evidence.
    Two passwords remain one factor because both are knowledge evidence and can be captured together.
  4. Replace the passcode with a biometric while retaining password login.
    Biometrics add another factor but do not necessarily provide phishing-resistant verifier binding.
The trap
It equates biometric use with phishing resistance. It mistakes multiple secrets for independent authentication factors. It strengthens a phishable factor without addressing phishing.

The proxy captured both existing factors, so cryptographic verifier binding is needed for phishing resistance.

10. Shared service credentials can still obscure which human: Which TWO limitations remain?

Easy
A remote clinical service inventories service accounts, assigns each an application owner, disables accounts unused for 30 days, and alerts when a disabled account is used. Which TWO limitations remain? Select TWO.

Select two. More than one option is correct — every correct one is ticked below.

  1. The inventory cannot support any account deprovisioning decision.
    Inventory ownership and inactivity data directly support identifying and disabling accounts for lifecycle management.
  2. An alert proves the subsequent use was authorized by a responsible owner.
    An alert records activity but cannot establish that the activity had legitimate authorization.
  3. Shared service credentials can still obscure which human initiated activity. ✓
    A service identity may record account activity without uniquely attributing actions to an individual operator.
  4. An active orphaned account can remain usable until the inactivity threshold expires. ✓
    The safeguard is time-based, so an ownerless account used periodically can remain enabled indefinitely.
  5. Disabling inactive accounts guarantees application dependencies will remain available.
    Disabling an account can affect undocumented dependencies; inventory does not guarantee operational continuity.
The trap
It treats lifecycle control as an availability guarantee. It confuses detection of use with authorization validation. It denies capabilities the implemented safeguard explicitly provides.

Time thresholds leave periodically used orphaned accounts active, while shared identities still weaken individual accountability.

11. The service identity can still misuse its authorized: What residual limitation remains?

Medium
An industrial manufacturer gives a service identity permission to execute only two required database procedures. The identity is stored in a protected vault and access is logged. What residual limitation remains?
  1. Restricting procedures prevents all damage from stolen credentials.
    Restricted permissions reduce scope but cannot guarantee harmless behavior within the permitted procedures.
  2. Logging proves every procedure call was business-approved before execution.
    Logs provide an activity record but do not prove prior business approval for each invocation.
  3. The service identity can still misuse its authorized procedures if compromised. ✓
    Least privilege limits available operations but cannot prevent misuse of operations the compromised identity legitimately may execute.
  4. The vault makes database authorization unnecessary for this identity.
    Credential protection does not replace authorization checks on the database objects or procedures.
The trap
It confuses accounting evidence with authorization. It overstates least privilege as complete compromise prevention. It confuses secret storage with permission enforcement.

Least privilege reduces scope, but a compromised identity may still misuse its two authorized procedures.

12. Identically classified agents may receive different: What inference is justified?

Medium
An online retailer’s ABAC policy permits refunds only when the requester is a support agent, the device is managed, the transaction is within the requester’s region, and the refund amount is below the approved threshold. What inference is justified?
  1. The support-agent role alone determines every refund decision.
    The policy explicitly requires device, regional, and transaction attributes in addition to the requester’s role.
  2. A managed device automatically grants refund authority regardless of requester.
    Device management is one condition and cannot replace the required identity, region, and transaction attributes.
  3. The policy is mandatory access control because it evaluates multiple conditions.
    Evaluating contextual attributes does not make a policy mandatory access control by itself.
  4. Identically classified agents may receive different decisions when context changes. ✓
    ABAC evaluates subject, device, location, and transaction attributes, so changed context can change authorization.
The trap
It treats one contextual attribute as sufficient authorization. It reduces attribute-based evaluation to role-based authorization. It confuses policy labels with the stated decision mechanism.

ABAC can produce different decisions for the same role when contextual attributes differ.

144 more Identity and Access Management (IAM) questions

The remaining 144 questions in this domain are part of the full CISSP bank — 1200 questions, every option explained. Start with the free five-minute check and see your score per domain.

Test your CISSP readiness — free

Other CISSP domains

Part of the Certsqill CISSP question bank · Identity and Access Management (IAM) · Every answer, right and wrong, comes with its own explanation.