Refer to the Exhibit Practice Questions

The pull request is automatically merged because allowed merge types include squash.

Why it fails: Allowing squash as a merge type only controls which merge strategies are available for completion; it does not automatically merge the pull request. A PR is only auto-completed when all branch policies are satisfied, and here the approval policy is not met due to require_last_push_approval dismissing approvals after the last push. Thus, the merge is blocked, not automatic.

The approvals are dismissed because require_last_push_approval is true.

Why it fails: This is the correct explanation. With require_last_push_approval set to true, the policy explicitly requires that the most recent push in the pull request has an appproval; any new push automatically dismisses all earlier approvals. Even if dismiss_stale_reviews is false, the last-push requirement takes precedence, so the current commits are unapproved and the merge is blocked.

The pull request is blocked because the merge type is not allowed.

Why it fails: Squash and rebase are both explicitly allowed in the merge type policy, so the merge type is not blocking the pull request; the actual block is due to the missing valid approval after the last push.

0 builds, because the excluded path takes precedence.

Why it fails: The excluded path does not blindly outrank included paths; Azure Pipelines evaluates the set of changed files against the include/exclude filters as a whole. A build is triggered whenever any changed file matches an include, even if other files match an exclusion. Since the change set contains an included path, the excluded path cannot suppress the build, so zero builds is impossible.

3 builds, because maxConcurrentBuildsPerBranch is 1 but batchChanges overrides.

Why it fails: maxConcurrentBuildsPerBranch controls the maximum number of builds that can run simultaneously for a branch, not the number of builds triggered by a single push. Setting it to 1 means one build runs at a time; any additional triggered builds would wait in the queue, but batchChanges already consolidates all changes from the same push into a single build. Therefore, the concurrency limit does not multiply the trigger count to three.

2 builds, one for each modified folder.

Why it fails: The trigger is branch-conditioned and path-filtered, but it does not iterate over folders and create one build per folder; a single push is processed as one event. When batchChanges is enabled, every change in that push is folded into one build, so having changes in two modified folders does not yield two builds. This option confuses path filtering (which merely includes or excludes files) with build-per-path semantics.

The Prod environment requires manual approval before deployment.

Why it fails: The preDeployApprovals array is empty, confirming no manual approval gates are configured for Prod; additionally, a manual approval would block on human sign-off and trigger an 'awaiting approval' state rather than waiting on Dev's deployment status, so this cannot explain the observed dependency.

The release definition ID 5 is incorrect.

Why it fails: The release was created successfully using release definition ID 5, which proves the ID is valid and accepted by the API; an invalid definition ID would cause the creation request to fail outright, not selectively delay a single environment's deployment.

The build artifact with ID 123 is not accessible.

Why it fails: If artifact ID 123 were inaccessible, the release would fail at artifact download for every environment that attempts to deploy it, including Dev; since Dev is the first environment and succeeds, the artifact is clearly accessible, and Prod's delay can only be attributed to pre-deployment environment conditions.

Add the 'actions/setup-node' action

Why it fails: The 'actions/setup-node' action only installs and configures a specified version of Node.js in the runner environment. It does not interact with Azure or establish any kind of Microsoft Entra ID/Microsoft Entra ID session, so it cannot resolve the authentication failure that occurs when the workflow tries to execute Azure CLI commands.

Add the 'azure/webapps-deploy' action

Why it fails: The 'azure/webapps-deploy' action is used to deploy an application to an existing Azure Web App, but it requires an already-authenticated Azure session (typically established by a prior 'azure/login' step). It performs deployment operations only and does not handle authentication, so adding it alone would still result in the same authentication failure for the Azure CLI commands.

Add the 'actions/github-script' action to use the GitHub token

Why it fails: The `actions/github-script` action executes JavaScript and can use the `github.token` context, but that token is scoped only to the GitHub repository and has no permissions against Azure resources. The deployment fails because the Azure CLI requires an authenticated session with Microsoft Entra ID, which the GitHub token cannot provide. This option is tempting because `github-script` is commonly used to interact with the GitHub API, and developers may mistakenly assume its token extends to external cloud services. It would be correct for tasks like creating a GitHub issue or comment, where repository-scoped authentication suffices.

Runs the pipeline on all branches with the variable.

Why it fails: The command explicitly specifies `--branch main`, so the pipeline runs only on the `main` branch, not on all branches. The `--variables` parameter defines a run-time variable for this single execution, but branch scoping remains limited to the value supplied to `--branch`.

Runs the pipeline and sets a secret variable.

Why it fails: Variables passed via `--variables` in `az pipelines run` are plain text and are not marked as secret. To supply secret variables to a pipeline run, you would need to use the `--variables-secret` parameter or reference secret variables from the pipeline's library or variable groups.

Creates a new pipeline named 'MyPipeline' with a variable.

Why it fails: The `az pipelines run` command is used to execute an existing pipeline, not to create a new one. Creating a pipeline would require a different command such as `az pipelines create`, which has its own parameters for defining the pipeline and its variables.

The pipeline runs only if the PR is merged

Why it fails: Merging a PR is not an Azure Pipelines trigger by itself; merge completion only indirectly starts a run if the destination branch is in the CI trigger list. Since the YAML limits CI to develop and main and the PR target/branch is not one of those, the merged commit still won't trigger this pipeline, so it does not run at all.

The pipeline runs as a CI build on the feature branch

Why it fails: The YAML's `trigger` (CI) block is explicitly scoped to `develop` and `main`, not to feature branches. Therefore, pushing commits to the feature branch does not satisfy the branch filter and no automatic CI build is started.

The pipeline runs as a PR validation build

Why it fails: The `pr` (pull request validation) trigger is configured only for `main`, so PRs targeting a feature branch will not invoke this pipeline. Because the PR in the exhibit targets a feature branch (not `main`), no PR validation build is created.

GitLab Flow

Why it fails: GitLab Flow uses environment branches such as production and staging, but it typically integrates feature branches via merge requests that can be rebased or squashed, avoiding the dense, non-linear merge-commit graph shown here. The exhibit's many simultaneous merge commits are more indicative of a branch-per-feature strategy that never linearizes history.

Trunk-based development

Why it fails: Trunk-based development encourages short-lived feature branches that are either rebased onto main before merging or merged directly via single commits, producing a strictly linear history. The exhibited history with multiple merge commits fanning out and converging violates that principle, so it cannot be trunk-based.

GitHub Flow

Why it fails: GitHub Flow uses feature branches off main and merges them via squash or rebase merges by default, which flattens each feature into a single commit and keeps the main branch history linear. The visible merge commits with branched topology contradict GitHub Flow's typical clean history, making it the wrong choice.

The resource group name is incorrect.

Why it fails: The resource group name is not the cause of the failure; it is correctly spelled and matches the resource group referenced elsewhere in the pipeline. An incorrect resource group would generate a different error during deployment, not an authentication failure.

The DEPLOYMENT_SLOT setting name is invalid.

Why it fails: DEPLOYMENT_SLOT is a valid variable name and aligns with standard Azure App Service deployment slot naming conventions. The pipeline fails due to missing authentication, not due to an invalid setting name, as the setting would be evaluated later in the execution.

The script syntax is invalid.

Why it fails: The script syntax is invalid. This is not the cause of the failure because the AzureCLI@2 task authenticates to Azure before executing any script content. If the service connection is missing or misconfigured, the task fails during the authentication phase, so the script is never parsed or run. Even if the script had a syntax error, it would produce a different, script-specific error message (e.g., from the shell or Azure CLI), not an authentication-related failure. Therefore, the syntax cannot be responsible for the pipeline error shown in the exhibit.

The last person who pushed can approve the pull request.

Why it fails: Because blockLastPusherReview is enabled, the most recent pusher of commits to the source branch is blocked from approving the PR, even if they are a valid reviewer. This prevents authors from self-approving their own changes.

Pull requests to main are automatically squash-merged.

Why it fails: The branch policy's requireSquashMerge attribute is set to false, so squash merging is not mandated nor automatically applied when completing a pull request. With this setting, PRs can be completed using any allowed merge type, such as a standard merge commit or rebase, depending on the user's selection. Thus, the claim that PRs to main are automatically squash-merged misreads a false boolean as an enforced behavior.

Approvals are reset when the source branch is updated.

Why it fails: Since isResetOnSourcePush is explicitly set to false, pushing new commits to the source branch does not invalidate approvals that have already been granted. If this flag were true, any new commit would reset all existing approvals and require fresh reviews before completion. Because the policy disables that reset, approvals remain valid across updates, making the statement that approvals are reset when the source branch is updated factually incorrect.

The audit logs are not enabled for the container registry.

Why it fails: The query is actively returning results from the AuditLogs table, which proves that diagnostic and audit settings are enabled for the container registry; if audit logs were disabled, the KQL query would return no audit events, not a pattern of failed operations.

The container registry is misconfigured and allowing anonymous pushes.

Why it fails: The log entries reflect repeated authentication failures during push attempts, which demonstrates that the registry requires valid credentials and is not configured to allow anonymous pushes; anonymous access would result in successful operations without authentication errors.

The 'contoso/api' repository has been successfully pulled by an unauthorized user.

Why it fails: The query shows failed pull operations against the 'contoso/api' repository, meaning that any unauthorized user's attempts to pull were rejected due to insufficient permissions; a successful unauthorized pull would be logged as an allowed operation, not as a failure.

Define the parameter in the 'parameters:' section of the YAML pipeline.

Why it fails: YAML pipeline parameters are compile-time inputs that control pipeline execution, not values passed to the Bicep deployment. They must be explicitly consumed by tasks, and simply defining a parameter doesn't inject it into the ARM template deployment—use overrideParameters to map pipeline variables to Bicep parameters.

Use a task to replace the string '${environment}' in the Bicep file before deployment.

Why it fails: Bicep files compile into ARM templates where parameter substitution is handled by the deployment engine; manually replacing placeholders is redundant and fragile. It also breaks the declarative nature of Bicep and makes the pipeline less maintainable because you're modifying code artifacts instead of passing parameters.

Modify the Bicep file to include a default value for environment.

Why it fails: A default value would apply only when no override is provided, so it cannot vary across deployment stages without explicit overrides. It might be useful for local development, but in a multi-stage pipeline you still need to pass different values via overrideParameters, otherwise all stages would deploy to the same environment.

The Deploy stage will be skipped

Why it fails: The Deploy stage will not be skipped because the default condition succeeded() evaluates to true when the Build stage completes successfully. Since the Build stage succeeded, the Deploy stage is allowed to run, so this option incorrectly predicts a skip.

Deploying to dev

Why it fails: Although a variable named 'environment' might originally be set to 'dev' elsewhere, the Deploy stage explicitly overrides it to 'prod' within that stage's variable scope. Stage variables take precedence over pipeline-level variables for the duration of the stage, so the script cannot output 'Deploying to dev'.

The script will fail because variable is not defined

Why it fails: The script will not fail because the variable 'environment' is defined at the Deploy stage level in the variables section. Azure DevOps resolves $(environment) to the defined stage value, so the script has a valid variable reference and executes without an undefined-variable error.

The branch filter is missing the 'refs/heads/' prefix.

Why it fails: Azure Pipelines branch filters do not require the 'refs/heads/' prefix; you can specify branch names directly such as 'main' or 'features/*'. The 'refs/heads/' prefix is optional and omitting it is valid syntax, so this is not a problem.

The trigger configuration has a syntax error: 'include' should be 'includes'.

Why it fails: In Azure Pipelines YAML, the trigger element uses a plural key 'include' for listing branches, paths, or file patterns to include. The singular 'includes' would be incorrect, so the configuration as written is syntactically valid.

The variable 'buildConfiguration' is not defined at the top level.

Why it fails: The variable 'buildConfiguration' is defined at the top level under the 'variables' key, making it available to compilation and all jobs. Its value 'Release' is set correctly, and the variable substitution in the buildConfiguration parameter is valid.

An error because the query syntax is incorrect

Why it fails: The Azure CLI --query parameter uses JMESPath, and the given expression is syntactically valid because it correctly combines a filter condition (location == 'eastus') with a projection (name, resourceGroup). Therefore, the command runs successfully and does not produce a query syntax error.

A list of all VMs in the subscription

Why it fails: The JMESPath query explicitly includes the condition location == 'eastus', which restricts the result set to VMs in the East US region only. Since VMs in other locations are filtered out, the output is not a list of all VMs in the subscription.

A list of all VMs in the westus location

Why it fails: The query condition specifies location == 'eastus', not 'westus', so all matching VMs are within the East US region. VMs located in West US are excluded by this filter, so the listed VMs are not from the westus location.

The policy will only apply if the storage account is in a specific resource group

Why it fails: The policy's rule does not include a resourceGroup field or a location condition; it targets all storage accounts within the assignment scope. The condition evaluates only the resource type and the supportsHttpsTrafficOnly property, so it is not restricted to any specific resource group.

The storage account will be created but HTTPS will be enforced

Why it fails: The policy effect is 'deny', not 'modify' or 'deployIfNotExists'. Deny blocks the resource creation request before the storage account is provisioned, so it cannot enforce HTTPS by altering the resource after creation—the request is simply rejected.

The storage account will be created and an audit event will be logged

Why it fails: The policy uses the 'deny' effect, whereas an audit effect only logs compliance information in the activity log. Because this is a deny policy, the resource creation is blocked rather than allowed with an audit event being recorded.