Hands-on labs can make AWS Solutions Architect – Professional concepts concrete, but a worthwhile lab has more than a deployed diagram. It states a failure or design question, produces measurable evidence and includes a safe cleanup plan. This article provides bounded practical exercises for architecture candidates who already understand AWS foundations and want to test their assumptions.
The SAP-C02 examination remains available only through November 16, 2026; AWS opened registration for SAP-C03 on October 27 and begins the updated exam on November 17. These labs address transferable architecture skills, not a guarantee that an older SAP-C02 resource matches the new exam blueprint. Review the appropriate official guide for the appointment you book.
Establish an isolated, cost-aware lab environment
Use a nonproduction AWS account or an explicitly approved sandbox, with spending visibility, minimal IAM privileges and no production data. Create a naming or tagging convention for all temporary resources, and know which services bill for runtime, storage, logging, inter-Region transfer and attached network infrastructure. Do not assume every example is covered by the Free Tier.
For each exercise, record the architecture, the hypothesis, expected behavior, observed output, time to recover and cleanup evidence. If the budget cannot support a managed database or multi-Region deployment, use a design walkthrough and AWS documentation rather than silently converting a costly production action into a supposed free lab.
Do not inject faults into production or remove protections merely to force a dramatic result. The objective is a reproducible controlled experiment whose operational trade-offs are clear.
Lab 1 — Observe load-balancer and instance resilience
Build a minimal sample web workload in two Availability Zones with a supported Application Load Balancer and Auto Scaling group. Use private subnet placement for back-end instances and a tightly scoped entry path. Configure an application health endpoint that reflects real readiness rather than a static success page.
Verify that the load balancer marks healthy targets available and the application responds through the expected listener. In the isolated sandbox, remove or stop one disposable target under an approved test condition. Observe health checks, replacement behavior, request errors and time to restore healthy capacity.
The lesson is that instance redundancy must be paired with sufficient remaining capacity, valid routing, healthy dependencies and recovery signals. A detailed Elastic Load Balancing explanation supports this lab because target registration and health cannot compensate for a failed shared database.
Capture the before-and-after target health and application results. Clean up the load balancer, target group, autoscaling resources, network interfaces and related test instances; verify that billable resources no longer remain.
Lab 2 — Test database failover and client recovery
A nonproduction RDS Multi-AZ instance can show how a standby is used for availability. Choose a supported engine and configuration, initialize a small dataset and establish a client connection through the correct endpoint. A Multi-AZ instance standby normally does not serve read traffic; a Multi-AZ DB cluster with readable instances is a distinct deployment architecture.
In a permitted test, initiate a documented failover or use an isolated fault exercise. Measure time until the application can successfully reconnect and determine whether transactions were safely retried. Compare client error handling, connection-pool behavior and monitoring events against expectations; do not promise a universal recovery duration.
Separate high availability from read scaling. A Multi-AZ and read-replica comparison makes clear why asynchronously replicated read replicas and managed automatic failover targets are not interchangeable.
RDS Multi-AZ can be costly. If budget does not allow provisioned redundancy, document the official service behavior and build a failure decision table without running a destructive test. Either way, identify the actual recovery objective and the evidence still missing.
Lab 3 — Make an event consumer safe under retries
Create a simple SQS queue, a dead-letter queue and a permitted worker that processes mock order events. Configure sensible visibility timeouts, retries and permissions. Assume events can be delivered more than once and choose a stable idempotency key for each business operation.
Send a repeated mock order event and simulate a worker failure after it has performed an action but before completion is acknowledged. Confirm that the consumer does not create duplicate business effects. Observe queue depth, age of oldest message and dead-letter handling while distinguishing expected retry behavior from a poison message.
The important architectural observation is that durability of queued messages is not equivalent to exactly-once business processing. Record which data store tracks idempotency and how that record is protected against race conditions.
After verification, delete the test messages, queues, worker, logs and any temporary durable records. Do not use real payments or customer messages in this exercise.
Lab 4 — Restore from a protected backup
Choose a small, disposable dataset and define a target Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Use a supported backup procedure with documented access controls, retention and where appropriate protected recovery copies. Test a restore into an isolated environment rather than assuming a successful backup job proves recoverability.
Measure the time between the simulated loss and successful validation of a restored service, and compare the latest recoverable data point with the RPO. Check encryption-key availability, identities that may delete recovery points and whether the restore is operationally complete.
The AWS Backup strategy is most useful when recovery testing, retention decisions and permission separation are covered together. Replication alone may propagate accidental or malicious changes and does not eliminate the need for tested recovery.
Clean up temporary restore infrastructure when evidence has been collected, respecting any required audit logs and approved retention periods.
Lab 5 — Check network reachability and least-privilege changes
Model two application subnets and one shared-services segment. Document the intended source, destination, protocol and port for each permitted flow. Inspect route tables, security groups and network ACLs, and use supported reachability diagnostics where available. A blocked connection is an opportunity to trace actual policy and routing decisions.
Now evaluate a proposed infrastructure change through a reviewed change set or equivalent infrastructure-as-code workflow. Ask whether the change would create a broad access path, remove logging or shift traffic to a paid network appliance. Apply changes only in the approved sandbox and verify effective rather than merely declared behavior.
The underlying AWS VPC connectivity and security concepts matter when a design spans peers, route tables and independently managed dependencies. A rule can be syntactically valid yet operationally dangerous.
Do not create inter-Region traffic, NAT gateways or Transit Gateways casually for a brief demonstration. Their usage and data transfer can incur charges beyond the visible compute resources.
Turn lab results into architecture evidence
For each lab, create a short result: the original requirement, design diagram, resources, test trigger, observed metrics, failure discovered, adjustment and validation after the fix. Ask what would happen if two faults coincided, what the residual dependency is and which cost or organizational constraint limits the proposed design.
A separate hands-on architecture failure-diagnosis approach can turn those artifacts into timed decision drills; the present page is deliberately a lab-building and verification walkthrough.
The goal is not to collect a large number of deployments. It is to prove that a design’s claims survive a controlled test, that an engineer can explain the trade-offs, and that every temporary cloud resource has a documented cleanup outcome.