DOP-C02 Incident and Event Response Practice Question

During an incident, a DevOps engineer needs to quickly revoke access to a set of IAM users who are suspected to be compromised. The users have programmatic access keys and console passwords. The engineer wants to minimize the impact on non-compromised users. Which action should the engineer take FIRST?

⚠ Common exam trap

The trap is confusing 'revoke access' with 'delete the identity' — candidates pick key deletion or user deletion, missing that an explicit Deny is the fastest, least-destructive, and most complete containment because it blocks both console and API paths.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Attach an IAM policy that explicitly denies all actions to the compromised users.

Attaching an explicit Deny policy to the compromised users immediately blocks all API and console actions for those principals while leaving other users untouched, and it is reversible once the incident is resolved. This is the fastest containment step that satisfies least-impact on non-compromised users. Deleting keys or users is more destructive and slower to reverse.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Delete the compromised IAM users.
Why it's wrong here
Deleting the compromised IAM users is irreversible and destroys forensic evidence. Once deleted, all attached policies, group memberships, and access keys are removed permanently, making it impossible to investigate what actions the compromised principal performed. Additionally, any AWS resources owned by those users, such as S3 buckets or EC2 instances, can become orphaned and inaccessible, causing further operational disruption. A safer approach is to first attach an explicit deny-all policy to contain the threat, then perform the investigation before considering deletion.
✓
Attach an IAM policy that explicitly denies all actions to the compromised users.
Why this is correct
Attaching a customer-managed IAM policy with an explicit 'Deny' effect for all actions on all resources immediately revokes both console and programmatic access for the compromised users. IAM's evaluation logic gives explicit denies precedence over any allow, so even if the user still has attached policies with broad permissions, the deny-all policy overrides them. This containment action preserves the user objects and their audit trail for forensic analysis, allowing you to safely investigate and later rotate credentials or delete the users if needed. Unlike disabling keys or changing password policies, this approach covers all access methods simultaneously.
✗
Delete the access keys of the compromised users.
Why it's wrong here
Deleting the access keys only disables AWS CLI, SDK, and API-based access, but it leaves the IAM user's console password and any existing authenticated sessions untouched. An attacker who has compromised the user's credentials could still sign in through the AWS Management Console, and if MFA is not enabled, the password alone remains a valid attack vector. Furthermore, if the attacker has obtained temporary security credentials via STS, deleting the long-term access keys does not invalidate those already-issued session tokens. Therefore, this action alone is insufficient to revoke all access and should not be relied upon as the primary containment measure.
✗
Change the IAM password policy to require strong passwords.
Why it's wrong here
Modifying the IAM account password policy only affects future password creation and change operations; it does not force the compromised users to change their existing passwords nor does it terminate any active console sessions. Password policy changes apply to every user in the AWS account, potentially locking out legitimate users if the new complexity or expiration rules are incompatible with their current passwords. This action is a preventive security control, not an incident response containment control, and it fails to revoke access keys, temporary credentials, or existing authenticated sessions. It provides no immediate protection against the ongoing compromise and should not be used as a first response.

Visual reference

Go deeper

DOP-C02 Incident and Event Response Practice Question

Why each option matters

Option-by-option breakdown

Related to this question