SOA-C02 Security and Compliance 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.

• ✗

  Use VPC peering connections between the VPCs.

  Why it's wrong here

  VPC peering connections simply route private IP traffic between two VPCs over AWS's internal network; they do not provide any encryption of the data plane by default. All traffic shared via a peering connection is unencrypted at the network layer, and the peering relationship is non-transitive, so it does not scale to multiple VPCs without full-mesh peering. Even if you encrypted at the application layer, the question specifically asks for encryption at the network layer, which peering does not deliver.

• ✗

  Use VPC endpoints to route traffic through AWS PrivateLink.

  Why it's wrong here

  VPC endpoints using AWS PrivateLink provide private, non-internet connectivity to AWS services or your own services via elastic network interfaces and Network Load Balancers, but they operate at the application/transport layer and do not encrypt traffic between VPCs. PrivateLink is designed to expose or consume services, not to create encrypted tunnels. Traffic over PrivateLink still relies on the VPC's network and any application-level TLS, so it cannot fulfill the requirement for an encryption mechanism at the network level.

• ✓

  Set up AWS Site-to-Site VPN connections between the VPCs via the transit gateway.

  Why this is correct

  AWS Site-to-Site VPN connections establish IPsec tunnels that encrypt all traffic between the connected sites. By attaching these VPN connections to a transit gateway, you can interconnect multiple VPCs and route private traffic through those encrypted tunnels, achieving confidentiality for inter-VPC communication. This is the correct approach because the VPN terminates IPsec encryption at the transit gateway, and the transit gateway handles routing between all attached VPCs and VPN connections.

• ✗

  Configure network ACLs to deny unencrypted traffic.

  Why it's wrong here

  Network ACLs are stateless, subnet-level firewalls that filter traffic based on source/destination IP addresses, ports, and protocols; they do not inspect payload content and cannot identify whether traffic is encrypted. Configuring NACLs to 'deny unencrypted traffic' is impossible because NACLs have no mechanism to detect encryption status. Even if you could set rules, NACLs are not a substitute for encryption, as they only allow or deny packets, never alter or protect their contents.

Go deeper

Related to this question