Explanation

Change Sets are a declarative, point-and-click deployment tool in Salesforce. They have well-known limitations that an architect must consider.

A is correct because Change Sets are inherently manual — they are built and deployed through the Setup UI by selecting components and clicking "Deploy." They cannot be scripted, scheduled, or integrated into a CI/CD pipeline. This makes them unsuitable for automated, source-driven deployment workflows, which is a major consideration when choosing a deployment strategy.

D is correct because Change Sets cannot be rolled back. Once deployed, there is no built-in undo. To reverse a Change Set, you must manually recreate and deploy a new Change Set containing the previous versions of the components (or use another tool like the Metadata API with a backup). This lack of rollback is a significant risk consideration.

E is correct because Change Sets can only be used between orgs that are affiliated with the same production org (i.e., a production org and its sandboxes, or sandbox-to-sandbox within the same org family). They cannot be reused between unrelated Production Salesforce orgs — you can't deploy a Change Set from one company's production to another's. This limits their use for distributing changes across independent orgs.

Together, A, D, and E capture the core limitations: no automation, no rollback, and restricted to affiliated orgs.

Why Other Options Are Incorrect

B. Change Sets cannot be validated before deployment — This is false. Change Sets can be validated before deployment — Salesforce provides a "Validate" option that performs a dry run (deploy without committing), running tests and checking for errors. So this is not a limitation.

C. Change Sets cannot be used for orgs affiliated with the same production org — This is false and backwards. Change Sets are specifically designed to work between orgs affiliated with the same production org (production ↔ sandboxes). This is exactly the scenario they do support.

References

* Salesforce Help – Change Sets: Manual creation/deployment; only between affiliated orgs; no rollback.

Explanation

During Apex testing, developers often hit governor limits because test methods execute in the same transaction context as setup data creation and assertions. Salesforce provides Test.startTest() and Test.stopTest() to address this.

When a test method calls Test.startTest(), Salesforce resets the governor limits for the code that follows, giving that block a fresh set of limits. This isolates the actual code being tested from the setup work (data creation) that ran before it. Test.stopTest() marks the end of that block and also forces any asynchronous jobs (future methods, batch, queueable) to execute synchronously so they can be asserted.

This is the official, recommended Salesforce pattern to avoid governor limit failures in tests and to properly test code.

Why Other Options Are Incorrect

B. AppExchange product to increase governor limits
— No AppExchange product can raise Salesforce governor limits. These limits are enforced by the platform and cannot be temporarily increased by third-party tools.

C. Auto reset property during off-hours
— There is no such feature. Governor limits reset per transaction, not on a time-based schedule.

D. Test.setLimit() and Test.resetLimit()
— These methods do not exist in Apex. This is a fabricated option.

References

* Salesforce Developer Docs – Apex Testing: Using Test.startTest() and Test.stopTest() — "Using startTest and stopTest to Test Governor Limits."

* Apex Developer Guide – Execution Governors and Limits: Limits are per-transaction and reset with Test.startTest().

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.

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.

Explanation

UC is moving from the org development model to the package development model using scratch orgs. To do this, the administrator must enable the correct Dev Hub settings.

The key setup steps for the package development model are:

1. Enable Dev Hub — Dev Hub is the required prerequisite for creating scratch orgs and for building unlocked packages and second-generation managed packages (2GP). Without Dev Hub, none of the package development model works.

2. Enable Second-Generation Managed Packages — This setting must be turned on to create and version 2GP managed packages (and it's also required for unlocked packages, which build on the same packaging infrastructure).

Since UC is moving to the package development model, the administrator needs to enable both Dev Hub and Second-Generation Managed Packages.

Why Other Options Are Incorrect

B. Enable Unlocked Packages, keep Second-Generation Managed Packages disabled — This is incorrect because the package development model requires 2GP to be enabled. Keeping 2GP disabled prevents creating packaged artifacts, and the option also omits enabling Dev Hub, which is the foundational prerequisite. You cannot build packages without Dev Hub.

C. Enable Unlocked Packages and Second-Generation Managed Packages — This omits enabling Dev Hub, which is mandatory for scratch orgs and packaging. While it lists the two package settings, without Dev Hub the whole model fails. It's an incomplete answer.

D. Enable Dev Hub, then enable Source Tracking for Scratch Orgs — Source tracking is a feature that tracks changes between a scratch org and version control. It is useful but not required to adopt the package development model, and the option omits the package enablement setting. Enabling source tracking alone doesn't enable packages.

References

Salesforce Developer Docs – Enable Dev Hub: Required for scratch orgs and packaging.

Salesforce Developer Docs – Second-Generation Managed Packages / Unlocked Packages: Requires Dev Hub and 2GP enabled in Setup.