CTA Review Board Exam Tips (Winter '26): How to Pass the Live Architecture Presentation

Quick Answer: What the CTA Review Board Tests

• Architectural breadth under pressure — The Review Board tests whether you can design a complete enterprise Salesforce architecture covering all domains simultaneously: data architecture (LDV, Big Objects), integration (API-led, CDC, MuleSoft), identity (SAML SSO, OAuth, Experience Cloud), security (OWD, sharing rules, FLS at scale), and deployment (release management, scratch orgs, CI/CD) — all in response to a single complex scenario.
• Decision justification and trade-off reasoning — The panel of CTAs deliberately challenges your decisions. They want to see you justify choices with explicit trade-offs (single-org vs multi-org: simpler governance but harder to achieve separate release cycles), hold your position under pressure when your reasoning is sound, and pivot gracefully when challenged with a valid constraint you had not considered.
• Risk identification and mitigation — Strong candidates proactively identify architectural risks in their own solution (large data volumes triggering sharing recalculation, Apex governor limits in complex automation, integration failure cascades) and describe mitigation strategies. Candidates who only present the 'happy path' without acknowledging risks are seen as less architecturally mature.

Presentation Structure: The Architecture Domains to Cover

Scenario Strategy: How to Approach the Review Board

The Review Board scenario is deliberately ambiguous — it will have constraints that conflict and requirements that could be solved multiple ways. The panel does not want the 'right answer'; they want to see architectural thinking, trade-off analysis, and the ability to defend a justified position under interrogation.

• For whiteboarding: draw a high-level architecture diagram first (org structure, system landscape, integration flows, identity boundaries). Use swim lanes or zones to separate concerns (internal users vs external users vs systems). Label every arrow with the integration pattern (REST, CDC, MuleSoft, Platform Events). The panel evaluates your diagram independently — it must stand alone as a clear architectural artefact, not just a prop for your verbal explanation.
• For panel Q&A: when the panel challenges a decision ('why not multi-org?', 'what if the integration fails?'), respond with 'That's a valid consideration — in this scenario I chose [approach] because [specific constraint from the scenario] makes [alternative] less suitable, though if [different constraint] were present, I would reconsider.' This structure shows you understand alternatives without abandoning your justified position. Do not simply agree with every challenge.
• For LDV scenarios (very common in Review Board): if the scenario mentions millions of records or high-volume data, explicitly address skinny tables for reporting performance, custom indexes for selective queries, data archiving strategy with Big Objects, and the impact of sharing recalculation on large data volumes. If you wait for the panel to ask about LDV rather than addressing it proactively, it signals insufficient architectural foresight.

Preparation Approach for the CTA Review Board

Mock Review Board sessions with a CTA mentor are essential — written study alone is insufficient

The most effective preparation is live mock Review Board sessions with a sitting CTA acting as a panel member. Trailblazer Community CTA groups run peer mock sessions. Key preparation activities: practice whiteboarding all five architectural domains from a single scenario in under 30 minutes; practise holding positions under challenge without becoming defensive or capitulating; study the Salesforce Architecture Patterns Trailmix and all architect-level credential study materials; review published CTA Review Board scenario reports and community post-mortems from candidates who have attempted the board.

Frequently Asked Questions

Is the Technical Architect Review Board worth pursuing?

The Technical Architect Review Board is the most prestigious credential in the Salesforce ecosystem — held by fewer than 1% of certified professionals. It validates the ability to design enterprise-scale Salesforce architectures across all domains simultaneously. CTAs command the highest salaries in the Salesforce job market and are sought by top SIs and consulting firms. The investment is significant (time, study, and fees), but for architects targeting the top of the Salesforce career ladder, it is widely considered the most valuable credential available.

What scenario topics does the CTA Review Board typically cover?

CTA Review Board scenarios are deliberately broad and ambiguous. They typically involve a large enterprise with multiple Salesforce clouds, integration requirements, identity and access management challenges, large data volumes, complex security and sharing requirements, and a release management question. You are expected to address all architectural domains — not just your strongest area. Scenarios often include deliberate constraints that force trade-off decisions.

How should I structure my CTA Review Board presentation?

A strong Review Board presentation typically follows: (1) Restate the scenario requirements and constraints in your own words to confirm understanding; (2) Present your solution architecture with a whiteboard diagram covering all domains; (3) Justify each key decision with explicit trade-offs (why this approach vs the alternative); (4) Call out risks and mitigation strategies proactively; (5) Summarise governance and deployment approach. The panel rewards candidates who demonstrate architectural thinking — the "why" behind decisions — not just correct answers.

What are the most common reasons candidates fail the CTA Review Board?

Common failure reasons: (1) Insufficient breadth — solving only the primary requirement and missing data architecture, identity, or deployment concerns; (2) Inability to defend decisions under panel questioning — changing the answer when challenged rather than holding a justified position; (3) Overlooking scalability — designing for current state without considering large data volumes or future growth; (4) Not addressing trade-offs — presenting one solution as if there are no alternatives or downsides; (5) Weak security architecture — not addressing field-level security, sharing rules, or external identity at scale.

What concepts do most Technical Architect Review Board candidates get wrong?

The most commonly misunderstood topics for the Technical Architect Review Board exam are: (1) The Scenario Is Deliberately Ambiguous — You Must Ask Clarifying Questions; (2) Defence Matters as Much as the Solution; (3) End-to-End Solution — Security, Deployment, and Governance Are Scored. Candidates are most confidently wrong on these — learn the distinctions early to avoid losing marks on questions you expect to get right.

Why do most Technical Architect Review Board candidates fail questions about The Scenario Is Deliberately Ambiguous?

The Review Board scenario intentionally omits details to see if candidates proactively identify and resolve ambiguity. Candidates who proceed on assumptions without questioning constraints will design solutions that do not fit the actual requirements. The first 10 minutes of the board should include explicit clarifying questions: "What is the data volume?" "Is multi-org on the table?" "What are...

Why do most Technical Architect Review Board candidates fail questions about Defence Matters as Much as the Solution?

Board members will challenge your design choices. A technically correct architecture that you cannot defend is scored lower than a pragmatic architecture you can explain under pressure. Candidates over-engineer their architecture to impress — the board expects a defensible, constraint-aware design with clear rationale for every major decision.

Why do most Technical Architect Review Board candidates fail questions about End-to-End Solution?

The Review Board scores the full solution, not just the technical architecture. Missing sections include: data security and sharing model, deployment and release strategy, integration governance, and post-launch support model. Candidates present only the data model and integration diagrams — the board expects a complete solution narrative covering all scored dimensions.

Related Exam Tips