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.

• ✓

  Requiring server-side encryption using the 's3:x-amz-server-side-encryption' condition key

  Why this is correct

  Requiring server-side encryption via the 's3:x-amz-server-side-encryption' condition key is a valid access restriction because it makes the presence and value of the x-amz-server-side-encryption header a precondition for the S3 operation. For example, you can require that the header equals AES256 or aws:kms, which denies requests that do not carry an encryption header even if the principal otherwise has s3:PutObject permission. This condition key is evaluated per request, giving you fine-grained, attribute-based control that enforces encryption compliance on all uploads.

• ✓

  Using the 'aws:PrincipalOrgID' condition key

  Why this is correct

  Using the 'aws:PrincipalOrgID' condition key is a valid organizational boundary control because it restricts access to principals whose AWS account is a member of a specified organization. The condition key uses the organization ID (o-xxxxxx) and is evaluated globally across AWS services, so it works even for cross-account access as long as member accounts are in the same organization. This is especially useful when you want to allow access only to accounts managed by your central governance structure and automatically include any new sub-accounts added to that org.

• ✓

  Restricting access to a specific VPC using the 'aws:SourceVpc' condition key

  Why this is correct

  Restricting access to a specific VPC with the 'aws:SourceVpc' condition key is valid because it examines the VPC ID from which the request originates, but it only works when a VPC endpoint is configured for S3. When traffic flows through a gateway endpoint or interface endpoint, the source VPC is recorded and evaluated; otherwise, the condition is not met. By combining this condition with the bucket policy, you can reject all requests coming from outside the selected VPC, effectively hiding the bucket from the public internet and other VPCs.

• ✗

  Using the 's3:ResourceAccount' condition key to restrict access to a specific bucket

  Why it's wrong here

  Using the 's3:ResourceAccount' condition key is incorrect for restricting access to a specific bucket because this key compares the AWS account ID that owns the resource — not the bucket name. A single AWS account may contain many buckets, so the condition only verifies that the bucket belongs to the specified account, which could be all buckets in that account. To isolate one bucket, you must use the bucket ARN in the Resource element of the policy statement, such as arn:aws:s3:::my-bucket, rather than relying on the ResourceAccount condition.

• ✓

  Limiting access to specific IP addresses using the 'aws:SourceIp' condition key

  Why this is correct

  Limiting access to specific IP addresses with the 'aws:SourceIp' condition key is a valid request-origin restriction because it checks the source IP address from which the API request was made. The condition accepts IPv4 or IPv6 addresses and CIDR blocks, allowing you to whitelist corporate office ranges or other trusted networks while denying all other sources. Be aware that for requests received via a VPC endpoint, the source IP is the endpoint's private IP, so you may need to combine this with 'aws:SourceVpc' if the original client IP is required for the policy decision.

Go deeper

Related to this question