Refer to the Exhibit Practice Questions

The policy should include 'Require device to be marked as compliant'.

Why wrong: Adding device compliance would not affect PAT authentication.

The policy should be scoped to 'All cloud apps' instead of just Azure DevOps.

Why wrong: Scoping to all cloud apps would not change how PATs are treated.

The Conditional Access policy is not enabled.

Why wrong: The exhibit shows a configured policy, but the issue is that PATs bypass Conditional Access.

0 builds, because the excluded path takes precedence.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 Azure Active Directory/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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Only the Test stage.

Why wrong: The Build stage runs first because the push to main matches the trigger include, but the Test stage's condition evaluates to false for refs/heads/main, so Test is skipped. Thus, only the Test stage cannot be the result.

Neither stage.

Why wrong: At least the Build stage runs because the push to main satisfies the branch trigger's include filter, so saying neither stage runs is incorrect.

Both Build and Test stages.

Why wrong: While the Build stage runs due to the main trigger, the Test stage does not execute because its condition explicitly fails for the main branch. Therefore, both stages running is not the outcome.

The pipeline runs only if the PR is merged

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 parameter file is missing the '$schema' property.

Why wrong: The exhibit explicitly includes the '$schema' property, so this option incorrectly claims it is missing. In ARM parameter files, '$schema' is a required metadata URI that identifies the parameter file schema, but its absence would produce a schema validation error, not a value-matching failure for the 'sku' parameter. The reported error is about the value not being in the allowed list, which is independent of the '$schema' property.

The 'sku' parameter is defined in the 'variables' section instead of 'parameters'.

Why wrong: In a parameter file, there is no 'variables' section; parameters are always declared under the top-level 'parameters' object, and the exhibit correctly does that. The error is a value validation failure, not a structural placement issue, because the ARM template's parameter definition for 'sku' specifies allowed values that the provided value does not match. Placing the parameter in 'variables' would be syntactically invalid in a parameter file and would cause a different error, not the one described.

The ARM template expects a different API version for the resource.

Why wrong: An API version mismatch typically produces errors like 'The resource type could not be found' or 'Unsupported api-version', not parameter value validation errors. The error here is specifically about the 'sku' parameter value not matching the allowed values defined in the template's parameters section, which is a template logic issue rather than an API version problem. Even if the API version changed, the allowed values for 'sku' are defined by the parameter declaration and would remain the same unless the template itself is updated.

The pipeline will trigger and run all steps because the branch name does not match any exclude pattern.

Why wrong: This is incorrect because the branch name starts with 'feature/', which directly matches the exclude pattern 'feature/*' defined in the pipeline trigger. As a result, the pipeline is explicitly prevented from triggering on this branch, regardless of any include patterns or step definitions. The exclude rule takes precedence and suppresses all pipeline runs for matching branches.

The pipeline will trigger only the restore and build steps, skipping tests.

Why wrong: This is incorrect because the pipeline is not triggered at all, so no steps, including restore, build, or test, will run. The exclude pattern 'feature/*' causes the pipeline to skip the entire execution for this branch, not just a subset of steps. The step visibility is irrelevant since the pipeline never starts.

The pipeline will trigger but fail with an error because the branch is not in the include list.

Why wrong: This is incorrect because the exclude rule takes precedence over include rules; the branch is explicitly excluded, so the pipeline will not trigger. There is no error or failure during execution because the pipeline is never initiated. The absence from an include list is irrelevant when an exclude pattern matches the branch name.

The deployment name already exists in the resource group.

Why wrong: Reusing a deployment name is allowed within a resource group's deployment history; ARM treats a redeployment as an update, not an error. A duplicate deployment name would produce a conflict on the deployment record itself (e.g., 'Deployment 'X' already exists'), not an InvalidTemplateDeployment error with a resource-level inner error like user conflict.

The resource group location does not match the template location.

Why wrong: The resource group location is not compared to the template location because ARM templates are region-agnostic and can deploy resources to any location supported by the subscription. A location mismatch would surface during resource creation as a 'NoRegisteredProviderFound' or 'InvalidLocation' error, not as an InvalidTemplateDeployment error with an inner user conflict.

The template has a syntax error in the JSON.

Why wrong: A JSON syntax error in the template would prevent the deployment from being parsed and would return an 'InvalidTemplate' error code, not 'InvalidTemplateDeployment'. Since the error message references a resource conflict, the template must have passed syntax validation and failed during resource provisioning.

The VM size is not available in the specified location.

Why wrong: This option is incorrect because the failure occurs during template validation and is reported as a parameter-related error, not a SKU or capacity issue. The error message points to a missing parameter definition, not to the availability of a specific VM size. Additionally, the template itself would be considered invalid by the ARM deployment engine before any location-specific SKU validation is performed.

The resource group location is invalid.

Why wrong: This option is incorrect because the error is clearly associated with the parameter section of the ARM template, not with the resource group's location. ARM template validation checks for missing parameter definitions independently of the target resource group's region, so an invalid location would surface as a different error, such as 'The provided location is not valid' or a location-specific policy failure. The existing note is correct and reflects that the root cause is the missing adminPassword parameter.

The parameter 'adminPassword' is misspelled in the template.

Why wrong: This option is incorrect because the parameter name 'adminPassword' is spelled consistently in both the osProfile section and the parameters section's potential declaration. The actual problem is that no such parameter is declared at all, not that it is misspelled; a typo would typically produce a different error about an unresolved parameter reference. Since the template is missing the parameter definition entirely, the ARM engine cannot map the osProfile value to any declared parameter, leading to the 'not defined' error.

The pipeline requires a manual trigger.

Why wrong: This is incorrect because the pipeline includes an explicit `trigger:` block, meaning a CI trigger is active and pushes automatically initiate evaluation against branch filters. A manual trigger would instead require the pipeline definition to specify `trigger: none` or require a user to click Run when no CI trigger exists. Since the trigger is present, the pipeline does not rely on a manual kick-off.

The pipeline has a CI trigger disabled.

Why wrong: The CI trigger is not disabled; it is configured, but only for the `main` branch. With `trigger: none` or no trigger block at all, Azure DevOps would disable automatic CI, but here the YAML contains a branch-scoped trigger. Thus the pipeline is not globally disabled, just filtered by branch.

The pool 'ubuntu-latest' is not available.

Why wrong: The `ubuntu-latest` pool is a Microsoft-hosted agent that is widely available in Azure DevOps, so it would not be the cause of a trigger failure. More fundamentally, agent pool selection only affects where a job executes after the pipeline is triggered; it has no role in determining whether a push to `devel` starts the pipeline. The absence of a run must be explained by the branch filter, not the pool.