CLF-C02 Billing, Pricing, and Support 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.

• ✓

  1. Prepare the S3 bucket for static website hosting. 2. Create a CloudFront distribution. 3. Configure the origin settings to point to the S3 bucket. 4. Update DNS to point to the CloudFront distribution.

  Why this is correct

  This sequence is correct because the S3 bucket must first be enabled for static website hosting so it can serve as a valid origin with the proper endpoint and permissions. You then create the CloudFront distribution, during which you specify the S3 bucket as the origin and configure behaviors like caching and HTTPS. After the distribution is deployed and its domain name is known, you update DNS (e.g., a CNAME) to point your custom domain to the CloudFront distribution. Preparing the bucket first ensures the origin is resolvable, and configuring the origin as part of distribution creation is mandatory because the distribution cannot exist without an origin.

• ✗

  1. Create a CloudFront distribution. 2. Prepare the S3 bucket for static website hosting. 3. Configure the origin settings to point to the S3 bucket. 4. Update DNS to point to the CloudFront distribution.

  Why it's wrong here

  This sequence is invalid because you attempt to create a CloudFront distribution before preparing the S3 bucket for static website hosting. While CloudFront can technically point to an S3 bucket that is not configured for static hosting, the intended workflow here requires the bucket to be ready first; more importantly, you cannot configure the origin settings meaningfully if the origin is not accessible or properly configured. Creating the distribution first would force you to supply a bucket endpoint that may not yet be set up as a website endpoint, leading to configuration errors or a distribution that fails to serve content. The origin configuration is an integral part of the distribution creation step, so initiating the distribution before the bucket is ready breaks the dependency order.

• ✗

  1. Prepare the S3 bucket for static website hosting. 2. Configure the origin settings to point to the S3 bucket. 3. Create a CloudFront distribution. 4. Update DNS to point to the CloudFront distribution.

  Why it's wrong here

  This order incorrectly isolates origin configuration as a separate step before creating the CloudFront distribution. In the AWS Management Console, the origin is defined within the Create Distribution wizard—you cannot configure the origin settings independently and then attach them to a distribution later. The correct sequence is to prepare the bucket, then create the distribution, and while doing so specify the S3 bucket's website endpoint or REST endpoint as the origin. Attempting to configure the origin in advance is not possible because there is no standalone 'origin resource' that exists before the distribution; the origin settings are an attribute of the distribution itself.

• ✗

  1. Update DNS to point to the CloudFront distribution. 2. Prepare the S3 bucket for static website hosting. 3. Create a CloudFront distribution. 4. Configure the origin settings to point to the S3 bucket.

  Why it's wrong here

  This ordering is fundamentally flawed because it attempts to update DNS before the CloudFront distribution exists or has a deployable domain name. DNS records (like CNAME or A records with CloudFront's domain) require the distribution's assigned domain name, which is only available after the distribution is created. Furthermore, the S3 bucket and origin configuration must be completed before any traffic can flow, so putting DNS first inverts the entire dependency chain. Even if the bucket were prepared later, the DNS record would point to a nonexistent distribution, causing resolution failures. The correct order always places DNS last because it relies on the fully created and configured distribution endpoint.

Go deeper

Related to this question