AZ-400 Question 166
Single answerYour team is responsible for maintaining a critical web application running in production. A high-severity defect has been identified that impacts core functionality, and you need to implement an emergency hotfix with minimal disruption. Which approach should you take to ensure the fix is quickly deployed to production and properly merged back into ongoing development work?
- A
Create a dedicated hotfix branch from the current release branch, fix and test the code, deploy to production, and then merge the hotfix back into the main branch and any relevant release branches.
- B
Immediately fix the code directly in the production environment without version control to expedite delivery.
- C
Make the change in the existing feature branch, wait for the next routine release cycle, and then merge into production.
- D
Delete the existing release branch and create a fresh main branch to apply the fix and redeploy everything from scratch.
Show answer and explanation
Correct answer: A
Explanation
A proper hotfix path plan typically involves creating a short-lived hotfix branch from the production or release branch, implementing and testing the fix, then deploying to production. After the fix is confirmed, changes should be merged back into both the main and relevant release branches. This ensures all codebases remain in sync while delivering an urgent fix. Refer to Microsoft documentation on branching strategies and release flow (https://learn.microsoft.com/en-us/azure/devops/repos/git/branching-guidance) for best practices.
- A. Correct.
Correct. This approach aligns with standard hotfix branching strategies. Creating a hotfix branch from the release branch allows you to isolate the fix, test it thoroughly before deployment, and then merge it back into the main branch and any other affected release branches to maintain code consistency.
- B. Incorrect.
Incorrect. Applying fixes directly to the production environment bypasses version control and proper testing. This is risky because it can introduce regression issues, and you lose track of changes in your repository, making it difficult to merge or rollback.
- C. Incorrect.
Incorrect. Waiting for the next routine release cycle isn�t appropriate for a critical defect that needs immediate resolution. Holding off the fix could leave the application in a broken state for too long.
- D. Incorrect.
Incorrect. Deleting the existing release branch and recreating the main branch is highly disruptive and not a recommended practice. It undoes previous release planning and complicates traceability of changes.