SY0-701 Security Architecture 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 multiple application servers behind a load balancer across separate availability zones.

  Why this is correct

  This design achieves high availability by removing the single point of failure at the application tier. The load balancer distributes traffic across multiple servers and performs periodic health checks, automatically removing any instance that fails. Deploying across separate availability zones (AZs) also protects against an entire data-center outage, because the load balancer can continue routing to healthy instances in the remaining AZs. This is a classic active-active pattern that provides automatic failover and scales horizontally to handle increased user load.

• ✗

  Use a single high-end server with RAID 10 and a larger power supply.

  Why it's wrong here

  A single high-end server with RAID 10 and a larger power supply is still a single point of failure at the host, network, and facility level. RAID 10 only protects against disk failures within that one server; it does nothing if the motherboard, CPU, power supply, or entire rack loses connectivity. A larger PSU only adds capacity, not redundancy. This approach is a scale-up strategy that cannot match the automatic failover and fault tolerance of multiple independent servers, and it still leaves the customer portal vulnerable to a total server outage.

• ✗

  Keep only nightly backups and restore manually after an outage.

  Why it's wrong here

  Nightly backups plus manual restoration is a disaster-recovery plan, not a high-availability solution. In an outage, you would need to detect the failure, provision or access backup infrastructure, restore the latest backup, and redirect traffic—likely taking hours or days. This approach also risks losing up to 24 hours of user transactions because the most recent data is only as fresh as the last backup. It fails the stated requirement of keeping the portal continuously serving users, because manual restoration inherently introduces long RTO and data-loss exposure.

• ✗

  Store the database on a local disk array attached to the primary server.

  Why it's wrong here

  Storing the database on a local disk array attached to the primary server tightly couples the database's availability to that single server. If the server fails, crashes, or loses power, the database becomes inaccessible even if you try to fail over the application tier—the data cannot be reached. This creates a shared failure domain, meaning the database and application are both knocked offline by the same underlying failure. A local disk array provides no redundancy for compute, network, or site-level failures, and it does not facilitate automatic failover of the database service.

• ✓

  Replicate the database to a standby site with automatic failover.

  Why this is correct

  Database replication to a standby site with automatic failover is the correct complement to multi-AZ application servers because it protects the stateful data tier independently from the stateless application tier. The standby database continuously receives updates from the primary, and when a failure is detected (e.g., via heartbeat or a replication lag threshold), the system automatically promotes the standby to primary. This ensures that even if an entire AZ or the primary database server is lost, the portal can continue operating with minimal downtime and minimal data loss. It addresses the RPO/RTO requirements far better than any backup-and-restore approach.