DOP-C02 Configuration Management and IaC Practice Question

A DevOps engineer is creating a CloudFormation template to deploy a VPC with public and private subnets. The template uses the 'AWS::EC2::VPC' resource and two 'AWS::EC2::Subnet' resources. The engineer wants to ensure that the subnets are created in different Availability Zones. What is the best approach?

⚠ Common exam trap

Many candidates confuse the CidrBlock property with AZ assignment, or assume Fn::GetAZs can directly return multiple AZs without using Fn::Select, leading them to pick option B or C.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use Fn::GetAZs function with Fn::Select to pick different AZs from the region's AZ list.

Fn::GetAZs returns a list of all Availability Zones in the region, and Fn::Select allows you to pick specific indices from that list, ensuring each subnet is assigned a different AZ. This approach is dynamic and region-agnostic, so the template works across regions without hardcoding AZ names. It also avoids the risk of using the same AZ for both subnets, which would violate the requirement for high availability.

Answer analysis

Option-by-option breakdown

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

✓
Use Fn::GetAZs function with Fn::Select to pick different AZs from the region's AZ list.
Why this is correct
Fn::GetAZs returns a list of all Availability Zones available in the current region, and Fn::Select chooses an element via its zero-based index. By combining them, you can assign the first AZ to one subnet (Fn::Select [0, Fn::GetAZs ""]) and the second AZ to another (Fn::Select [1, Fn::GetAZs ""]), ensuring two distinct AZs without hardcoding region-specific names. This approach remains valid even as the region's AZ list changes and keeps the template portable across regions.
✗
Use the CidrBlock property to define different AZs.
Why it's wrong here
The CidrBlock property is used to specify the IP address range (e.g., 10.0.0.0/16) for a VPC, subnet, or security group rule; it has no relation to Availability Zone placement. To place a resource such as a subnet in a specific AZ, you must use the dedicated AvailabilityZone property, not CidrBlock. Therefore, trying to define different AZs via CidrBlock is fundamentally a type mismatch and has no effect on AZ selection.
✗
Use Fn::GetAZs function with a count of 2 to automatically assign different AZs.
Why it's wrong here
Fn::GetAZs is a function that returns a list of all AZs; it does not accept a count parameter nor does it automatically distribute resources across a specified number of AZs. Writing something like Fn::GetAZs: 2 is invalid syntax and would cause a template error. Even if the function returned a substring, it would not assign distinct AZs to separate resources—you must explicitly use Fn::Select with different indices to pick specific entries from the list.
✗
Hardcode the Availability Zone names in the template.
Why it's wrong here
Hardcoding Availability Zone names like "us-east-1a" in a template breaks reusability because AZ names are scoped to each AWS account and region. An AZ name such as "us-east-1a" may map to a different physical availability zone in another account, and some AZ names might not be available in all accounts or regions. Using Fn::GetAZs and Fn::Select instead allows the template to adapt automatically to the account's actual AZ mapping, avoiding hardcoded dependencies.

Visual reference

Go deeper

DOP-C02 Configuration Management and IaC Practice Question

Why each option matters

Option-by-option breakdown

Related to this question