SCS-C02 Identity and Access Management Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:*","Resource":"*"}]}

  Why it's wrong here

  This statement is dangerously over-permissive: it allows every S3 API action (s3:*) against every S3 resource in the account. A read-only requirement for a single bucket is completely unmet because the IAM policy would let an attacker or compromised instance list, write, delete, and even change bucket policies or object ACLs across all buckets. Least privilege demands that the action be limited to s3:GetObject and the resource be scoped to arn:aws:s3:::my-bucket/*, not a blanket s3:* on *.

• ✗

  {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:GetObject","Resource":"*"}]}

  Why it's wrong here

  Although this improves on s3:* by only permitting the s3:GetObject action, the Resource is still "*", which means the role can read objects from any bucket in the account—and in any other account that has granted the necessary cross-account permissions. The requirement is to restrict access to objects in the specific bucket my-bucket, so the resource ARN must be scoped to arn:aws:s3:::my-bucket/*. An IAM policy with Resource "*" fails the principle of least privilege and exposes every object the role can reach, not just the intended bucket.

• ✗

  {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:GetObject","Resource":"*","Condition":{"IpAddress":{"aws:SourceIp":"10.0.0.0/16"}}}]}

  Why it's wrong here

  The use of aws:SourceIp in an IAM role policy is ineffective because the condition is evaluated against the source IP of the principal making the request—and when an EC2 instance assumes a role, the API call originates from the instance's private or public IP, but the role's credentials are used by the instance, not by the IP itself. More fundamentally, IAM role policies cannot use aws:SourceIp reliably for EC2 because the source IP seen by S3 is the IP of the client making the request, which could be a NAT gateway, load balancer, or VPC endpoint, not the instance's IP. Additionally, the Resource is still "*", so even if the IP condition were valid, it would still grant GetObject on all buckets, not just my-bucket. The correct approach is to scope the Resource to the target bucket's objects and, if network-level control is needed, place the IP condition on the S3 bucket policy (or use a VPC endpoint condition) instead.

• ✓

  {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::my-bucket/*"}]}

  Why this is correct

  This is the correct least-privilege policy: it restricts the s3:GetObject action to a specific Resource ARN, arn:aws:s3:::my-bucket/*, which matches only objects inside the my-bucket bucket. The lack of s3:ListBucket permission is fine for direct object retrieval—the caller must know the object key, but that matches the requirement of granting access to the bucket's objects. The policy contains no wildcards beyond the object-name segment (*), so it does not grant access to other buckets or to bucket-level operations like listing. This scoping aligns with AWS's recommended practice of using resource-level permissions for S3 actions and is the only option that satisfies the principle of least privilege.

Go deeper

Related to this question