SOA-C02 Cost and Performance Optimization 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.

• ✓

  Step 1: Create the peering request, Step 2: Accept the peering request, Step 3: Update route tables in both VPCs, Step 4: Adjust security groups.

  Why this is correct

  This is the correct order because you must first initiate the peering connection (step 1), then the owner of the other VPC must accept (step 2). Only after the connection is active can you add routes to the route tables (step 3) to direct traffic between the VPCs. Finally, security groups (step 4) should be adjusted to allow traffic based on the new routes.

• ✗

  Step 1: Create the peering request, Step 2: Update route tables in both VPCs, Step 3: Accept the peering request, Step 4: Adjust security groups.

  Why it's wrong here

  This is incorrect because route tables cannot be updated until the peering connection is accepted (step 3). The route table update requires the peering connection to be in the 'active' state, which only occurs after acceptance.

• ✗

  Step 1: Accept the peering request, Step 2: Create the peering request, Step 3: Update route tables in both VPCs, Step 4: Adjust security groups.

  Why it's wrong here

  Accepting a peering request is impossible before a request exists because the acceptance operation requires the peering connection ID that is generated only when the requester creates it. The proper sequence is creation first, then acceptance in the 'pending-acceptance' state, which transitions the connection to 'active'. Only after the connection is active can you update route tables to reference the peering connection, so placing acceptance before creation also blocks later route propagation and security group updates.

• ✗

  Step 1: Update route tables in both VPCs, Step 2: Create the peering request, Step 3: Accept the peering request, Step 4: Adjust security groups.

  Why it's wrong here

  This is incorrect because route tables should be updated only after the peering connection is active. Updating them before the request is created and accepted would add routes referencing a non-existent or pending connection, which is not valid.