SOA-C02 Networking and Content Delivery 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.

• ✗

  Configure an S3 bucket policy with a condition for aws:SourceIp.

  Why it's wrong here

  An S3 bucket policy with a condition for aws:SourceIp evaluates only the IP address of the request and has no built-in capability to map that IP to a country. When CloudFront is in front of S3, the origin sees CloudFront's edge IP addresses rather than the viewer's IP, so the condition would gate traffic based on CloudFront's location, not the actual user's country. Even if you tried to retrieve a GeoIP database and reference it in the policy, S3 bucket policies do not support such dynamic lookups, making this approach ineffective for country-based restrictions.

• ✓

  Configure CloudFront geo restriction (whitelist or blacklist) at the distribution level.

  Why this is correct

  CloudFront geo restriction (whitelist or blacklist) is a native feature that uses a country-level database derived from the request's source IP to allow or block requests at the edge. It is configured directly on the distribution through the 'Restrictions' tab and applies to all content types before the request reaches the origin, requiring no changes to your application or backend. This is the simplest and most cost-effective way to enforce geographic access controls, as it requires no additional AWS services and works automatically with the CloudFront's global edge network.

• ✗

  Use IAM policies to restrict access based on the user's location.

  Why it's wrong here

  IAM policies are designed to control permissions for AWS principals (like IAM users, roles, or AWS services) and do not support any condition key that represents a user's geographic location. While IAM has aws:SourceIp, that key checks the IP address of the requesting principal and is not converted to a country; additionally, in a CloudFront architecture, the principal seen by AWS is typically CloudFront, not the end user. IAM is for managing access to AWS APIs and resources, not for restricting HTTP access to content distributed via CloudFront, so this option is fundamentally misaligned with the requirement.

• ✓

  Use AWS WAF associated with CloudFront to create a rule that blocks requests based on geographic origin.

  Why this is correct

  AWS WAF associated with CloudFront can implement geo-based access control by adding a geo match rule that inspects the country of origin derived from the requester's IP address. This rule can be configured to block or allow traffic from specific countries, and it integrates with other WAF features like rate-based rules or IP reputation filters for more granular protection. It is a valid solution, but it adds an extra service and cost compared to CloudFront's native geo restriction, and it requires careful rule configuration to avoid unintended traffic drops.

• ✗

  Set up an Application Load Balancer rule to deny traffic from certain IP ranges.

  Why it's wrong here

  An Application Load Balancer rule can match on the source IP CIDR of incoming requests, but it has no built-in capability to determine a requester's country from its IP address. You would have to manually compile and maintain large lists of IP ranges for every country you want to block or allow, which is impractical and error-prone as ranges change frequently. In a CloudFront setup, the ALB as an origin would typically see CloudFront's IP address, not the viewer's IP, unless you configure the distribution to forward the X-Forwarded-For header; even then, the ALB lacks the GeoIP logic needed to translate IPs into country codes, making this a poor substitute for CloudFront geo restrictions or WAF geo match rules.

Go deeper

Related to this question