SCS-C02 Infrastructure Security 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.

• ✓

  Deploy resources across multiple Availability Zones.

  Why this is correct

  Distributing workloads across multiple Availability Zones within a Region makes an entire data-center failure survivable because each AZ runs on independent power, cooling, and physical networking. If one AZ degrades or goes offline, healthy copies of the workload in other AZs continue to serve traffic, giving the design a failure domain with no single point of failure. This is the foundational pattern for mission-critical architecture on AWS and is more effective than any single-instance or IP-level technique.

• ✓

  Use Elastic IP addresses for failover between instances.

  Why this is correct

  Elastic IP addresses support failover by allowing a static public IP to be detached from an unhealthy instance and reassociated to a standby instance within seconds, avoiding the DNS TTL delay that would occur with DNS-based failover. This is useful for scripts or automation that monitor instance health and trigger remapping, giving administrators deterministic control over the failover target. Note that EIP reassociation is most effective when the standby instance is in a different Availability Zone, otherwise the failover remains vulnerable to an AZ-wide outage.

• ✗

  Use a single internet gateway for the VPC.

  Why it's wrong here

  An internet gateway is a redundant, horizontally scaled AWS-managed component that is attached at the VPC level, and a standard VPC can have only one IGW, so using a single IGW is not an availability risk. The gateway itself does not become a bottleneck or a single point of failure because AWS internally designs it for high availability across multiple facilities. The real resilience risk in a network architecture comes from instance placement and subnet design, not from the number of internet gateways.

• ✗

  Use a single Availability Zone for all resources to reduce complexity.

  Why it's wrong here

  Putting all resources in one Availability Zone reduces operational complexity but concentrates the workload's blast radius: any outage affecting that AZ, whether from power loss, cooling failure, or network disruption, takes the entire workload offline. AWS recommends at least two AZs for production workloads because an AZ is a credible failure domain despite being composed of independent data centers. The modest additional cost and orchestration complexity of multi-AZ deployment is the accepted price for the availability critical systems require.

• ✗

  Place all instances in a public subnet for easy access.

  Why it's wrong here

  Placing all instances in a public subnet gives them direct ingress/egress paths to the internet, which expands the attack surface unnecessarily but does nothing to improve redundancy or uptime. Public or private is purely a routing and security posture decision determined by the route table and whether the subnet has a direct route to an internet gateway. A critical architecture keeps application instances in private subnets and exposes only load balancers or NAT gateways in public subnets, because availability is achieved through fault-tolerant placement and health checks, not subnet visibility.

Go deeper

Related to this question