Salesforce Development Lifecycle and Deployment Architect Practice Test

Correct answer: A. Run a hybrid model: fix and baseline scope through a formal requirements and approval gate, then build and test iteratively inside that baseline with change control on the baseline itself

The constraint here is traceability and a fixed, externally-approved scope, not the cadence of the build. A hybrid model satisfies both: the requirements baseline is agreed and signed once, which gives the auditor the approval-to-component trail they need, and the team still builds in sprints inside that baseline so defects surface early. Changes to the baseline go through change control rather than through sprint re-prioritisation.

Pure Scrum fails the audit requirement, because a backlog the product owner can re-order at will is exactly what the filing forbids. Abandoning iteration entirely is an over-correction — nothing about the audit requirement prevents incremental build and demonstration, and removing them removes the early feedback that keeps a fixed-scope build honest. Dropping documentation misreads the Agile Manifesto: it values working software over comprehensive documentation, not instead of the documentation a regulator requires.

The wider point the exam is testing is that methodology is a recommendation you justify from constraints — regulatory exposure, scope volatility, team maturity, stakeholder availability — rather than a default you apply to every client.

Exam section: Application Lifecycle Management  ·  Difficulty: Medium

Correct answer: C. It describes only the deployment step; application lifecycle management also covers planning, environment strategy, development, testing, release, and post-release operation of the change

Application lifecycle management is the end-to-end discipline that carries a change from an idea through planning, environment provisioning, build, test, release and into ongoing operation and support. A deployment tool is one link in that chain. Conflating the two is the single most common maturity gap this exam probes, because a team that only owns the deployment step has no answer for who prioritises work, which sandbox it is built in, how it is tested, when it ships, or what happens when it breaks in production.

Change sets can deploy Apex, so the claim that the org therefore has no application lifecycle management at all is factually wrong. Adding the Ant Migration Tool alongside change sets swaps one tool for two and repeats the same category error, and calling application lifecycle management the deployment mechanism simply restates the misconception.

In an interview or an exam scenario, the useful follow-up is to ask what happens to a change after it lands: who monitors it, who owns the defect, and how the fix gets prioritised. That question exposes the gap faster than any tooling audit.

Exam section: Application Lifecycle Management  ·  Difficulty: Easy

Correct answer: B. Establish the foundations first — a version control repository as the source of truth, an environment strategy with separate development and integration sandboxes, and an agreed change control process — then introduce automation on top of them

Automation amplifies whatever process it is pointed at. A pipeline built over an org with no source of truth and no environment separation automates an ungoverned process and produces faster, more confident overwrites. The architect's recommendation has to be sequenced by maturity: source control and environment separation first, an agreed definition of how a change is approved and promoted second, tooling third.

Buying the tool first is the trap the scenario is built around. Locking administrators out of production is a control with no alternative path — it stops the symptom by stopping the work, and it will be reversed within a week. Jumping straight to package-based development with scratch orgs skips several maturity levels; a team that has never used a branch will not succeed with a source-driven, ephemeral-environment model, and an org with years of unpackaged metadata cannot be decomposed into packages overnight.

Expect several questions phrased this way. The answer is almost never the most advanced option available — it is the next achievable step from where the customer actually is.

Exam section: Application Lifecycle Management  ·  Difficulty: Medium

Correct answer: D. Sprint cadence and programme milestones operate at different levels: the sprints deliver and validate increments, while the quarterly milestones remain the external commitment the increments roll up to

Hybrid delivery works when the two cadences are understood as nested rather than competing. The programme commits to the business on quarterly outcomes; the workstream builds towards those outcomes in increments and uses each demonstration to reduce the risk of missing the commitment. Nothing about a sprint boundary conflicts with a milestone boundary as long as the increment is traceable to the milestone it serves.

Discarding the programme plan is not available to the architect and is not necessary. Forcing the workstream onto a quarterly cadence throws away the early feedback that makes fixed milestones survivable. Claiming sprints remove milestone reporting is simply false and is the kind of promise that loses an architect the room.

The practical addition to this answer is the integration point: agree in advance which sprint increments are demonstrable internally and which are externally releasable, because that is where hybrid programmes actually break.

Exam section: Application Lifecycle Management  ·  Difficulty: Medium

Correct answer: C. Assess people, process and technology together — who owns each stage of the lifecycle, what the agreed process is at each stage, and which tools support it — and identify the weakest of the three

Maturity is a function of people, process and technology, and the constraint is always the weakest of the three. An org with an excellent pipeline and no named release owner fails on people. An org with a strong governance body and no source control fails on technology. An org with both but no agreed definition of done fails on process. Assessing all three and naming the binding constraint is what makes the subsequent recommendation defensible.

Counting metadata measures complexity, not maturity — a small org can be immature and a large one disciplined. Benchmarking deployment frequency against industry figures produces a number with no remediation attached to it. Reviewing only tooling inverts the actual dependency: process determines which tooling is useful, not the other way round.

The output of this assessment should be a sequenced roadmap, because maturity gaps have dependencies — you cannot introduce continuous integration before source control, or release management before an environment strategy.

Exam section: Planning  ·  Difficulty: Medium

Correct answer: A. Use the sandbox preview window: confirm which of the customer's sandbox instances are designated preview instances for the release, ensure a suitable sandbox is on one of them, and run the regression suite there against the new release before production is upgraded

Salesforce publishes, for each seasonal release, which sandbox instances receive the release ahead of production — the sandbox preview window. Refreshing or creating a sandbox on a preview instance inside that window gives the customer an environment running the next release while production is still on the current one, which is the only way to run a genuine pre-upgrade regression pass. Confirm the current instance designation on Salesforce Trust and in the release's preview guidance, because the mapping is published per release rather than being fixed.

Waiting until after the upgrade converts a preventable risk into an incident; Salesforce runs Apex tests across customer orgs before a release, but that is not a substitute for the customer's own functional regression. Production upgrades cannot be deferred by support case. Version-pinning on Apex classes limits some behavioural changes but does not protect against UI changes, changes to standard objects, or altered behaviour in features the code depends on.

The plan should also include a decision on what happens if regression fails — whose sign-off is needed, and which mitigations are available before the upgrade date.

Exam section: Planning  ·  Difficulty: Medium

Correct answer: D. A Center of Excellence that owns platform-wide standards, an architecture review board that reviews significant designs against them, and local delivery teams that retain day-to-day autonomy inside those standards

The failure mode here is divergence without a shared standard, so the fix is a standards-owning body plus a review point for decisions that cross unit boundaries, while leaving local teams free to deliver. That balance — centralised standards, federated delivery — is what a Center of Excellence with an architecture review board is for.

Full centralisation of build removes the responsiveness each unit is defending and creates a queue that units will route around. No central structure is the status quo that produced the problem. Reviewing every change regardless of size is the opposite failure: the board becomes a bottleneck, review quality falls because volume is high, and teams start splitting changes to avoid it. Governance should be risk-tiered, with lightweight paths for low-risk changes.

In the exam, watch for the word every in governance options. A framework that reviews everything and a framework that reviews nothing both fail, for different reasons.

Exam section: Planning  ·  Difficulty: Medium

Correct answer: B. Concurrent work in a single shared environment means changes silently overwrite each other and there is no reliable record of what any individual change consisted of, so a partial or incorrect release is likely and difficult to diagnose

All four observations are real, but the exam asks for the highest-priority risk, and that is the one that can put wrong code into production without anyone noticing. In a shared org with no source control, the last save wins, there is no diff, no history and no attribution, and a change set assembled from that org can easily carry half of one developer's work and all of another's.

Limited data storage in a Developer sandbox is a genuine constraint but it affects test fidelity rather than release correctness. Metadata type coverage in change sets is a known operational cost, handled with a documented manual-step checklist. Configuration drift from infrequent refreshes matters, but it is a slower and more visible problem than silent overwrites.

The remediation is the same one the exam expects throughout: version control as the source of truth, and separate development environments so that concurrent work is merged deliberately rather than by accident.

Exam section: Planning  ·  Difficulty: Medium

Correct answer: A. Track the published release schedule for the org's instance, schedule regression testing in the preview window, and avoid scheduling a major customer release into the same weekend as the platform upgrade

Planning around the platform calendar means three concrete things: knowing the upgrade date for the org's own instance rather than a generic date, using the preview window for regression, and not stacking your own change on top of the platform's change in the same window. When two things change at once and something breaks, you have doubled your diagnosis time.

A full quarterly freeze is a disproportionate response that starves the business of delivery. Assuming backwards compatibility is how customers discover the exceptions the hard way. Instance assignment is not customer-selectable for scheduling convenience.

A good answer also names what happens in the days immediately after the upgrade: a short heightened-monitoring period, with the release notes' known-issues list to hand.

Exam section: Planning  ·  Difficulty: Easy

Correct answer: C. An integrated release plan that maps each stream to its own environments, defines the shared integration and staging environments, sets a merge and code-freeze calendar, and defines the hotfix path with its back-merge obligation

Parallel streams collide in three predictable places: the same metadata edited twice, the staging environment contended for, and a hotfix that ships to production and is then silently reverted by the next release. An integrated release plan is the artefact that addresses all three, because it names the environments, the dates, and the obligation to merge every hotfix back into the mainline.

A shared backlog view helps visibility and does nothing about environment contention or merge order. A single shared sandbox for all three streams reintroduces the overwrite problem at a larger scale. Serialising the streams removes the collision by removing the parallelism, which is not a plan — it is a refusal of the requirement.

The detail most often missed is the back-merge. A hotfix applied to production and not merged into the development mainline is a regression waiting for the next release to reintroduce it.

Exam section: Planning  ·  Difficulty: Hard

Correct answer: B. A named release owner who takes the decision against pre-agreed exit criteria — test results, defect thresholds, sign-offs and a rehearsed rollback plan — with the relevant business owner accountable for accepting residual risk

Release decisions are made well when the criteria are agreed before the pressure arrives and a named person is accountable for applying them. That person is not necessarily the most technical — they are the one who can hold the line on the criteria and who owns the consequence. The business owner accepts residual risk, because some of that risk is commercial rather than technical.

The lead developer has the deepest code knowledge and the least distance from the work; they are an essential input, not the decision-maker. Automated gates are valuable and should block on objective criteria, but a tool cannot weigh a known cosmetic defect against a contractual go-live date. Re-reviewing the design at release time is too late to change anything and delays the release for no benefit.

The rollback plan belongs in the exit criteria, and it must be rehearsed. A rollback plan that has never been executed is an assumption, not a plan.

Exam section: Planning  ·  Difficulty: Medium

Correct answer: D. Full sandbox

Only a Full sandbox copies the complete production configuration together with production data volumes, which is what performance testing at scale requires. It is also the sandbox type that supports the longest history and the most realistic user acceptance testing.

Developer and Developer Pro sandboxes copy configuration only, with modest data storage limits, so they cannot represent production volumes. A Partial Copy sandbox copies configuration plus a sample of data selected by a sandbox template, subject to a per-object record cap, which makes it a good integration and limited UAT environment but not a performance testing environment.

The trade-off to state alongside the recommendation is the refresh interval: a Full sandbox has the longest minimum interval between refreshes of the four types, so it must be positioned in the release calendar deliberately rather than refreshed on demand. Data masking or seeding also has to be planned, because a Full sandbox brings real customer data with it.

Exam section: System Design  ·  Difficulty: Easy

Correct answer: D. The Full sandbox minimum refresh interval is longer than the gap between releases, so the plan needs either a different environment type for staging, a revised release cadence, or an accepted approach to reconciling staging without a refresh

Sandbox refresh intervals are a hard design constraint that the exam expects you to plan against rather than discover. Full sandboxes have the longest minimum interval of the four types — long enough that a four-week release cadence cannot assume a fresh copy before every release. Developer and Developer Pro sandboxes have the shortest interval, and Partial Copy sits between them.

Full sandboxes are refreshable, so the claim that they must be deleted and recreated is wrong — but they cannot be refreshed on demand at any time either, which is exactly the constraint the plan has missed. A refresh replaces the sandbox contents with a new copy of production, so code that exists in production comes with it; the statement that refreshing deletes Apex is wrong as written.

The realistic resolutions are to make staging a Partial Copy sandbox with a template that gives representative data, to lengthen the cadence, or to accept that staging is refreshed on a slower cycle and to keep it aligned in between by deploying to it exactly as you deploy to production. Always confirm the current interval and storage figures in Salesforce Help before committing them to a design document.

Exam section: System Design  ·  Difficulty: Medium

Correct answer: C. A Partial Copy sandbox with a sandbox template that selects the objects to include, supplemented by a seeding process for anything the template cannot supply

A sandbox template is exactly the mechanism for this requirement: it defines which objects are copied into a Partial Copy or Full sandbox, which makes the resulting data set intentional and repeatable rather than ad hoc. Anything the template cannot provide — reference data held in custom settings, for example, or records needed for a specific test path — is added by a scripted seeding step so that the environment is reproducible after every refresh.

Manual loading by testers is not repeatable and produces environments that diverge within days. A Full sandbox meets the realism requirement but not the "without copying every production record" requirement, and it brings a much larger data protection obligation. Testing in production is not an option for integration testing of unreleased functionality.

Note the data protection dimension: any copy of production data into a lower environment needs a masking or anonymisation decision made explicitly, and the exam expects the architect to raise it rather than wait to be asked.

Exam section: System Design  ·  Difficulty: Medium

Correct answer: A. Evaluate the decision against the actual drivers — shared customers and cross-division reporting, shared processes and reuse, governance appetite, regulatory separation, and platform limits — and recommend accordingly, noting that no shared customers and separate regulatory regimes weaken the case for consolidation

Org strategy is a judgement made from drivers, not a default. The strongest arguments for a single org are a shared customer base, cross-business reporting, reuse of process and configuration, and a single governance body able to arbitrate. The strongest arguments for multiple orgs are genuine process independence, regulatory or data residency separation, independent release cadences, and org-level limits.

In this scenario, no shared customers and separate regulatory regimes remove most of the consolidation benefit while retaining all of the migration cost and governance conflict. That is not a universal rule — it is what these particular facts point to.

The option that proposes consolidating the data while keeping separate user interfaces describes what consolidation actually costs: once the data is in one org, separating what each division sees is a sharing, profile and page layout exercise of considerable ongoing complexity. It is achievable, but presenting it as a simple mitigation understates the work, and the exam rewards candidates who price the consequence.

Exam section: System Design  ·  Difficulty: Hard

Correct answer: D. The tool gives a single prioritised backlog, visible work-in-progress and flow metrics, and — when linked to the version control repository — traceability from a requirement through the commit and the pull request to the release it shipped in

The architectural value of agile tooling is traceability and flow visibility, not ceremony. When a work item links to the commits and pull requests that implemented it, and those link to the release that shipped them, you can answer the two questions that matter in a governance forum: what is in this release, and where did this change come from. A spreadsheet cannot make that link.

No tool is mandatory. No tool replaces a product owner — prioritisation is a business decision informed by the tool, not produced by it. And no tool guarantees throughput; claiming it does is the sort of promise that discredits the rest of a proposal.

The traceability argument is also the governance argument, which is why it lands with steering committees in a way that velocity charts do not.

Exam section: System Design  ·  Difficulty: Easy

Correct answer: B. Change sets are declarative and manual, are limited to orgs in the same deployment lineage, cannot delete components and cannot be version-controlled or automated, whereas a source-driven pipeline promotes from a repository, can be automated and audited, and supports destructive changes

The credited answer lists the differences that actually drive the recommendation. Change sets are convenient and require no additional tooling, but they are manual, unversioned, non-repeatable, restricted to connected orgs in the same lineage, and cannot delete metadata. A pipeline that deploys from a repository gives you a reviewable history, repeatability across environments, automation, and the ability to include destructive changes.

Change sets are not faster for every release size — assembling a large change set by hand is slow and error-prone, and it has to be redone for every target org. No pipeline removes manual steps entirely: some settings, some feature enablement and most data still need pre- or post-deployment handling, which is why a documented runbook survives automation. The two mechanisms are not equivalent in any meaningful sense.

A pragmatic transition keeps change sets available for genuine emergencies while the pipeline becomes the default path, with a rule that anything deployed by change set is reconciled back into the repository afterwards.

Exam section: System Design  ·  Difficulty: Medium

Correct answer: A. Maintain a dedicated hotfix environment that mirrors the current production release, build and test the fix there, deploy it to production, and merge the fix back into the development mainline and the in-flight release branch

A hotfix path exists so that urgent fixes do not have to inherit the risk of an in-flight release. The design has three parts: an environment that matches what is live in production right now rather than what is being tested, a fast test-and-deploy route from it, and a mandatory back-merge into the mainline and the release branch so the fix is not lost at the next deployment.

Changing production directly leaves no tested artefact and no record; it is the behaviour a hotfix process exists to replace. Adding the fix into the release under test contaminates a regression cycle that has already started and forfeits weeks of testing. Shipping the entire release early to carry one fix releases everything else untested alongside it.

Most hotfix processes fail on the back-merge rather than the deployment. Make it an exit criterion of the hotfix, not an afterthought.

Exam section: System Design  ·  Difficulty: Medium

Correct answer: C. Short-lived feature branches merged into a mainline through reviewed pull requests, a release branch cut and stabilised for each monthly release, and hotfix branches taken from the release tag and merged back into both the mainline and the release branch

This is the standard shape for scheduled releases with a hotfix obligation. Short-lived feature branches keep work isolated but merge often enough to avoid painful integration. A release branch lets a release stabilise while new development continues on the mainline. Hotfix branches from the release tag give urgent fixes a path that does not carry unreleased work, and the back-merge keeps every line consistent.

Committing straight to a single branch removes review and makes it impossible to exclude unfinished work from a release. Per-developer long-lived branches guarantee a large, high-risk merge at exactly the moment there is no time for one. Branch-per-environment with manual copying reintroduces the drift that source control is supposed to eliminate — the branches diverge and nobody can say which is authoritative.

If the team moved to continuous delivery, trunk-based development with feature flags would become the better fit. The exam wants the strategy matched to the release cadence, not a single favourite.

Exam section: Building  ·  Difficulty: Medium

Correct answer: B. Adopt an org-based development model with source control first, and consider extracting well-bounded areas into unlocked packages incrementally once dependencies are understood

Package-based development requires clean dependency boundaries, and a decade of unbounded metadata does not have them. The achievable path is to put the existing org under source control and deploy from it — the org-based model — which delivers most of the governance benefit immediately, and then to extract genuinely self-contained areas into unlocked packages one at a time as their dependencies are mapped.

Attempting the full split up front stalls on circular dependencies and produces packages that cannot be installed in any order. Staying on change sets forgoes the benefit for no reason; legacy orgs work perfectly well under source control. A rebuild is disproportionate and carries far more risk than the problem it solves.

The useful test for whether an area is ready to become a package is whether you can list everything outside it that references it. If you cannot, it is not ready.

Exam section: Building  ·  Difficulty: Hard

Correct answer: D. Scratch orgs suit source-driven development where the environment's shape is defined in the project's configuration and can be recreated on demand; they are ephemeral, created from a Dev Hub, and do not contain a copy of the org's existing metadata or data

The defining property of a scratch org is that it is built from source rather than copied from an org. Its features and settings come from a scratch org definition file, its metadata comes from the repository, and its data comes from a seeding script. It is created from a Dev Hub, it is short-lived by design, and it is disposable — which is what makes it excellent for isolated feature work and per-branch continuous integration.

That same property is why it is not always preferable: if the team's metadata is not fully in source, a scratch org will be missing whatever is not, and reproducing a complex legacy org's shape in a definition file can be substantial work. Scratch orgs are not copies of production, so they are unsuitable for user acceptance testing, which needs production-like configuration and data. They are available to any org with Dev Hub enabled, not just partners.

In a mixed environment strategy it is common to use scratch orgs for feature development and continuous integration while retaining sandboxes for integration, UAT and staging.

Exam section: Building  ·  Difficulty: Medium

Correct answer: C. Agreed coding standards, mandatory peer review through pull requests, automated static analysis run on every pull request, and unit tests that assert behaviour rather than merely execute lines

Quality at the point of build comes from a layered set of cheap, automatic checks plus human review. Standards make review objective. Pull requests make review routine rather than exceptional. Static analysis catches the mechanical problems — queries and DML inside loops, missing sharing declarations, hard-coded identifiers — before a human looks at the code. Meaningful assertions are what turn a test from a coverage device into a defect detector.

Raising the coverage threshold alone is the classic false comfort: coverage measures which lines executed, not whether the behaviour was correct, and a test with no assertions can achieve full coverage while verifying nothing. Routing every class through one architect creates a bottleneck and does not scale. More manual regression testing finds defects later and more expensively, which is the opposite of the goal.

If you can only introduce one of these first, make it the pull request — it is the hook that every other check attaches to.

Exam section: Building  ·  Difficulty: Medium

Correct answer: A. Create the data the test needs inside the test context — typically through a shared test data factory, or from static resources loaded with Test.loadData — so that tests are self-contained and give the same result in any org

Unit tests must be deterministic and environment-independent, because they run in scratch orgs, sandboxes and production, and they run during deployment when nobody is watching. Creating the data in the test — through a factory class that other tests reuse, or from a static resource loaded with Test.loadData — is what guarantees the same result everywhere.

Querying existing records makes the test depend on whatever happens to be in the org, so it passes in the sandbox where it was written and fails during the production deployment. Loading a production extract into every sandbox is a data protection problem and does not make the tests deterministic anyway. SeeAllData=true is a targeted escape hatch for the small number of records that genuinely cannot be created in a test context; applying it everywhere reintroduces exactly the coupling you are trying to remove.

A shared factory is worth the effort for a second reason: when a validation rule or required field changes, you fix the factory once instead of every test class.

Exam section: Building  ·  Difficulty: Medium

Correct answer: D. Negative cases where the operation should fail and the error is asserted, bulk behaviour across a collection of records, and behaviour under different user permissions using System.runAs

A complete Apex test asserts three things beyond the happy path. Negative cases confirm that invalid input is rejected and that the error raised is the one intended. Bulk cases confirm the code behaves correctly and within governor limits when processing a collection rather than one record. Permission cases, written with System.runAs, confirm behaviour for users whose profile, permission sets or record access differ from the running user's.

Coverage alone is not the target, as the happy-path-only option assumes. Exhaustive field combinations are not achievable or useful. Live integration calls do not belong in unit tests at all — callouts must be mocked, using HttpCalloutMock or a stub, so the test does not depend on an external system's availability.

State the bulk case explicitly in an interview or exam answer. It is the one candidates most often omit, and it is the one that fails first in production.

Exam section: Building  ·  Difficulty: Medium

Correct answer: B. Make the version control repository the source of truth: developers commit to branches, changes are merged with conflicts resolved explicitly, and production is deployed from the merged mainline rather than from an individual sandbox

The defect here is that the org, not the repository, is being treated as the source of truth. When each deployment starts from an individual sandbox, the later deployment carries that sandbox's version of the file and silently reverts anything it did not know about. Merging in version control surfaces the conflict at merge time, where a human resolves it deliberately.

A file-locking calendar is a manual process that fails the first time someone forgets, and it does not scale past a handful of developers. A single shared sandbox replaces silent deployment overwrites with silent editor overwrites. More frequent refreshes narrow the window but do not close it, and they destroy in-progress work.

This scenario appears in some form on almost every sitting of this exam, because it is the clearest demonstration of why source control is an architectural requirement rather than a developer preference.

Exam section: Building  ·  Difficulty: Easy

Correct answer: A. Metadata API coverage is broad but not complete, and it varies by release — some org settings and feature enablement, and all record data, sit outside it — so the release plan must include a documented list of manual pre- and post-deployment steps verified against the current Metadata API coverage documentation

The architecturally important fact is that Metadata API coverage is broad, incomplete, and changes every release. Salesforce publishes the supported types in the Metadata API Developer Guide, and it is the architect's job to check that list against the release contents rather than assume. Record data is never deployed by the Metadata API, and some org-level feature enablement has to be done in Setup or requested from Salesforce.

Claiming the Metadata API supports every configuration change overstates its coverage; claiming it only supports code understates it dramatically, since it deploys the great majority of declarative configuration. Suggesting that anything unsupported can simply go by change set instead misunderstands the relationship between the two mechanisms: change sets are built on the same underlying metadata layer, so a type that is unsupported there is generally unavailable to change sets too.

The practical artefact is a deployment runbook with an explicit manual-steps section, kept under version control alongside the code and reviewed as part of the release.

Exam section: Deploying  ·  Difficulty: Medium

Correct answer: C. The reference data, because record data is not carried by a metadata deployment and must be loaded or deployed by a separate mechanism, and the activation state of the flow, because whether it deploys active depends on the org's configuration and test coverage

Two things reliably need separate handling. Record data is not metadata: pricing reference data stored in records has to be migrated by a data load or, if it is modelled as custom metadata type records, deployed alongside the metadata. And a flow's active state on deployment depends on the target org's settings and on flow test coverage, so a release that assumes a flow arrives switched on should verify that assumption rather than inherit it.

Record types deploy normally, so singling them out as undeployable is wrong. Required fields can be added to populated objects, though the population strategy for existing records is a real consideration. Assuming a single deployment handles all four automatically and in the correct order is the belief that causes the incident.

This is the argument for modelling configuration-style reference data as custom metadata types rather than custom setting or custom object records where the model allows it: custom metadata type records deploy with the metadata, which removes an entire class of release-day data steps.

Exam section: Deploying  ·  Difficulty: Hard

Correct answer: B. The Metadata API is designed for bulk retrieval and deployment of metadata to move configuration between orgs; the Tooling API is designed for fine-grained, interactive access to individual development components, supporting development tooling such as editors, debugging and test execution

The distinction is bulk migration versus granular development access. The Metadata API works with sets of components, typically driven by a package manifest, and is what deployment pipelines and change sets rest on. The Tooling API exposes individual development objects so that IDEs and development tools can read, modify, run tests against and debug specific components without retrieving and deploying whole sets.

They are distinct APIs with distinct purposes, so treating them as alternative names for the same thing is wrong. The split is not code versus configuration — both APIs address a range of component types. And the Tooling API has not replaced the Metadata API for deployment; that supposed Winter '23 changeover is an invented release milestone.

For the exam, the phrase worth remembering is that you deploy with the Metadata API and you develop against the Tooling API.

Exam section: Deploying  ·  Difficulty: Medium

Correct answer: D. Model them deliberately: values that must move with the release as custom metadata type records that deploy with the metadata, and values that are genuinely environment-specific as hierarchy custom settings or custom metadata records populated per environment by a documented post-deployment step

Technical reference data needs a deliberate split. Anything that is really part of the release — a lookup table the new code depends on — belongs in custom metadata type records, which deploy alongside the metadata and are therefore versioned and reviewable. Anything that legitimately differs per environment — an endpoint pointing at a sandbox integration, a switch that is off in production until go-live — must be excluded from the deployment and set per environment through a documented, repeatable step.

Hard-coding removes the administrator's ability to change the values, which is the requirement. A single custom object with manual export and import is what the customer is effectively doing now, and it fails on exactly the overwrite risk described. Static resources deploy with metadata but are an awkward and opaque place to hold values administrators are expected to edit.

Whichever model is chosen, the environment-specific values need to be recorded somewhere version-controlled — not as secrets in the repository, but as a documented inventory of what has to be set where.

Exam section: Deploying  ·  Difficulty: Hard

Correct answer: C. Run a validation-only deployment against production ahead of the window with the required test level, then use the resulting successful validation to perform a quick deploy inside the window, subject to the validity period for quick deploys

A validate-only deployment runs the full deployment including tests against production without committing anything. If it succeeds, Salesforce retains the result for a limited period, during which a quick deploy commits the already-validated payload without re-running the tests. That is precisely the mechanism for separating the expensive part from the maintenance window. Confirm the current validity period in Salesforce Help when you build the runbook, and note that the payload must not change between validation and quick deploy.

Production deployments of Apex require tests to run at the platform-defined level, so deploying with tests disabled and running them afterwards is not available. Sandboxes cannot be promoted to production. Splitting a release into many small deployments increases the number of failure points and the risk of deploying components in an order that leaves the org inconsistent.

Plan the validation early enough that a failure leaves time to fix and re-validate before the window, otherwise you have moved the risk rather than removed it.

Exam section: Deploying  ·  Difficulty: Medium

Correct answer: A. The org must meet the platform's overall Apex code coverage requirement for the deployment to succeed, and coverage is an aggregate measure across the org rather than a guarantee that any individual class is well tested

The platform enforces an aggregate Apex code coverage requirement for production deployments, and every trigger must have some coverage. It is an org-level gate, which is why a well-tested area can carry a poorly-tested one over the line. That is the architectural point: coverage is a floor imposed by the platform, not a measure of test quality, and an architect who reports coverage as a quality metric is reporting the wrong thing.

There is no per-class 75% gate, so the option describing one is wrong. Sandboxes do not enforce the coverage requirement in the way production does, which is why a deployment can pass in a sandbox and fail in production — the reverse of the claim that coverage is only checked when deploying to a sandbox. Production deployments run tests at the platform-defined level rather than at the deployer's discretion, so choosing to run no tests at all is unsafe as written.

Always confirm the current numeric thresholds and test-level behaviour in the Apex Developer Guide before writing them into a design document, because deployment behaviour is refined between releases.

Exam section: Deploying  ·  Difficulty: Medium

Correct answer: D. Change sets cannot delete components, so either delete them manually in production as a documented post-deployment step, or adopt a source-driven deployment that supports destructive changes as part of the release

Change sets are additive only. They cannot delete components from the target org, which is a real operational cost of the change set model and one of the strongest practical arguments for moving to source-driven deployment, where a destructive changes manifest lets removals travel with the release, be reviewed in a pull request, and be applied consistently to every environment.

Deleting metadata is supported — manually, and through destructive changes in a metadata deployment — so the claim that no mechanism allows it is wrong. Change sets themselves offer no way to mark a component for deletion, which rules out that route as well. Sandboxes cannot be deployed wholesale over production; deployments move selected components, not entire orgs.

Whichever route is chosen, deletions need their own review discipline: confirm nothing references the component, take the removal through the same environments as any other change, and be explicit that deleting a field destroys its data.

Exam section: Deploying  ·  Difficulty: Medium

Correct answer: B. Build an automated regression suite covering the critical business processes, run it on every build and before every release, and retain a smaller manual pack for exploratory testing and genuinely subjective checks

Release frequency and manual regression are in direct conflict: at monthly cadence a three-week manual pack consumes the cycle. The resolution is to automate the repeatable regression across critical business processes so it runs in minutes on every build, and to spend the remaining human testing effort on exploratory work and on judgements automation cannot make.

Pruning the pack to recently-failing tests is survivorship bias — it removes exactly the tests that have been protecting the areas that have not broken. Apex unit tests are necessary but not sufficient: they test code units, not end-to-end business processes, declarative automation or the user interface. Extending the cycle abandons the requirement rather than meeting it.

Sequence the automation by business criticality and by how often the path changes; automating the stable, high-value paths first gives the fastest return.

Exam section: Testing  ·  Difficulty: Medium

Correct answer: A. Run unit tests and static analysis on every commit in development and continuous integration, functional and integration tests in the integration environment, user acceptance testing with business users in UAT, and performance, data-volume and full end-to-end rehearsal in the production-like staging environment

Each environment supports the tests its fidelity and cost allow. Fast, cheap, deterministic checks belong early and on every commit. Tests that need integrated components belong in the integration environment. Business acceptance needs business users and realistic configuration. Performance and volume testing need production-scale data, which only the most production-like environment provides.

Running everything everywhere wastes the cycle time that early environments exist to protect, and user acceptance testing in a development sandbox produces feedback on an environment nobody will use. Concentrating all testing in staging pushes every defect to the most expensive point to fix it. Deferring testing to production with a phased rollout is not a testing strategy — it is using customers as the test environment.

The principle worth stating explicitly is that the cost of fixing a defect rises with the distance from where it was introduced, which is what makes the ordering above an economic argument rather than a stylistic one.

Exam section: Testing  ·  Difficulty: Medium

Correct answer: C. Point out that coverage measures which lines executed during tests, not whether behaviour was verified — a test with no meaningful assertions raises coverage without detecting defects — and that coverage says nothing about declarative automation, integrations or the user interface

Coverage is an execution metric, not a verification metric. A test that calls a method inside Test.startTest() and asserts nothing contributes to coverage identically to a test that asserts every output. And a Salesforce release is mostly not Apex: flows, validation rules, sharing configuration, integrations and the user experience carry substantial risk that Apex coverage does not measure at all.

There is no industry threshold at which coverage becomes evidence of low risk. Chasing 100% usually produces more assertion-free tests, making the metric less informative rather than more. Abandoning Apex tests discards a genuinely valuable and automatically-enforced safety net.

The better assurance story combines assertion quality (are outcomes actually checked?), business process coverage (which critical journeys have automated regression?), and defect trends over recent releases.

Exam section: Testing  ·  Difficulty: Medium

Correct answer: B. Define one test data strategy across the stack: mask or synthesise sensitive fields whenever data leaves production, seed lower environments with generated or masked data through a repeatable process, and treat any environment holding real data as in scope for the same controls as production

The requirement is a single strategy applied consistently, not a per-environment decision. Sensitive fields are masked or synthesised at the point data leaves production; lower environments are seeded by a repeatable process so they can be rebuilt after every refresh; and any environment that does hold real data — typically a Full sandbox before masking completes — inherits production's access controls, logging and retention obligations for as long as it does.

Copying unchanged data and relying on profiles ignores that a sandbox typically has weaker operational controls, a wider audience and a longer life than anyone assumes. Insisting on synthetic data everywhere including production support investigations is unworkable, because some defects only exist in the real data. Letting each team invent its own data set is how orgs end up with tests that pass in one environment and fail in the next.

Masking is also a scheduling constraint: it has to run as part of the sandbox refresh process, before the environment is opened to its users, and it should be automated rather than remembered.

Exam section: Testing  ·  Difficulty: Hard

Correct answer: D. Execution of the critical-path regression suite in a sandbox on the new release during the preview window, targeted testing of the features named in the release notes that touch the customer's customisations, and a review of announced retirements and known issues

Platform release regression is risk-targeted. Run the critical-path suite to catch broad breakage, then add focused testing where the release notes intersect the customer's own customisations — changed behaviour on an object the code depends on, an altered default, a retiring feature. The retirement and known-issues review is the part teams most often skip and the part that most often produces a surprise.

Treating the platform release as an ordinary release ignores the fact that the change was not made by your team and is not described by your own release notes. Testing only new features misses the regressions that matter. Re-running everything ever written is neither achievable in the preview window nor a good use of it.

Record the results against the release name, because the same analysis is required three times a year and the previous pass tells you which areas are historically fragile.

Exam section: Testing  ·  Difficulty: Medium

Correct answer: C. Define entry and exit criteria for UAT — what must be complete and already tested before UAT begins, what scenarios will be executed, how defects are triaged and severity-rated, and what constitutes acceptance — and agree them with the business before the cycle starts

UAT that overruns and produces scope disputes almost always lacks agreed entry and exit criteria. Entry criteria stop UAT being used as a substitute for functional testing that should already have happened. A defined scenario set stops the scope argument. An agreed triage and severity model stops every finding becoming a blocker. Acceptance criteria let the cycle end.

Removing UAT discards the only stage where the people who will actually use the system evaluate it. Extending until no defects are found is an open-ended commitment, since testing does not converge to zero. Running UAT in production exposes real users and real data to unreleased functionality.

The severity model deserves particular attention: most UAT overruns come from cosmetic findings being raised at the same priority as functional failures, and that is a definition problem rather than a testing problem.

Exam section: Testing  ·  Difficulty: Medium

Correct answer: A. Managed package built in an org with a registered namespace

A managed package is the only model that gives an ISV all three: a registered namespace that isolates its components from the subscriber's, protection of the package's source, and a supported upgrade path that lets the publisher ship new versions to installed orgs.

An unmanaged package is a one-time copy: its components land as ordinary, editable components in the subscriber org, there is no namespace isolation and no upgrade path. An unlocked package is upgradeable and version-controlled, but its metadata is visible and editable in the installed org, which does not meet an intellectual property requirement; it is designed for a customer's own internal modularisation rather than for commercial distribution. Change sets only work between orgs in the same deployment lineage, so they cannot reach customer orgs at all.

The corresponding constraint to state in the same breath is that managed packages restrict what the publisher can change or remove in later versions, which is why package design deserves care before the first release rather than after it.

Exam section: Releasing  ·  Difficulty: Easy

Correct answer: D. Unlocked packages, which are versioned and upgradeable, can be developed from source control, and leave the installed metadata visible and editable in the org

Unlocked packages are designed for exactly this: internal modularisation with version history, an upgrade path, and source-driven development, while the metadata remains visible and editable in the installed org — which is what an internal team needs when it has to inspect or urgently adjust something in production.

Managed packages would lock the customer out of its own configuration and impose ISV constraints for no benefit. Unmanaged packages have no upgrade path, so every change means a full re-release with manual reconciliation. Staying monolithic is the status quo the requirement is asking to move away from, and it makes independent team cadences impossible.

The prerequisite is honest dependency analysis. Unlocked packages only deliver independent cadence if the boundaries are genuinely independent; packages that reference each other's internals recreate the monolith with extra ceremony.

Exam section: Releasing  ·  Difficulty: Medium

Correct answer: B. Unmanaged package

An unmanaged package is a one-time transfer of components that become ordinary, fully editable metadata in the target org, with no link back to the publisher and no upgrade path. When the requirement is explicitly "take this, own it, we will not be updating it", that is the correct fit — a template rather than a product.

A managed package would prevent the client modifying the components and would create an ongoing support relationship the consultancy has said it does not want. An unlocked package with a retained namespace implies continued publisher involvement for the same reason. A sandbox cannot be handed over as a deliverable; sandboxes belong to the production org that created them.

Be explicit with the client that unmanaged means unsupported: once installed, the components are theirs, and any later improvements from the consultancy would arrive as a separate install with manual reconciliation.

Exam section: Releasing  ·  Difficulty: Easy

Correct answer: A. A release train: a fixed, published cadence with a defined code-freeze, regression and go-live calendar, where work that is ready by the cut-off joins the release and work that is not waits for the next departure, plus a separate hotfix path for urgent production fixes

A release train decouples team progress from release scheduling. The dates are fixed and published, so the business can plan; teams join the train when ready rather than negotiating a date each time; and because the cadence is frequent, missing one is a short wait rather than a crisis. The separate hotfix path is what stops the fixed cadence becoming a reason to bypass the process.

Releasing on demand from three teams into one production org means overlapping, uncoordinated changes to shared metadata and no stable regression baseline. Three independent monthly releases triples the regression effort against a target that each team's release changes. An annual release maximises batch size, which maximises both the risk and the difficulty of diagnosing what broke.

The train's credibility depends entirely on the cut-off being enforced. The first time an exception is made for a late feature, the cut-off stops being a date and becomes a negotiation.

Exam section: Releasing  ·  Difficulty: Medium

Correct answer: C. A rehearsed recovery plan that states, per component, whether recovery is by forward fix or by redeploying the previous version, how data created since go-live will be handled, who authorises the decision, and how long each route takes

There is no general undo for a Salesforce deployment, so a recovery plan has to be specific and rehearsed. For each component you decide in advance whether the route is a forward fix or a redeployment of the prior version; you decide what happens to records created against the new configuration since go-live, because those do not disappear when metadata is reverted; you name the person who authorises the call; and you know the elapsed time of each route, because that is what the decision actually turns on.

Salesforce Support does not roll production back to a point in time on request. A sandbox cannot be deployed over production. A change set of previous versions is a partial and misleading comfort: it cannot restore deletions, it does not address data created since go-live, and it is untested precisely when it is needed.

Rehearsal is the part that gets cut and the part that matters. A recovery plan that has never been executed in a staging environment is a document, not a capability.

Exam section: Releasing  ·  Difficulty: Hard

Correct answer: B. Assign environments by purpose: development environments per stream, a shared integration environment where the streams merge, a production-like staging environment for UAT and rehearsal, a training environment refreshed to a known state before each cohort, and a hotfix environment matching the current production release

Environments are assigned by the job they do, and the release plan then states which environment each activity happens in and when each is refreshed. Streams need isolation to develop and a shared place to integrate. UAT and rehearsal need production-like configuration and data. Training needs a stable, known state that does not shift under a cohort mid-course. Hotfixes need an environment that matches what is live now, not what is being tested.

Giving every stream a Full sandbox is expensive, constrained by the long Full sandbox refresh interval, and multiplies the amount of production data being copied around. One sandbox for everything reproduces the shared-environment overwrite problem and makes training, UAT and development contend for the same org. Training in production risks real data and real automation firing on practice records.

State the refresh calendar alongside the assignment. An environment strategy without refresh dates drifts into a set of orgs nobody trusts.

Exam section: Releasing  ·  Difficulty: Medium

Correct answer: D. Managed packages impose upgrade constraints — certain component changes and removals are restricted once released to subscribers — so the version must be designed to preserve compatibility for installed orgs, with deprecation handled deliberately

The defining property of a released managed package is that subscribers depend on it and the publisher cannot freely take things away. Salesforce restricts certain changes and removals after a component has shipped, precisely so that an upgrade does not break an installed org's data, integrations or extensions. Version planning therefore means designing for compatibility and handling removals through deprecation rather than deletion.

Version numbers are functional, not cosmetic — they determine upgrade paths and what a subscriber is running. Managed package upgrades install over the existing version rather than requiring an uninstall, which is the whole point of the model. And upgrades are not applied to every subscriber simultaneously; publishers must expect a range of installed versions in the field, which is exactly why testing against earlier versions matters.

Check the current upgrade and deprecation rules in the ISVforce guidance before committing a package roadmap, since the specifics differ by component type and are refined over time.

Exam section: Releasing  ·  Difficulty: Hard

Correct answer: C. Identify the changes, retrofit them into version control and into the lower environments so the source of truth and the environments match production, and then address why the pipeline was bypassed

Production changes that are not in source control create drift, and drift is what causes the next release to silently overwrite them. The correct sequence is to find them — Setup Audit Trail and a metadata comparison between production and the repository are the usual tools — bring them into the repository and into the lower environments, and only then look at the process question.

Reverting working changes the business depends on damages trust and does not address the cause. Permanently excluding components from deployments creates an unmanaged island that grows over time and eventually blocks unrelated work. Refreshing sandboxes aligns the environments but leaves the repository wrong, which is the copy that governs future deployments.

The process conversation matters as much as the retrofit. If the pipeline could not deliver an urgent change in an acceptable time, the administrator's behaviour was rational and the pipeline needs an emergency path rather than the administrator needing a reprimand.

Exam section: Operating  ·  Difficulty: Medium

Correct answer: A. A mandatory retrofit step: the change is recorded, committed to version control and applied to the lower environments within a defined period, and the emergency is reviewed afterwards

Emergency paths are legitimate; what makes them safe is the obligation to reconcile afterwards within a defined window. Without it, each emergency permanently widens the gap between the repository and production, and the drift is discovered only when a release overwrites something the business now depends on. The post-incident review is what stops the emergency path becoming the ordinary path.

Restricting who may make the change controls authorisation, not drift. Restricting when it happens does nothing about reconciliation. Prohibiting emergency changes entirely is not credible — teams will do it anyway and simply stop telling you, which is strictly worse than a governed path.

Set the retrofit window in hours or days, not "as soon as possible", and track outstanding retrofits somewhere visible. An unbounded obligation is not an obligation.

Exam section: Operating  ·  Difficulty: Medium

Correct answer: D. Extract the shared components into versioned packages built from a single shared repository, and install and upgrade them into each org on that org's own schedule

The requirement is one source, many consumers, independent schedules, and that is what versioned packages built from a shared repository provide. Each org installs a specific version and upgrades when its own release calendar allows, while the shared code has one place it is developed, reviewed and tested.

Copying from a nominated master org is manual, unversioned and drifts again immediately, because there is no record of which org has which version. Merging four production orgs is a multi-year programme and a wildly disproportionate response to shared components. Accepting the divergence is the status quo that produced four incompatible versions of the same audit logging.

The governance addition is a defined owner for the shared packages and a policy on supported version skew — how far behind an org may fall before it must upgrade — otherwise the packages become four copies again with more ceremony.

Exam section: Operating  ·  Difficulty: Hard

Correct answer: B. A sandbox refresh is a point-in-time copy for development and testing, not a backup: it is constrained by refresh intervals, it is not designed for selective restore into production, and a genuine strategy needs a defined recovery point and recovery time objective supported by an appropriate backup mechanism and a tested restore procedure

A sandbox refresh is a development artefact. Its cadence is governed by the sandbox refresh interval rather than by a recovery point objective, and there is no supported mechanism for selectively restoring records from it back into production with their relationships intact. Backup and restore is a design with stated objectives: how much data loss is tolerable, how quickly the business must be operational, what mechanism meets those, and — critically — a restore that has actually been tested.

Refreshing more often does not turn a copy into a restore capability. Salesforce does not offer an on-request point-in-time restore of any org as a standard service; customers are responsible for their own backup strategy, using Salesforce's backup offering, the export service, or a partner product. A weekly export is a component of a strategy, not a strategy: it needs a stated recovery point objective, a restore procedure, and a test.

The line worth remembering is that nobody has a backup until they have completed a restore.

Exam section: Operating  ·  Difficulty: Medium

Correct answer: A. Setup Audit Trail reviewed on a regular cadence, together with an automated metadata comparison between production and the version control repository that reports differences to the release owner

Detection needs one event source and one state source. Setup Audit Trail tells you what was changed, by whom and when, over a defined retention window. An automated comparison between production metadata and the repository tells you what is different right now, regardless of who did it or whether it was recorded. Together they catch both the change that was made and the drift that accumulated.

Interviews rely on memory and goodwill. Restricting the administrator profile is an access control that reduces the number of people who can cause drift without detecting the drift that remains — and it will not survive contact with operational reality. A quarterly retrieve stored on a shared drive is a snapshot nobody compares against anything.

Route the comparison's output to the person accountable for the release rather than to a distribution list, and give it a defined action: every difference is either retrofitted into the repository or reverted, with a recorded decision.

Exam section: Operating  ·  Difficulty: Medium