AWS Exam Scenario Workshop

TL;DR

• The method is identical across SAP-C02 exams, whiteboard interviews, and real design reviews: anchor on explicit requirements, eliminate options that violate constraints, name the trade-offs explicitly, and choose the simplest design that satisfies everything asked.
• Multiple technically-valid AWS architectures are deliberate distractors; the correct answer is the simplest one that meets every stated requirement, not the most impressive-sounding one.
• Ambiguity handling (asking clarifying questions, stating assumptions before designing) is the proxy for real-world design judgment—guessing silently and charging ahead reveals the same weakness in high-stakes reviews.
• Senior judgment is measured not by service names recited, but by whether every technical choice is explicitly anchored to a stated requirement or constraint, and what was rejected and why.
• Design reviews live or die on whether a service choice is justified by concrete requirements or justified by popularity; “because everyone uses it” is exactly the anti-pattern this track has taught against.

Core Concepts

Complex SAP-C02 Scenarios

The exam deliberately includes multiple technically-valid architectures among answer choices. The skill being tested is not “name AWS services,” but “can you match a design to a stated requirement without over- or under-engineering it.” When three of four options are technically workable, the correct answer is almost always the simplest option that satisfies every stated requirement. An option that adds redundancy, complexity, or capability the scenario never asked for is a classic distractor, engineered to catch candidates who reach for impressive-sounding architecture instead of requirement-matched architecture.

Whiteboarding and Handling Ambiguity

Whiteboarding tests something distinct from service knowledge: how a candidate handles ambiguous, under-specified requirements. Real requirements almost always are under-specified; the skill separates candidates who ask clarifying questions and state explicit assumptions before designing from those who silently guess and charge ahead. This is not a soft skill—it is a direct proxy for how that person will behave in actual, higher-stakes design reviews where an unstated wrong assumption costs real time and money. A candidate who demonstrates this habit in an interview will exhibit it in production design work.

Design Reviews and Requirement Anchoring

Real design reviews live or die on whether a proposed architecture is justified against an actual requirement or justified by popularity, familiarity, or confident presentation. “Let’s use Kubernetes, it’s what everyone uses” with no connection to a stated requirement is exactly the anti-pattern every module in this track has been building the instinct to catch. The correct reviewer response is to ask what specific requirement the more complex option satisfies that a simpler one doesn’t, not to accept it because it was said with conviction. Service choice justified by requirement is fundamentally different from service choice justified by reputation.

Trade-Off Analysis

Trade-off analysis is the actual differentiator between a design that survives scrutiny and one that only sounds confident. A design presented with its trade-offs and rejected alternatives documented has demonstrably been through real analysis. A design presented as simply “the right way to do it,” with no alternatives acknowledged, has not—regardless of how senior or confident the person presenting it sounds. A design with documented trade-offs and rejected alternatives is more trustworthy than the most confidently-presented design without acknowledgment of cost or alternatives.

Requirement Anchoring as the Central Habit

Senior and principal-level judgment is not measured by how many service names someone can recite. It is measured by whether every technical choice is explicitly anchored to a stated requirement or constraint, and whether that person can explain what they rejected and why. A candidate who says “I’d use DynamoDB here because the access pattern is single-key lookups at high scale, and I rejected Aurora because we don’t need relational joins for this specific workload” has demonstrated actual skill. A candidate who says “DynamoDB is what I always use for scale” has demonstrated pattern-matching, not judgment. This distinction is foundational to senior engineering judgment across all 38 modules of this track.

Design Review Method (Step-by-Step)

1. Identify the explicit, non-negotiable requirement driver before evaluating any option — latency, compliance, cost ceiling, RTO/RPO, team capability.
2. Eliminate any option that violates a stated constraint, regardless of how elegant it otherwise is.
3. Among what’s left, name the real trade-offs of each remaining option explicitly — do not let the most familiar or most impressive-sounding one win by default.
4. Choose the simplest design that satisfies every stated requirement — added complexity needs to justify itself against a real requirement, not against “best practice” in the abstract.
5. Document the decision, the rejected alternatives, and why — so the next person reviewing this does not have to reconstruct the reasoning from nothing.

Common Pitfalls

• Pitfall: Picking the most feature-rich or most complex-sounding answer when the simplest option that satisfies every stated requirement was available and correct. Why: tendency to conflate complexity with thoroughness or to assume more capability is always better. Fix: Always evaluate against the explicit requirement first; eliminate what doesn’t satisfy it, then choose the simplest survivor.
• Pitfall: Charging ahead on an ambiguous requirement without stating assumptions, then designing against the wrong interpretation entirely. Why: skipping the clarification step feels faster but produces designs that solve the wrong problem. Fix: Ask clarifying questions and state explicit assumptions before designing; document assumptions so they can be verified.
• Pitfall: Justifying a service choice by popularity or personal familiarity instead of connecting it to what the scenario or business actually needs. Why: pattern-matching feels efficient but detaches the choice from the problem being solved. Fix: Connect every service choice to a stated requirement; be able to explain what that service satisfies that an alternative does not.
• Pitfall: Presenting a design with total confidence and zero acknowledged trade-offs, which reads as thorough but is actually a sign the trade-off analysis was skipped. Why: confidence without caveats can be compelling, but it masks insufficient analysis. Fix: Always articulate the trade-offs of the design chosen, what could have been chosen instead, and why the choice is optimal for the stated requirements.

Interview Questions

• “Walk me through how you’d approach a design scenario where the requirements are deliberately incomplete.” — tests whether they ask clarifying questions and state assumptions, or guess silently.
• “Present two competing designs for the same problem, and defend which one you’d actually ship.” — tests whether they can articulate real trade-offs for both, not just advocate for a favorite.
• “When an option is technically valid but sounds unfamiliar, how do you decide whether it belongs in your design?” — tests whether they anchor to requirements or rely on familiarity.
• “What’s the difference between a senior engineer’s answer and a mid-level engineer’s answer to the same technical question?” — tests whether they have internalized requirement-anchored reasoning as a practiced habit, not just a phrase they know to say.