Hands-on experience for AWS Certified Solutions Architect – Professional should sharpen architecture judgment under incomplete and sometimes conflicting evidence. Building an environment is one skill; diagnosing what failed, choosing an appropriate recovery and defending its cost and security consequences is another. This article concentrates on decision exercises and after-action reasoning rather than repeating a list of laboratory construction steps.
AWS announced that SAP-C02’s final examination date is November 16, 2026, with SAP-C03 testing beginning November 17. The case studies retain a SAP-C02 learning context while exercising skills that remain valuable in the successor’s resilience, governance and operational-excellence domains. Candidates should use AWS’s version-specific official examination guide for current coverage.
Design each exercise around a business objective
Start with a concise service brief. Who uses the system? Which operations are critical? What outage or data-loss tolerance has the business accepted? Which dependencies are controlled by external providers or other internal teams? These requirements determine whether a recovery pattern is sensible, not whether a diagram uses the newest service.
For a customer booking workflow, write a baseline: during a regional incident it must recover within an agreed RTO, tolerate no more than the agreed RPO and preserve user authorization. Record the assumed traffic, data consistency requirements and permitted budget. If these are missing, the exercise should require the architect to ask before recommending a design.
Separate the expected evidence into service health, data integrity, access correctness and cost. A response can restore traffic but still be unacceptable if it loses confirmed bookings or bypasses audit controls.
Drill 1 — The load balancer is healthy but orders fail
A synthetic check reports HTTP success from an application load balancer, yet customers receive errors when submitting orders. Several targets are registered healthy and Auto Scaling has spare capacity. One team’s suggestion is to add more EC2 instances immediately.
A strong diagnosis asks whether the health check actually exercises the failed dependency. Inspect application traces, database connections, throttling and timeouts before changing capacity. A load balancer can route correctly while every target depends on the same unavailable service.
The better architecture decision might involve a richer readiness check, resilient connection handling, a controlled fallback or database failover, depending on the measured cause. The fault-tolerant design discussion explains why apparent instance redundancy is not enough when failure domains overlap.
For the debrief, identify the initial misleading signal, the decisive evidence, the minimal safe intervention and the prevention that would make the next incident easier to detect.
Drill 2 — Region recovery meets RTO but violates RPO
A SaaS application has a disaster-recovery environment ready in another Region. After a simulated regional outage, the application recovers within the required one hour, but a reconciliation shows that recent confirmed transactions were not replicated.
This is a successful availability recovery but a failed data-loss objective. Determine which data stores replicate asynchronously, whether backups have adequate frequency, how applications handle in-flight writes and what reconciliation is possible. Switching DNS or global routing faster will not recover data that never arrived.
A useful continuity and disaster-recovery plan tests RTO and RPO separately, along with application credentials and staff readiness. Do not call an architecture fault tolerant just because a secondary Region appears on its diagram.
The revised decision may require a different replication or consistency design, a more conservative failover threshold or a narrower service promise. Each option has technical and business costs, and may be unacceptable under a strict transaction-integrity requirement.
Drill 3 — A queue survives an outage but duplicates payment
A worker processes a mock payment event and writes a result. It then times out before the queue acknowledges completion, so the message returns and another worker performs the effect a second time. The queue behaved as designed, but the business operation was not idempotent.
Inspect the event ID, business idempotency key, durable processing state and transaction boundary. Evaluate whether retries, dead-letter behavior and visibility timeouts can be adjusted safely. No queue configuration alone proves exactly-once business impact when side effects occur outside a single atomic operation.
The architecture decision is to protect the business effect, not merely suppress redelivery. Use controlled records and replayable tests; never test this behavior with real customer payments.
This drill also tests communication. A good incident report distinguishes lost messages, delayed messages and duplicate effects rather than treating every queue incident as data loss.
Drill 4 — A security restriction interrupts recovery
An organization tightens a service control policy or changes key permissions after a security review. During a later failover exercise, the disaster-recovery role cannot access an encrypted snapshot or retrieve a necessary secret. A proposal to grant broad administrative privileges would make the exercise pass quickly.
The responsible response is to identify the precise denied action, affected role, encryption key policy and organization-level controls. Correct the authorized recovery path narrowly and retest. An emergency bypass of the governance boundary may be more dangerous than a longer but controlled recovery.
Design recovery permissions before the disaster and rehearse them under an approved change process. Security, operations and business owners should know who can approve the recovery and how actions are logged.
The lesson is that availability depends on secure access to dependencies. Reproducing compute and data in another Region without recovery identities and keys is incomplete architecture.
Drill 5 — A resilient topology becomes unexpectedly costly
A team chooses a multi-Region pattern, adds several NAT gateways and enables extensive cross-Region replication. The service meets performance targets but its recurring cost exceeds the budgeted benefit. The initial proposal to reduce cost is to disable monitoring and backups.
Analyze the cost drivers first: data transfer, gateway processing, provisioned capacity, storage replication and logging. Compare the business RTO/RPO with lower-cost pilot-light or warm-standby choices, and assess which controls are non-negotiable.
A topology optimized for the highest imaginable availability is not automatically the right design. Reliability, security and cost are simultaneous constraints. Price estimates must use the actual Region, traffic distribution, retention and service usage rather than a copied generic example.
A short structured SAP-C02 architecture lab can collect the telemetry for this exercise, but the purpose here is selecting which service level and trade-offs are defensible.
Evaluate decisions rather than lab attendance
After each scenario, ask the participant to state the business requirement, initial assumption, evidence that changed the diagnosis, selected action, rejected alternatives and expected side effects. Assess whether the decision respected security, data integrity, cost and a realistic recovery process.
A candidate who can deploy three AWS services but cannot explain their common failure domains has not demonstrated professional design judgment. Conversely, a carefully reasoned tabletop exercise can reveal important missing knowledge before anyone provisions expensive resources.
Keep practical notes in a decision record and update the exercise when AWS’s official exam blueprint or service behavior changes. The transferable skill is making a defensible architecture choice under constraints, not memorizing an old SAP-C02 answer pattern.