Free Salesforce-Platform-Development-Lifecycle-and-Deployment-Architect Practice Test Questions (2026)

A.   There is a $T test helper object that can be used to create the instance of the Lightning component, and it is promise enabled.

D.   The testing can be viewed in the lightning.force.com/c/jasminetests.app URL. The page loads and runs Jasmine test and writes pass/fail information to the screen.

Explanation

Salesforce provides a native Aura component testing framework based on Jasmine and a test helper object called `$T`.

A is correct because the `$T` test helper (available via the Aura test framework) is used to create instances of Lightning/Aura components in tests, and its methods return promises. This promise-enabled design lets developers chain `.then()` calls to handle asynchronous component behavior cleanly — essential since Aura components are asynchronous by nature.

D is correct because the Aura test framework exposes a test runner page at the `/c/jasminetests.app` URL in a Salesforce org. Navigating to this page loads and runs the Jasmine tests and displays pass/fail results on screen. This is the standard way to execute Aura component tests.

Together, A and D describe the two key knowledge points: the `$T` helper (A) for writing tests and the Jasmine test runner URL (D) for executing and viewing results.

Why Other Options Are Incorrect

B. JavaScript tested in Jest; Apex controllers via test classes
— Jest is the framework used for testing Lightning Web Components (LWC), not Aura components. While Apex controllers are indeed tested with Apex test classes, the JavaScript portion of Aura components is tested with the Jasmine-based Aura test framework, not Jest. This option conflates Aura and LWC testing.

C. Install the Lightning test service AppExchange package
— There is no AppExchange package required to enable Aura component testing. The Aura test framework is built into the platform (via `$T` and the Jasmine test runner). No external package installation is needed.

References

Aura Components Developer Guide – Testing Aura Components: `$T` helper, `$T.createComponent()`, and promise-based testing.

Aura Components Developer Guide – Jasmine Test Runner: Accessing `/c/jasminetests.app` to run and view test results.

A.   Developers often have to turn to the debug log for details of the failed Apex executions.

C.   An Apex process runs into an un-handled exception when an HTTP callout has an unexpected status code in the response body.

D.   Developers constantly ask the testers for a screenshot of the error and the exact steps of reproducing the error.

Explanation

Inadequate negative unit testing means the tests do not sufficiently verify how the code behaves when unexpected, invalid, or error conditions occur. As a result, error handling problems are discovered later by developers or testers instead of being caught during unit testing.

A is correct because developers having to rely on debug logs to understand failed Apex executions can indicate that tests are not adequately covering error conditions or validating expected failures. Strong negative tests should intentionally exercise invalid inputs and exception scenarios and clearly verify the expected behavior, reducing the need to investigate failures manually through debug logs.

C is correct because an unhandled exception caused by an unexpected HTTP status code indicates that the code does not properly handle an error response. Negative unit tests should simulate unexpected callout responses, such as error status codes, and verify that the application handles them gracefully. If this scenario reaches production as an unhandled exception, it is a common sign that negative testing is insufficient.

D is correct because developers repeatedly needing screenshots and exact reproduction steps from testers suggests that error scenarios are not being adequately anticipated and covered by automated negative tests. Comprehensive negative tests should reproduce known failure conditions automatically and verify the expected error handling, reducing dependence on manual reproduction by testers.

Why Other Options Are Incorrect

B. When an Apex batch job runs at a scheduled time, an increased number of Apex execution errors occur over all.
— Scheduled batch execution errors do not specifically indicate inadequate negative unit testing. Batch jobs can fail for many reasons, including data problems, configuration issues, limits, or infrastructure conditions. The symptom described does not directly identify a lack of tests for negative scenarios.

E. The delivered user interfaces are regularly not meeting the expectations of the business users.
— This is primarily a functional or requirements-validation problem rather than a symptom of inadequate negative unit testing. Negative tests focus on invalid inputs, exceptions, error conditions, and unexpected behavior. Business users finding that the interface does not meet their expectations is more closely related to requirements, usability, or user acceptance testing.

References

Salesforce Apex Developer Guide – Testing Apex: Unit testing guidance, including testing expected behavior and exception scenarios.

Salesforce Apex Developer Guide – Testing HTTP Callouts: Guidance for testing callout behavior and handling simulated responses and errors.

C.   Avoid releasing near peak business periods.

Explanation

Universal Containers is highly seasonal and approaching its busiest period. A major production release near peak business season introduces significant risk: if the release causes defects, performance issues, or downtime, the business could suffer lost revenue and customer impact during its most critical window.

The recognized ALM best practice is to freeze deployments / avoid major releases during peak business periods. Instead, schedule releases for a low-traffic window so that:

* Any issues can be detected and resolved without impacting peak business.
* Rollback/remediation can happen with minimal business disruption.
* Support and engineering teams are fully available (not consumed by peak operations).

This is a standard release governance recommendation in Salesforce ALM and enterprise change management.

Why Other Options Are Incorrect

A. Make declarative changes in production only
— This violates ALM best practice. Changes should flow through sandboxes and version control, never be made directly in production. Direct production changes bypass testing and audit trails, increasing risk — especially dangerous before peak season.

B. Bypass regression testing for minor changes
— Regression testing should never be bypassed, even for "minor" changes. Untested changes can break existing functionality, and before peak season the risk is magnified. Skipping regression testing contradicts quality governance.

D. Developers should conduct user acceptance testing
— UAT must be performed by business users/stakeholders, not developers. Developers testing their own work creates bias and misses business-level validation. This is a clear separation-of-duties violation.

References

Salesforce Trailhead – Application Lifecycle Management: Release management and deployment windows.

A.   Refresh all non-preview sandboxes during the release preview window.

Explanation

When a major Salesforce release is approaching, orgs that participate in preview get the new release first, while non-preview sandboxes stay on the current (old) version until the release is rolled out to production. This creates a version mismatch: preview sandboxes run the new release, but non-preview sandboxes still run the old release.

For a deployment train (a chain of sandboxes used to promote changes toward production), this mismatch is a serious problem. If non-preview sandboxes remain on the old version while preview sandboxes are on the new version, testing and deployments may behave inconsistently, and changes validated in preview may not behave the same in non-preview.

The architect should recommend refreshing all non-preview sandboxes during the release preview window so the entire deployment train runs on the same release version. This ensures:

* Consistent behavior across all environments in the train.
* Testing reflects what production will run after the release.
* Deployments don't fail due to version differences.

Aligning all sandboxes to the same release during the preview window is the standard ALM recommendation.

Why Other Options Are Incorrect

B. No advice needed; mixing instance types is important for regression testing
— Mixing preview and non-preview instances is not desirable for a deployment train. Version mismatches cause inconsistent test results and deployment failures. It's not a deliberate regression-testing strategy.

C. Refresh all non-preview sandboxes when the release management team has time
— Timing matters. Refreshes must happen during the preview window, not "whenever there's time." Waiting until after the preview window means the sandboxes may already be on the new release (or misaligned), defeating the purpose and risking deployment failures.

D. Contact support to rollback the release when Salesforce upgrades the sandboxes
— Salesforce does not roll back releases on request. Sandbox upgrades to a new release are irreversible. This is not a valid option and reflects a misunderstanding of the release process.

References

* Salesforce Help – Preview Sandboxes and Release Windows: Preview vs. non-preview instance behavior during releases.
* Salesforce Trailhead – Application Lifecycle Management: Aligning sandboxes to the same release during preview.

A.   GitHub flow

Explanation

When a major Salesforce release is approaching, orgs that participate in preview get the new release first, while non-preview sandboxes stay on the current (old) version until the release is rolled out to production. This creates a version mismatch: preview sandboxes run the new release, but non-preview sandboxes still run the old release.

For a deployment train (a chain of sandboxes used to promote changes toward production), this mismatch is a serious problem. If non-preview sandboxes remain on the old version while preview sandboxes are on the new version, testing and deployments may behave inconsistently, and changes validated in preview may not behave the same in non-preview.

The architect should recommend refreshing all non-preview sandboxes during the release preview window so the entire deployment train runs on the same release version. This ensures:

* Consistent behavior across all environments in the train.
* Testing reflects what production will run after the release.
* Deployments don't fail due to version differences.

Aligning all sandboxes to the same release during the preview window is the standard ALM recommendation.

Why Other Options Are Incorrect

B. No advice needed; mixing instance types is important for regression testing
— Mixing preview and non-preview instances is not desirable for a deployment train. Version mismatches cause inconsistent test results and deployment failures. It's not a deliberate regression-testing strategy.

C. Refresh all non-preview sandboxes when the release management team has time
— Timing matters. Refreshes must happen during the preview window, not "whenever there's time." Waiting until after the preview window means the sandboxes may already be on the new release (or misaligned), defeating the purpose and risking deployment failures.

D. Contact support to rollback the release when Salesforce upgrades the sandboxes
— Salesforce does not roll back releases on request. Sandbox upgrades to a new release are irreversible. This is not a valid option and reflects a misunderstanding of the release process.

References

Salesforce Help – Preview Sandboxes and Release Windows: Preview vs. non-preview instance behavior during releases.

Salesforce Trailhead – Application Lifecycle Management: Aligning sandboxes to the same release during preview.

C.   Managed package

Explanation

UC's innovative apps division is releasing an application that will be installed in external trading partners' Salesforce environments (different orgs owned by third parties). The division also wants to keep the application up to date across all those environments over time.

This is the textbook use case for a Managed Package:

Distributable to external orgs — Managed packages are designed to be installed in other Salesforce orgs, including partner/customer orgs.

Upgradeable — UC can release new versions of the managed package, and partners can upgrade to receive fixes and enhancements, keeping every environment current.

IP protection — Managed packages hide the source code, protecting UC's intellectual property (unlike unmanaged packages).

Namespace isolation — A managed package uses a namespace, preventing naming conflicts with the partner's own code — critical because partners will build on top of the app with their own Process Builders and triggers.

AppExchange / versioning support — Managed packages support versioning and can be listed/distributed formally.

Because partners extend the app with their own automation, namespace isolation and upgradeability are essential — both provided by managed packages.

Why Other Options Are Incorrect

A. Change sets
— Change sets are used to move metadata between orgs in the same production/related org structure (e.g., sandbox → production). They cannot be used to distribute an app to external, unrelated partner orgs. Wrong mechanism entirely.

B. Unmanaged package
— Unmanaged packages expose all source code, offer no IP protection, and cannot be upgraded once installed. Partners would receive a one-time copy with no way to receive future updates — directly contradicting UC's requirement to keep the app up to date. Unmanaged packages are intended for one-time distribution (e.g., templates), not ongoing app distribution.

D. Zip file deployable by SFDX or ANT
— A zip/metadata deployment is a developer tool for moving metadata between orgs, not a distribution/packaging mechanism for external partners. It provides no versioning, no upgrade path, no namespace isolation, and requires the partner to run deployment tooling. Not suitable for distributing an app to trading partners.

References

Salesforce ISVforce Guide – Managed Packages: Distribution to external orgs, upgrades, and IP protection.

Salesforce Developer Docs – Unmanaged vs. Managed Packages: Managed packages support upgrades and hide source; unmanaged do not.

D.   Using Git, create a release branch from the develop branch. All fixes must be made in the release branch. After deployment, merge release with develop.

Explanation

The scenario: a sprint is complete, changes are awaiting business approval before production deployment, but the team wants to immediately start the next sprint. This is the classic "release in flight while development continues" problem.

The release branch strategy (from GitFlow) solves this cleanly:

1. Create a release branch from `develop` when the sprint is complete. This branch represents the code that will go to production.

2. The team starts the next sprint on `develop` (or new feature branches) — development continues uninterrupted.

3. Any fixes needed during UAT/approval are made on the release branch, not on `develop`, so the pending release is stabilized without being polluted by new, unfinished sprint work.

4. After deployment to production, the release branch is merged back into `develop` so fixes are not lost and the two lines converge.

This isolates the pending release from ongoing development, allowing both to proceed in parallel — exactly what UC needs.

Why Other Options Are Incorrect

A. First task of the new sprint must be deployment approval
— This blocks the new sprint on the previous release's approval. It couples the new sprint's start to an external approval gate, delaying work and defeating the purpose of starting the next sprint immediately.

B. Migrate code to UAT, begin new sprint in Dev, make fixes in UAT and deploy
— This creates a divergent branch problem: fixes made in UAT are not tracked in version control and won't flow back to Dev/develop. It risks losing fixes and creating environment drift. It also lacks a structured branching mechanism.

C. Commit upcoming changes to feature branches without merging to develop; deploy from develop, then merge new sprint features
— This is confusing and incorrect. It says to deploy from `develop` (which already contains the completed sprint), but the handling of feature branches and merge order is muddled. It doesn't provide a clean isolated release branch for stabilizing the pending release.

References

Salesforce Trailhead – Application Lifecycle Management: Branching strategies and release management.

GitFlow Branching Model (Vincent Driessen): Release branches isolate pending releases while development continues on `develop`; merge back after deployment.

B.   Use the Sandbox Preview Guide to check if there is any necessary action needed. UC might have to prepare, refresh, and redeploy to UAT.

Explanation

UC's timeline is the key: UAT in 2 weeks, production release in 4 weeks, and a major Salesforce release in 6 weeks. UC wants to release on the current version but also verify the new release won't break anything. This is a sandbox preview planning problem.

Salesforce publishes a Sandbox Preview Guide for every major release. It is the authoritative source for:

Preview cutoff dates — the date by which a sandbox must be refreshed (or not) to land on the preview vs. stay on the current version.
Which sandbox types are eligible for preview.
Required actions — e.g., when to refresh a sandbox so it's on the version you need.

Since UC's sandboxes were refreshed two months ago, their preview status depends on the cutoff dates relative to now. The architect can't assume outcomes — they must check the Preview Guide and may need to prepare, refresh, and redeploy to align Stage and UAT with the correct versions (e.g., keep one on the current release for UAT, and use the other on preview for regression against the new release).

Why Other Options Are Incorrect

A. Refresh Stage now, do not refresh UAT; Stage will be on preview and UAT will not
— This is speculative. Preview assignment depends on refresh timing vs. the preview cutoff, not a simple "refresh = preview / don't refresh = no preview" rule. The Guide must be consulted.

C. Visit [trust.salesforce.com](https://trust.salesforce.com/) for preview cutoff dates; work with support to get on the preview instance
— `trust.salesforce.com` shows service status/maintenance, not sandbox preview cutoff dates. And you cannot request support to place a sandbox on preview — preview status is determined by refresh timing, not support action.

D. Refresh Stage from UAT; after cutoff use the upgraded one for regression, non-upgraded one for UAT
— This is convoluted and based on assumptions about which sandbox gets upgraded. Refreshing Stage from UAT is not a standard action, and the plan presumes version outcomes without consulting the Preview Guide.

References

* Salesforce Help – Sandbox Preview Guide: Published per major release; defines preview cutoff dates, eligible sandboxes, and required actions.
* Salesforce Help – Sandbox Preview Instructions: Refresh timing determines preview vs. non-preview status.

A.   No manual steps should be carried out.

C.   Any production change should have explicit stakeholder approval.

Explanation

In a highly regulated and audited environment, every production change must be traceable, repeatable, and formally approved. Auditors require evidence that changes followed a controlled, documented process — not ad-hoc human actions.

A is correct because manual steps are the enemy of auditability. Manual changes (clicking in Setup, editing metadata directly in production) are hard to track, reproduce, and prove to auditors. Automated, scripted deployments (CI/CD, version-controlled metadata) produce a consistent, repeatable, and auditable trail — exactly what regulated environments demand. Eliminating manual steps ensures every change is captured and verifiable.

C is correct because regulated environments require explicit stakeholder approval before production changes. Approval gates provide the authorization evidence auditors look for — proving that changes were reviewed and sanctioned by accountable parties before going live. This is a core control in change management (e.g., SOX, HIPAA, GDPR compliance).

Together, A and C ensure production changes are controlled (approval) and auditable (no manual steps) — the two foundational requirements of a regulated change process.

Why Other Options Are Incorrect

B. All changes including hotfixes should be reviewed against Salesforce Partner security principles
— "Salesforce Partner security principles" is not a recognized standard for reviewing internal production changes. While security review is important, this option misstates the requirement and references an irrelevant framework (partner security applies to ISV/AppExchange partners, not general production change control).

D. After deployment, the development team should test and verify functionality in production
— This violates separation of duties, a key audit control. The development team should not be the ones verifying their own changes in production — verification should be done by an independent party (e.g., QA, business users, or a separate release team). Allowing developers to self-verify undermines the audit trail and independence required in regulated environments.

References

Salesforce Well-Architected Framework – Security & Operational Excellence: Change control and auditability in regulated environments.

Salesforce Trailhead – Application Lifecycle Management: Automated deployments and approval gates.

A.   Plan this as a minor release with training and change management.

Explanation

NTO has changes to its opportunity renewal process — a workflow and a trigger. These are business-process changes within a single functional area, not a broad, cross-org overhaul. The scope is small and contained, which fits the definition of a minor release.

Critically, the changes affect how users work (the opportunity renewal process), so the release must include training and change management to ensure users adopt the new process smoothly. Minor releases don't mean "no communication" — they still need proper rollout, documentation, and user enablement.

The architect should recommend treating this as a minor release with training and change management — proportional governance matched to the change's scope and user impact.

Why Other Options Are Incorrect

B. Plan as a major release and align with a Salesforce major release
— A workflow and trigger for one process is too small to warrant a major release. Aligning with a Salesforce major release would delay the change unnecessarily (Salesforce releases are only 3x/year) and add overhead disproportionate to the scope.

C. Plan as an interim release after checking with Salesforce support
— There is no need to involve Salesforce Support for deploying your own workflow and trigger changes. "Interim release" tied to Salesforce Support is not a real release type for customer-authored changes.

D. Plan as a patch release and align with a Salesforce patch release
— Patch releases refer to Salesforce's own post-release bug fixes to the platform, not customer deployments. Customers don't "align with Salesforce patch releases" for their own metadata changes. Wrong concept entirely.

References

Salesforce Trailhead – Application Lifecycle Management: Release types (major, minor, patch) and proportional governance.

Salesforce Well-Architected Framework – Operational Excellence: Matching release process to change scope.