Management plane logs show that a long-lived access key belonging to a service account is being used right now from an unfamiliar IP address to launch compute instances in regions the company never uses. What is the most effective immediate containment step?
Select an answer to reveal the explanation.
Short Explanation
If someone copied your house key, changing the alarm code doesn't help; you've got to change the lock. A leaked access key keeps working until you revoke it, no matter what you do to anyone's password. Cut off the key, fence off what the attacker built and keep it as evidence instead of deleting it.
Full Explanation
In cloud environments the credential is often the attack path, so containment starts by revoking or disabling the abused access key, which immediately stops further API calls made with it. The instances the attacker created should then be isolated with deny-all security group rules or stopped, with snapshots taken, so they cannot continue mining, scanning or exfiltrating while still serving as evidence of what was run. Deleting the instances first stops cost but destroys forensic data and leaves the key active, so the attacker can simply launch more. Resetting a human administrator's password and enforcing multifactor sign-in does not invalidate an access key used for programmatic calls; the service account credential is independent of the person's interactive login. Asking the provider to contain the activity misplaces shared responsibility: identity and access management in the customer's tenancy is the customer's job, and the provider will typically advise rather than act. Exam caveat: after containment, review the logs for persistence such as newly created identities, keys or role changes. Operational check: confirm the key is disabled, that no new API calls appear from the unfamiliar address, that guardrails restrict unused regions and that long-lived keys are replaced with short-lived workload credentials.