Incident Response practice questions

Break-glass access is a pre-planned emergency path for when normal access fails. It must not depend on the failed system, must be tightly protected (MFA, credentials stored out of band) and must alert on every use.

Two facts decide. First, independence: a permission set and any credential store reached through federation fail with the identity provider. Second, scope: root is independent but unrestricted. IAM users in the security tooling account, with hardware MFA, credentials in an offline safe and an alarm on sign-in, are independent of the provider, can be limited to assuming the incident response roles, and are noticed whenever they are used.

1. Identify the failure being planned for: the external identity provider is down or untrusted.
2. Remove every option that still authenticates or retrieves credentials through that provider.
3. Remove options that cannot be limited to incident response, such as root users.
4. Keep the design with MFA, out-of-band credential storage and alerting on use.

Exam tip: Break-glass credentials must work without the identity provider, be stored out of band with MFA, be scoped, and page someone every time they are used.

A dedicated forensics account is a preparation control. It holds analysis tooling and evidence outside the blast radius of any workload account and is reachable only by the forensics team.

The account is the strongest isolation boundary in AWS. Controls inside the compromised account, such as a separate VPC or an Object Lock bucket, protect pieces of the evidence but leave the environment reachable by that account's credentials. Log Archive and the management account are isolated from workloads, but each has its own purpose and audience; placing analysts there widens access to the organization's log record or its most privileged account.

1. Ask whether the location is inside the compromised account's security boundary; if so, reject it.
2. Ask whether the location forces new access into an account that serves another purpose.
3. Choose a dedicated forensics account, with access limited to the forensics team.
4. Share snapshots into it from affected accounts rather than analyzing in place.

Exam tip: Analyze evidence in a dedicated forensics account, not inside the compromised account, Log Archive or the management account.

Long-term IAM user access keys can be deactivated. Deactivation is the reversible first containment step; deletion is an eradication step taken after the investigation.

Deactivating stops the exposed key immediately and can be reversed. Deletion also stops it but cannot be reversed. Creating a second key does not stop the first. The aws:TokenIssueTime deny is the session-revocation pattern for temporary credentials; that condition key is absent from requests signed with long-term access keys, so the deny does not apply to them. CloudTrail keeps the key ID in past events whether the key is deactivated or deleted.

1. Identify the credential type: a long-term access key of an IAM user.
2. Apply the constraints: immediate, reversible, console access untouched.
3. Set the key to Inactive; remember that the token-age deny only matches temporary credentials.
4. Delete the key later, in eradication, once CloudTrail scoping is complete.

Exam tip: Exposed long-term key: set it to Inactive first; delete it later. A token-issue-time deny does not stop long-term keys.

Temporary credentials cannot be deactivated or recalled. A role's existing sessions are revoked by an inline deny on the role conditioned on aws:TokenIssueTime being earlier than the revocation time.

Only a policy on the role affects sessions that already exist, because permissions are evaluated on every request. Trust-policy changes affect new AssumeRole calls only, and maximum session duration applies only to sessions requested later. Of the two token-age denies, DateLessThan blocks sessions issued before the cutoff, the leaked ones, while DateGreaterThan would block the fresh sessions instead.

1. Recognize that leaked role credentials are temporary and cannot be deactivated.
2. Discard controls that act only on new sessions (trust policy, maximum session duration).
3. Attach Deny * with DateLessThan on aws:TokenIssueTime set to the current time.
4. Let legitimate callers assume the role again for new credentials.

Exam tip: Revoke a role's existing sessions with Deny * where aws:TokenIssueTime is earlier than now; trust-policy and session-duration changes do not touch issued sessions.

Each account has three alternate contacts: billing, operations and security. AWS sends security-related notifications, including Trust & Safety abuse notices, to the security contact as well as the root email address.

The security alternate contact adds the on-call list without taking anything from finance, and it can be set centrally across the organization once trusted access for AWS Account Management is enabled. The operations contact is the near-twin of the wrong type. Changing the root email works but breaks the finance constraint. SNS topics carry your own messages, not AWS's emailed notices.

1. Identify the channel AWS uses: email to the root address and the matching alternate contact.
2. Match security and abuse notices to the security alternate contact.
3. Keep finance on the root email by adding a contact rather than replacing the root email.
4. Set the contact centrally from the management account or a delegated administrator.

Exam tip: Set the security alternate contact on every account, centrally through AWS Organizations, so AWS security and abuse notices reach responders.

The executable runbook format on AWS is the Systems Manager Automation document: versioned steps that call AWS APIs under a scoped assume role, start from the console or EventBridge, and keep a per-step execution history. OpsCenter can link these runbooks to OpsItems.

Automation meets every requirement at once, but only with one assume role per runbook: that is what gives each procedure only its own permissions. The shared-role variant is the near-twin that breaks least privilege. Run Command on a bastion also shares one instance profile across all procedures and records command output rather than per-step API status. CloudFormation manages resources declaratively and does not run imperative response steps.

1. List the requirements: repeatable, least privilege per procedure, console form or EventBridge, per-step record.
2. Pick the mechanism that gives a console form, an EventBridge target and per-step history: Automation runbooks.
3. Check how permissions are scoped: one assume role per runbook, not one shared role.
4. Reject Run Command on a bastion and CloudFormation stacks.

Exam tip: Write runbooks as Systems Manager Automation documents: scoped assume role, console form, EventBridge trigger, per-step history.