““Practicing scenario-based questions helped me strengthen my understanding of lifecycle management, governance, and deployment strategy.””
Laura Walsh
Salesforce Solution Architect
This is not a feature-recall exam. Of the 65 questions you’ll see (60 scored, 5 unscored and unidentified), the large majority are built as customer scenarios — a paragraph describing an org’s size, release cadence, team structure, or a problem they’re having — followed by “what would you recommend?” You get 105 minutes, which works out to under two minutes per question once you account for reading time, and the scenarios are often dense enough that re-reading them twice eats into that budget fast.
You need 39 of 60 scored questions correct (65%) to pass. Registration runs USD 400 plus local tax, and a retake is USD 200. There’s no formal prerequisite to sit this exam, though it’s one of four certifications required for the Salesforce Certified System Architect credential, so a meaningful share of people taking it are already mid-way through the architect track rather than coming in cold.
The question style leans harder into judgment than most Salesforce exams below the architect tier. You’ll rarely see “what does X do” — you’ll see “given this constraint, which of these four defensible-sounding options is actually the best fit,” where two or three answers aren’t wrong exactly, just worse for the scenario described.
Domain | Weighting | Approx. Questions |
|---|---|---|
Application Lifecycle Management | 8% | 5 |
Planning | 13% | 7 |
System Design | 15% | 9 |
Building | 14% | 9 |
Deploying | 14% | 9 |
Testing | 13% | 7 |
Releasing | 13% | 7 |
Operating | 10% | 6 |
System Design carries the most weight, and Building and Deploying are tied for second — together those three domains are nearly 45% of the exam, which tells you where your study hours should concentrate first.
Operating is small on paper and costly in practice. At 10% it looks skippable, but its questions tend to be some of the most situational on the exam — things like what to do when a change was made directly in production and now needs to flow backward into source control, or how to reconcile artifacts across a multi-org landscape. Candidates who triage their study time by weighting alone often walk in underprepared for this domain specifically.
Packaging nuance trips up people who know packaging exists but not when to use which type. Managed, unmanaged, and unlocked packages each show up with different trade-offs around versioning, namespace ownership, and who’s allowed to modify what post-install. The exam doesn’t ask “what is an unlocked package” — it asks you to pick a packaging strategy for an ISV vs. an internal multi-team org vs. a consulting partner handoff, and the right answer changes with the scenario.
Metadata API vs. Tooling API boundaries. People who’ve only worked with change sets often haven’t internalized what each API can and can’t deploy, and the exam tests that gap directly — particularly around metadata types that require manual post-deployment steps because they aren’t covered by either API.
Sandbox strategy beyond “we have a few sandboxes.” Storage limits and refresh intervals by sandbox type (Developer, Developer Pro, Partial Copy, Full) come up in scenario form — e.g., recommending a sandbox strategy for a team running multiple concurrent project streams plus a hotfix lane. Knowing the names of the sandbox types isn’t the same as being able to map them onto a release calendar.
Because almost every question is scenario-based, drilling isolated facts gets you less mileage here than it does on, say, Platform App Builder. When you review a missed question, don’t just note the correct answer — write out why each wrong option was a plausible-but-flawed choice for that specific scenario. That’s the actual skill the exam is testing, and it’s the skill flashcards don’t build.
Time yourself in blocks that mirror the pacing: roughly 100 seconds per question. If you’re consistently going over on System Design, Building, or Deploying questions specifically, that’s a signal to go back to Salesforce DX and the Metadata API documentation rather than just doing more questions — the slowdown is usually a comprehension gap, not a speed problem.
Also deliberately mix domains rather than practicing one domain at a time. exam scenarios don’t announce which domain they’re testing, and some questions straddle two (a release-management question that’s testing your Planning-domain governance knowledge, for instance).
Studying this like Platform Developer I — going deep on Apex and code mechanics instead of the process, governance, and tooling decisions the exam actually weights.
Treating all eight domains as equally worth the same study time instead of front-loading System Design, Building, and Deploying.
Memorizing a static definition of each packaging type without practicing the “which one for this scenario” judgment call.
Skimming Operating because 10% feels low, then getting blindsided by its scenario complexity.
Not reading Salesforce’s own Metadata API and Tooling API developer guides directly — third-party summaries tend to flatten the exact limitations the exam likes to test.
New to Salesforce DevOps (admin or developer background, limited lifecycle exposure): Plan on 6–8 weeks. Start with Application Lifecycle Management and Planning to build the governance vocabulary, then move into System Design and Building once the terminology is familiar.
Has related experience (holds Platform Developer I, has touched CI/CD pipelines or packaging before): 3–4 weeks is usually enough, concentrated on Deploying, Releasing, and Operating — the domains least like day-to-day development work.
Retaking after a fail: 1–2 weeks, but only if you go back through your score breakdown by domain first. A retake without a targeted gap review tends to repeat the same miss pattern.
Last updated on Oct, 28 2026