Architectural judgment matters more than remembering service names
A professional architecture question usually contains a constraint that rules out a superficially attractive solution. A design might require access across dozens of AWS accounts, recovery in another Region, a fixed regulatory boundary, and predictable operating cost. The candidate’s job is to identify which constraint is actually decisive. Memorizing feature lists will not settle a decision about whether a team needs a central networking account, regional isolation, or a different operational ownership model.
Use a short decision brief for each practice architecture: required availability, permitted downtime, maximum data loss, regulatory location, likely traffic pattern, ownership boundaries, and the team that will operate the system. Then state one preferred design and one defensible alternative. A strong answer explains why the rejected design fails a stated requirement, rather than calling a popular AWS service a best practice in every situation.
The outgoing Amazon AWS SAP-C02 exam provides a useful framework for evaluating cross-service architectural trade-offs. AWS lists November 16, 2026 as its final sitting date, opens SAP-C03 registration on October 27 and begins SAP-C03 delivery on November 17. Candidates should confirm the available appointment and study the objectives for the version they will actually take.
Separate accounts according to risk and operational ownership
An organization running production, development, and regulated workloads should not treat a single large account as the default. Separate accounts provide stronger service-quota, cost and identity boundaries. AWS Organizations and organizational units make policy inheritance manageable; service control policies define permissions that cannot be exceeded by principals in affected accounts, but they do not themselves grant an IAM permission.
Suppose a security team needs centralized logs from application accounts while platform engineers maintain shared networks. The design must cover both cross-account delegation and failure isolation. A logging account can receive organization-wide CloudTrail evidence subject to applicable configurations, while a networking account can host centrally managed shared resources. That does not mean every workload must hairpin through one inspection device; network paths must be designed from traffic and security requirements.
Practice tracing one request from a workload subnet across routing tables, security groups, DNS, private endpoints and any inspection hop. State which team can change each control. A diagram with ownership and return paths reveals mistakes that a service-by-service flashcard cannot.
Design recovery against explicit RTO and RPO
Recovery time objective and recovery point objective answer different questions. An application may be available again in thirty minutes but lose several hours of accepted transactions; that could meet an RTO while violating an RPO. Conversely, synchronous replication can reduce potential data loss but adds cost, latency and operational complexity.
For a customer-facing ordering service, define a regional failure scenario and rehearse how traffic changes, whether data is consistent, what DNS or routing must do, and how operators determine that the recovered system is safe to serve writes. Multi-AZ improves fault tolerance within a Region; cross-Region recovery is a separate design decision. Backups, point-in-time restoration, asynchronous replication and active-active patterns serve different objectives. Do not equate a replica with a tested recovery plan.
A convincing answer includes a verification step. After a simulated failover, check application health, missing or duplicated business transactions, secret and key access, observability, and the ability to return to normal operation. Recovery is complete only when the business workload is functioning correctly, not when an infrastructure resource reports healthy.
In the regional-recovery exercise, be explicit about secret management and identity dependencies. A replicated database does not help if an application cannot assume its runtime role, decrypt stored values or reach the authentication authority needed during failover. Include a negative test for a missing key permission and a recovery test for an unavailable network dependency. This distinguishes a complete application recovery from a plan that covers only compute and storage.
Make hybrid connectivity a routed design, not a product checklist
A data center connected to AWS creates several possible paths: site-to-site VPN, dedicated connectivity, private DNS integration, and traffic transiting shared networking infrastructure. Choosing among them requires bandwidth, latency, availability, encryption, routing change frequency and failure-domain requirements. A Direct Connect circuit does not automatically provide end-to-end application encryption or a complete high-availability design.
Consider two data centers and two AWS Regions. Begin with BGP advertisements and route-preference rules, then test the failure of a circuit and the loss of a data center edge router. Decide whether workloads may use an internet-based backup path and whether data residency allows cross-Region routing. DNS forwarding can be just as important as IP reachability when private service names resolve differently inside and outside AWS.
The practical exercise is to draw the forward and return path under healthy and failed states. If outbound flows leave through one security device and return through another, state whether inspection is stateful and what that asymmetry means for connectivity. Architecture exams reward the ability to account for that behavior.
Treat migration as a staged business transition
Modernization is not the same as copying servers. A workload may contain coupled applications, licensing constraints, undocumented scheduled jobs, static IP dependencies, external service contracts and a database that cannot tolerate a long write outage. Before choosing replication or containerization, establish the application dependency map and decide which interfaces can be decoupled safely.
For a transactional application moving from a data center, rehearse how to build a migration wave. Inventory clients and integrations, define rollback criteria, test identity and DNS changes, measure replication lag, then run a cutover drill with a bounded write-freeze or other consistency plan. A database catch-up indicator alone is insufficient unless the application’s business invariants remain true after cutover.
Retain a recovery route for failures discovered after traffic moves. A realistic runbook defines decision owners, observability checks, a maximum acceptable rollback window, and conditions under which rollback itself would cause worse data divergence.
Test architecture against the failure you did not design for
A normal-state diagram can conceal dangerous assumptions. Run through an account compromise, a Region outage, an exhausted service quota and an unexpected burst of data transfer. For each failure identify the first observable signal, the workload scope, the recovery action and the team that owns the decision. A proposed design with no operator or test for its recovery path remains an unproven design.
For instance, a shared inspection VPC may satisfy centralized policy management but become an organization-wide bottleneck unless routing, capacity and availability are designed explicitly. Failure of one attachment or one inspection zone can cause only a subset of flows to fail. A realistic exercise maps each affected subnet and routes a representative packet through the surviving path; it does not assume that adding multiple firewalls automatically delivers resilience.
Capacity problems have a different signature. A high-traffic analytics export might be throttled, exceed a Lambda concurrency limit in an associated workflow or create unexpected inter-Region egress. Locate the controlling quota or price dimension and decide whether the right response is batching, a service redesign, reserved capacity or a change in data placement. The goal is to diagnose the actual limiting dependency.
An architecture review is strongest when it includes a negative test. Demonstrate that an unauthorized account cannot read a regulated data bucket, a failed Region can be isolated, and a restored application does not silently expose older records to a newly added consumer.
Optimize cost with the right unit of value
Price comparisons become misleading when they ignore usage behavior. A cheap compute instance may be expensive if it is oversized, always on, or requires large data transfer across Availability Zones or Regions. Conversely, a more expensive managed service might reduce incident response or maintenance labor. Cost optimization must use a workload unit—per successful transaction, per data pipeline run, or per tenant—rather than compare monthly invoices without context.
Start by separating fixed commitments, variable request charges, storage growth, network egress, and support costs. Test a representative peak and a quiet period. Savings Plans, reserved capacity and spot capacity are conditional tools, not universal recommendations; interruption tolerance and utilization matter. Match performance and recovery requirements before applying discounts.
For exam practice, defend every cost recommendation with its hidden trade-off. Consolidating accounts can simplify the bill but weaken isolation; aggressive data lifecycle rules can lower storage cost but undermine restore time; cross-Region active-active availability can increase transfers and operational burden.
A decision-oriented practice routine
Choose one representative architecture scenario each week and write a one-page decision record: assumptions, nonnegotiable requirements, proposed AWS components, threat and failure model, operational ownership, cost driver, rejected alternative, and acceptance test. Only after recording your independent decision should you compare it with AWS documentation or a review by a qualified colleague.
Keep a mistake log by reasoning error rather than by memorized question: overlooked data residency, confused backup with replication, misread service control policy inheritance, ignored failback, or selected a migration method without a consistency plan. Revisit the underlying constraint with a different workload. This makes preparation useful whether the candidate takes SAP-C02 during its remaining availability or studies the updated SAP-C03 objectives.
A strong review is one a second engineer can challenge. Hand the decision record to someone who did not see your first attempt, ask them to identify an assumption the design cannot survive, and respond with a concrete test or a revised decision. Technical disagreement is useful when each participant can point to a requirement, measurable signal and failure condition rather than a preferred service logo.