Lesson 345 · AWS Learning Path

AWS 345: Stakeholder architecture review and defended trade-offs

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

Why this checkpoint matters

Architecture is a decision discipline practiced with people. Security, operations, finance, product, legal, data, and delivery teams see different risks. A professional architect must make a complex design understandable, reveal uncertainty, defend evidence, accept valid corrections, and leave the meeting with owned decisions rather than vague agreement.

This checkpoint is an oral board. You will prepare one of the AWS341-AWS344 designs, present it to role-playing stakeholders, answer unannounced challenges, correct the architecture, and produce a decision record. Presentation polish cannot compensate for missing evidence.

Outcomes

You will demonstrate that you can:

• frame a business decision before explaining technology;
• tailor one architecture to executive, security, operations, finance, and engineering concerns;
• distinguish fact, measured evidence, requirement, assumption, estimate, constraint, risk, and opinion;
• explain request, identity, data, failure, deployment, observability, and cost paths;
• compare viable alternatives on equivalent criteria;
• respond constructively when a reviewer disproves an assumption;
• convert review outcomes into findings, owners, acceptance tests, and approval conditions.

Review principles

The review is a blame-free examination of the workload, not an audit of an individual. The architect owns clarity, not infallibility. “I do not know; here is how we will prove it” is stronger than invented certainty.

Use these evidence labels on slides and diagrams:

Roles and decision rights

Use at least six participants. One person can play multiple roles only if they state which role is speaking.

• Business sponsor: outcomes, deadlines, customer impact, and residual business risk.
• Product owner: functional behavior, prioritization, and acceptance.
• Security/risk: identity, data, threats, evidence, incident response, and exceptions.
• Operations/SRE: observability, ownership, deployment, quotas, recovery, and toil.
• Finance/FinOps: demand assumptions, allocation, commitments, forecast, and value.
• Data/legal: authority, classification, residency, retention, deletion, and lineage.
• Delivery/application: implementation, contracts, testing, migration, and skills.
• Facilitator/timekeeper: agenda, challenge fairness, decisions, and parking lot.

Record who recommends, who decides, who accepts residual risk, who implements, and who operates. A RACI chart does not create authority unless the named people accept it.

Preparation package

Distribute a pre-read at least one review cycle before the session. It must include:

1. one-page business context and decision request;
2. scope, exclusions, constraints, and success measures;
3. requirement-to-decision traceability excerpt;
4. context, request/data, identity, deployment, failure, and operational views;
5. current versus target state and transition stages;
6. options considered, knockout criteria, weighted comparison, and sensitivity;
7. capacity, quota, performance, RTO/RPO, and cost assumptions;
8. threat/failure analysis, open findings, exceptions, and residual risks;
9. implementation, validation, rollback, recovery, and decommission plan;
10. explicit decisions and approvals requested from the board.

Every diagram needs title, scope, time/state, trust boundaries, Region/account/AZ boundaries, numbered flow, legend, owner, and version. Do not mix logical and deployment views without labeling the distinction.

The 75-minute review

Run this agenda with a visible clock:

Start with “The board must decide X because outcome Y is at risk by date Z.” Do not begin with service icons. Explain the normal request path in under three minutes, then show where identity, data, evidence, and failure paths differ.

Defending a trade-off

Use a repeatable seven-part answer:

1. Restate the requirement and priority.
2. Name the selected option.
3. Name at least one viable alternative.
4. Compare both using the same criteria and evidence.
5. State what the selected option makes worse or transfers to operators.
6. State assumptions and what evidence could reverse the decision.
7. Name owner, validation, and review trigger.

Example: “Regional active/passive was selected because residency and five-minute RPO are hard constraints. Active/active lowers recovery time but introduces write-conflict and operational complexity. The selected design accepts a longer observed failover target and requires tested capacity in the recovery Region. If the business approves globally writable semantics and funds continuous dual-region operation, the decision must be reopened.”

Avoid claiming a service is “best,” “serverless,” “fully managed,” “highly available,” “secure,” or “cost effective” without explaining the workload-specific consequence.

Unannounced challenge cards

The facilitator selects at least eight cards. The architect gets two minutes to clarify and five minutes to respond.

1. Legal changes one data class from regional processing to regional storage and processing.
2. Finance cuts steady-state budget by 25 percent but keeps recovery objectives.
3. The expected peak becomes ten times larger for one hour each month.
4. The identity provider fails during a privileged incident response.
5. A central network dependency loses one Availability Zone.
6. A service quota cannot be increased by the launch date.
7. Replication lag violates RPO during the recovery test.
8. The selected database cannot support one required consistency behavior.
9. An acquired business brings overlapping CIDRs and a separate security team.
10. A customer requests deletion while immutable retention applies to audit evidence.
11. The team cannot operate the chosen orchestration platform around the clock.
12. A cutover rollback is requested after transactions were accepted in the target.

For each, record impacted requirement, affected views, immediate decision, evidence needed, revised option or control, cost/schedule effect, owner, and acceptance test. “We will monitor it” is not a complete response.

Questions every panel must ask

Business and product

• What is the measurable outcome, and what happens if the date slips?
• Which requirement is hard, and which can be negotiated?
• What customer-visible behavior occurs during partial failure?
• Who accepts degraded operation and residual risk?

Security, data, and legal

• Who can assume each identity, and what constrains the resulting session?
• Where do plaintext, ciphertext, keys, backups, logs, and derived data travel?
• Who can alter or delete evidence?
• How are retention and deletion conflicts resolved by data class?

Operations and delivery

• Which team receives the first actionable signal at 03:00?
• What remains operational when the control plane or identity provider is unavailable?
• How is a failed deployment stopped, rolled back, or rolled forward?
• Which recovery claim has been measured end to end?

Finance and capacity

• Which quantities drive the bill, and who owns forecast variance?
• What is the unit metric and allocation policy?
• What costs occur only during migration, failure, retention, or recovery tests?
• Which commitment could become stranded?

Findings and decision closure

The scribe records every challenge as answered, finding, decision, action, or parking-lot item. A finding contains observation, evidence, affected requirement, consequence, likelihood, priority, owner, treatment, due date, acceptance criteria, and retest. Use AWS340 rather than closing findings in meeting notes.

Allowed outcomes:

• Approved: required evidence exists and no blocking finding remains.
• Conditionally approved: named conditions, owners, evidence, dates, and expiry are explicit.
• Rework required: material decisions or evidence remain incomplete.
• Rejected: the proposal cannot satisfy a hard requirement or risk boundary.

Silence is not approval. A sponsor cannot accept security, legal, or operational risk outside their authority.

Scoring rubric

Score 100 points: decision framing 10, requirement/evidence discipline 15, architectural coherence 15, trade-off defense 15, security/data/failure reasoning 15, operations/migration/cost 15, stakeholder communication 10, correction and closure 5. Pass requires 80 overall and no category below half.

Automatic failure applies if the architect hides a known limitation, invents evidence, cannot identify authoritative data, has no rollback after target writes, assigns no owner to a critical control, or treats challenge as personal criticism rather than architecture evidence.

Required artifacts

Submit the pre-read, role/decision-rights map, agenda, versioned six-view package, requirements excerpt, option matrix, capacity and cost worksheets, challenge-card draw, question/answer transcript, findings register, changed-decision log, corrected diagrams, residual-risk record, stakeholder decision, and a personal reflection naming three reasoning improvements.

Official sources

• The Well-Architected review process
• Prepare for a Well-Architected review
• Prioritize improvements
• AWS Well-Architected Framework