AWS Certified Solutions Architect – Professional is changing exam versions in November 2026. As of October 24, SAP-C02 remains the current test, and AWS identifies November 16 as its last testing day. Registration for SAP-C03 opens October 27; the updated version follows on November 17. Candidates should not describe SAP-C02 as retired before the final date or assume that an SAP-C02-only training programme is complete preparation for SAP-C03. Those timing and coverage questions are distinct from the enduring engineering skills a professional cloud architect needs.
The professional-level challenge is not whether someone recognizes a service name. It is whether that person can choose a workable architecture under competing security, cost, reliability, migration and operational constraints. A design can be secure but impossible to operate, resilient but financially irresponsible, or efficient for one region while violating a data-residency obligation in another. Good architecture starts with explicit trade-offs that can be tested against realistic failure scenarios.
Decide what the workload must protect and recover
Begin with service objectives. How much downtime is tolerable? What data loss can the business accept? Which transactions must remain auditable? An availability target and a recovery time objective influence whether the workload needs multi-AZ protection, regional failover or a more specialized active-active design. These choices have dramatically different operational costs. A second region is not automatically useful if it cannot authenticate users, decrypt backups or resolve private DNS during the primary outage.
Document the system of record and state transitions. A stateless web tier can scale independently, but orders and payments are not stateless. Replication may introduce lag, conflicts or application requirements for read/write ownership. A database failover test should include application reconnection, idempotent retries and the handling of transactions that were acknowledged just before failure. Otherwise a recovery diagram promises far more than the workload can actually deliver.
Define the boundaries between high availability and disaster recovery. Redundant instances in one region reduce local infrastructure failures; they do not satisfy a plan for region loss. Conversely, a geographically distributed architecture can still fail because of a shared identity dependency or mistaken deployment. Challenge common-mode failures, not only hardware failures.
Structure multi-account security deliberately
Large AWS estates benefit from clear account ownership, organizational controls and distinct workload identities. A production application team may need permission to deploy its service but not to change organization-wide logging or billing controls. A security analyst may need read-only access to audit evidence without gaining rights to alter it. Document how resource and identity policies interact in cross-account data access; an apparently harmless trust relationship can create an unintended escalation path.
Design for evidence during an incident. If a role is compromised, which events reveal the assumption of that role, the actions it took and the affected resources? Are logs protected in an account with separate administration? Can a responder contain the identity without losing access to all critical deployment or recovery functions? Auditable emergency paths help teams respond without relying on uncontrolled administrator accounts.
Encryption should follow classification and operational requirements. A key policy that prevents an application from restoring data after a controlled failover is a reliability defect, while broadly accessible decryption is a security defect. Test both unauthorized denial and necessary recovery access using the identities that would actually perform the task.
Understand where the network sends traffic
A multi-account or hybrid network can become difficult to reason about when many VPCs, Transit Gateway attachments, private endpoints and VPN connections interact. Draw traffic flows from user to application, application to data and operational tools to management endpoints. Include both outbound and return paths, DNS resolution and identity checks. If central inspection is required, validate that routing cannot bypass it through a backup or cross-region path.
An enterprise may have overlapping CIDR ranges inherited from acquisitions or historic network choices. A connection that works in a slide deck will not solve overlapping address space automatically. Consider translation, staged renumbering, service boundaries and application-level integration based on constraints, then record the long-term cost of the workaround. A temporary networking exception can become a permanent security blind spot unless someone owns it.
Evaluate latency and cost as network architecture properties. Cross-region calls can add user-visible delay and ongoing data-transfer charges. A centralized firewall can reduce policy duplication while adding traffic dependencies. High availability of the inspection tier matters only if the routes and health-check behavior support it during a partial failure.
Select services by contract, not popularity
A managed service removes some infrastructure operations but does not remove data modelling, authorization or recovery obligations. For databases, decide access patterns, transaction needs, scale limits and recovery options before making a product selection. For messaging, consider delivery guarantees, order requirements, poison messages and what an application does after a retry. For caching, decide when stale data can be served and how invalidation is handled. The distinction between service features and application guarantees should be explicit.
A complicated business workflow may need multiple services, but more components can create harder incident diagnosis. Minimize unnecessary hops and avoid adding asynchronous orchestration simply because it looks cloud-native. A direct synchronous call can be reasonable when the user must receive a definitive answer and the dependency is reliable enough; an event queue is valuable when the process can tolerate delayed completion and needs buffering. Choose based on failure semantics.
Modern workloads may integrate generative-AI capabilities, and AWS’s updated professional exam acknowledges changing architectural scope. Yet an AI component is still subject to data classification, access boundaries, evaluation, monitoring and cost controls. Do not treat a model endpoint as an exemption from security review or as a substitute for predictable business logic when deterministic behavior is required.
Design migrations around reversibility and evidence
Migrations fail when they are treated only as data-copying exercises. Inventory interfaces, dependencies, operational ownership, encryption keys and recovery objectives before choosing a transfer technique. Decide whether the migration uses a long coexistence period, dual writes, change-data capture or a scheduled cutover. Each method carries consistency and complexity risks. A plan should show how the team will detect divergence and which system remains authoritative at each stage.
Practice a cutover with real operational constraints. Can the team revert traffic after a partial migration without duplicating transactions? Have background jobs, certificates, DNS, logs and secrets been moved too? Does a read-only transition change business behavior? The test is not complete when the new environment starts; it is complete when user transactions reconcile and the fallback path is understood.
Infrastructure-as-code and repeatable pipelines support safer migration, but a successful deployment does not guarantee application correctness. Use smoke tests, synthetic transactions and monitored business outcomes. Preserve a baseline and record the exact version of changes so a failed release can be investigated without guessing what happened.
Make cost optimization an architectural review
Cost discussions should separate baseline capacity, demand variability, storage growth, data transfer, operational labor and recovery needs. A cheaper instance family may not be an improvement if it increases latency and drives customer churn. A serverless pattern may lower idle cost but become unexpectedly expensive under a retry loop. Model likely demand and worst-case failure conditions rather than comparing two nominal monthly price tags.
Cost allocation must support decisions. Tagging and account structure can help associate usage with teams, but shared networking and security platforms still need a clear chargeback or showback policy. Investigate idle capacity and inefficient transfer paths with the same care applied to performance issues. A savings proposal should specify how service-level objectives remain protected.
Prepare for SAP-C03 without losing the substance
The SAP-C03 transition reflects changing cloud-architecture responsibilities, including more cloud-native and AI-related design decisions. The official guide published for the new version should determine the final study map; avoid relying on an unsourced list of ‘new questions’ or assuming that the old SAP-C02 blueprint carries forward unchanged. For someone already fully prepared, the November 16 SAP-C02 endpoint may justify completing the existing examination, subject to actual appointment availability. Others should plan for the new version deliberately.
Useful labs span failures rather than product names. Simulate an unavailable dependency, an unauthorized cross-account request, a broken network return path and a migration rollback. For every scenario, state the intended business outcome, evidence that the design worked and the trade-off accepted. That process supports both exam preparation and professional architecture decisions long after SAP-C02 is historical.
One useful review exercise is to present two technically correct architecture options to an imaginary business owner. One favors lower routine cost with a longer recovery time; the other pays for regional redundancy and more complicated data reconciliation. Estimate the effect of a realistic traffic spike, region failure and service credential expiry on both. Explain where the weaker option still might be entirely suitable and where the stronger design could fail through a shared dependency. An architect who can make those trade-offs legible to decision-makers is doing more than memorizing the name of an AWS service.
Source note: AWS’s current Solutions Architect – Professional certification page announces SAP-C03 registration opening October 27, 2026 and SAP-C02’s last testing day November 16, 2026. This October 24 article makes no claim that future appointments are guaranteed.