AZ-400 Question 168
Single answerYour DevOps team frequently encounters critical production bugs requiring immediate fixes ahead of the regular release schedule. You need to design a reliable hotfix path that allows you to implement and deploy high-priority code fixes quickly while preserving code stability. Which approach should you implement?
- A
Create a dedicated hotfix branch from the main (production) branch, apply the fix, run targeted tests, deploy, and then merge changes back into the development branch.
- B
Commit the hotfix directly onto the development branch, approve it with a single code review, and merge into the main (production) branch without separate testing.
- C
Clone the repository, apply changes only in the cloned repo, and merge back to the main branch at the next scheduled sprint review.
- D
Wait until the next sprint to include the fix in the standard release cycle, ensuring that it goes through all existing stages from development to production.
Show answer and explanation
Correct answer: A
Explanation
A dedicated hotfix branch from the production branch is a standard approach recommended by many branching models (including GitFlow) provided by Microsoft and others. This method prioritizes rapid resolution of critical bugs while ensuring necessary testing and approval steps are followed. Once validated, merging the fix back into development preserves consistency and prevents regression in future releases. Refer to Microsoft� documentation on branching strategies for further guidance.
- A. Correct.
This is correct. Creating a short-lived hotfix branch from the production (main) branch, resolving the issue, running targeted validation tests, and deploying ensures minimal disruption while fixing the bug quickly. Afterwards, merging changes back into development helps keep all branches in sync.
- B. Incorrect.
This approach ignores important pipeline stages and relies heavily on the development branch. It risks embedding untested emergency fixes into ongoing development work and can lead to instability or regression.
- C. Incorrect.
Keeping fixes in a separate, standalone clone and merging them at a later sprint review delays critical deployments. This approach lacks a reliable, fast feedback loop and does not align with typical DevOps best practices.
- D. Incorrect.
Waiting for the next release cycle is not appropriate for high-priority issues that must be addressed immediately. This approach disregards the urgency of fixing critical production bugs.