Common Mistakes, Mock Boards & Practice
Why candidates fail the CTA Review Board, what judges look for, trade-off articulation, risk communication, and how to set up and run effective mock boards.
Common Mistakes: Why Candidates Fail
Based on insights from CTA judges and candidates who have been through the board:
Presentation Mistakes
- Repetition — Wasting finite presentation time repeating elements already covered. Say it once, say it well, move on
- Solution dumps — Describing your architecture without tying each element to a specific requirement
- Skipping trade-offs — Presenting only the happy path without acknowledging limitations
- Poor time management — Spending too long on early sections and rushing through later ones
- Unreadable diagrams — Diagrams that are correct but too cluttered or poorly labeled for judges to follow
- Memorized scripts — Sounding rehearsed rather than conversational
Technical Mistakes
- Shallow integration design — Saying “extract, cleanse, transform, and load” without providing the specific steps you would take
- LDV mismanagement — Architecting large data volume scenarios incorrectly (skinny tables, indexing, archiving strategies)
- Memorized OAuth flows — Reciting SSO/OAuth without understanding when and why to apply each flow
- Missing failure scenarios — Not addressing what happens when integrations fail, systems go down, or data is corrupted
- Ignoring governor limits — Not proactively addressing how your design works within platform limits
Communication Mistakes
- Bluffing — Judges can sense when you do not truly understand your solution. Honesty with reasoning always beats confident bluffing
- Defensiveness — Treating every challenge as an attack rather than an opportunity to demonstrate depth
- Not answering the question — Talking around the question instead of addressing it directly
- Single-perspective answers — Only giving the technical view without business context, or vice versa
Mindset Mistakes
- Thinking there is one right answer — The scenario is intentionally ambiguous; judges evaluate reasoning quality, not whether you matched a rubric
- Trying to be perfect — Attempting to cover every edge case instead of focusing on the critical requirements
- Fear of changing your answer — If you realize mid-presentation that you made a mistake, correct it. Sticking with a wrong answer out of fear looks worse
The Judges’ Perspective
Insights from CTA judges who have shared their perspective:
What Judges Want You to Know
“The judges are not here to fail you. We do want to pass every candidate that steps into the room. We understand the dedication and sacrifice every candidate puts into preparation for the board.” — Dinesh Yadav, CTA Board Judge
The Three Things Judges Evaluate on Every Answer
- Did you identify the requirement? If judges do not know what you are solving for, they cannot score you
- Is your solution appropriate? Does it use the platform effectively and address the requirement?
- Can you justify it? Do you know why this is the best approach and what alternatives exist?
What Separates Pass from Fail (Judge Perspective)
| What Judges Want to See | What Judges See in Failing Candidates |
|---|---|
| Structured, logical presentation flow | Scattered, hard-to-follow presentation |
| Every solution tied to a requirement | Solutions without clear requirement mapping |
| Proactive risk identification | Only reactive risk discussion when asked |
| Depth of understanding | Surface-level buzzword answers |
| Ability to compare and contrast approaches | Only knowing one way to solve each problem |
| Graceful adaptation to challenges | Rigid defense or complete capitulation |
| Clear, readable diagrams with legends | Cluttered or incomplete diagrams |
| Honest acknowledgment of limitations | Bluffing or overconfidence |
The “Compare and Contrast” Expectation
“You need to be able to compare and contrast the various ways to solve a problem. If you always discard certain features from your solutions, there’s nothing to say that you won’t get a judge who loves that feature and has figured out that it’s actually the best approach.” — Keir Bowden (Bob Buzzard), CTA
This means for every major decision, you should be able to articulate:
- What you chose and why
- What alternatives you considered
- Why the alternatives were less appropriate for this specific scenario
- Under what conditions you would choose the alternative instead
Trade-Off Articulation
Trade-off analysis appears across nearly every CTA exam objective. It is the single most important skill to master.
The Trade-Off Formula
For every significant architectural decision, articulate:
I chose [APPROACH] because [REASONS tied to requirements].I considered [ALTERNATIVE] but rejected it because [SPECIFIC LIMITATION in this context].The trade-off I accept is [WHAT YOU GIVE UP].I mitigate that trade-off by [MITIGATION STRATEGY].If [CONDITION CHANGED], I would reconsider and potentially switch to [ALTERNATIVE].Trade-Off Categories to Address
| Category | Example Trade-Off |
|---|---|
| Build vs. Buy | Custom Apex integration vs. MuleSoft — cost vs. maintainability |
| Platform vs. Custom | Declarative flows vs. Apex triggers — simplicity vs. flexibility |
| Real-time vs. Batch | Streaming API vs. scheduled batch — immediacy vs. resource consumption |
| Single-org vs. Multi-org | Consolidation vs. separation — simplicity vs. data isolation |
| Security vs. Usability | Strict sharing rules vs. wide access — protection vs. user friction |
| Performance vs. Completeness | Selective sync vs. full sync — speed vs. data availability |
| Cost vs. Capability | Community vs. full licenses — budget vs. functionality |
How to Practice Trade-Off Articulation
For each of your major design decisions, write out:
- What did you choose?
- What are 2-3 alternatives?
- What criteria drove your choice? (cost, complexity, scalability, timeline, risk)
- Under what conditions would you change your mind?
- Can you present this in under 60 seconds?
Risk Communication
Proactively identifying and communicating risks signals senior architectural maturity. Judges value risk identification as highly as solving for requirements.
The Risk Communication Framework
For each risk, state:
- Risk: What could go wrong
- Probability: How likely it is (High / Medium / Low)
- Impact: What happens if it occurs (High / Medium / Low)
- Mitigation: What you are doing to prevent or reduce it
- Contingency: What you would do if it happens anyway
Risk Categories to Cover in Your Presentation
| Category | Example Risks |
|---|---|
| Data | Data quality issues during migration, LDV performance degradation |
| Integration | Third-party API changes, integration failures, data consistency |
| Security | Oversharing of data, SSO provider outages, portal security gaps |
| Adoption | User resistance, training gaps, process change management |
| Technical | Governor limit breaches, platform changes, technical debt |
| Project | Timeline slippage, resource availability, scope creep |
| Operational | Monitoring gaps, incident response, business continuity |
How to Present Risks Effectively
Do not save risks for the end. Weave risk awareness throughout your presentation:
- When presenting integrations: “The key risk here is [X], which I mitigate by [Y]”
- When presenting data model: “At this data volume, the risk is [X], so I’ve included [Y]”
- When presenting security: “The portal architecture introduces a risk of [X], addressed by [Y]”
Have a dedicated risk slide, but also demonstrate risk awareness organically throughout.
Practice Techniques
Mock Board Practice Plan
Successful CTA candidates follow a structured practice regimen:
| Timeframe | Activity | Frequency |
|---|---|---|
| 6+ months out | Study domains, build foundational knowledge | Daily study |
| 3-6 months out | Practice individual artifacts under time pressure | 2-3x per week |
| 6-8 weeks out | Full mock review boards with panels | 1-2x per week |
| Final 2 weeks | Intensive mocks with at least one CTA judge | 2-3x per week |
| Total mocks | 8-10 full mock sessions minimum |
Practice Drills
1. The 20-Minute Diagram Sprint
Set a timer for 20 minutes. Given a blank scenario, draw a complete architecture diagram. Focus on speed and completeness, not beauty.
2. The 90-Second Artifact Presentation
Take any diagram you have created and practice explaining it in 90 seconds or less. Record yourself. Watch it back. Trim the fat.
3. The Hostile Q&A
Have a study partner ask you the hardest questions they can think of. Practice pausing before answering, using the STAR-A framework, admitting gaps honestly while demonstrating reasoning, and adapting your design on the fly.
4. The “Explain to a Business Person” Drill
Take a deeply technical decision and explain it in terms a VP of Sales would understand. Then explain it in terms a CTO would want to hear. Switch between the two.
5. The Trade-Off Gauntlet
For each major decision in your design, have a partner ask “Why not [alternative]?” Practice articulating trade-offs for every single decision.
6. The Clock Drill
Present your full solution with a visible timer. Mark where you are at 15 minutes, 30 minutes, and 40 minutes. Adjust your pacing until you consistently finish in 35-40 minutes with a strong close.
7. Record and Review
Record every mock presentation. Watch it with the sound off — are you making eye contact? Is your posture confident? Then watch with sound — are you concise? Do you repeat yourself? Do you say “um” too much?
What to Practice With
- Practice with diverse groups, not just the same study buddy
- Seek panelists who include at least one CTA or CTA judge
- Use publicly available mock scenarios (Apex Hours, CTA 202, Flow Republic, Ladies Be Architects, Architect Trailblazers community)
- Practice with Lucidchart specifically, since that is the tool you will use on exam day
Mock Review Board: How to Set Up and Run
Mock Board Structure
Replicate the real board as closely as possible:
| Element | Real Board | Your Mock |
|---|---|---|
| Judges | 3-4 active CTAs | 2-4 people (ideally with 1+ CTA/CTA candidate) |
| Format | Virtual (Zoom) | Virtual (Zoom or Google Meet) |
| Scenario | Official Salesforce scenario | Community mock scenarios |
| Preparation | 180 minutes, no internet | 180 minutes, no internet, no notes |
| Tools | Lucidchart with Salesforce Shape Library | Lucidchart with Salesforce Shape Library |
| Presentation | ~30-45 minutes | ~30-45 minutes |
| Q&A | ~40-90 minutes | ~40-60 minutes |
| Feedback | Pass/Fail with notes | Structured feedback by domain |
After the Mock: Structured Feedback
Have each panelist score and comment on all 7 domains:
Domain 1 (System Architecture): [1-5 score] -- [specific feedback]Domain 2 (Security): [1-5 score] -- [specific feedback]Domain 3 (Data): [1-5 score] -- [specific feedback]Domain 4 (Solution Architecture): [1-5 score] -- [specific feedback]Domain 5 (Integration): [1-5 score] -- [specific feedback]Domain 6 (Dev Lifecycle): [1-5 score] -- [specific feedback]Domain 7 (Communication): [1-5 score] -- [specific feedback]
Strengths: [what went well]Areas for improvement: [what to work on]Would this pass a real board? [Yes / Borderline / No]Where to Find Mock Scenarios
| Source | URL | Notes |
|---|---|---|
| Apex Hours | apexhours.com | Free mock scenarios |
| CTA 202 | cta202.com | Community scenarios by Andrew Hart |
| CTA Gang of Four | ctagof.com | Curated list of all public scenarios |
| Flow Republic | flowrepublic.com | Scenarios included with coaching |
| Trailhead Community | trailhead.salesforce.com | Architect study group resources |
Mock Board Progression
Start easy and increase difficulty:
- First mocks (months 3-4): Focus on completing all artifacts and covering all domains. Do not worry about Q&A performance yet.
- Middle mocks (months 4-6): Add hostile Q&A. Practice defending decisions and handling curveballs.
- Final mocks (last 6-8 weeks): Full simulation with strict timing, CTA judges on the panel, and no mercy in Q&A. Target 1-2 per week, with 8-10 total.
- Final week: Do one last mock 5-7 days before your real board. Do not mock the day before — rest.
Quick Reference: The Day-Of Checklist
Preparation Phase (180 minutes)
- Read the entire scenario once without writing (15-20 minutes)
- Identify actors, systems, and integration points from page 1 — start drawing immediately
- Highlight critical requirements vs. nice-to-haves
- Note all explicit constraints and assumptions
- Create your core artifacts in Lucidchart (System Landscape, Data Model, Role Hierarchy first)
- Build remaining artifacts (Integration, Security, Migration, Governance)
- Reserve final 15 minutes to review: did you address every requirement?
- Prepare your opening statement and closing summary mentally
Presentation Phase (30-45 minutes)
- Open with business context and critical requirements (3-5 minutes)
- Walk through each artifact with the “requirement -> solution -> justification -> trade-off” pattern
- Check your time at 15 and 30 minutes — adjust pace
- Close with key decisions, trade-offs, and risks (2-3 minutes)
- Speak to the camera, not your slides
Q&A Phase (40-90 minutes)
- Listen carefully to each question — restate if needed
- Pause before answering (3-5 seconds)
- Use STAR-A for challenges
- Tie answers back to requirements
- Admit gaps honestly with reasoning, never bluff
- Adapt gracefully when challenges reveal genuine gaps
- Stay calm and confident throughout