Cyber Security Quiz: Account Lifecycle Management
10 questions · exam conditions
0:00
Account Lifecycle ManagementQuestion 1 of 10

A company uses HR as the authoritative identity source. A hiring manager submits an access request for a new employee one week before the employee's HR start date so that equipment and applications will be ready on the first day. The request includes standard departmental access and access to a sensitive finance system.

Which provisioning approach BEST balances operational readiness with account lifecycle controls?

Create all requested accounts immediately, but require the employee to change each temporary password on the start date.
Stage the identity and standard accounts in advance, activate them on the HR start date, and require separate approval for finance access.
Wait until the employee signs in on the start date, then provision all requested access based solely on the manager's request.
Activate standard and finance access immediately, but configure monitoring to alert if either account is used before the start date.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Account Lifecycle Management

Practice Account Lifecycle Management 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 Account Lifecycle Management, 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

A company uses HR as the authoritative identity source. A hiring manager submits an access request for a new employee one week before the employee's HR start date so that equipment and applications will be ready on the first day. The request includes standard departmental access and access to a sensitive finance system.

Which provisioning approach BEST balances operational readiness with account lifecycle controls?

  1. Create all requested accounts immediately, but require the employee to change each temporary password on the start date.
  2. Stage the identity and standard accounts in advance, activate them on the HR start date, and require separate approval for finance access. (correct answer)
  3. Wait until the employee signs in on the start date, then provision all requested access based solely on the manager's request.
  4. Activate standard and finance access immediately, but configure monitoring to alert if either account is used before the start date.
Explanation: When a question involves pre-hire provisioning, you should be thinking about two competing pressures: operational readiness (getting systems ready before day one) and identity lifecycle governance (ensuring access is tied to verified employment status and proper authorization). The best solutions satisfy both without sacrificing either. Option B threads this needle precisely. By staging the identity and standard accounts in advance, the system is ready to go on day one. Activating everything on the HR start date ensures accounts are tied to a verified employment event — not just a manager's promise. Requiring separate approval for the sensitive finance system reflects the principle of least privilege and separation of duties, acknowledging that not all access should flow through a single request, especially for high-risk systems. Option A fails because creating live accounts before employment begins creates orphaned or premature access. A password-change requirement on the start date is a weak compensating control — the accounts exist and could be exploited before anyone notices. Option C goes to the opposite extreme: waiting until the employee physically arrives to begin provisioning defeats the entire purpose of advance planning and creates a chaotic first-day experience. Option D is the most dangerous choice — fully activating sensitive finance access immediately and relying on monitoring is reactive, not preventive. Monitoring alerts you after a violation; it doesn't stop one. The pattern to remember here is stage, then activate. Pre-provisioning is legitimate and useful, but activation should be gated by an authoritative lifecycle event (like an HR start date), and elevated access should always require a separate approval step regardless of timing.

Question 2

An organization automatically disables accounts in connected software-as-a-service applications when HR records a termination. A monthly review finds that several terminated users still have active accounts in one application because its provisioning connector failed silently.

Which improvement would MOST directly address the lifecycle-control weakness?

  1. Require terminated employees' managers to attest monthly that the employees no longer need access to the application.
  2. Delete terminated users from the HR system after processing so the provisioning connector has fewer records to synchronize.
  3. Shorten password-expiration periods in the affected application so terminated users eventually lose usable credentials.
  4. Add reconciliation and exception alerts that compare authoritative termination records with actual application account status. (correct answer)
Explanation: When you see a question about identity and access management failures, focus on the root cause: the system didn't know it had failed. Silent failures are among the most dangerous control gaps because they create an illusion of security while leaving real exposure. The fix must address the detection gap, not just the symptom. Option D is correct because reconciliation — automatically comparing what the authoritative HR system says should be true against what the application reflects is true — directly closes that gap. Exception alerts then surface any mismatch immediately, converting a silent failure into a visible, actionable event. This is a fundamental principle of identity governance: your provisioning system is only as trustworthy as your ability to verify its outputs. Option A is tempting because manager attestation sounds like a control, but it's a compensating detective control that relies on human memory and monthly scheduling — it doesn't fix the automated process or guarantee timely discovery. It also places accountability on someone who may not know a connector failed. Option B is counterproductive. Deleting terminated users from the HR system removes the authoritative record needed to drive deprovisioning. You'd be destroying the source of truth rather than using it to enforce access removal. Option C addresses the wrong layer entirely. Password expiration creates a delay — terminated accounts might remain usable for weeks — and doesn't actually remove access. It's a weak compensating measure, not a lifecycle control. The study tip here: when a question involves a process that "failed silently," the strongest answer will always involve visibility and verification mechanisms, not workarounds that assume the broken process eventually corrects itself.

Question 3

A terminated employee's mailbox and cloud files are subject to a legal hold. The legal department instructs IT to preserve all relevant records for an investigation. The employee must not retain access after the termination time.

Which action BEST satisfies both deprovisioning and preservation requirements?

  1. Keep the user account active but reset its password, because the retained content remains associated with an accessible identity.
  2. Disable interactive access and revoke sessions while preserving the mailbox and files under retention or legal-hold controls. (correct answer)
  3. Delete the user account and all associated content immediately, then recover records later from ordinary system backups if requested.
  4. Convert the account into a shared account for legal personnel while leaving the employee's existing sessions unchanged.
Explanation: When a question pairs deprovisioning with legal hold, you're being asked to balance two competing obligations: security (terminate access immediately) and compliance (preserve data intact). The trap is assuming these goals conflict — they don't, if you use the right controls. The ideal solution, captured in B, separates identity access from data retention. Disabling interactive login and revoking active sessions immediately cuts off the former employee's ability to authenticate or continue any live session. Simultaneously, placing the mailbox and files under retention or legal-hold controls preserves them in a legally defensible, tamper-evident state — exactly what the legal department needs. The account can remain in a disabled state in the directory purely as an anchor for that data, without granting any real access. A fails because keeping the account active — even with a reset password — leaves an enabled identity in the system. That's a security risk, and it doesn't constitute proper deprovisioning. Password resets are not a substitute for disabling or suspending an account. C is the most dangerous choice. Deleting the account and its associated content would almost certainly destroy evidence, violating the legal hold. Backup recovery is unreliable, slow, and may be incomplete — courts do not look favorably on organizations that delete records under active holds. D converts the account into a shared account while leaving existing sessions open, which means the terminated employee could still be authenticated. That directly violates the deprovisioning requirement. Remember this pattern: on exam questions involving legal holds, access removal and data preservation are independent controls — never sacrifice one for the other.

Question 4

During an incident, an analyst needs elevated access to a forensic platform for approximately four hours. Standard administrator accounts require lengthy approval, so the incident manager requests a temporary privileged account. Similar temporary accounts have previously remained active after incidents ended.

Which provisioning design BEST addresses the operational need and prior lifecycle failure?

  1. Provision a named privileged account with an enforced four-hour expiration, recorded approval, and automatic removal of elevated access. (correct answer)
  2. Provision a shared privileged account with a rotating password and ask the incident manager to request deletion after the investigation.
  3. Add permanent privileges to the analyst's ordinary account and rely on the next quarterly review to determine whether they remain necessary.
  4. Provide the existing administrator's credentials to the analyst and change the password after the incident has been formally closed.
Explanation: When a question describes both an operational urgency and a past lifecycle failure (accounts lingering after incidents), you're being tested on just-in-time (JIT) privileged access provisioning — the principle that elevated access should be scoped tightly in time, identity, and accountability, then automatically revoked. The strongest solution is A. It satisfies every requirement simultaneously: the account is named (creating individual accountability), carries an enforced four-hour expiration (time-scoping eliminates reliance on human follow-through), includes recorded approval (audit trail), and removes elevated access automatically (directly addressing the prior failure of accounts surviving past their purpose). Automatic expiration is the critical differentiator — it doesn't trust anyone to remember. B is tempting because rotating passwords add some security, but a shared account destroys individual accountability, and asking the manager to request deletion manually repeats exactly the human-dependent lifecycle failure the scenario warned you about. C is the worst lifecycle choice — converting a temporary need into a permanent privilege change and deferring review to a quarterly cycle means elevated access could persist for months, a textbook example of privilege creep. D shares credentials from an existing administrator's account, which violates the principle of individual accountability and non-repudiation; you can no longer attribute actions taken during the incident to the correct person, and the delayed password change leaves a window of shared access. A useful exam heuristic: whenever a scenario mentions prior control failures, the correct answer will almost always contain an automated enforcement mechanism — not a policy, reminder, or manual step — because automation removes human error from the equation.

Question 5

A company is redesigning new-hire provisioning. All employees need email, collaboration tools, and security training. Access to production systems is needed only by certain technical roles and can change the company's services. Management wants most onboarding to be automated without treating all access as equally low risk.

Which provisioning model BEST meets these requirements?

  1. Automatically provision baseline employee services from the authoritative hire event, but require role-based approval for production access. (correct answer)
  2. Require individual approval for every baseline service and automatically grant production access when a technical job title is detected.
  3. Provision all baseline and production services from the hire event, then remove unnecessary access during the first annual certification.
  4. Create only an email account from the hire event and let coworkers share other accounts until formal requests are completed.
Explanation: When you see provisioning questions on a cybersecurity exam, think about two core principles working together: least privilege (users get only what they need) and efficiency (security shouldn't create unnecessary friction). The challenge is applying different risk thresholds to different access tiers. Option A correctly separates low-risk baseline access (email, collaboration, security training) from high-risk production access. Automating baseline provisioning from the authoritative hire event is efficient and appropriate because these services are universally needed and carry limited risk. Requiring role-based approval for production access applies a proportional control where the actual risk lives — production systems can materially impact company services. This is the principle of risk-tiered provisioning in action. Option B inverts the logic catastrophically: it adds friction where risk is low (individual approval for email) while removing controls where risk is high (auto-granting production access based on a job title string). Job titles are not authoritative access decisions — they're easily misconfigured and bypass proper review. Option C violates least privilege from the start. Granting everyone everything at hire and cleaning it up annually means users hold unauthorized access for potentially 12 months. Annual certification is a detective control, not a substitute for proper initial provisioning. Option D creates a security nightmare by encouraging account sharing, which destroys accountability, makes audit trails meaningless, and violates basic identity management principles. "Sharing accounts until requests complete" is never acceptable practice. The key pattern to remember: match your approval rigor to your risk level. Automate the routine; gate the sensitive. Questions that describe mixed-risk environments are almost always testing whether you apply controls proportionally.

Question 6

An employee is terminated while actively connected to several cloud applications through single sign-on. The identity provider disables the employee's account immediately, but some applications issue refresh tokens that remain valid after the identity-provider session ends.

Which additional action is MOST important for completing deprovisioning promptly?

  1. Reset the employee's directory password and allow existing application sessions to expire according to their normal lifetimes.
  2. Remove the employee from directory groups and wait for each application's scheduled nightly synchronization to complete.
  3. Revoke active sessions and refresh tokens, then verify that downstream application accounts have been disabled. (correct answer)
  4. Delete the employee's mailbox and home directory before disabling any accounts maintained directly by applications.
Explanation: When a user is terminated, disabling the identity provider (IdP) account is necessary but not sufficient — this is the core concept being tested. Modern federated identity systems use tokens (especially OAuth refresh tokens) that can persist independently of the IdP session. Think of a refresh token as a spare key: even if you change the front door lock, anyone holding that spare key can still get in until the key itself is revoked. Option C is correct because it closes both gaps simultaneously. Revoking active sessions invalidates any live SSO connections, while revoking refresh tokens prevents applications from silently issuing new access tokens. Verifying that downstream accounts are disabled ensures no application maintained its own shadow account that slipped through. This is a complete, immediate response. Option A fails because resetting the directory password does nothing to active sessions or issued tokens that are already in circulation — applications holding valid tokens don't re-authenticate on every request, so the employee's access continues until those tokens naturally expire, potentially for hours or days. Option B compounds the problem by introducing deliberate delay. Nightly synchronization means the former employee could have up to 24 hours of continued access through application-level accounts, which is an unacceptable window for a termination scenario. Option D gets the sequence backwards. Deleting mailboxes and home directories before disabling accounts could destroy data needed for forensic or legal purposes, and it still doesn't address active tokens or application sessions. Your study tip: on deprovisioning questions, always ask yourself what survives after the IdP account is disabled? Tokens, sessions, and local application accounts can all outlive the central directory entry — complete deprovisioning must address all three.

Question 7

A payroll integration runs under a non-interactive service account. The account is registered to an engineer who is leaving the company, but disabling it at the engineer's termination time would stop payroll processing. The account's password is also known to members of the engineer's team.

What is the BEST deprovisioning-related action?

  1. Leave the service account unchanged because non-interactive identities are outside the scope of employee lifecycle processes and are governed separately by application owners.
  2. Disable the service account simultaneously with the engineer's user account to maintain consistency, then restore it only after payroll processing fails and an emergency change is approved.
  3. Transfer ownership to an accountable team or role, validate the continuing business need, rotate its credential, and remove the departing engineer's access. (correct answer)
  4. Rename the service account to reflect the replacement engineer's identity, retain the existing shared password to avoid integration disruption, and update privileges at the next scheduled review.
Explanation: When a departing employee is linked to a service account, you're dealing with two overlapping concerns: employee offboarding and service account governance. The key principle is that service accounts must have clear, accountable ownership independent of any individual's employment status — and any credential exposure must be remediated during a transition. Option C handles all of this correctly. Transferring ownership ensures ongoing accountability, validating the business need confirms the account should still exist, rotating the credential eliminates the risk from the shared password (which is now a known exposure), and removing the engineer's access closes the offboarding loop. This is the textbook "clean handoff" that satisfies both continuity and security. Option A is dangerously wrong because it treats service accounts as exempt from lifecycle management. Non-interactive accounts are absolutely in scope for deprovisioning reviews — orphaned or unowned service accounts are a primary attack surface for privilege escalation. Option B gets the urgency right but executes it recklessly. Deliberately disrupting payroll to force an emergency change is not a best practice; it's operationally harmful and avoidable. Good deprovisioning planning prevents outages rather than manufacturing them. Option D sounds pragmatic but is actually a rebranding exercise, not real security hygiene. Renaming the account to another engineer's identity just creates a new orphan-account risk in the future, and retaining the shared password deliberately leaves a known-compromised credential in place — exactly what you're supposed to fix. Study tip: On questions about service account deprovisioning, look for answers that address ownership, credential hygiene, and business validation together. Any answer that ignores even one of these three pillars is incomplete.

Question 8

A database administrator transfers to the procurement department. The HR system records the transfer, and the identity platform automatically assigns the standard procurement role. The administrator's former database privileges are not automatically removed because they were granted through a separate ticketing process.

What is the BEST lifecycle-management response to this transfer?

  1. Retain the database privileges because transferred employees may need prior access to assist their former departments.
  2. Disable the employee's identity and create a replacement identity containing only the standard procurement role.
  3. Review access against the new job duties, remove unneeded database privileges, and retain only separately justified exceptions. (correct answer)
  4. Leave all current privileges unchanged until the next annual access certification identifies incompatible permissions.
Explanation: When an employee changes roles, identity governance requires you to realign their access with their new responsibilities — this is the core principle of least privilege combined with access lifecycle management. A job transfer is a trigger event that demands a formal access review, not passive inaction. The right response here is C because it follows that principle precisely: you examine what the employee actually needs in their new procurement role, remove the database privileges that no longer apply, and document any exceptions that have a legitimate business justification. This balances security (eliminating unnecessary access) with operational reality (some cross-functional access may be warranted temporarily). A is wrong because it treats "might be helpful someday" as a valid reason to retain elevated database privileges. Speculative utility is never a justification for access — that reasoning leads directly to privilege sprawl and violates least privilege. B is overly aggressive and operationally disruptive. Disabling and recreating an identity destroys audit continuity, breaks any active sessions or credentials tied to that identity, and is disproportionate for a routine internal transfer. Identity continuity matters for accountability and forensic traceability. D is the most dangerous distractor. Waiting for an annual certification to catch a role mismatch leaves incompatible, high-risk database privileges active for potentially 12 months — a serious violation of timely access governance. Transfer events are discrete triggers that require immediate review, not deferred batch processes. Your study tip: on exam questions about user lifecycle events (onboarding, transfer, offboarding), always look for the answer that is timely, proportionate, and least-privilege-aligned — that combination almost always points to the correct response.

Question 9

A former employee is rehired after one year. The employee's previous directory account is disabled but retained for audit purposes. During the prior employment period, the account accumulated project-specific and administrative access that is not required for the new position.

Which action is MOST appropriate when provisioning the rehired employee?

  1. Reactivate the retained account with all prior entitlements because its audit history establishes that the access was previously approved.
  2. Match the person using an immutable identity attribute, preserve historical linkage, and provision only access approved for the new position. (correct answer)
  3. Create an unrelated identity with a new personnel identifier so that no permissions from the prior employment can be inherited.
  4. Reactivate only the prior administrative permissions, then allow the employee to request ordinary application access after starting work.
Explanation: When questions involve provisioning a returning employee, you're being tested on two core IAM principles working together: identity continuity and least privilege. The key tension is between preserving accountability history and preventing privilege accumulation. The right approach, captured in B, threads that needle precisely. By matching the person using an immutable attribute (like an employee ID or biometric identifier), you maintain an unbroken audit trail linking past and present activity — which is critical for forensic integrity and compliance. However, you provision only the access justified by the new role, treating the rehire like a fresh access grant rather than a restoration. This satisfies both auditability and least privilege simultaneously. A is a classic privilege accumulation trap. Prior approval doesn't justify current access — roles change, projects end, and the new position has different requirements. Reactivating all prior entitlements violates the principle of least privilege and skips a mandatory access review. C seems cautious but creates an orphaned identity problem. Breaking the link between old and new accounts fragments audit history, making it impossible to correlate past behavior with the current user. You lose accountability continuity, which undermines forensic and compliance objectives. D inverts the provisioning logic entirely. Administrative permissions carry the highest risk and should be the last entitlements granted after review, not the starting point. Letting someone begin with elevated access while routine access catches up is a serious security misstep. Your study tip: whenever you see a rehire or account reactivation scenario, immediately ask two questions — does the audit trail stay intact? and is access scoped to the new role only? The correct answer will satisfy both.

Question 10

A six-month contractor engagement is extended informally several times. The contractor's sponsor frequently forgets to notify IAM personnel about extensions and completion dates. As a result, contractor accounts have remained active after work ended.

Which control would BEST reduce residual access without unnecessarily interrupting authorized extensions?

  1. Give contractor accounts fixed expiration dates and require the sponsor to approve an extension before each expiration. (correct answer)
  2. Create contractor accounts without expiration dates and include them in the same annual review used for employees.
  3. Disable each contractor account after six months and allow the help desk to reactivate it without sponsor confirmation.
  4. Require contractors to change passwords monthly and have sponsors report completed engagements when operationally convenient.
Explanation: When you see a question about contractor account lifecycle management, focus on two competing risks: residual access (accounts staying active too long) and operational disruption (cutting off legitimate workers). The best control minimizes both simultaneously. A fixed expiration date with mandatory sponsor approval before renewal — option A — directly addresses the root cause described in the passage. The sponsor's forgetfulness isn't punished after the fact; instead, the system forces a conscious, proactive decision before access continues. If the sponsor forgets, the account expires automatically, eliminating residual access. If the engagement is legitimately extended, the approval process documents it. This closes the gap without surprising anyone mid-project. Option B is dangerous because folding contractors into an annual employee review cycle means accounts can remain active for up to a year after work ends — far too long, and exactly the problem the scenario describes. Contractors and employees have fundamentally different tenure expectations and shouldn't share the same review cadence. Option C removes the safeguard entirely. Allowing the help desk to reactivate accounts without sponsor confirmation simply recreates the accountability gap — now the help desk becomes the weak link instead of the sponsor. Reactivation should always require the same authority that originally justified the access. Option D combines two weak controls that neither expire accounts nor create hard enforcement. Monthly password changes don't remove access, and "when operationally convenient" reporting is essentially the same informal process already failing in the scenario. Your study tip: on identity and access management questions, always look for controls that are automatic by default and require deliberate human action to continue — not the other way around.