Letting Only Release Managers Merge from Develop into Main
You are a DevOps engineer for a large enterprise that uses GitHub Enterprise Cloud. The development team follows a GitFlow branching strategy with develop, feature, release, and main branches. The release branch is created from develop when a release is ready. After testing, the release branch is merged into main and then tagged. However, the team frequently forgets to merge release branches back into develop, causing hotfixes applied to main to not be in develop. You need to implement an automated process to ensure that after a release branch is merged into main, the changes are also merged back into develop. The solution must not require manual intervention and must handle merge conflicts gracefully by opening a pull request for conflict resolution. Which approach should you use?
⚠ Common exam trap
Many candidates choose a scheduled workflow (Option C) thinking it is sufficient, but it fails to handle merges that occur between scheduled runs and does not gracefully manage merge conflicts by opening a pull request.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Create a GitHub Actions workflow that triggers on push to main, attempts to merge main into develop, and if conflicts occur, opens a pull request for manual resolution.
It uses a GitHub Actions workflow triggered on pushes to main to automatically merge main into develop. If conflicts arise, the workflow opens a pull request for manual resolution, ensuring no changes are lost and the process remains automated without manual intervention.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure a branch protection rule on main that requires a pull request to merge into develop.
Why it's wrong here
Branch protection rules enforce required PRs and status checks, but they do not automate the merge process; developers still have to manually create and complete a pull request, so this policy alone cannot synchronize main into develop.
- ✓
Create a GitHub Actions workflow that triggers on push to main, attempts to merge main into develop, and if conflicts occur, opens a pull request for manual resolution.
Why this is correct
This workflow triggers on every push to main, uses a script or git commands to merge main into develop, and if conflicts arise, it creates a pull request for manual conflict resolution, providing timely automation while preserving human oversight for conflicting changes.
- ✗
Create a scheduled workflow that runs daily and merges main into develop if there are no conflicts.
Why it's wrong here
A scheduled daily workflow is not event-driven, so it may merge main into develop hours after a release or before dependent changes are finalized; also, merging without any conflict check or review can unintentionally introduce unreviewed changes.
- ✗
Set up a webhook in GitHub that calls an Azure Function to merge main into develop.
Why it's wrong here
A GitHub webhook is only an HTTP notification; it fire-and-forgets a JSON payload to a configured endpoint. An Azure Function would need to be fully built to validate the payload, authenticate to GitHub, perform a git merge, and manually handle merge conflicts—none of which is provided by the webhook itself. Without built-in conflict resolution, this approach often fails on conflicting changes and leaves main and develop diverged, with no automatic PR for human review. Additionally, webhooks have no native retry or status reporting mechanism, making the pipeline less reliable and harder to monitor than a GitHub Actions workflow.
Go deeper
Related to this question
Learn chapter
Designing and Implementing Instrumentation Strategy
Key term
DevOps
DevOps is a set of practices that combines software development (Dev) and IT operations (Ops) to shorten the development lifecycle and deliver high-quality software continuously.
Key term
Feature
A feature is a distinct unit of functionality that delivers value to the user, often managed and tracked throughout the software development lifecycle.
About these practice questions
One of 696 original AZ-400 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Refer to the exhibit. The YAML pipeline triggers on commits to main and develop branches, and pull requests targeting develop. A developer pushes a commit directly to main. What will happen?
medium- A.The pipeline does not run because the PR trigger requires a pull request.
- ✓ B.The pipeline runs once for the CI trigger.
- C.The pipeline runs twice: once for the CI trigger and once for the PR trigger.
- D.The pipeline runs once for the PR trigger only.
Why B: The pipeline is configured with a CI trigger for both main and develop branches, and a PR trigger only for pull requests targeting develop. When a developer pushes a commit directly to main, the CI trigger fires because the push matches the main branch, causing the pipeline to run once. The PR trigger does not activate because there is no pull request involved.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.