Salesforce Certified Technical Architect - Architect Evaluation – Complete Winter '26 Guide

Scenario-Based Assessment Format

The Salesforce CTA (Certified Technical Architect) Review Board is a scenario-based oral examination — not a multiple-choice test. Candidates receive a multi-page business scenario 30 minutes before their 2-hour board session. The scenario describes a fictional company with a complex Salesforce + external system landscape, business requirements, and technical constraints. The candidate must design a complete solution architecture, present it to a panel of 3–4 CTA evaluators, and defend it under challenge. The evaluation tests architectural thinking, communication of trade-offs, adaptability when the scenario changes, and mastery of all Salesforce platform areas.

Architecture Decision Justification

Every architecture decision must be justified with three elements: the business requirement it satisfies, the technical reasoning (why this approach over alternatives), and the explicit trade-offs (cost, complexity, maintainability, risk). Evaluators specifically probe whether candidates can articulate why they chose X over Y — not just what they chose. Common decision areas: single org vs. multi-org, declarative vs. code, synchronous vs. async, AppExchange vs. custom build, Salesforce-native data store vs. external database. Preparation tip: for each major decision in practice scenarios, explicitly say "I chose X over Y because..." and name the specific trade-offs. Vague answers are probed until the candidate either justifies or concedes.

Risk & Trade-off Analysis

CTAs are expected to proactively identify risks in their own designs — evaluators expect candidates to say "One risk with this approach is..." before being asked. Risk categories: technical risks (governor limits, data volume, API capacity), business risks (adoption, change management, vendor lock-in), operational risks (monitoring, support, upgrades), and security/compliance risks. Mitigation strategies must be specific — not "we will monitor it" but "we will implement a dead letter queue with alerting and a manual reprocessing workflow for failed events." Risk scoring (probability × impact) demonstrates mature architectural thinking. The evaluation rewards candidates who are intellectually honest about their design's weaknesses.

Defense of Design Choices

The Review Board will challenge design choices with "What if..." and "Why not..." questions to test whether the candidate truly understands the solution or memorized a template. Common challenges: "What if the integration endpoint goes down for 4 hours during business hours?", "What if your MuleSoft solution is over budget — what is the fallback?", "Why didn't you use a Platform Event here instead of a REST callout?" Candidates should respond with: acknowledge the challenge, explain the impact on the current design, and either defend it (with new justification) or adapt it (with a revised approach). Changing a design under challenge is not failure — it demonstrates that the architect can think dynamically.

Evaluator Rubric & Common Failure Areas

The CTA Review Board evaluates candidates on: Breadth (covering all required architecture areas), Depth (detailed, specific answers in each area), Communication (clear diagrams, structured verbal explanations), and Adaptability (handling scenario changes and challenges gracefully). Common failure areas: (1) Focusing only on Salesforce and ignoring external systems. (2) Providing generic answers without specific Salesforce feature references. (3) Failing to address security, data architecture, or integration explicitly. (4) Reacting defensively to challenges instead of engaging constructively. (5) Running out of time before covering all scenario requirements. Preparation: complete 10+ full mock Review Board sessions with peer CTAs or coaches, record and review yourself, and practice under time pressure.

Demonstrating Architecture Breadth

Evaluators look for evidence of experience across all CTA domains: data architecture, integration, security, UX, environment management, and data migration. Build a portfolio of real-world architectural decisions.

Handling Ambiguity

CTA evaluations present deliberately ambiguous scenarios. Practice asking clarifying questions, stating your assumptions clearly, and designing solutions that are flexible enough to accommodate multiple interpretations.

Whiteboard Communication

Practice whiteboarding architecture diagrams quickly and clearly. Your diagram should show system boundaries, integration points, data flows, and key design decisions — without being cluttered.

Justification Framework

Use a consistent framework: state the requirement, present options, identify trade-offs for each, and recommend with clear rationale. This structured approach demonstrates CTA-level thinking.

Prepare with Mock Sessions

The CTA community regularly runs mock Review Board sessions. Participating in these is the single most effective preparation strategy — treat each mock as the real thing and seek detailed feedback.