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 AWS Firewall Manager to centrally define and enforce security group rules across all VPCs.

  Why this is correct

  AWS Firewall Manager is the correct choice because it provides centrally managed security policies that automatically apply and enforce security group rules across all VPCs and accounts in an AWS Organization. It continuously audits compliance, automatically repairs non-compliant resources, and allows you to define common security group rules in one place, eliminating per-VPC manual updates while offering a single pane of glass for ongoing enforcement.

• ✗

  Create a single security group and attach it to all VPCs.

  Why it's wrong here

  A security group is a VPC-scoped resource; each security group exists only within the VPC where it was created and cannot be attached to instances in a different VPC. Even with VPC peering or a transit gateway, you cannot reference or share a security group across VPC boundaries, so creating a single security group and attaching it to all VPCs is fundamentally impossible—you would need a separate security group in each VPC.

• ✗

  Define security group rules in AWS CloudFormation templates and deploy them to each VPC.

  Why it's wrong here

  CloudFormation templates can deploy security group rules consistently across many VPCs via StackSets, but this is a provisioning mechanism, not ongoing centralized enforcement. Once deployed, changes to the template require a deliberate update action, and without additional services like AWS Config to detect drift, non-compliant changes made outside CloudFormation will go unnoticed. It lacks the continuous auditing and automatic remediation that Firewall Manager provides, making it a manual, not centralized, solution.

• ✗

  Use network ACLs instead of security groups for centralized management.

  Why it's wrong here

  Network ACLs are stateless and operate at the subnet level, not at the VPC or instance level, which fundamentally changes traffic behavior compared to security groups. They require separate inbound and outbound rules, are evaluated in numeric order, and do not support stateful allow-return traffic, so using them instead of security groups would break common application patterns and create onerous rule management. Network ACLs also lack the VPC-scoped central management and instance-level control needed to replace security groups across multiple VPCs.

Go deeper

Related to this question