Course menuSCS-C03

Exams / SCS-C03 / Study guide / Finding and removing unintended access (IAM Access Analyzer)

Finding and removing unintended access (IAM Access Analyzer): SCS-C03 study notes and practice questions

What to know about Finding and removing unintended access (IAM Access Analyzer) for the SCS-C03 exam, from the Identity and Access Management domain (20% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.

Last verified against current AWS documentation ·How we write our questions

What to know for the exam

These questions describe a resource that may be reachable by people or accounts it should not be, or a set of roles and keys that nobody uses. They ask which Access Analyzer capability finds the problem and which action resolves it. Remember that Access Analyzer answers “who can reach this?” and “what is unused?”, while configuration checks against a standard are a different job.

The facts that decide answers

  • Zone of trust is the account or the organization that an analyzer watches. An analyzer can be scoped to one account or to an organization.
  • External access findings show supported resources, such as S3 buckets, IAM roles, KMS keys and Lambda functions, that a principal outside the zone of trust can reach. Shared with another account counts as external. Public counts as external too.
  • Internal access analysis shows which principals inside your organization can reach selected resources, which helps you narrow access that is broader than intended.
  • Unused access findings report unused roles, unused IAM user access keys and passwords, and unused permissions on roles and users. You choose the lookback period.
  • Custom policy checks run in CI/CD. A check can confirm that a new policy grants no access beyond a reference policy, or that it does not grant specific actions.
  • Policy validation flags syntax errors and security warnings while you write a policy.
  • Archive rules suppress findings that are expected and approved, so the active list shows only new problems.
  • Coverage is limited to the resource types Access Analyzer supports. It does not inspect every AWS resource.

How to choose

Scenario wording Pick
S3 bucket or KMS key shared with another account External access finding in an account analyzer
Access granted to any account in the organization Organization analyzer
Roles and access keys that nobody has used for months Unused access findings
Stop a pipeline from merging a policy that widens access Custom policy check, CheckNoNewAccess
Prove that a policy never grants a specific action Custom policy check, CheckAccessNotGranted
An approved, intentional public resource clutters the findings Archive rule
Check resources against security standards such as CIS Security Hub CSPM, not Access Analyzer

Common traps

  • Expecting Access Analyzer to find every misconfiguration. It covers reachability for supported resource types only.
  • Confusing external with public. External means outside the zone of trust. Public means anyone can reach the resource.
  • Archiving findings without a documented reason.
  • Ignoring unused-access findings because a role “might be needed.” Review them and remove what is unused.
  • Using an account analyzer when the question asks about sharing across the whole organization.
  • Using Security Hub CSPM controls as the answer to “who can access this resource?” Controls check configuration. Access Analyzer checks reachability.

Read Using IAM Access Analyzer and the custom policy checks guide.

Try the 1 practice question

A public health agency uses IAM Access Analyzer across its AWS Organizations. Last week the analyzer raised an external access finding for a customer managed KMS key that protects data for an analytics pipeline. The finding shows that a principal in an AWS account outside the organization can use the key.

The agency approved a data-sharing partner account for this key months ago, and that partner's finding is expected. The team wants it archived so that it stops hiding new findings. The unknown account must lose access today, and the pipeline must keep running.

Which action should the security engineer take?

Choose one answer.

  1. A. Confirm that the unknown account is not approved, then edit the key policy to remove its principal. Add an archive rule that matches the approved partner finding, so the expected finding stops cluttering the list.
  2. B. Turn off IAM Access Analyzer across the organization until the unknown account's access is removed, so that no further findings are generated during the investigation of the key.
  3. C. Schedule the key for deletion, create a replacement key with a new policy, and copy the pipeline encrypted data to the new key in a maintenance window next month. Delete the old key after the copy is complete.
  4. D. Attach a resource control policy to every account that denies KMS actions on all keys to principals outside the organization, so that every external principal is blocked.
Show the answer and explanation

Answer: A

  • A. Right: Correct. The key policy decides who may use the key, so removing the unknown principal ends its access today while the pipeline keeps its own statements. The archive rule covers only the approved finding, and any new unexpected finding still appears. Learn more: What is IAM Access Analyzer? (opens in a new tab)
  • B. Wrong: Turning off the analyzer removes the visibility the agency needs, and it does not revoke the existing access. The unknown account would keep using the key until someone edits the key policy.
  • C. Wrong: Deleting the key would stop the pipeline and make its data unreadable until the copy finishes. The unknown account's access ends only when the old key is gone, which is far too slow for today.
  • D. Wrong: The resource control policy would block the unknown account, but it also blocks the approved partner account, which breaks the data-sharing agreement. The partner's expected access must stay in place.

Explanation

Access Analyzer reports which principals outside the zone of trust can reach a resource, and fixing a finding means changing that resource's policy. A key policy decides who may use the key, so editing it removes the unknown access today. Archive rules keep expected findings out of the way, while turning the analyzer off, deleting the key or blocking all external principals fails the requirements.

Study

Want more on Finding and removing unintended access (IAM Access Analyzer)? The 5 full-length practice sets have 6 more Finding and removing unintended access (IAM Access Analyzer) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets

Study Finding and removing unintended access (IAM Access Analyzer)

More Identity and Access Management topics