- Which provisioning model BEST meets these requirements?
Answer: Automatically provision baseline employee services from the authoritative hire event, but require role-based approval for production access.
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.
- Which of these activities is an example of deprovisioning?
Answer: Revoking a departed worker's email and VPN access
Deprovisioning removes or disables access when a user leaves or no longer needs it. A quarterly access review can reveal access to remove, but the review itself is recertification, not deprovisioning.
- Over six years, an analyst moved through three teams. Each move added access, but none was removed. Her account now exceeds her role. What is this?
Answer: Privilege creep
Access that accumulates as a user changes jobs without old rights being removed is privilege creep. Privilege escalation is tempting but refers to obtaining unauthorized higher rights, usually through an attack.
- What is the BEST deprovisioning-related action?
Answer: Transfer ownership to an accountable team or role, validate the continuing business need, rotate its credential, and remove the departing engineer's access.
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.
- Which provisioning approach BEST balances operational readiness with account lifecycle controls?
Answer: Stage the identity and standard accounts in advance, activate them on the HR start date, and require separate approval for finance access.
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.
- Which action BEST satisfies both deprovisioning and preservation requirements?
Answer: Disable interactive access and revoke sessions while preserving the mailbox and files under retention or legal-hold controls.
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.
- Which improvement would MOST directly address the lifecycle-control weakness?
Answer: Add reconciliation and exception alerts that compare authoritative termination records with actual application account status.
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.
- Which additional action is MOST important for completing deprovisioning promptly?
Answer: Revoke active sessions and refresh tokens, then verify that downstream application accounts have been disabled.
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.
- An audit finds many users keep access they no longer need. Which control BEST finds and corrects this on an ongoing basis?
Answer: Periodic access reviews by managers
Periodic access reviews have owners confirm each user's access is still needed and remove the rest. MFA is tempting but only proves who is logging in; it leaves unneeded permissions in place.
- Which action is MOST appropriate when provisioning the rehired employee?
Answer: Match the person using an immutable identity attribute, preserve historical linkage, and provision only access approved for the new position.
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.
- Which provisioning design BEST addresses the operational need and prior lifecycle failure?
Answer: Provision a named privileged account with an enforced four-hour expiration, recorded approval, and automatic removal of elevated access.
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.
- What is the BEST lifecycle-management response to this transfer?
Answer: Review access against the new job duties, remove unneeded database privileges, and retain only separately justified exceptions.
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.
- A new hire joins the finance team. Which provisioning practice BEST limits the risk from her new account?
Answer: Grant access based on her role, using least privilege
Provisioning from the job role with least privilege grants only needed access. Copying a coworker seems efficient but inherits years of extra permissions the new hire should not have.
- A contractor's project ended months ago, yet his account is still active and no manager is listed as its owner. What does this describe?
Answer: Orphaned account
An account that stays active after its user leaves, with no owner, is orphaned and a prime target for misuse. Privilege creep is different: it describes a current user who gathers excess access over time.
- Which control would BEST reduce residual access without unnecessarily interrupting authorized extensions?
Answer: Give contractor accounts fixed expiration dates and require the sponsor to approve an extension before each expiration.
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.
