Lesson 347 · AWS Learning Path

AWS 347: SAP-C02 final readiness review

Anil Jalela · Published Jun 7, 2026 · 7 min read

Why this checkpoint matters

Booking an exam because a course is finished is not an evidence-based decision. Professional certification readiness combines current blueprint coverage, architecture reasoning, practical evidence, timed performance, confidence calibration, safety, and the ability to explain service boundaries under challenge.

This lesson is a final board, not another quiz. It produces one of three outcomes: ready for the scheduled exam version, conditionally ready after bounded remediation, or not ready. No score is allowed to hide a critical practical or safety gap.

Confirm the exam version first

As of September 23, 2026, AWS states that registration for SAP-C03 opens October 27, 2026 and that the final SAP-C02 testing date is in November 2026. Confirm the exact date, language, delivery option, current exam guide, and policies on the official AWS Certification pages before making a booking decision.

This course preserves its established SAP-C02 URL and checkpoint title. If you schedule SAP-C03, perform a new guide-to-evidence mapping and remediate every newly introduced or materially changed objective. Do not assume that a SAP-C02 score predicts SAP-C03 readiness.

What readiness means

Readiness is the intersection of five proofs:

current objective coverage
        + architecture reasoning
        + implementation/failure evidence
        + timed decision performance
        + safe professional behavior
        = defensible booking decision

A learner can pass practice questions by recognizing wording while being unable to design or operate the solution. Another learner may be a strong operator but lose points through pacing and requirement extraction. The board measures both.

Required evidence pack

Bring these artifacts before the review begins:

1. The official exam guide for the exact scheduled version and retrieval date.
2. Objective-to-lesson and objective-to-artifact map.
3. Two independent full-length timed simulations, including item-level results.
4. AWS346 attempt log, confidence ratings, rationales, and changed retest.
5. AWS335/AWS341 enterprise capstone and correction record.
6. AWS336/AWS342 migration/DR capstone and clocked recovery evidence.
7. At least six practical build/test/cleanup records across identity, network, compute, storage/data, observability/automation, and resilience.
8. Architecture decision records showing rejected alternatives.
9. Weak-topic remediation log with spaced retest dates.
10. Exam logistics, accommodations if applicable, identification, and contingency plan.

If an artifact is unavailable, mark it missing. Do not replace observed work with a retrospective claim.

Step 1: objective coverage audit

Copy each task statement from the current official guide into a ledger. Do not rely on remembered domain names. For every statement record:

The domain percentage is not the average of optimistic self-ratings. Weight each task by the current guide and use the lowest supported level when evidence conflicts. A high overall average cannot compensate for zero evidence in a major task.

Step 2: service-boundary oral board

A reviewer chooses at least 12 pairs. In three minutes per pair, state common purpose, decisive differences, hidden ownership, failure behavior, cost drivers, rejection conditions, and one changed requirement that reverses your choice.

Required pool:

• ALB, NLB, API Gateway, CloudFront, and Global Accelerator;
• security groups, network ACLs, AWS Network Firewall, WAF, and Shield;
• VPC peering, Transit Gateway, Cloud WAN, PrivateLink, and VPC Lattice;
• S3, EBS, EFS, FSx, instance store, and Backup;
• RDS Multi-AZ, read replicas, Aurora, DynamoDB, ElastiCache, and Redshift;
• SQS, SNS, EventBridge, Kinesis, Amazon MQ, and MSK;
• Lambda, ECS, EKS, EC2 Auto Scaling, Batch, and Step Functions;
• IAM policies, resource policies, SCPs, RCPs, permissions boundaries, and session policies;
• CloudTrail, Config, CloudWatch, GuardDuty, Security Hub, and Detective;
• MGN, DRS, DMS, DataSync, Transfer Family, and migration strategies;
• Route 53 routing, ARC, Global Accelerator, and application-level fencing;
• Savings Plans, Reserved Instances, Spot, allocation, budgets, and anomaly detection.

Answers that merely expand acronyms score zero. The learner must identify the requirement that decides.

Step 3: architecture change challenges

The board chooses six capstone assumptions and changes them without warning. Examples:

1. Residency now includes logs, backups, model inputs, and support access.
2. RPO changes from one hour to five minutes while budget remains fixed.
3. A central network dependency is prohibited for critical traffic.
4. The identity provider is unavailable during incident response.
5. A target database cannot preserve a required transaction behavior.
6. Cutover rollback is requested after target-side writes begin.
7. Peak traffic increases tenfold for one hour.
8. The organization acquires accounts with overlapping CIDRs.

For each, identify affected requirements, diagrams, controls, costs, owners, tests, and approval. Change the decision when the evidence requires it. Defending an obsolete decision more confidently is not professional reasoning.

Step 4: practical evidence review

Randomly select six practical records. Each must prove:

• authorized scope and cost/safety boundary;
• initial state and exact commands or configuration;
• positive test and expected evidence;
• negative or denied-path test;
• injected failure and diagnosis from evidence;
• recovery or rollback;
• cleanup and billing verification;
• explanation of what the test does not prove.

Examples include an IAM trust/permission diagnosis, routed two-way VPC flow, EBS snapshot/restore, S3 policy/encryption/version recovery, Auto Scaling replacement, database restore/failover, queue retry/DLQ handling, CloudFormation change/drift, or monitoring alarm/notification chain.

Automatic failure applies if credentials are exposed, destructive commands lack scope and recovery, cleanup is unproved for billable labs, or fabricated output is presented as observed.

Step 5: timed-performance audit

For each full simulation calculate:

• overall and domain score;
• single-response and multiple-response accuracy;
• answered, unanswered, flagged, and changed counts;
• average time plus slowest ten items;
• confidence calibration: high-confidence correct and high-confidence wrong;
• error categories: knowledge, extraction, scope, reasoning, assumption, pacing, or confidence;
• repeated weak concepts across attempts.

Use independent and changed questions. Repeating the same question bank measures memory as well as competence. Read every explanation, including correct guesses.

Minimum local gate:

• two full simulations at or above 80 percent under current timing;
• no domain below 75 percent;
• multiple-response accuracy at or above 75 percent;
• no unanswered items caused by pacing;
• every high-confidence error explained and changed-retested;
• scores are stable rather than one isolated peak.

These local thresholds are preparation gates, not AWS scaled scores or guarantees.

Step 6: safety and professional judgment

The learner must explain how to handle ambiguous authorization, unknown production state, risky data movement, missing rollback, unsupported recovery claims, and pressure to bypass review. Passing requires all of these behaviors:

• stop when authority or blast radius is unclear;
• preserve evidence and avoid exposing secrets/customer data;
• distinguish read-only diagnosis from mutation;
• back up and define rollback before reversible change;
• require an authorized risk owner for exceptions;
• report uncertainty and failed tests honestly;
• never reproduce or request protected exam content.

Readiness matrix

Score each dimension from 0 to 4 using actual evidence.

Normalize the weighted score to 100. Ready requires at least 80, every mandatory minimum, and no blocking condition. Conditional readiness is permitted only when the score is at least 75 and all remaining gaps can be retested before the booking decision. Otherwise, mark not ready.

Blocking conditions

Do not approve booking while any condition remains:

• exam version or objective map is uncertain;
• only one full timed simulation exists;
• a domain remains below threshold twice;
• capstone has unresolved critical findings;
• RTO/RPO, authorization, or cost claims lack evidence;
• the learner cannot explain authoritative data and rollback after writes;
• practical cleanup/safety evidence is missing;
• confidence remains poorly calibrated;
• identification, delivery environment, or accommodation requirements are unresolved.

Remediation contract

Every gap becomes a small contract: exact skill, evidence of weakness, source to study, practical or diagram artifact, two changed questions, owner, target date, retest date, and pass threshold. Limit concurrent remediation themes so learning becomes deep rather than scattered.

Use spacing: understand the boundary, build or trace it, explain it aloud, answer changed scenarios later, then retest under time pressure. Close a gap only when new evidence meets its acceptance criterion.

Final decision record

Record scheduled version, evidence dates, weighted score, simulation results, blocking-condition status, remaining risks, board members, and one decision:

• Ready to schedule or sit the exact version.
• Conditionally ready; do not book until listed gates pass.
• Not ready; continue the dated remediation plan.

Certification is a checkpoint, not an endpoint. After the exam, preserve weak-topic learning, continue production-safe labs, review changing AWS services, and seek architecture feedback from real stakeholders.

Official sources

• AWS Certified Solutions Architect - Professional
• AWS Certification exam preparation
• AWS Certification policies
• AWS Well-Architected Framework