ALM maturity gaps in people, process and technology
How to assess a Salesforce team against the Well-Architected Operational Excellence maturity levels and name the fix for each gap: correlated logging, runbooks and distributed review, declarative review, real quality gates, fast CI with callout mocks, blameless postmortems, on-call rotation, version control as the change record and environments defined in source.
Given a complex customer scenario, assess ALM maturity and identify the people, technology, and processes required.
~8 min read · 10 practice questions ·
What the exam expects
- Place a team on the Well-Architected Operational Excellence maturity levels (Lean, Scale and Governance Optimized) and name the next step that fits its size and risk.
- Spot people gaps (one reviewer, one release person, one incident owner) and recommend distributed review, runbooks and an on-call rotation.
- Spot process gaps: unreviewed declarative changes, quality gates nobody trusts, blame-focused incident reviews.
- Spot technology gaps: uncorrelated logs, slow all-or-nothing CI, orgs as the only change record, hand-built environments, and know when to start source-driven development.
Key terms: observability (understanding internal state from logs, metrics and traces); correlation ID (one identifier carried through every step of a process so its log entries join up); bus factor (how many people can leave before knowledge is lost); quality gate (an automated check a change must pass to move on); blameless postmortem (an incident review that seeks the systemic cause, not a culprit); infrastructure as code (an environment's definition and seed data in version control).
Key facts
- Detail
- Two for production-bound changes; three in a five-person team is a bottleneck
- Detail
- Flows, validation rules, permission sets and sharing rules get the same review as code
- Detail
- Target under 15 minutes; 45-60+ minutes is an anti-pattern
- Detail
- Tests that perform callouts fail by default; use
Test.setMockso the callout is not made and the mock response is returned
- Detail
- All Severity 1 and 2 incidents, within 24-48 hours, blameless
- Detail
- Date, user and what changed; download covers the past 180 days, after which entries are deleted
- Detail
- Edition, add-on features and settings; check a team version into source control
- Detail
- Complete the move early, before org-based habits solidify
Sources for this section (5)
- Operational Excellencearchitect.salesforce.com (opens in a new tab)
- DevOps Patternsarchitect.salesforce.com (opens in a new tab)
- Testing HTTP Calloutsdeveloper.salesforce.com (opens in a new tab)
- Setup Audit Trailhelp.salesforce.com (opens in a new tab)
- Scratch Org Definition Filedeveloper.salesforce.com (opens in a new tab)
- Why does a correlation ID help more than extra log volume when a multi-step process fails?
- When does a single incident owner stop being an acceptable model?
- What happens to an Apex test that makes a real HTTP callout?
- When should a team move from org-based to source-driven development?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Platform Development Lifecycle and Deployment Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 26 lessons of the Platform Development Lifecycle and Deployment Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (10 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams