How Should You Handle Leaked IAM Access Keys?

SCS-C03 By islever Editorial Last updated

Respond to compromised resources and workloads. Design and implement controls to protect credentials, secrets, and cryptographic key materials.

Short answer

BE Deactivate the exposed IAM access key to stop further use, then generate an IAM credential report to review the key's last-used activity.

Question

A development team is creating an open source toolset to manage a company's software as a service (SaaS) application. The company stores the code in a public repository so that anyone can view and download the toolset's code.
The company discovers that the code contains an IAM access key and secret key that provide access to internal resources in the company’s AWS environment
A security engineer must implement a solution to identify whether unauthorized usage of the exposed credentials has occurred. The solution also must prevent any additional usage of the exposed credentials.
Which combination of steps will meet these requirements? (Choose two.)
  1. Use AWS Identity and Access Management Access Analyzer to determine which resources the exposed credentials accessed and who used them.
  2. Deactivate the exposed IAM access key from the user’s IAM account. Correct Answer
  3. Create a rule in Amazon GuardDuty to block the access key in the source code from being used.
  4. Create a new IAM access key and secret key for the user whose credentials were exposed.
  5. Generate an IAM credential report. Check the report to determine when the user that owns the access key last logged in. Correct Answer

Key Takeaways

This question tests incident response for leaked IAM credentials, and the trap is assuming IAM Access Analyzer tracks who used a key—it only analyzes resource policies.

Exposed IAM access keys in a public repository require immediate containment and usage review. The correct SCS-C03 response is to deactivate the key and use an IAM credential report to check whether it was used, not to rely on IAM Access Analyzer.

Common mistake: Many candidates choose A, expecting IAM Access Analyzer to show which resources the exposed key accessed, but Access Analyzer identifies externally accessible resources rather than credential usage.

Expert Analysis

Why the Answer Is Correct

Deactivating the exposed IAM access key (option B) immediately changes its status to inactive, so any API request signed with that key pair is rejected; this is the fastest containment step and directly satisfies the requirement to prevent additional usage. Generating an IAM credential report (option E) provides the access key's last-used date, region, and service, which lets the security engineer see whether the leaked key was used at all and whether that use occurred after the public exposure. Together these steps address both halves of the question: stop the bleeding and gather evidence of unauthorized activity. The AWS security blog on quickly identifying when an access key was last used supports using the credential report for this exact triage.

Why the Other Options Are Wrong

Option A is wrong because IAM Access Analyzer analyzes resource-based policies to identify resources shared with external entities; it does not record which resources a specific access key touched or who used it—CloudTrail is the service for that kind of API activity history. Option C is wrong because GuardDuty can detect anomalous credential use but cannot create a rule that blocks a specific access key from being used; blocking is done by deactivating or deleting the key. Option D is wrong because issuing a new access key does not invalidate the exposed key, so the leaked credential can continue to be used until it is deactivated or deleted. Option E's credential report is imperfect for detailed forensics, but it is the only offered mechanism that checks whether the exposed key was used, which is why it pairs with B.

Community Comment Notes

Commenters split between AB and BE, but the BE camp correctly focused on containment and key usage. As libz noted, the credential report "shows last login activity but doesn’t provide detailed resource access analysis," which is why it is a triage check rather than full forensics. Man_Kind argued that Access Analyzer does not tell you who did what and when the credential was last used, and 7f6aef3 explained that Access Analyzer identifies external access while CloudTrail is needed for credential usage. bigdata2ml pointed to an AWS blog showing that the credential report can quickly identify when an access key was last used, reinforcing option E.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When you see leaked IAM credentials, immediately look for an option that disables or deletes the key, then pair it with a usage-review mechanism such as the credential report or CloudTrail. Eliminate options that claim Access Analyzer or GuardDuty can track or block credential usage.

Frequently Asked Questions

Why is IAM Access Analyzer wrong for checking who used the exposed key?

IAM Access Analyzer evaluates resource policies to find external access; it does not log API calls or identify the principal behind a credential's use. CloudTrail or the credential report is appropriate for usage review.

Does deactivating the access key delete it permanently?

No. Deactivation sets the key to Inactive so API calls fail, but the key remains listed; you can delete it later after investigation.

More SCS-C03 FAQ →

Discussion 8 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 8

  1. libz 👍 2
    Credential report shows last login activity but doesn’t provide detailed resource access analysis
  2. bigdata2ml 👍 1
    Questions is : to identify whether unauthorized usage of the exposed credentials has occurred. The solution also must prevent any additional usage of the exposed credentials. This blog explains that it can be achieved with credential report https://aws.amazon.com/blogs/security/new-in-iam-quickly-identify-when-an-access-key-was-last-used/
  3. 7f6aef3 👍 1
    B — Desactivar la key expuesta → previene uso adicional E — Credential report con "last used" → identifica si/cuándo se usó la credencial expuesta. A: Access Analyzer identifica recursos con acceso externo, no "qué recursos accedió una credencial y quién la usó" (eso lo da CloudTrail).
  4. gonzales 👍 1
    Credentail report When the key was last used Whether it has been used recently Analyser: • Used for: • External access to resources (e.g., public S3 buckets) • NOT for: • Tracking credential usage
  5. bigdata2ml 👍 1
    https://aws.amazon.com/blogs/security/new-in-iam-quickly-identify-when-an-access-key-was-last-used/#:~:text=From%20the%20IAM%20console%2C%20you,When%20you%20click%20an%20individual
Show 3 more comments
  1. giancesarini2023 👍 1
    Use IAM Access Analyzer to investigate the use of the exposed credentials and immediately disable the compromised access key to prevent any further use.
  2. Liongeek 👍 1
    AB Credential Report says when he logged, not which API calls he made. Question asks for USAGE
  3. Man_Kind 👍 1
    A does NOT tell you who did what and when the cred was last used B - D

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

How should a secured S3 CloudFormation template be shared across AWS Organizations?

S-grade

How to enforce MFA for AWS CLI EC2 commands?

S-grade

How Do You Disable a Compromised IAM Identity Center User and Audit Activity?

S-grade

How to Find S3 Buckets with Sensitive Data Using Macie with Least Overhead?

S-grade

Practice All SCS-C03 Questions

Access 86 questions with complete answers and detailed explanations.

View Full SCS-C03 Practice Test →

← Back to SCS-C03 Study Guide