AWS SAP-C02 Solutions Architect – Professional Practical Preparation: Scenarios, Exercises, and Skills to Rehearse

 

AWS Solutions Architect – Professional preparation becomes productive when architecture stops being a list of services and starts becoming a sequence of decisions under constraints. The SAP-C02 exam is built around professional judgment: several options may work technically, but only one may fit the required availability, migration risk, governance model, operating effort, security boundary, latency target, or cost profile. Practical preparation therefore needs to reproduce the decision process rather than merely reproduce diagrams from a course.

As of September 19, 2026, SAP-C02 is in a version transition. AWS has announced that registration for SAP-C03 opens October 27, 2026 and that November 17, 2026 is the final day to take SAP-C02. Candidates already committed to SAP-C02 should keep their exercises aligned to the SAP-C02 blueprint and verify the version on their booking. The current SAP-C02 exam is 180 minutes with 75 questions. AWS identifies four scored domains: Design Solutions for Organizational Complexity at 26%, Design for New Solutions at 29%, Continuous Improvement for Existing Solutions at 25%, and Accelerate Workload Migration and Modernization at 20%.

A useful practical plan should exercise all four domains together. If you rehearse networking only as networking, identity only as identity, and migration only as migration, you miss the integrated reasoning that makes a professional-level scenario difficult. The exercises below are designed to force trade-offs. They are not intended as exact replicas of exam questions. Their purpose is to train the architecture behaviors the exam rewards.

If you have not yet measured where your biggest gaps are, use the SAP-C02 readiness matrix first. Then use the exercises here to turn those gaps into observable skills rather than vague study goals.

Build an architecture notebook before building labs

Practical preparation does not require a large AWS bill. Many of the most valuable exercises are design exercises that can be performed on paper or in a diagramming tool, followed by small validations in a sandbox. Start an architecture notebook with a repeatable template for every scenario.

For each exercise, record the business objective, mandatory constraints, preferred constraints, failure tolerance, data classification, identity boundary, network boundary, recovery objectives, migration limitations, operating model, and cost pressure. Then write two or three plausible architectures. For each architecture, note what it optimizes and what it sacrifices.

This habit prevents a common failure mode: selecting a service first and inventing a justification afterward. On SAP-C02, the service name is often less important than the reason it fits. Your notebook should make that reasoning visible.

Add a final section called “disqualifiers.” List the single requirement that makes each rejected option unacceptable. For example, a proposed cross-account design may be secure but operationally unmanageable; a multi-Region design may meet availability goals but violate data residency; a migration plan may be technically clean but exceed the allowed outage; a cheaper architecture may create an unacceptable recovery point objective. Learning to articulate the disqualifier is one of the fastest ways to improve professional-level question analysis.

Exercise 1: Design a multi-account landing zone for a growing organization

Imagine a company with 120 AWS accounts across five business units. The company has grown through acquisition. Each business unit currently manages identity, logging, networking, and security differently. Leadership wants centralized security visibility and cost allocation without eliminating business-unit autonomy. A new acquisition of 25 accounts must be integrated within three months.

Begin by drawing an AWS Organizations structure. Decide which organizational units reflect policy boundaries rather than organizational charts. Consider production versus nonproduction, regulated workloads, shared services, security accounts, network accounts, sandbox environments, and acquired accounts that may need a temporary quarantine or transition OU.

Then design guardrails. Separate preventive controls from detective controls. Decide where service control policies should apply and where they would be dangerous if introduced without inventory. Describe how you would test an SCP before broad rollout. Identify services or workflows that could fail if a policy denies an API call that teams currently depend on.

Next, design centralized logging and security visibility. Decide where CloudTrail, AWS Config, Security Hub, GuardDuty, and log archives should reside. Think about delegated administration, retention, write protection, and who can alter logging configuration. The point of the exercise is not to memorize every setup step; it is to understand control ownership and blast radius.

Add identity. Compare AWS IAM Identity Center for workforce access with IAM roles for workload or cross-account access. Decide how permission sets, role assumption, emergency access, and least privilege should work. Include a process for acquired users whose existing identity provider cannot be migrated immediately.

Finally, add cost governance. Determine how accounts, tags, Cost Categories, budgets, and consolidated billing support allocation and visibility. Do not confuse a reporting requirement with a hard spending-control requirement. A budget alert is not the same thing as preventing resource creation.

Your deliverable should be a one-page architecture plus a migration sequence for moving the acquired accounts into the new governance model. A strong answer describes staged adoption: inventory, logging, identity integration, baseline controls, pilot SCPs, wider enforcement, and continuous monitoring. A weak answer simply says “use Control Tower” without explaining what must be governed and how disruption is avoided.

Exercise 2: Connect multiple Regions, data centers, and partner networks

Create a scenario with three AWS Regions, two on-premises data centers, 40 VPCs, a shared security inspection function, and two external partners. Some applications require full private connectivity. Others should expose only a specific service to partner consumers. The company also has overlapping IP ranges from an acquisition.

Draw at least three network designs. One might use Transit Gateway per Region with inter-Region peering. Another might combine Direct Connect, Direct Connect gateway, Site-to-Site VPN backup, and centralized inspection. A third might use AWS PrivateLink for partner-facing service exposure rather than extending network reachability.

For each design, answer these questions: Where are routes propagated? Which networks are transitive? What happens if address spaces overlap? How is DNS resolved across environments? Where does traffic inspection occur? What is the failure path if Direct Connect is unavailable? Which components are regional? Which connections incur data-transfer or processing charges? Who owns route changes?

Then introduce a failure. Assume the primary Direct Connect location goes offline. Trace traffic from an on-premises client to a production service. Do not simply say “VPN takes over.” Describe routing preference, BGP behavior, available bandwidth, expected performance, and whether the backup path is actually sized for critical traffic.

Introduce a security change. A partner should now reach only one API, not the entire VPC. If your original design gave the partner routable network access, redesign the boundary. PrivateLink may be more appropriate because the partner consumes a service endpoint rather than becoming part of the network topology.

Finally, introduce overlapping addresses. Decide whether to readdress, isolate, use NAT, expose services through PrivateLink, or redesign communication at the application layer. The professional skill is recognizing that connectivity does not require universal routing.

Exercise 3: Translate RTO and RPO into a recovery architecture

Choose a business-critical application with a web tier, application tier, relational database, object storage, secrets, DNS, and external dependencies. Give it an RTO of 45 minutes and an RPO of five minutes. Then create a second workload with an RTO of 24 hours and an RPO of 12 hours.

Design recovery for both. The first workload may need warm standby, multi-Region data replication, automated infrastructure deployment, tested DNS failover, replicated secrets or key access, and a documented cutover process. The second may be satisfied by backup and restore. The exercise is to prevent overengineering: the correct strategy depends on business objectives.

Create a dependency map. Include identity, KMS keys, certificates, DNS zones, container images, configuration, queues, event sources, external SaaS integrations, and network connectivity. Ask whether each dependency is recoverable in the target Region. A database replica alone does not make an application recoverable.

Run a paper disaster. Assume the primary Region becomes unavailable. Start a timer and walk through every action required to restore service. If a step relies on a person knowing an undocumented command, mark it as operational risk. If a step relies on resources that are created only after disaster declaration, estimate provisioning time. If failover depends on DNS, consider TTL and health-check behavior.

Then simulate data corruption rather than regional failure. A replicated database can reproduce bad data in another Region. Determine how point-in-time recovery, backups, immutability, and change controls protect against logical corruption. This is an important distinction because high availability and recoverability are related but not identical.

Finish by estimating cost. Explain why the first workload justifies higher standby cost while the second does not. Professional architecture balances risk and economics rather than maximizing redundancy everywhere.

Exercise 4: Choose a deployment strategy under conflicting release constraints

Create an application that processes financial transactions. Releases occur weekly. The business requires rapid rollback if error rates increase, cannot tolerate losing in-flight transactions, and wants production validation before sending all traffic to a new version.

Compare blue/green, canary, rolling, and in-place deployment strategies. For each, describe infrastructure duplication, rollback speed, database compatibility, capacity requirements, traffic shifting, and operational complexity. Consider CodeDeploy, load balancer target groups, Route 53 weighted routing, Lambda aliases, or container deployment controllers where appropriate, but keep the focus on behavior.

Now add a database schema change. The old application version and new version may run simultaneously during traffic shifting. Design an expand-and-contract schema migration so both versions remain compatible. A deployment strategy that is safe for stateless compute may fail if the database change is irreversible.

Introduce a 5% canary. Define the signals that determine whether deployment continues: application error rate, latency, business transaction success, queue depth, database errors, and security events. “No alarms” is not enough if the wrong metrics are observed.

Next, imagine that the new release is cheaper but has slightly higher latency. Decide what threshold is acceptable. This makes the exercise realistic: architecture decisions often involve trade-offs rather than binary success and failure.

Exercise 5: Build a secure data platform with multiple access patterns

Design a platform that ingests application events, transactional records, documents, and partner files. Analysts need historical queries, operational applications need low-latency reads, and machine-learning teams need controlled access to curated data. Some records contain personally identifiable information and must stay in specific Regions.

Start by classifying data based on access pattern, consistency, retention, residency, and sensitivity. Decide which data belongs in Amazon S3, relational databases, DynamoDB, analytics services, streaming systems, or specialized stores. Avoid selecting one database for everything.

Design encryption. Decide when AWS managed keys are sufficient and when customer-managed KMS keys provide necessary control. Consider key policies, grants, cross-account access, rotation, deletion risk, and the availability implications of key ownership.

Design access. Separate workforce access from application identity. Use roles and resource policies deliberately. Decide whether analysts should query data in place, access curated copies, or assume roles into producer accounts. Consider Lake Formation or equivalent governance patterns where appropriate, but explain the ownership model.

Add data movement. Determine how partner files arrive, how streaming data is buffered, and how failures are retried without producing duplicates. Consider idempotency, dead-letter queues, backpressure, schema evolution, and replay.

Then add a residency constraint. Some data cannot leave one Region, but aggregated non-sensitive metrics can be global. Redesign replication and analytics so global visibility does not violate locality. This exercise develops the ability to separate datasets by policy instead of treating the application as a single undifferentiated workload.

Exercise 6: Diagnose and improve an existing architecture instead of replacing it

Professional architects inherit systems. Create a deliberately imperfect architecture: an Auto Scaling web tier, a relational database, a cache, a queue, and object storage. Add symptoms: intermittent latency, rising cost, frequent manual deployments, failed background jobs, and occasional database connection exhaustion.

Before redesigning anything, build an observability plan. Decide which CloudWatch metrics, logs, traces, database statistics, queue metrics, load balancer metrics, and application indicators are needed. Form hypotheses. High CPU might indicate compute pressure, but latency could instead come from database locks, connection pools, downstream timeouts, or network behavior.

Choose one symptom at a time. For database connection exhaustion, investigate connection pool sizing, Lambda concurrency, proxying, long transactions, and application behavior. For queue backlog, compare producer rate, consumer throughput, visibility timeout, retry behavior, poison messages, and scaling. For high NAT Gateway cost, inspect traffic destinations and decide whether VPC endpoints or architecture changes reduce processing and transfer.

For manual deployments, identify what can be automated safely. Infrastructure as code, deployment pipelines, configuration management, patch orchestration, and runbooks may reduce toil, but automation should include validation and rollback. An unsafe script is not operational excellence.

The key rule is diagnosis before replacement. SAP-C02 scenarios may offer an attractive greenfield design even when the requirement is to improve the existing solution with minimal disruption. Train yourself to identify the smallest change that satisfies the stated objective.

Exercise 7: Plan a migration wave with real dependencies

Invent a portfolio of 30 applications. Include Windows applications, Linux services, commercial databases, shared file systems, batch processing, message brokers, and one mainframe integration. Give each workload a business owner, downtime tolerance, data volume, dependency list, support status, and modernization opportunity.

Classify each workload using migration strategies such as rehost, replatform, refactor, repurchase, relocate, retain, or retire. Do not assign strategies based on technical fashion. A system scheduled for retirement may not deserve modernization. A system with an immovable deadline may be better rehosted first and modernized later. A proprietary database with licensing constraints may drive a different decision.

Build dependency groups. If three applications share one database, moving only one application can introduce latency and support complexity. Group workloads into waves based on dependency, business criticality, testability, and rollback options.

Choose migration tools based on workload characteristics. Compare AWS Application Migration Service, AWS Database Migration Service, DataSync, Storage Gateway, Snow Family devices, Transfer Family, native database replication, and partner tooling where relevant. Explain why the selected tool fits data volume, change rate, network capacity, schema transformation, downtime, and cutover needs.

Then design rollback. What happens if application validation fails after cutover? How long can source and target remain synchronized? Who decides to roll back? What data written after cutover must be reconciled? A migration plan without rollback criteria is incomplete.

End with post-migration improvement. Once the system is stable, identify candidates for managed databases, containers, serverless processing, event-driven integration, or other modernization. Separate migration success from modernization success.

Exercise 8: Architect for global users without pretending all data is global

Design a customer application with users in North America, Europe, and Asia. The application needs low latency, but some European records must remain in Europe. The company also wants a single global sign-in experience and centralized operational visibility.

Split the problem into request routing, compute placement, data placement, identity, and observability. Compare CloudFront, Global Accelerator, Route 53 routing policies, multi-Region compute, regional data stores, global databases, and replicated object storage based on actual requirements.

Do not default to active-active everywhere. Some workloads benefit from active-active; others are simpler and safer with active-passive or regional isolation. Define what state can be replicated and what state must remain local.

Create a failure scenario in which one Region becomes unavailable. Decide whether users are routed elsewhere, whether their data is available, and whether residency rules still apply. If European user data cannot leave Europe, failing European users to a US Region may violate policy even if the technology supports it.

Add an operational requirement: security teams need centralized findings. Determine which metadata or findings can be aggregated without moving restricted business data. This forces you to distinguish control-plane visibility from workload-data replication.

Exercise 9: Reduce cost without weakening resilience or security

Take one of your earlier architectures and assume finance requests a 20% cost reduction. Do not start with a list of discount mechanisms. Break spending into compute, storage, database, data transfer, networking, observability, backup, and operational labor.

For compute, examine utilization, scaling behavior, instance families, Savings Plans, Reserved Instances, spot suitability, and serverless alternatives. For storage, examine lifecycle policies, access patterns, stale snapshots, and replication. For database cost, examine sizing, I/O, replicas, licensing, engine choice, and workload shape. For networking, look for unnecessary NAT processing, cross-AZ or cross-Region transfer, and inefficient paths.

Then mark resources that exist specifically for resilience or security. A standby database may look underutilized but be essential to RTO. Centralized logging may look expensive but be required for investigation or compliance. Encryption and security inspection may carry cost that cannot simply be removed.

Propose three savings categories: waste elimination, pricing-model optimization, and architectural improvement. Rank each change by savings, risk, implementation effort, and reversibility. This makes cost optimization an architecture exercise instead of a procurement exercise.

Exercise 10: Perform an architecture review with adversarial questions

Choose any design you created and conduct a review as if another architect were trying to disprove it. Ask: What fails if one Availability Zone is unavailable? What fails if a Region is unavailable? What if an administrator credential is compromised? What if a KMS key is disabled? What if DNS is misconfigured? What if traffic grows tenfold? What if the database is corrupted? What if a partner sends malformed data? What if a deployment must be rolled back? What if one acquisition uses overlapping addresses? What if the budget is cut by 30%?

For every answer, require evidence. “It is highly available” is not evidence. Name the redundant components, failure domains, routing behavior, state replication, and recovery process. “It is secure” is not evidence. Name the trust boundaries, identity mechanism, least-privilege controls, logging, encryption, and response path.

Then ask whether the design is operable. Who receives alarms? Who can deploy? Who owns shared networking? How are accounts provisioned? How are certificates rotated? How are backups tested? How are configuration changes reviewed? Professional architecture includes operating model because a technically elegant system can fail through unclear ownership.

Use small hands-on labs to validate uncertain behavior

Full-scale labs are unnecessary, but selected hands-on validation is valuable when behavior is easy to misunderstand. Build tiny experiments with clear questions.

For IAM, create two sandbox accounts and test role assumption, resource-based policies, permission boundaries, and an SCP. Observe the difference between a permission granted by identity policy and a permission blocked by organizational policy. Test what happens when a resource policy grants access across accounts.

For networking, create two or three VPCs and examine route tables, Transit Gateway attachments if available in your sandbox, security groups, network ACLs, DNS resolution, and VPC endpoints. If cost is a concern, diagram expensive services and validate only the behavior you actually need to see.

For resilience, test restore procedures rather than merely enabling backups. Create a small database or object dataset, back it up, restore it, and verify application access. Recovery is a process, not a checkbox.

For event-driven systems, create a queue and consumer, deliberately fail messages, examine visibility timeout and retry behavior, and introduce a dead-letter queue. Observe how duplicate delivery affects idempotency.

For deployment, create a trivial application and test weighted traffic or blue/green behavior. The value is seeing how rollback, health checks, and state compatibility interact.

Record the result in your architecture notebook. A lab should answer a question. If it does not resolve uncertainty, it is activity rather than practice.

Turn practice questions into architecture drills

Practice questions can be useful when you use them to expose reasoning errors rather than memorize answer patterns. After a timed set, classify every miss. Was it missing service knowledge, failure to identify the decisive requirement, confusion about organizational boundaries, weak migration reasoning, cost misunderstanding, or rushing?

For each wrong answer, rewrite the scenario into a design prompt. Remove the answer choices and solve it from first principles. Then create one variation: change the RTO, add a residency rule, introduce overlapping IP space, reduce the budget, or require minimal operational effort. If your architecture changes appropriately, you understand the constraint. If you repeat the same service choice regardless of the change, you may be pattern matching.

Use fresh questions rather than repeatedly cycling the same set. Recognition can create a false sense of readiness. The target is the ability to explain why an architecture fits before seeing candidate answers.

The broader SAP-C02 study plan can help you place these exercises into a repeatable schedule. Practical work is most valuable when it is targeted to measured weaknesses and followed by review, not when it becomes an open-ended lab project.

Rehearse time-bounded design decisions

SAP-C02 gives 180 minutes for 75 questions, so preparation should include reasoning under time pressure. Some questions will be short, while others contain long scenarios with multiple constraints. You cannot spend equal time on every item.

Run a weekly exercise in which you give yourself five minutes to analyze a long scenario. First minute: identify the business objective and mandatory constraints. Second minute: mark failure, security, network, and data boundaries. Third minute: compare two plausible designs. Fourth minute: state the decisive trade-off. Fifth minute: write the answer and move on.

This is not a rule for actual exam timing; it is a drill for decision discipline. As you improve, the constraint extraction should become faster. You should notice phrases such as “least operational effort,” “no public internet,” “must preserve IP addresses,” “cannot modify the application,” “RPO under five minutes,” or “hundreds of accounts” immediately because they shape the architecture.

Also practice abandoning an unproductive line of reasoning. If you are comparing four services but the scenario actually turns on a governance or migration constraint, stop and reframe. Professional judgment includes recognizing when you are solving the wrong problem.

Build a two-week practical rehearsal cycle

A focused two-week cycle can combine design, labs, and review without trying to rebuild the entire AWS platform.

On days one and two, run the multi-account and network exercises. On days three and four, focus on resilience and secure data design. On day five, perform a timed mixed set and classify errors. On days six and seven, validate the two most uncertain behaviors in small labs.

During the second week, work through deployment, architecture improvement, migration, global design, and cost optimization. Use the architecture review exercise to attack each design. Finish with another timed set and compare the error categories with the first week.

Your improvement metric should not be only percentage correct. Track how often you identify the decisive requirement, how often you can disqualify wrong alternatives in one sentence, how often you detect cross-domain dependencies, and how often your first design requires major revision after review.

If you repeatedly struggle with foundational service selection rather than professional trade-offs, revisit associate-level architecture concepts. The Solutions Architect Associate perspective can help separate foundational breadth from the organizational and migration judgment expected at professional level.

Final practical-readiness standard

You are approaching SAP-C02 practical readiness when you can take an unfamiliar business scenario, extract constraints quickly, draw a defensible architecture, explain failure behavior, identify identity and network boundaries, plan migration or deployment, estimate operational implications, and defend cost choices without relying on a memorized diagram.

You should also be able to change the architecture when one requirement changes. If a five-minute RPO becomes 24 hours, your recovery design should simplify. If a partner needs one service instead of network access, your connectivity model may change. If accounts grow from five to 500, governance and automation become more important. If data cannot leave a Region, a global architecture must separate globally distributable components from restricted state.

That adaptability is the point of practical preparation. The SAP-C02 blueprint is broad, but professional readiness is not measured by knowing the largest number of AWS service names. It is measured by disciplined reasoning: requirements before products, failure modes before slogans, boundaries before connectivity, evidence before confidence, and trade-offs before conclusions.

One final rehearsal is to explain the design to two different audiences. First, give a technical explanation to another architect, including routing, trust boundaries, state, recovery, and deployment details. Then explain the same decision to a business owner using risk, downtime, cost, and operational effort. If the business explanation collapses into service names, the architecture may not yet be tied strongly enough to requirements. If the technical explanation cannot identify concrete mechanisms, the design may be too abstract.

Keep an explicit decision log as well. For each exercise, record the option selected, alternatives rejected, decisive constraint, new risk introduced, and validation still required. Return to the log a few days later and challenge the decision with fresh eyes. This practice makes weak assumptions visible and trains the kind of deliberate comparison required when several exam answers are technically credible. It also prevents a common study problem: remembering the final diagram while forgetting why it was chosen.