Lesson 337 · AWS Learning Path

AWS 337: Final SAP-C02 readiness review

Anil Jalela · Published May 28, 2026 · 7 min read

Why this lesson matters

One high practice score does not prove architecture or exam readiness. A candidate can guess correctly, memorize wording, avoid weak domains, or recognize repeated questions. Professional readiness also requires safe practical work, explanation, troubleshooting, evidence, cost awareness, and honest uncertainty.

This review triangulates exam performance, changed scenarios, architecture artifacts, practical evidence, service-boundary explanations, and capstone defense. It produces Ready, Ready with scheduled remediation, or Defer and retest, never a motivational pass unsupported by evidence.

As of this review, AWS states SAP-C02's last test date is November 17, 2026, with SAP-C03 registration opening October 27. Verify the official page before making a booking decision.

Learning outcomes

By the end, you can:

• build a four-domain/task readiness matrix;
• distinguish coverage, score, confidence, and demonstrated skill;
• audit practical and architecture evidence for completeness;
• test service boundaries through oral and changed-scenario defense;
• prioritize gaps by consequence and recurrence;
• remediate with first-party sources and safe evidence;
• make a documented booking/defer decision;
• prepare a final study, logistics, and post-certification growth plan.

1. Evidence hierarchy

Require several independent evidence types. Correct answers with weak explanation remain a gap.

2. Exam-version gate

Before scoring readiness, record target exam code, booking deadline, current exam guide version/date, official duration/question format, available language, delivery method, and transition notice. If the intended appointment falls after the SAP-C02 retirement date, prepare to the published SAP-C03 guide when available rather than assuming identical domains.

Do not let urgency force an unsupported booking. Certification remains useful only when it reflects durable skill.

3. Domain and task matrix

Create one row per official task statement under:

• Domain 1, Design Solutions for Organizational Complexity;
• Domain 2, Design for New Solutions;
• Domain 3, Continuous Improvement for Existing Solutions;
• Domain 4, Accelerate Workload Migration and Modernization.

For every task capture:

coverage count
timed accuracy and confidence
changed-retest result
architecture artifact
lab or evidence artifact
oral explanation status
recurring error cause
current rating
remediation owner/date

Use ratings:

• Proven: multiple independent sources, including changed application;
• Developing: partial evidence or inconsistent results;
• Unproven: missing coverage/evidence;
• Incorrect: demonstrated misconception requiring remediation.

Do not average an untested task into a pass.

4. Timed-practice audit

Review at least two independent 75-question simulations from AWS334. Compare overall/domain/task accuracy, confidence calibration, time checkpoints, multiple-response performance, guesses, harmful answer changes, and root-cause trends.

Priority order:

1. high-confidence wrong answers;
2. repeated misconception across different scenarios;
3. hard requirement/security/recovery mistakes;
4. untested task or service boundary;
5. time-driven misses;
6. isolated low-confidence knowledge miss.

Never translate local raw percentages into an AWS scaled score. Define internal readiness thresholds before seeing results and require stability, not one peak.

5. Practical evidence audit

Sample cumulative labs across identity, network, compute/Auto Scaling/load balancing, S3/storage, databases, serverless/integration, monitoring/security, backup/DR, migration, multi-account governance, and cost.

Every accepted lab should show:

• prerequisite and ownership boundary;
• build or supplied-evidence path;
• expected positive behavior;
• denied/negative test;
• injected failure and diagnosis;
• rollback/recovery;
• monitoring and security evidence;
• cost tier and cleanup verification;
• explanation in the learner's own words.

A screenshot without command/configuration context and interpretation is insufficient. A successful create operation does not prove failure recovery or cleanup.

6. Architecture portfolio audit

Review requirements, diagrams, ADRs, threat models, reliability plans, cost models, operating models, migration plans, and capstones. Check traceability:

requirement -> decision -> component/control -> test -> evidence -> owner

Use AWS335 and AWS336 as synthesis gates. Ask whether the learner can explain why the selected design is preferable, what it costs, how it fails, who operates it, how data is recovered, what was rejected, and which assumption would reverse the decision.

7. Service-boundary oral board

Run a 60-minute oral board with no notes for the first answer, then allow official documentation for correction. Ask contrasts such as:

• SCP versus IAM/resource/KMS policies;
• security group versus network ACL versus route;
• Multi-AZ versus read replica versus backup versus multi-Region DR;
• ALB versus NLB versus GWLB;
• SQS versus SNS versus EventBridge versus Step Functions;
• RDS/Aurora versus DynamoDB versus Redshift;
• Savings Plans versus Reserved Instances versus Capacity Reservations versus Spot;
• MGN versus DRS versus DMS versus DataSync;
• Route 53 versus CloudFront versus Global Accelerator;
• CloudTrail versus Config versus CloudWatch versus security findings.

For each, require purpose, scope, key behavior, failure, cost driver, and rejection case. “They are all for security” or acronym recall does not pass.

8. Architecture challenge board

Give five changed scenarios:

1. overlapping-CIDR acquisition with regulated data;
2. queue backlog threatening a database;
3. accidental deletion despite Multi-AZ;
4. post-cutover target writes followed by failure;
5. multi-account preventive control with emergency exception.

The learner has five minutes each to identify requirements, draw flow, compare options, select, state failure/cost/owner, and cite validation. Change one constraint and require re-evaluation.

9. Safety and professional behavior

Readiness requires that the learner:

• never uses root for daily work or shares credentials;
• resolves account/Region/resource ownership before mutation;
• understands billed dependencies and cleanup order;
• treats destructive commands visibly and uses backups/rollback;
• redacts account/customer/internal data;
• distinguishes read-only evidence from proof of behavior;
• states uncertainty and consults current official documentation;
• does not use exam dumps or disclose live questions.

An unsafe candidate is not ready even with a high test score.

10. Gap register and remediation

Each gap contains evidence, impact, cause, corrective activity, owner, due date, changed retest, and closure. Match work to cause:

• service knowledge: first-party reading plus contrast and safe lab;
• requirement extraction: constraint-led original scenarios;
• architecture integration: diagram/ADR and review;
• troubleshooting: evidence pack and failure injection;
• practical gap: build/test/recover/cleanup exercise;
• time: timed micro-sets and flagging discipline;
• communication: oral defense and stakeholder summary.

Do not solve every gap by watching another broad course.

11. Readiness decision

Example decision gates:

Ready means every mandatory gate passes. Ready with scheduled remediation permits only noncritical improvements that do not threaten exam or practical competence. Defer and retest applies when any mandatory gate fails. Record reviewer and candidate signatures or explicit digital approval.

12. Booking and logistics

After a Ready decision, verify official account name/ID requirements, appointment timezone, delivery method, language, accommodation, reschedule policy, check-in, system test, room rules, travel, and contingency. Use current AWS/Pearson information, not copied course screenshots.

Plan rest and light review; do not schedule a last-minute flood of new services. Protect exam confidentiality afterward.

13. Post-certification growth

Certification is a checkpoint, not expert status. Maintain a quarterly plan for production-like labs, architecture reviews, incident analysis, cost optimization, security, current service/lifecycle changes, and mentoring. Preserve expiring cleanup evidence and never maintain costly labs without purpose.

14. Read-only account hygiene snapshot

aws sts get-caller-identity --query Arn --output text
aws resourcegroupstaggingapi get-resources --resources-per-page 50 --output json
aws cloudwatch describe-alarms --state-value ALARM --output table
aws backup list-backup-jobs --by-state FAILED --max-results 20 --output table

These are scope-limited indicators. They cannot prove an account is empty or secure. Use service inventories and billing evidence from earlier cleanup lessons.

15. Required submission

Submit:

1. exam-version verification;
2. complete domain/task matrix;
3. two-simulation comparison;
4. confidence/time/error analysis;
5. practical evidence index;
6. architecture portfolio traceability audit;
7. AWS335 defense record;
8. AWS336 defense record;
9. ten service-boundary explanations;
10. five changed architecture challenges;
11. safety/ethics audit;
12. prioritized gap register;
13. completed remediation and changed retests;
14. readiness board minutes;
15. signed decision and conditions;
16. booking/logistics checklist;
17. final study plan;
18. 90-day post-certification growth plan.

Cost and cleanup

This lesson creates no AWS resources. Exam purchase occurs only after the learner accepts the fee and readiness decision. Do not purchase, reschedule, or access external accounts on the learner's behalf.

Knowledge check

1. Does one high score prove readiness? No; require independent, practical, and transferable evidence.
2. What is the highest-priority miss? A repeated high-confidence misconception or unsafe boundary error.
3. Can an untested task be averaged into a pass? No; it remains unproven.
4. What does an oral board add? Evidence of service-boundary understanding and communication.
5. When should booking be deferred? When any mandatory readiness or safety gate fails.

Lesson acceptance

All 18 artifacts and mandatory gates must pass. Any untested critical task, recurring misconception, unsafe practical behavior, failed capstone defense, or unstable timed performance results in Defer and retest with owned remediation.

Official sources

• AWS Solutions Architect Professional certification
• SAP-C02 exam guide
• SAP-C02 in-scope services
• AWS Certification exam preparation
• AWS Certification policies
• AWS Well-Architected Framework