AWS SAP-C02 Solutions Architect – Professional Deep Dive: New solution design — From Fundamentals to Exam Scenarios

 

Designing a new AWS solution at professional level is not a service-selection exercise. It is a process of turning business requirements into an architecture that can be deployed safely, survive expected failures, enforce the right trust boundaries, meet performance targets, and remain economically defensible after the first month of operation. That is why the current AWS Certified Solutions Architect – Professional SAP-C02 exam gives Design for New Solutions 29% of scored content, the largest single domain in the blueprint.

The domain is broad because a new solution has no excuse for inheriting avoidable mistakes. The architect is expected to make deliberate choices about deployment, business continuity, security, reliability, performance, and cost before those choices become expensive production constraints. In an exam scenario, several answers may technically work. The stronger answer is usually the one that satisfies the decisive requirement with the smallest unnecessary blast radius, operational burden, recovery risk, or long-term cost.

As of September 19, 2026, SAP-C02 is still the current version of this certification. AWS has announced that registration for SAP-C03 opens on October 27, 2026 and that the transition will occur in November. Candidates booked for SAP-C02 should therefore keep their reasoning anchored to the current SAP-C02 guide rather than mixing future blueprint changes into current preparation. A current SAP-C02 exam overview is useful for that broader version and domain context; this article stays focused on the architecture decisions inside new-solution design.

The most useful way to study this domain is to stop asking, ‘Which AWS service belongs to this keyword?’ and instead ask, ‘What is the workload trying to achieve, what can fail, what must be protected, what must scale, what can be operated automatically, and which trade-offs are acceptable?’ The sections below build that reasoning model from fundamentals to exam-style scenarios.

What Domain 2 actually tests

AWS currently divides Design for New Solutions into six tasks: deployment strategy, business continuity, security controls, reliability, performance, and cost optimization. Those labels can look like separate study chapters, but real architecture questions mix them. A deployment mechanism affects recoverability. A database choice affects performance, availability, and cost. A network boundary affects security and operational complexity. A cross-Region design affects resilience, data-transfer cost, and failure procedures at the same time.

That overlap is intentional. A professional solutions architect should be able to reason through the consequences of a decision instead of optimizing one metric in isolation. For example, adding a second Region may reduce recovery time, but it also introduces replication behavior, data consistency questions, failover testing, duplicated infrastructure, deployment coordination, and possibly regulatory constraints. ‘More resilient’ is not enough; the design has to be proportionate to the stated recovery objective.

This is also why the domain is easier when you think in architecture layers. Start with business outcomes and constraints. Then define trust and failure boundaries. Select data and integration patterns. Choose compute, storage, and managed services. Design deployment and rollback. Add observability and recovery. Finally, test the design against performance and cost objectives. Service names come after the problem has been shaped.

Begin with requirements, not a service catalog

A strong design starts by separating requirements into categories. Functional requirements describe what the system must do. Nonfunctional requirements describe qualities such as latency, availability, durability, throughput, privacy, recovery, and cost. Organizational requirements add ownership, compliance, deployment, and support constraints. Existing dependencies can matter even in a ‘new’ solution because the workload may need to integrate with corporate identity, on-premises networks, shared data platforms, or established security controls.

Before drawing an architecture, translate vague language into measurable or testable statements. ‘Highly available’ is weak. ‘The public API must continue serving requests after the loss of one Availability Zone without manual intervention’ is useful. ‘Fast’ is weak. ‘The checkout path must keep the 95th percentile response time below the stated target during a predictable seasonal peak’ is useful. ‘Secure’ is weak. ‘Only the payment service may decrypt cardholder data, keys must be centrally governed, and administrative access must be auditable’ creates design constraints.

Exam questions often hide the decisive requirement in one phrase: minimize operational overhead, preserve source IP addresses, recover within minutes, avoid data loss beyond a defined window, support unpredictable spikes, retain data for years, isolate regulated workloads, or reduce cross-Region transfer. Train yourself to underline that phrase mentally before evaluating answers. If you start with the services in the options, attractive features can distract you from the constraint that actually determines the architecture.

Build a constraint hierarchy before comparing architectures

Not every requirement has equal priority. Some are hard constraints: regulatory residency, maximum recovery time, required encryption boundary, a fixed integration protocol, or an immovable cutover deadline. Others are preferences: lower cost, less custom code, familiar tooling, or a particular managed service. Professional architecture means knowing which preference can be sacrificed when two goals conflict.

A useful sequence is: identify disqualifiers first, then compare trade-offs among the remaining options. If a solution cannot meet the RPO, it should be removed before discussing cost. If a design exposes a private service to the public internet when the requirement explicitly prohibits public exposure, its lower operational effort is irrelevant. If a workload must absorb a tenfold spike within minutes, a fixed-capacity design that would require a maintenance window to scale should be rejected before you compare hourly prices.

This constraint hierarchy also prevents overengineering. A business may accept four hours of recovery time for an internal reporting portal. A multi-Region active/active design can be impressive but economically and operationally unjustified. SAP-C02 frequently rewards the simplest architecture that fully meets the stated requirement, not the architecture with the largest number of high-availability features.

Define ownership and account boundaries early

Even when Domain 2 focuses on a new workload, organizational design still matters. Ask who owns the workload, who owns security evidence, who pays for it, which environments need isolation, and whether production should share an account with development. The account boundary influences IAM, quotas, billing, logging, incident response, network design, and the blast radius of administrative mistakes.

If the scenario describes multiple business units, regulatory scopes, or independent workload teams, account separation can be part of the solution even when the question never says ‘AWS Organizations.’ Conversely, creating a new account for every tiny component can create needless operational overhead. The boundary should correspond to real differences in ownership, policy, risk, lifecycle, or cost accountability.

Candidates who need a deeper treatment of this decision can review the multi-account design guide. For new solutions, the important connection is that governance should be designed before deployment pipelines, network routes, and IAM roles harden assumptions that are difficult to reverse later.

Treat deployment strategy as an architecture decision

Deployment is not an afterthought that belongs only to a DevOps team. Task 2.1 explicitly expects candidates to reason about infrastructure as code, CI/CD, change management, configuration management, upgrade paths, rollback mechanisms, and the use of managed services to reduce undifferentiated work. A solution that cannot be changed safely is not fully designed.

For infrastructure, repeatability matters. AWS CloudFormation or another infrastructure-as-code approach allows environments to be created from reviewed definitions instead of undocumented console actions. That supports consistent testing, controlled promotion, drift awareness, and recovery. The exam signal is usually not ‘use CloudFormation because IaC is good’; it is a requirement such as repeatable environments, minimized configuration drift, automated regional recovery, or controlled deployment across many accounts.

For application releases, the deployment pattern should match risk tolerance. In-place updates may be simple but can increase blast radius. Rolling deployments reduce simultaneous change but create a period with mixed versions. Blue/green patterns can make rollback fast because the previous environment remains available, but they may require duplicated capacity and careful data compatibility. Canary releases limit initial exposure and provide evidence before full rollout. The right answer depends on rollback speed, compatibility, traffic control, cost, and how state is handled.

Design rollback before you need it

A rollback plan is credible only if the architecture preserves a path back. Application code can often be reverted quickly, but schema changes, event formats, irreversible data transformations, and external contracts can make rollback much harder. Professional designs therefore consider backward compatibility, versioned APIs, additive schema changes, deployment sequencing, and feature flags where appropriate.

Suppose a new application version writes a new database format that the old version cannot read. A blue/green deployment alone does not guarantee safe rollback because the data plane has moved forward. A better release strategy might use an expand-and-contract schema change: introduce backward-compatible structures first, deploy code that can work with both versions, migrate data gradually, and remove the old structures only after the rollback window closes.

Exam distractors often present an automation tool without addressing reversibility. If the requirement emphasizes minimizing failed-release impact, ask what happens after the monitoring alarm fires. Which component shifts traffic? Is the previous version still viable? Does the database remain compatible? Can configuration be restored? The answer that describes only deployment speed may miss the actual reliability requirement.

Use managed services when they remove work that does not differentiate the business

The current exam guide explicitly includes adopting managed services to reduce provisioning and patching overhead. That does not mean ‘serverless is always best.’ It means operational work is a design variable. If two architectures satisfy the technical constraints, the one that removes unnecessary fleet management, backup scripting, failover orchestration, or patching may better satisfy a ‘least operational overhead’ requirement.

For example, a team could operate a self-managed database cluster on EC2, but Amazon RDS or Amazon Aurora may provide managed backups, maintenance integration, replicas, and Multi-AZ options that reduce operational burden. A queue built inside an application can work, but Amazon SQS may provide durable buffering and independent scaling with less custom infrastructure. A custom cron fleet can execute scheduled work, but EventBridge Scheduler or managed workflow services may be more appropriate when the requirement is simple scheduling and reliability rather than custom compute control.

Managed services still require architecture. You must understand service limits, failure behavior, scaling controls, encryption, network reachability, logging, backup, and cost. The professional skill is not outsourcing thought to AWS; it is choosing where the shared-responsibility boundary should sit.

Business continuity starts with RTO and RPO

Business continuity design should begin with recovery objectives, not with the phrase ‘multi-Region.’ Recovery Time Objective is the maximum acceptable delay before restoring service after a disruption. Recovery Point Objective describes the maximum acceptable amount of data loss measured in time. These objectives are set by the business and determine how much recovery capability is justified.

AWS commonly describes disaster-recovery approaches along a spectrum: backup and restore, pilot light, warm standby, and multi-site active/active. The architecture becomes more capable and generally more expensive and operationally complex as recovery objectives become stricter. A backup-and-restore strategy may be reasonable for a lower-priority workload with recovery measured in hours. A warm standby can support much shorter recovery because a reduced but functional environment already exists. Multi-site active/active can reduce service interruption further but adds the hardest consistency, routing, deployment, and operational questions.

The exam pattern is to match the recovery design to the stated objective. If a scenario requires an RPO of a few minutes, a daily snapshot is not sufficient no matter how durable the snapshot is. If the RTO is several hours, duplicating the full production stack in another Region may be unnecessary unless another requirement, such as regulation, demands it.

Distinguish high availability from disaster recovery

High availability and disaster recovery overlap but solve different scopes of failure. A Multi-AZ architecture can protect against the loss of an Availability Zone or a component within a Region. It does not automatically provide recovery from a regional disruption, a destructive application bug, malicious deletion, or data corruption replicated to every live copy.

This distinction matters because adding replicas is not the same as adding recoverability. A synchronous replica can improve availability but may copy logical corruption immediately. Point-in-time recovery and immutable or protected backups address a different failure mode. Cross-Region replication can improve regional resilience, but the replication lag becomes part of the RPO discussion and the failover mechanism becomes part of the RTO discussion.

When reading an exam question, classify the failure being protected against. Hardware failure, AZ failure, Region failure, data corruption, credential compromise, deployment failure, and operator error may require different controls. The best solution usually targets the specified failure mode instead of applying generic redundancy everywhere.

Design security from trust boundaries and data flows

Task 2.3 covers IAM, network controls, encryption at rest and in transit, service endpoints, credential management, managed security services, and patch management. These topics become manageable when you draw trust boundaries first. Identify users, services, accounts, networks, data stores, external partners, and administrative paths. Then ask which interactions are necessary and which should be impossible.

Least privilege is easier when the design gives each workload component a narrow responsibility. A web tier that only needs to publish a message should not receive broad database permissions. A batch worker that reads one S3 prefix should not receive wildcard access to every bucket. Human administrators should use roles or centralized workforce access rather than static credentials distributed across accounts. Workload identities should use temporary credentials wherever possible instead of embedded keys.

The exam often tests whether you can reduce the trust surface without breaking the business flow. If an external consumer needs one private service, exposing an entire VPC through broad routed connectivity may be excessive. If an AWS service needs to reach another AWS service privately, a VPC endpoint may reduce reliance on internet paths. If administrators need emergency access, design an auditable break-glass path rather than giving every operator permanent elevated permissions.

Separate network reachability from authorization

A network route only makes a destination reachable; it does not prove the caller is authorized. A security group can restrict traffic by protocol, port, and source context, but it does not replace IAM for API authorization. IAM permissions can allow an API call, but the caller still needs a network path to a private endpoint. Strong architectures layer these controls instead of expecting one layer to do everything.

This is especially important for service-to-service designs. A private application may use internal load balancers, VPC endpoints, security groups, and IAM roles together. The route and endpoint define where traffic can flow, security groups constrain network conversations, and IAM or application authorization decides what the caller can do. Encryption protects the traffic and data, while logging provides evidence about use.

Exam distractors frequently solve the wrong layer. A question about preventing public network exposure may offer an IAM policy that still leaves a public endpoint reachable. A question about limiting who can call an API may offer a private subnet but no identity control. Always map the requirement to the control plane that actually enforces it.

Make encryption and key ownership part of the architecture

Encryption decisions are not complete when you check a box that says ‘encrypted.’ Determine what data is sensitive, where it is stored, where it moves, which principal can decrypt it, who administers the keys, how keys rotate, how access is logged, and whether the organization requires customer-managed keys or separation of duties.

At rest, AWS services often provide encryption by default or as a configurable option, but key choice changes the control model. AWS-owned or AWS-managed keys can reduce operational overhead, while customer-managed KMS keys can provide more explicit policy control, rotation choices, grants, and auditability. The requirement should drive the decision. If a central security team must control decryption across several workload accounts, key policy and cross-account design become part of the solution.

For secrets, avoid treating encrypted configuration files as a complete credential-management strategy. Services such as AWS Secrets Manager or Systems Manager Parameter Store can centralize secret storage and access, and some use cases support rotation. The architectural question is how applications obtain credentials without embedding long-lived secrets in code, images, user data, or deployment scripts.

Reliability means designing for expected failure, not hoping failure is rare

Task 2.4 expects candidates to reason about Multi-AZ and multi-Region architectures, scaling, application integration, quotas, DNS routing, and managed-service availability. The principle is simple: identify dependencies, understand how each can fail, and prevent one failure from unnecessarily cascading through the whole workload.

A stateless application tier behind an elastic load balancer is easier to recover than servers that hold unique local state. A durable queue between producers and workers allows each side to scale and fail independently. Retries with exponential backoff and jitter can recover from transient errors, but unbounded retries can amplify an outage. Idempotent operations make retries safer. Timeouts prevent a dependency from consuming resources forever. Dead-letter queues isolate poison messages for investigation.

Reliability also requires capacity awareness. A perfectly redundant design can still fail if it hits an account quota, a connection limit, a downstream API throttle, or an unmodeled scaling bottleneck. Professional architects treat quotas and dependency capacity as part of the failure model, not as details to check after launch.

Use loose coupling where failure independence matters

Loose coupling is valuable when components have different scaling rates, availability characteristics, or maintenance cycles. If a web request must wait synchronously for five downstream systems, the user experience inherits the combined latency and availability of all five. If some work can be asynchronous, placing a durable queue or event layer between components can reduce that coupling.

However, asynchronous architecture changes the programming model. You must think about duplicate delivery, ordering, retries, visibility timeouts, poison messages, event schemas, replay, and eventual consistency. An answer that adds SQS or EventBridge is not automatically better if the business transaction requires immediate synchronous confirmation. The requirement determines whether decoupling is appropriate.

A common exam pattern is a bursty producer overwhelming a slower consumer. Buffering with a queue allows the producer to continue accepting work while consumers scale based on queue depth. The queue absorbs the rate difference and protects the downstream system. The important reasoning is not the product name; it is the separation of arrival rate from processing rate.

Design scaling from the real bottleneck

Elastic compute does not help when the bottleneck is a database connection limit, a single partition key, a downstream partner API, an NAT gateway design, or a serialized workflow. Begin performance and reliability analysis by finding the constrained resource. Then decide whether to scale up, scale out, cache, partition, batch, buffer, replicate, or redesign the access pattern.

For compute fleets, scaling policies should be tied to a signal that represents load. CPU can be useful for compute-bound work, but request count, queue depth, concurrency, latency, or custom business metrics may be better for other workloads. Predictive or scheduled scaling can help when demand has stable patterns, while target tracking can react to measured load. The architecture must also ensure new capacity can initialize quickly enough to satisfy the demand curve.

For serverless services, scaling may be built in, but concurrency and downstream capacity still matter. A Lambda function that can scale rapidly may overwhelm a relational database if every invocation opens a connection. Techniques such as connection pooling, RDS Proxy, concurrency controls, batching, or an asynchronous buffer can make the overall system scale coherently.

Choose compute by operating model and workload shape

EC2, containers, and serverless compute can all be correct answers. The choice should follow workload characteristics. EC2 provides the most host-level control and can fit specialized software, long-running processes, custom networking, or licensing constraints. Containers provide packaging consistency and can be orchestrated through Amazon ECS or Amazon EKS. AWS Fargate can remove host management for suitable container workloads. AWS Lambda fits event-driven functions that benefit from automatic scaling and short-lived execution without server management.

The exam signal ‘least operational overhead’ often favors a more managed option when all technical requirements are met. The signal ‘requires custom kernel modules’ or ‘must use a specific host-based license’ may push toward EC2. The signal ‘existing Kubernetes platform and tooling’ can make EKS relevant, but Kubernetes should not be selected merely because the architecture is modern. Its operational model must be justified.

Be careful with false binaries. A workload does not have to be entirely serverless or entirely containerized. A public API might use API Gateway and Lambda, while a long-running processing component uses ECS, and a specialized analytics job uses a managed data service. Professional architecture composes services around requirements rather than enforcing one compute ideology across every component.

Choose data stores from access patterns and consistency needs

Purpose-built databases are an important SAP-C02 idea. Start with how data is read and written, the relationship model, transaction boundaries, latency needs, scale, query patterns, and operational constraints. Then choose the data service. A relational database is appropriate when relational integrity and transactions dominate. DynamoDB can fit predictable key-value or document access at very large scale. ElastiCache can offload hot reads. OpenSearch can support search-oriented access. Specialized services exist because one database model is not optimal for every workload.

A common mistake is choosing the database that the team already knows before validating the access pattern. That can create expensive scaling problems later. The opposite mistake is fragmenting a simple workload across many specialized stores without operational justification. Every additional data technology creates backup, monitoring, security, schema, and expertise requirements.

Exam scenarios often reveal the answer through one decisive data characteristic: millisecond key-based access at unpredictable scale, complex relational transactions, read-heavy repeated queries, immutable object storage, time-series ingestion, or a search workload. Translate the workload into access patterns first; then compare services.

Match storage to durability, latency, access frequency, and sharing requirements

Storage selection should consider how data is accessed and how long it must persist. Amazon S3 is a durable object store suitable for many data-lake, backup, content, and archive patterns. EBS provides block storage for EC2 and fits low-latency block-device requirements. EFS provides shared file semantics for Linux workloads. FSx families address specific file-system requirements. Storage class and lifecycle choices can reduce cost when data ages.

The exam may test whether you understand the difference between performance and durability. Provisioning faster storage does not automatically make a system more durable. Multi-AZ or replication options, backup, versioning, object lock, and recovery mechanisms address different risks. Similarly, a shared file requirement is not solved by attaching one EBS volume to many independent hosts unless the specific supported access mode and application semantics fit.

For data lakes or large object datasets, consider request patterns, lifecycle transitions, retrieval delay, and data transfer. A design that places every object in the fastest storage class forever may meet latency but violate cost objectives. A design that archives active data too aggressively may create retrieval delays that violate the application requirement.

Use caching, buffering, and replicas to solve specific performance problems

Task 2.5 explicitly mentions caching, buffering, and replicas. These patterns solve different bottlenecks. A cache reduces repeated work or repeated reads. A buffer absorbs rate differences and protects downstream systems. A read replica adds read capacity and can sometimes support geographic read locality. None of them is a universal accelerator.

Caching requires a freshness strategy. Decide what can be stale, for how long, how entries are invalidated, and what happens on a cache miss or cache outage. A cache in front of a database can reduce load dramatically, but stale or inconsistent data can be unacceptable for some transactions. CloudFront can cache edge content and reduce origin load, while application caches such as ElastiCache operate closer to application data and logic.

Replicas require consistency reasoning. An asynchronous read replica may lag behind the primary, which is acceptable for product browsing but not necessarily for a just-completed financial transaction. The exam often rewards recognizing that the performance pattern changes semantics. Always ask what the user expects to observe immediately after a write.

Design performance from end to end, not component by component

A system can contain individually fast components and still have poor end-to-end performance because of network distance, chatty APIs, serialization, cold starts, lock contention, oversized payloads, inefficient queries, or synchronous dependency chains. Map the request path and budget latency across components. The slowest or most variable dependency may dominate the experience.

Geography matters. If users are global, putting all application logic in one Region may create unnecessary network latency even when the servers are powerful. CloudFront, Global Accelerator, regional deployments, replicated data, or edge-oriented patterns may help depending on protocol and consistency needs. But global architecture adds cost and state-management complexity, so it should be justified by the latency or resilience requirement.

Performance testing should reflect realistic access patterns. Average load is not enough if the business experiences sharp peaks. A design should be tested with representative concurrency, payload sizes, data volumes, cache states, and failure conditions. On the exam, a requirement that emphasizes a predictable peak, unpredictable burst, or low-latency global access should change the architecture.

Make cost optimization part of initial design

Task 2.6 exists because cost is an architecture property. Instance family, storage tier, data transfer, replication, idle capacity, database model, licensing, and managed-service choices can change cost by orders of magnitude. The correct design is not the cheapest possible system; it is the lowest-cost architecture that still meets the business objectives and risk tolerance.

Separate fixed and variable cost. A permanently provisioned fleet may be efficient for steady utilization but wasteful for intermittent demand. Serverless or on-demand capacity can be attractive for spiky or low-duty-cycle workloads but may cost more at sustained high usage. Savings Plans or Reserved Instances can reduce eligible steady-state compute cost, but committing before understanding baseline utilization can create waste. Spot Instances can reduce cost for interruption-tolerant work but are inappropriate when the workload cannot tolerate interruption.

Rightsizing is also continuous. A new system begins with estimates, and real measurements should refine those assumptions after launch. Build observability and cost allocation so the team can see utilization and spend by workload, environment, or business owner. Cost optimization that cannot be measured becomes guesswork.

Model data-transfer cost explicitly

Data transfer is easy to ignore on a diagram because arrows look free. In real systems, data crossing Availability Zones, Regions, public endpoints, NAT devices, or service boundaries can create meaningful charges and performance effects. Domain 2 explicitly expects candidates to reason about data-transfer modeling.

Suppose an application tier in one Availability Zone constantly queries a database in another. The architecture may be resilient, but the cross-AZ traffic pattern can add cost and latency. A centralized inspection or NAT architecture can also create data-processing charges when large volumes pass through it. Cross-Region replication can be essential for recovery, yet the amount of replicated data should be part of the financial model.

The exam signal is often a large-volume data path combined with a cost objective. Trace where the bytes move. Ask whether the same outcome can be achieved with locality, caching, private service integration, aggregation, compression, lifecycle changes, or a different architecture. Do not optimize transfer cost by breaking resilience or security requirements; treat it as one constraint in the complete design.

Plan observability before launch

A new solution is not production-ready if operators cannot tell whether it is healthy. Define the signals needed to detect customer-impacting failure, capacity pressure, security anomalies, and cost drift. Metrics show quantitative behavior, logs explain events, traces reveal request paths, and events can trigger automation. The exact tool set depends on the workload, but observability should be connected to business outcomes rather than limited to infrastructure statistics.

For example, CPU below 50% does not prove a checkout system is healthy. More useful signals may include successful checkout rate, payment authorization latency, queue age, failed dependency calls, inventory reservation errors, and end-to-end latency percentiles. Technical telemetry should make it possible to explain why a business KPI is moving.

Monitoring also supports recovery. Alarms can trigger Auto Scaling, failover workflows, or incident notifications. Health checks can influence Route 53 routing. Centralized logging can support security investigations. The architecture should avoid a circular dependency in which the monitoring system fails with the workload it is supposed to diagnose.

Scenario 1: A global ecommerce launch

Consider a retailer launching a new ecommerce platform. Traffic is usually moderate but can rise tenfold during announced promotions. Customers are distributed across several continents. The business requires the storefront to remain available after an Availability Zone failure, orders must not be lost, and the team wants to minimize infrastructure operations. The initial temptation might be to select ‘multi-Region active/active’ because the users are global, but that is not justified yet.

Start with requirements. Global users create a latency concern, but static and cacheable content can be served through CloudFront without running the entire transactional system in every Region. A Multi-AZ application architecture in one Region can satisfy the stated AZ-failure requirement. Stateless application compute can scale horizontally behind a load balancer. A managed relational database such as Aurora or RDS with an appropriate Multi-AZ configuration may fit transactional order data if the data model requires relational consistency. SQS can decouple non-immediate fulfillment tasks so a traffic spike does not overwhelm downstream processing.

For deployment, an automated pipeline can create immutable application artifacts and use a deployment pattern with health-based rollback. Infrastructure as code keeps environments repeatable. Security groups and private subnets reduce unnecessary exposure, IAM roles give components only the permissions they need, and KMS-backed encryption protects data. CloudWatch metrics and application telemetry track error rate, latency, queue depth, and order completion.

Now change one constraint: the business requires checkout to continue after a full regional outage with an RTO of five minutes and an RPO close to zero. The architecture must be reconsidered. Data replication, cross-Region routing, conflict handling, failover testing, and deployment coordination become central. The point is that the service list changed only because the requirement changed. That is SAP-C02 reasoning.

Scenario 2: A regulated partner API

A financial company is building an API for a small number of business partners. Traffic is predictable, but the data is sensitive. Partners must connect privately, only approved workloads may invoke the service, decryption keys must remain under central security control, and all administrative actions must be auditable. The organization prefers managed services but cannot permit public internet exposure to the API.

The architecture should begin with the trust boundary. If partners connect through established private connectivity, an internal load balancer or private API pattern can keep the service off public endpoints. If service exposure should be narrow rather than providing broad routed network access, AWS PrivateLink may be appropriate. Security groups restrict network flows, while application authorization and IAM-based service permissions enforce who can perform actions. These layers solve different problems.

Sensitive data can use encryption in transit and at rest. Customer-managed KMS keys may fit the central-control requirement, with carefully designed key policies and grants that let the workload decrypt only what it needs. Secrets should be retrieved at runtime from an appropriate managed secret store rather than embedded in application packages. Central logging and security findings should be delivered to an account controlled by the security team so workload administrators cannot easily erase evidence.

The cheapest architecture that uses a public endpoint plus an allow list may be disqualified immediately because the scenario requires private connectivity. A complex multi-Region design may also be unnecessary if no regional recovery objective is stated. Again, disqualifiers come before optimization.

Scenario 3: A bursty document-processing pipeline

A media company receives large batches of documents at unpredictable times. Each document must be analyzed, enriched, and written to durable storage. Processing may take several minutes per item. Ingestion should remain available even when processing slows, jobs can be retried safely, and the company wants to pay little when no documents are arriving.

This is a rate-decoupling problem. An object upload can generate an event that places work onto a durable queue. Workers can scale independently based on backlog. Depending on execution characteristics, Lambda, ECS on Fargate, AWS Batch, or another managed compute option could process the jobs. The correct choice depends on runtime length, resource needs, packaging, concurrency, and operational preferences.

Idempotency is essential because retries can produce duplicate processing attempts. The workflow should record a stable job identifier and prevent duplicate side effects. A dead-letter path can isolate jobs that repeatedly fail. Queue age and backlog become important health metrics. Durable object storage retains source and result data, and lifecycle policies can move older artifacts to lower-cost storage classes when access declines.

Notice how reliability, performance, and cost reinforce each other. Buffering protects the processor, elastic workers absorb bursts, and scale-to-demand behavior reduces idle cost. A synchronous API that holds a connection open until every document finishes would couple user experience to processing time and would be a weaker fit for the stated requirements.

Scenario 4: A low-latency read-heavy product service

A product-catalog service serves millions of read requests, while updates are relatively infrequent. The business needs consistently low read latency during peaks and can tolerate a short delay before every reader sees the newest product description. The existing relational database is becoming overloaded by repeated identical reads.

The key clue is the asymmetry between reads and writes plus tolerance for bounded staleness. Caching can remove repeated reads from the database. Depending on the access path, CloudFront may cache public HTTP responses at the edge, while ElastiCache can serve application-level data closer to the compute tier. Read replicas may also increase read capacity if the relational model remains appropriate.

The cache design needs expiration and failure behavior. What is the time-to-live? How are important updates invalidated? Can the application fall back to the database if the cache is unavailable? Will a sudden cache flush create a thundering herd against the origin? A professional answer considers those questions rather than simply saying ‘add cache.’

If the access pattern is actually a simple key lookup at massive scale and the relational features are not used, a purpose-built NoSQL design might be worth evaluating. But a database migration is a larger architectural change than inserting a cache. The exam question will tell you whether the goal is immediate relief with minimal change or a new architecture optimized for the access pattern.

Recognize distractors that are technically valid but architecturally weak

SAP-C02 distractors often solve part of the problem. One answer may improve availability but violate cost. Another may meet performance but create an unnecessary public exposure. Another may automate deployment but provide no rollback. Another may add a second Region even though the requirement is only an Availability Zone failure. These answers are difficult because they are not nonsense; they are incomplete.

Watch for overbroad trust. Broad CIDR ranges, wildcard IAM permissions, shared administrator credentials, and unnecessary public endpoints often conflict with least-privilege requirements. Watch for operationally heavy answers when the scenario emphasizes managed services or minimal administration. Watch for synchronous coupling when the workload is bursty and can be asynchronous. Watch for backup-only designs when the RPO is shorter than the backup interval.

Also watch for solutions that ignore data behavior. A read replica does not fix write contention. Auto Scaling EC2 instances does not fix a single hot partition. CloudFront does not accelerate a private database protocol. Cross-Region read replicas do not automatically provide application failover. The strongest answer addresses the actual bottleneck and includes the surrounding control needed to make the pattern work.

Use a repeatable reasoning sequence on exam scenarios

A disciplined sequence reduces cognitive load. First, identify the business outcome. Second, extract hard constraints: availability scope, RTO, RPO, latency, throughput, compliance, public/private exposure, ownership, and budget. Third, identify the existing state and what can or cannot change. Fourth, classify the dominant architecture problem: deployment, continuity, security, reliability, performance, cost, or a combination.

Fifth, eliminate answers that violate a hard constraint. Sixth, compare the survivors by operational burden, blast radius, reversibility, scalability, and cost. Seventh, test the preferred answer against failure: what happens if an AZ disappears, a dependency throttles, a deployment fails, a credential is compromised, or demand doubles? Eighth, verify that the design can be operated and observed.

This sequence is faster than memorizing hundreds of keyword-to-service mappings because it uses the same reasoning across different topics. It also protects you from shiny-feature distractors. The service name should make sense only after the problem has been classified.

Practice architecture changes, not static architecture recognition

The best preparation exercise for new-solution design is to take one architecture and change one requirement at a time. Start with a regional web application. Then add a five-minute RTO. Add a strict RPO. Add a private partner. Add unpredictable traffic. Add a data-residency rule. Add a requirement to minimize operations. Add a cost ceiling. Each change should force you to revisit only the parts of the architecture that the new constraint affects.

When you need additional variants, use the practical SAP-C02 scenario-drills guide as raw material and write down why each changed constraint causes a different design. If you move from one Region to two, explain the data and routing consequences. If you replace synchronous work with a queue, explain the consistency and retry consequences. If you choose a managed service, explain which operational tasks disappear and which responsibilities remain.

Avoid rehearsing the same solved question until the answer feels obvious. That tests recognition, not architecture judgment. Build variants where two answers remain plausible and the winner changes because one constraint changes. Those comparisons develop the exact skill the professional exam is trying to measure.

Create decision tables for the six Domain 2 tasks

For deployment, record release pattern, rollback mechanism, infrastructure repeatability, configuration control, and operational effort. For continuity, record failure scope, RTO, RPO, data replication, backup, failover trigger, and recovery testing. For security, record trust boundaries, identity, network reachability, encryption, key ownership, secret management, patching, and evidence retention.

For reliability, record redundancy, decoupling, retry behavior, idempotency, scaling, quotas, health checks, and dependency failure. For performance, record access patterns, latency budget, throughput, caching, buffering, replicas, data locality, and the actual bottleneck. For cost, record utilization shape, pricing model, storage lifecycle, data transfer, managed-service trade-offs, and how spend will be measured after launch.

The table should include ‘reject when’ conditions, not only ‘use when.’ Knowing why you would reject an architecture is often more valuable on SAP-C02 than knowing one situation where it works. A professional architect is expected to compare alternatives, not merely recognize valid services.

Connect new-solution design to the rest of SAP-C02

Domain boundaries are study aids, not architecture walls. A new solution deployed into an enterprise must fit organizational complexity: account structures, shared networking, identity, and governance. Once it is running, the same workload becomes a continuous-improvement problem involving operational excellence, security posture, performance, and reliability. If it replaces an existing system, migration and modernization constraints may shape the deployment sequence.

That is why deep study of Domain 2 should reinforce the other domains instead of competing with them. A decision about a new database can later affect migration strategy. A new account boundary can affect cost allocation and incident response. A private network design can affect how an on-premises workload is migrated. A deployment pipeline becomes part of operational improvement after launch.

If your study notes isolate every topic, deliberately add cross-domain questions. For each architecture, ask what changes if it belongs to a large multi-account enterprise, what must be monitored after launch, and how you would migrate an existing workload into the design. Those questions make the knowledge transferable.

Final readiness checklist for new-solution design

Before considering this domain ready, you should be able to take an unfamiliar scenario and produce a short requirement sheet before naming services. You should be able to distinguish RTO from RPO, high availability from disaster recovery, network reachability from authorization, scaling from buffering, caching from replication, and managed-service convenience from actual business fit.

You should be able to explain why a deployment can roll back, how a workload behaves when one dependency fails, where credentials come from, who can decrypt sensitive data, what metric triggers scaling, which component is the performance bottleneck, where major data-transfer charges can occur, and which assumptions should be validated with a load or recovery test.

Most importantly, you should be able to defend trade-offs. A good professional-level answer sounds like this: ‘This design meets the five-minute RTO because the standby environment is already running and data is continuously replicated; it costs more than backup and restore, but the stricter recovery requirement justifies that cost. We avoid active/active because the scenario does not require near-zero interruption and the additional consistency and operational complexity are unnecessary.’ That reasoning is more valuable than a memorized list of AWS services.

Use the broader SAP-C02 study plan to place this domain in your remaining preparation time, then keep practicing decisions until you can change an architecture confidently when the requirements change. New-solution design is not about inventing the most elaborate cloud diagram. It is about turning constraints into a system whose deployment, security, failure behavior, performance, and cost can all be explained before production makes those decisions expensive to undo.