Cyber Security Quiz: Iam Failure Modes
10 questions · exam conditions
0:00
Iam Failure ModesQuestion 1 of 10

An engineer transfers from database operations to application development. The IAM workflow adds the developer role automatically but leaves the database administrator role in place because the transfer was not classified as a termination. Three months later, the engineer's workstation is compromised.

Which IAM failure most directly increases the potential impact of the compromise?

Role accumulation retained administrative privileges that were no longer required after the transfer
Credential staleness allowed an expired workstation certificate to remain accepted after the transfer
Authentication weakness permitted the engineer to enroll a second factor without identity proofing
Account duplication caused the engineer's application activity to be recorded under two identities
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Iam Failure Modes

Practice Iam Failure Modes in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Iam Failure Modes, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An engineer transfers from database operations to application development. The IAM workflow adds the developer role automatically but leaves the database administrator role in place because the transfer was not classified as a termination. Three months later, the engineer's workstation is compromised.

Which IAM failure most directly increases the potential impact of the compromise?

  1. Role accumulation retained administrative privileges that were no longer required after the transfer (correct answer)
  2. Credential staleness allowed an expired workstation certificate to remain accepted after the transfer
  3. Authentication weakness permitted the engineer to enroll a second factor without identity proofing
  4. Account duplication caused the engineer's application activity to be recorded under two identities
Explanation: When a question describes a user changing roles within an organization, your instinct should be to examine least privilege and access lifecycle management — specifically whether old permissions were cleaned up when new ones were granted. The core failure here is privilege accumulation, sometimes called "role creep." When the engineer transferred, the IAM system granted developer permissions but never revoked the database administrator role. After the workstation is compromised, an attacker inherits everything that engineer could access — not just developer resources, but also sensitive database systems the engineer no longer needed. The retained administrative database role is what turns a routine account compromise into a high-impact incident. Answer A correctly identifies this: the unnecessary privilege directly expands the attacker's blast radius. Answer B describes credential staleness — an expired certificate remaining valid — which is an authentication control failure, not a privilege scoping failure. The passage gives no indication that certificates were involved in the compromise. Answer C describes a multi-factor enrollment weakness, which would affect authentication (how someone proves who they are), not authorization (what they can do once authenticated). Even if relevant, it doesn't explain why the compromise has elevated impact. Answer D introduces account duplication and audit trail confusion, which is an accountability concern but doesn't increase what an attacker can do with the compromised account. Your study tip: when a question asks about impact of a compromise, look for answers about what the attacker gains access to, not just how the compromise happened. Excessive privileges expand impact; weak authentication enables access — these are distinct concepts the exam often conflates as distractors.

Question 2

During an access review, a manager sees that a support analyst belongs only to the HelpDesk group. The HelpDesk group is nested in Operations, which is nested in Platform-Admins. An explicit policy attached to Platform-Admins permits production configuration changes. The analyst has never used that permission.

What is the most accurate IAM finding?

  1. No failure exists because the analyst has not exercised the administrative permission
  2. The account is over-permissioned because effective access includes inherited production administration (correct answer)
  3. The account contains stale credentials because nested membership bypasses normal password rotation
  4. The account is properly scoped because only directly assigned group memberships count during review
Explanation: When reviewing IAM (Identity and Access Management) configurations, you must always evaluate effective permissions, not just what's directly assigned. Effective permissions are the full set of privileges a user actually holds after all group memberships, nesting, and inheritance are resolved — regardless of whether those permissions have ever been used. In this scenario, the analyst belongs to HelpDesk → nested in Operations → nested in Platform-Admins. Because Platform-Admins carries an explicit "permit production configuration changes" policy, that permission flows down through every nested member, including this analyst. The analyst effectively holds production admin rights whether they know it or not. This makes B correct: the account is over-permissioned because inherited access creates real risk, even when unused. A is a dangerous misconception. "Never used" is irrelevant to whether a permission exists and poses risk. An attacker who compromises this account gains full effective permissions instantly. Least-privilege violations don't disappear because the user hasn't clicked a button yet. C confuses two separate IAM concerns. Stale credentials refer to old passwords, unused service accounts, or expired tokens — not permission inheritance. Nested group membership has nothing to do with password rotation policies. D is precisely the trap this question is designed to expose. Only directly assigned groups do not define effective access in most IAM systems. Group nesting propagates permissions transitively, so reviewing only direct assignments gives a false sense of security. Your strategy: whenever you see nested groups on an exam, mentally "unroll" the full chain and ask what permissions reach the user at the deepest level. That unrolled view is what attackers see — and what reviewers must evaluate.

Question 3

An identity governance tool recommends removing every permission not used within the previous 60 days. A payroll administrator has not invoked the year-end tax-reporting function for 11 months, while a developer has broad production write access that has never been part of the developer's assigned duties.

How should an access reviewer interpret these findings?

  1. Both permissions are stale because any entitlement unused for 60 days necessarily lacks business justification
  2. Neither permission is risky because usage history alone cannot establish that an account is over-permissioned
  3. Validate the seasonal payroll need, but remove the developer access unless a current business need is documented (correct answer)
  4. Retain the developer access, but remove the payroll permission because it has the longer inactivity period
Explanation: Access reviews aren't just about flagging idle accounts — they require understanding why a permission exists and whether the inactivity reflects a real risk. When you see a question pairing a contextually explainable absence with a structurally inappropriate permission, your job is to distinguish between "unused because of timing" and "unused because it was never legitimate." The payroll tax-reporting function is a classic seasonal entitlement. Year-end processing happens once annually, so eleven months of inactivity is entirely expected — removing it based purely on the 60-day rule would disrupt a legitimate, documented business function. The developer's broad production write access, however, has never been part of their assigned duties. That's not a timing issue; it's a structural over-permissioning problem. The access shouldn't exist regardless of usage frequency. Retaining it violates the principle of least privilege. Answer C correctly treats these as fundamentally different situations: verify the seasonal business need for the payroll permission, and revoke the developer access unless someone can produce a current justification. Answer A is wrong because it treats the 60-day threshold as an absolute rule, ignoring business context. Automated tools flag candidates for review — they don't replace human judgment. Answer B swings to the opposite extreme, arguing that usage data is meaningless, which discards a genuinely useful signal about over-permissioning. Answer D inverts the logic entirely, retaining the clearly unjustified developer access while penalizing a permission that has a straightforward seasonal explanation. Your study tip: on access management questions, always ask two separate questions — "Is the inactivity explainable?" and "Was the permission ever appropriate?" These have independent answers, and confusing them is exactly the trap these questions are designed to set.

Question 4

A service account's secret is rotated every 30 days. After each rotation, the new secret is emailed to four administrators and copied into several deployment files. Old secrets are invalidated immediately, but one deployment file belongs to a retired application and is never updated or deleted.

Which assessment is most accurate?

  1. Rotating the secret every 30 days eliminates credential risk regardless of how the secret is distributed
  2. The retired file proves every previously issued secret remains valid and can still authenticate
  3. The retired file holds a stale secret, but immediate invalidation means that old value can no longer authenticate (correct answer)
  4. The account is over-permissioned because sharing the same secret with multiple administrators expands its authorization scope
Explanation: Credential lifecycle management questions test whether you understand that secret validity and secret exposure are two separate concerns. When a secret is rotated, the old value is invalidated — meaning it can no longer authenticate. But exposure is a different problem: who has seen the secret, where it's been stored, and whether those locations are properly governed. With that framing, C is the most accurate assessment. The retired deployment file does hold an old secret, but because the organization immediately invalidates previous secrets upon rotation, that stale value is cryptographically dead — it won't grant access. The risk the retired file creates is operational clutter and a potential future misconfiguration, not an active authentication vulnerability right now. A is wrong because it overclaims. Rotation reduces risk but doesn't eliminate it regardless of distribution. If secrets are emailed and scattered across files without proper access controls, exposure risk still exists during the 30-day window the secret is active. "Regardless of how it's distributed" is the red flag phrase here. B is wrong because it directly contradicts the scenario. The passage explicitly states old secrets are immediately invalidated, so a stale secret in the retired file cannot authenticate — it's not a backdoor to valid credentials. D is wrong because it confuses exposure scope with authorization scope. Sharing a secret with multiple administrators expands who knows the secret, not what the account is permitted to do. Over-permissioning refers to excessive privileges, which isn't described here. Watch for answer choices that conflate credential exposure with credential validity — they sound similar but represent entirely different risks.

Question 5

A security administrator removes a compromised user's privileged group memberships at 10:00. The IAM console shows that the user now has standard access only. At 10:15, the same user successfully performs an administrative action through an application that issued an eight-hour access token at 09:00 and does not re-evaluate group membership until token renewal.

Which remediation most directly closes the immediate IAM gap?

  1. Shorten the password-expiration period, then require a password change at the next interactive login
  2. Reset the user's password, then wait for the eight-hour token to expire through normal processing
  3. Remove the user from additional standard groups, then preserve the existing token for audit evidence
  4. Revoke active sessions and tokens, then verify that new tokens contain only current entitlements (correct answer)
Explanation: When you encounter IAM remediation questions, focus on timing and token lifecycle. The core issue here isn't what the directory says — it's what the active token contains. Revoking group membership in the console updates the source of truth, but any already-issued token carries its entitlements like a signed ticket: valid until expiration or explicit revocation, regardless of what changed upstream. That's exactly why D is correct. Revoking active sessions and tokens immediately invalidates the eight-hour token issued at 09:00 — the one still carrying privileged claims. When the user authenticates again, the new token is minted against current group membership, which now reflects only standard access. This directly closes the gap with no waiting period. A is a common distraction because password changes feel like strong remediation. But changing the password doesn't invalidate an already-issued bearer token. The malicious session continues until that token expires naturally — potentially hours later. B recognizes the token problem but prescribes passive waiting. "Wait for the eight-hour token to expire" means up to nearly eight more hours of administrative access for a compromised account. That's not remediation — that's acceptance of continued risk. C is especially misleading. Removing the user from additional standard groups actually reduces their standard access, not their privileged access, while deliberately preserving the dangerous token under the guise of audit preservation. Logs should capture evidence; tokens should not be kept active for that purpose. Your study tip: directory state ≠ session state. On IAM questions, always ask whether the fix addresses the active token or only the identity record — they're different attack surfaces.

Question 6

A vendor's maintenance engagement ended yesterday. The vendor account has a valid password, an enrolled hardware token, and privileged access to a production appliance. Logs show no login for 90 days, but the contract owner has not confirmed whether emergency support will continue.

Which immediate response best reduces IAM risk while allowing the access decision to be resolved?

  1. Disable the account temporarily and require documented reauthorization before restoring privileged access (correct answer)
  2. Rotate the password immediately while leaving the account and hardware token fully enabled
  3. Keep the account active until inactivity reaches the organization's standard 180-day threshold
  4. Remove the hardware token while preserving password-only privileged access for emergency support
Explanation: When you see IAM (Identity and Access Management) questions involving vendor or third-party accounts, your mental framework should center on the principle of least privilege combined with separation of duties: access should exist only as long as it is actively authorized, and uncertainty is never a valid reason to leave privileged access open. Here, the vendor's contract ended, no login has occurred in 90 days, and authorization for continued access is unconfirmed. The risk is real and immediate — an active privileged account with MFA credentials on a production system is a significant attack surface. Option A is the right move because it neutralizes the immediate risk without burning the bridge: disabling the account preserves the credentials, token enrollment, and audit trail, so access can be cleanly restored if the contract owner confirms emergency support is still needed. Reauthorization creates the documented paper trail that compliance frameworks (like NIST 800-53 or ISO 27001) require. Option B is flawed because rotating the password while leaving the account and hardware token active does almost nothing — the account remains fully functional and the token alone could be leveraged in certain flows. Option C essentially kicks the can down the road using an arbitrary inactivity threshold as a substitute for an actual access decision; thresholds exist for automated cleanup, not for resolving known, active authorization gaps. Option D is backwards — removing MFA while keeping password-only privileged access increases risk by stripping a security layer from an already-questionable account. Your takeaway: on IAM questions, "disable with documented reauthorization" is almost always preferable to partial measures. Reversible + auditable = the right IAM default when authorization is unclear.

Question 7

A cloud team deletes an external partner's local user accounts after a project ends. However, a production role still trusts the partner's cloud account and can be assumed by any principal in that account. The role has broad storage and database permissions.

Which control gap remains after the local accounts are deleted?

  1. A stale federated trust can still grant an external identity over-permissioned production access (correct answer)
  2. A password-reuse condition can restore the deleted local accounts through the partner's directory
  3. A missing local group can prevent production administrators from reviewing database audit events
  4. An expired encryption certificate can cause the cloud role to inherit storage permissions automatically
Explanation: When you see a question about cloud access control, focus on identity trust relationships — not just local accounts. Deleting local users removes one attack surface, but cloud environments often have separate trust mechanisms that persist independently. Here, the real gap is that the production role has a cross-account trust policy allowing any principal from the partner's cloud account to assume it. This is a federated trust — the role doesn't care about your local user accounts at all. Even after those accounts are deleted, someone from the partner's cloud account can still assume the role and access storage and databases with broad permissions. That's exactly what A describes: a stale federated trust granting an external identity over-permissioned production access. A makes this the correct answer. B is a red herring. Password-reuse conditions and directory sync don't "restore" deleted accounts — deletion is not reversible through credential reuse alone. This conflates password policies with account lifecycle management in a way that doesn't reflect how cloud IAM actually works. C introduces a missing local group affecting audit log review. While audit access is a real concern, the question asks about the control gap that remains after deletion — nothing in the scenario involves broken audit visibility. D is technically nonsensical. Expired encryption certificates don't cause roles to inherit permissions. Certificate lifecycle and IAM role permissions are entirely separate systems; one expiring doesn't trigger the other. Study tip: On cloud security questions, always ask yourself: are there trust relationships that exist outside local user accounts? Cross-account roles, federated identity providers, and service principals can all survive account deletions — review each independently.

Question 8

A company disables a departing contractor's interactive user account on the contractor's final day. The contractor had previously created an API key for an automation account, stored it on a personal laptop, and documented no owner or expiration date. The automation account remains enabled.

Which action most directly addresses the residual IAM risk?

  1. Reset the contractor's disabled user-account password and preserve the API key for operational continuity
  2. Revoke the API key and validate whether the automation account still has a legitimate business owner (correct answer)
  3. Remove the contractor from interactive login groups and retain the automation account's existing permissions
  4. Require multifactor authentication for future contractor logins and leave noninteractive credentials unchanged
Explanation: When a question describes a departing user who controlled credentials beyond their primary account, your focus should shift immediately to orphaned credentials — a classic IAM risk where access outlives the person who created it. Disabling an interactive login is only one layer; any API keys, service tokens, or automation accounts that person controlled remain live attack surfaces. This is exactly the trap the scenario sets. The contractor's interactive account is disabled, which feels like the problem is solved — but the API key stored on a personal laptop still works, and the automation account it authenticates against has no documented owner. That combination means an unauthorized party could use the key indefinitely, with no one monitoring or claiming responsibility for the account. Answer B directly closes both gaps: revoking the API key eliminates the stolen-credential risk, and validating business ownership ensures the automation account is either transferred to a legitimate owner or decommissioned. Answer A is actively harmful — resetting the password on a disabled account doesn't re-enable it and preserving the API key leaves the core vulnerability untouched. Answer C addresses only the interactive login side again; removing someone from login groups when their account is already disabled accomplishes nothing, and retaining the automation account's permissions leaves the orphaned access in place. Answer D is a forward-looking control for future contractors and explicitly ignores the noninteractive credentials that are the entire problem here. As a study tip, remember that on IAM questions, credential scope matters as much as account status. Always ask: were there any keys, tokens, or service accounts this person owned? Disabling one login rarely eliminates all access paths.

Question 9

An HR feed identifies workers by email address. After an employee changes their surname, the IAM platform creates a new account under the new email address but does not associate it with the prior identity. The employee can use the new account, while the old account remains enabled with finance-system access.

Which failure mode best explains the remaining exposure?

  1. A password-complexity defect causes both accounts to derive credentials from the same surname value
  2. A separation-of-duties conflict occurs because two employees now approve the same finance transaction
  3. A federation outage prevents the new account from receiving finance permissions from the old account
  4. An orphaned duplicate identity retains valid credentials and authorization after the identity attribute changed (correct answer)
Explanation: When you see IAM (Identity and Access Management) scenarios on the exam, focus on the lifecycle of an identity — what happens when attributes change, accounts multiply, or deprovisioning fails. The core danger is always: does a stale identity retain access it should no longer have? Here, the employee's surname changed, triggering a new account — but the old account was never disabled or linked to the new one. That old account still holds valid credentials and finance-system authorization. Nobody revoked it. Nobody owns it. This is the textbook definition of an orphaned duplicate identity: a ghost account that persists with real access after the legitimate identity has effectively moved on. That makes D the correct answer — the failure is precisely that an unlinked, forgotten account retains both working credentials and active permissions. A is wrong because password complexity has nothing to do with the scenario. No credential-derivation flaw is described; the issue is account proliferation and missing deprovisioning, not how passwords are constructed. B introduces separation-of-duties, which concerns conflicting approval authorities between people — there's no mention of two employees approving the same transaction, so this is a complete mismatch. C brings up federation outages, which relate to broken trust between identity providers and service providers. No federation failure is described; the new account actually works fine. The problem is the old account persisting, not the new one failing. Your study tip: whenever a question describes an account that lingers after a change event, immediately think orphaned identity and deprovisioning failure. These questions test whether you understand that IAM risk isn't only about granting access — it's equally about revoking it.

Question 10

An organization maintains a break-glass account with unrestricted administrative access. The password is stored in a controlled vault, checkout requires two approvers, every use triggers an alert, and the password is rotated after checkout. During a quarterly review, auditors discover that a second break-glass account has the same privileges but no documented owner and has not been tested for two years.

What is the most appropriate conclusion?

  1. Both accounts violate least privilege solely because unrestricted emergency permissions are always prohibited
  2. The second account is a stale privileged identity, while the controlled account may be justified by safeguards (correct answer)
  3. The controlled account is stale because rotating its password after use prevents routine login activity
  4. The second account is acceptable because inactivity demonstrates that its privileges have not been abused
Explanation: When you see a question about privileged access management, ask yourself: what controls justify keeping a high-privilege account, and what makes an account a security liability? The key distinction is between controlled risk and unmanaged risk. The first account, despite having unrestricted access, is surrounded by compensating controls — dual-approval checkout, alerting on every use, and post-use password rotation. These safeguards make the risk visible and bounded. Emergency "break-glass" accounts can be legitimate precisely when such guardrails exist. The second account, however, has no documented owner, no evidence of testing in two years, and presumably none of those controls. An undocumented, untested privileged account is the textbook definition of a stale privileged identity — an orphaned account that attackers could exploit with no one noticing. That reasoning confirms B as correct. A is wrong because it overgeneralizes. Unrestricted emergency access is not automatically prohibited; it can be justified by compensating controls. Blanket statements like "always prohibited" are usually traps on security exams. C misunderstands what makes an account "stale." Password rotation after checkout is a security best practice, not evidence of inactivity. Staleness refers to unreviewed, unowned, or untested accounts — not accounts with rotating credentials. D is dangerously backwards. Inactivity does not prove safety; it may simply mean the account hasn't been discovered or used by an attacker yet. Absence of abuse is not evidence of acceptable risk. Study tip: On privileged access questions, always evaluate accounts on two axes — what controls exist and is the account still actively governed. Both matter independently.