Question 1
Choose 1
Universal Containers (UC) has multiple teams with major projects working concurrently in their own
developer sandboxes. After deploying to production, a bug is discovered. Due to tight timelines, the
development team has suggested correcting the bug in the user acceptance testing (UAT) environment, which
is a full copy sandbox.
What should the architect recommend?
Correct answer:
A. UC should spin up a new sandbox to use as a hot fix environment. Once the bug is corrected, the
change should be applied to production and downstream environments.
Explanation
The correct answer is A. When a production bug must be fixed quickly and outside the normal release cycle, the recommended practice is to create a dedicated hot fix environment (a separate sandbox) rather than fixing directly in a shared environment like UAT. A hot fix sandbox keeps the urgent fix isolated from the ongoing project work happening in other sandboxes, prevents interference with UAT testing cycles, and allows the fix to be developed, tested, and validated properly. Once verified, the hot fix should be deployed to production and then propagated to downstream environments (such as UAT and other sandboxes) so those environments remain in sync with production and the fix is not accidentally overwritten by later deployments.
Why the Other Options Are Incorrect
B. The fix should be made in the developer environment where the project work was done. – Fixing directly in the original developer sandbox risks entangling the urgent bug fix with in-progress project changes that are not yet ready for production. Those incomplete changes could be pulled into the fix deployment, introducing new bugs or scope creep. It also breaks the isolation needed for a controlled hot fix and can disrupt the normal project cadence rather than protecting it.
C. Since the issue was found in production, it should be treated as a change request and go into the backlog as an enhancement. – A production bug that impacts live users is generally treated as a defect requiring prompt action, not deferred as an enhancement in the backlog. Unless it is purely cosmetic or truly non-critical, routing it through the normal backlog would delay the fix and contradict the tight timelines and production impact described. Treating it strictly as a backlog enhancement is not appropriate when production is actively affected.
D. Correcting the bug in UAT is ideal. Since UAT is a full copy, it will be the fastest location to fix and test the resolution. – Fixing directly in UAT is risky because UAT is typically a shared environment used for ongoing testing by multiple teams. Changes made there can interfere with other teams' testing, may not be properly version-controlled in source, and can be lost or overwritten during the next sandbox refresh or release cycle. It also violates separation of concerns between environments and undermines a controlled deployment process. Speed alone is not a sufficient reason to bypass proper environment discipline.
Reference
Salesforce Architect documentation on Application Lifecycle Management and Environment Strategy; Salesforce Sandbox documentation (types, refresh behavior, and isolation); Salesforce recommended practices for hot fixes and release management.
The correct answer is A. When a production bug must be fixed quickly and outside the normal release cycle, the recommended practice is to create a dedicated hot fix environment (a separate sandbox) rather than fixing directly in a shared environment like UAT. A hot fix sandbox keeps the urgent fix isolated from the ongoing project work happening in other sandboxes, prevents interference with UAT testing cycles, and allows the fix to be developed, tested, and validated properly. Once verified, the hot fix should be deployed to production and then propagated to downstream environments (such as UAT and other sandboxes) so those environments remain in sync with production and the fix is not accidentally overwritten by later deployments.
Why the Other Options Are Incorrect
B. The fix should be made in the developer environment where the project work was done. – Fixing directly in the original developer sandbox risks entangling the urgent bug fix with in-progress project changes that are not yet ready for production. Those incomplete changes could be pulled into the fix deployment, introducing new bugs or scope creep. It also breaks the isolation needed for a controlled hot fix and can disrupt the normal project cadence rather than protecting it.
C. Since the issue was found in production, it should be treated as a change request and go into the backlog as an enhancement. – A production bug that impacts live users is generally treated as a defect requiring prompt action, not deferred as an enhancement in the backlog. Unless it is purely cosmetic or truly non-critical, routing it through the normal backlog would delay the fix and contradict the tight timelines and production impact described. Treating it strictly as a backlog enhancement is not appropriate when production is actively affected.
D. Correcting the bug in UAT is ideal. Since UAT is a full copy, it will be the fastest location to fix and test the resolution. – Fixing directly in UAT is risky because UAT is typically a shared environment used for ongoing testing by multiple teams. Changes made there can interfere with other teams' testing, may not be properly version-controlled in source, and can be lost or overwritten during the next sandbox refresh or release cycle. It also violates separation of concerns between environments and undermines a controlled deployment process. Speed alone is not a sufficient reason to bypass proper environment discipline.
Reference
Salesforce Architect documentation on Application Lifecycle Management and Environment Strategy; Salesforce Sandbox documentation (types, refresh behavior, and isolation); Salesforce recommended practices for hot fixes and release management.