Hard Difficulty Questions

Use of service principal with least privilege

Why it fails: While a service principal with least privilege is a critical security best practice for authenticating Azure DevOps to Azure resources, it is an implementation detail of authentication rather than a core factor that shapes the overall release pipeline design.

Single environment deployment

Why it fails: Designing for a single environment deployment is insufficient because release pipelines typically progress through dev, test, and production environments to incrementally validate changes; relying on one environment eliminates the staging and approval phases that reduce deployment risk.

The pipeline run was triggered by a PR merge, and the approval needs to be re-applied after the build completes.

Why it fails: Wrong: Approval for an environment is tied to the specific pipeline run and its commit, so a PR merge does not retroactively invalidate an existing approval; the approval remains valid for the run that triggered it, and only a new run would need approval.

The build pipeline includes a step that modifies the approval settings.

Why it fails: Wrong: Azure Pipelines does not allow pipeline steps to modify environment approval settings, because approvals are configuration defined at the environment or pipeline level, not accessible via build tasks; attempting to do so would be outside the API scope of tasks.

The approver is not a member of the security group defined in the approval settings.

Why it fails: Wrong: The scenario states the approver is authorized in the security group, so membership is not the issue; the re-approval is triggered by the commit changing, not by an authorization failure.

Use pre-commit hooks to scan for secrets

Why it fails: Client-side, not integrated with Copilot.

Disable GitHub Copilot for the organization

Why it fails: Overly restrictive.

Enable secret scanning for the repository

Why it fails: Detects after commit.

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.

Set the 'Timeout in minutes' for the entire stage to 15.

Why it fails: Setting the stage timeout to 15 minutes applies an overall deadline for the entire stage, so if any task (including pre-deployment or other post-deployment tasks) runs too long, the stage is cancelled. It does not specifically target the manual validation task, and when the timeout is hit the stage is cancelled rather than the deployment being explicitly rejected, so it fails to provide the intended 'reject on timeout' behavior.

Configure a pre-deployment approval with a timeout of 15 minutes.

Why it fails: Pre-deployment approvals in Azure DevOps have a timeout, but when the timeout expires the approval is merely expired—it is not automatically rejected. By default, an expired approval does not block the deployment; it simply removes the pending approval, which could actually allow the deployment to continue, defeating the requirement to reject within 15 minutes.

Add a PowerShell task after the manual validation that checks the status and cancels the pipeline if not approved.

Why it fails: A PowerShell task after the manual validation cannot 'cancel' the pipeline; at best it can throw an error to fail a single task. Moreover, because tasks run sequentially, the PowerShell task would only execute after the manual validation has already completed (either approved or rejected), so it cannot retroactively enforce a timeout on that validation nor replicate the built-in 'On timeout' rejection behavior.

The checkout step for 'shared-templates' must be before the template reference, which it is.

Why it fails: Template resolution occurs during pipeline compile time, before any steps execute, so the runtime order of checkout steps is irrelevant to whether the template can be found. Even with a prior checkout, the template path is still evaluated against the repository's root, not the working directory after checkout.

The template file is missing from the shared-templates repository.

Why it fails: The error message 'could not find' is ambiguous: it can mean the file does not exist, but in this scenario the template file likely exists at the repository root. The real issue is that the path 'shared-templates/build-steps.yml' incorrectly assumes the repository name is a subfolder, whereas the path must be relative to the repository root.

The ref 'refs/heads/main' does not exist in the shared-templates repository.

Why it fails: If the ref 'refs/heads/main' did not exist in the shared-templates repository, Azure DevOps would return a distinct error such as 'The ref refs/heads/main could not be found' during template resolution. Since the reported error is specifically about the template file path, the ref itself is valid and not the cause of the failure.

Add a step that pauses the pipeline until a manual approval is received via a custom webhook.

Why it fails: Implementing a custom webhook requires external infrastructure and manual logic to manage the pause state, whereas GitHub Environments provide native deployment protection rules. This approach is intended for integrating third-party orchestration tools that exist outside of GitHub's built-in workflow engine. You would use webhooks if your approval process required validation from an external system, such as a bespoke security scanning tool or a custom ticketing platform integrated with Microsoft Entra ID.

Use a workflow_dispatch trigger and require the senior developer to manually run the production deployment.

Why it fails: Manual workflow_dispatch gives no dependency on the staging job's success and no enforced approval gate; the senior developer could trigger production regardless of staging outcome. It suits ad-hoc, human-initiated runs, not gated promotion. Environment protection rules with required reviewers, chained via needs, provide the actual staging-success dependency.

Use a build matrix to run staging and production deployments in parallel.

Why it fails: A build matrix runs jobs concurrently across parameter combinations, so production would start alongside staging rather than after its success, and it provides no approval mechanism. Matrices suit testing multiple platform or version variants in parallel, not sequential gated promotion.

GitFlow

Why it fails: GitFlow uses long-lived develop and release branches with delayed integration, so concurrent edits to the same files diverge and surface conflicts at merge time. It is tempting because GitFlow structures releases well. Trunk-based development with short-lived branches and frequent integration keeps changes small, reducing conflicting edits.

Forking workflow

Why it fails: Forking workflow isolates each developer in a separate repository, so simultaneous edits to shared files accumulate and collide only when pull requests merge upstream. It is tempting because forks suit open-source contribution. Trunk-based development with short-lived branches and frequent pulls integrates changes continuously, shrinking conflict windows.

Centralized workflow

Why it fails: A Centralized workflow commits directly to a shared main branch, so concurrent edits to the same files overwrite or conflict on push rather than integrating incrementally. It is tempting because it mirrors TFVC's single-server model. Trunk-based development with short-lived feature branches and frequent integration reduces conflicting simultaneous edits.

A deployment group target

Why it fails: A deployment group target is an agent registered for classic release pipelines targeting machines, not a component of an agent pool. Self-hosted pools require an organisation-level pool, agent software and a personal access token for registration.

Azure VM extension for Azure Pipelines Agent

Why it fails: The Azure VM extension installs and configures the agent on a VM, but it is not a required pool component; a pool needs a name, agent software and permissions. It is tempting because the extension automates agent installation on existing VMs, which is the correct choice when onboarding many Azure VMs at scale.

The acceptance tests are not comprehensive enough and missed a regression.

Why it fails: Test coverage is not the mechanism here: the staging slot passed, then production failed only after the swap, which points to slot-specific settings such as app settings marked as slot settings or connection strings. It is tempting because weak tests do cause escapes, but that would not explain failure confined to production post-swap.

The acceptance tests should have been run after the swap.

Why it fails: Running tests after the swap would test production traffic and cannot prevent the failure; the swap itself moves the warmed staging instance into production, so the defect lies in slot-specific configuration. It is tempting because post-deployment verification is a genuine practise, but it detects problems rather than causing this one.

The slot swap was not 'warm-up' and caused downtime.

Why it fails: App Service performs a warm-up during swap when application initialisation or health checks are configured, and a missing warm-up causes brief unresponsiveness, not a persistent outage. It is tempting because warm-up genuinely affects swap downtime, but the stem's symptom of sustained unresponsiveness after a successful staging test indicates slot-swapped settings instead.

Set the 'NoWarn' property to NU1603 to ignore warnings about missing packages.

Why it fails: Incorrect. The 'NoWarn' property suppresses warnings like NU1603 (dependency version mismatch) but does not affect package resolution failure.

Use the 'dotnet restore' task with the '--no-cache' flag.

Why it fails: Incorrect. The '--no-cache' flag skips the local cache for restore but does not add sources or change failure behavior.

Set the 'CheckConsistency' flag to true in the restore task.

Why it fails: Incorrect. The 'CheckConsistency' flag is used to verify package integrity after restore, not to enforce failure on missing packages. The restore task already fails by default if a package cannot be resolved.

Configure the Azure Artifacts feed to use the public NuGet gallery as an upstream source.

Why it fails: Incorrect. Configuring an upstream source makes the Azure Artifacts feed automatically fall back to the public NuGet gallery, but if the package is missing from both, restore will fail. However, this option alone does not meet the requirement to explicitly fail if a package is not found in either source, and it requires only a single source—not both.

pull_request_target with branches: [main] and types: [closed]

Why it fails: pull_request_target with types: [closed] fires on every closed pull request, including merges and rejections, and runs in the base branch context, so it cannot guarantee a build only after a successful review merge. It is tempting for labelling or commenting on PRs, but push to main is the correct trigger here.

pull_request with branches: [main]

Why it fails: The pull_request trigger fires when a pull request is opened, synchronized, or reopened, and by default does not fire on the merge/close event unless you explicitly specify types: [closed]. Even with types: [closed], it runs in the context of a merge commit and may not have access to secrets in the same way as pull_request_target, but without specifying closed it only runs during PR lifecycle, not at completion.

workflow_dispatch

Why it fails: The workflow_dispatch event requires a user to manually trigger the workflow via the GitHub UI, API, or CLI, so it cannot automatically enforce that all merges to main run the workflow. This makes it unsuitable for a required validation that must run on every PR merge, as it depends on human action rather than the merge event.

The approver must be an individual user, not a group.

Why it fails: Approval checks in Azure Pipelines can be assigned to individual users or to groups, including Microsoft Entra ID groups and security groups. There is no requirement that the approver be a single user; delegating approvals to a group is common to avoid single points of failure. The real prerequisite is that the approver (whether a user or group) must have the 'Approve pipeline permissions' permission on the environment.

The approval must be configured in the release pipeline's pre-deployment conditions.

Why it fails: Approvals are not configured directly in a release pipeline's pre-deployment conditions; they are added as checks on an environment in Azure Pipelines. For classic release pipelines, the approval settings are defined on the environment itself, and while they may appear before deployment, they are not part of the pipeline's pre-deployment condition configuration. The condition may trigger the approval, but the approval check itself is bound to the environment resource.

Use a single workflow that builds all projects on every push

Why it fails: A single workflow that builds all projects on every push is inefficient for a monorepo because it triggers the entire build and test suite for every commit, even when changes are isolated to one component. This wastes compute time, slows down CI feedback, and creates unnecessary coupling between unrelated projects.

Use submodules to separate projects

Why it fails: Using submodules to separate projects breaks the monorepo model by introducing nested Git repositories, requiring manual synchronization and version coordination. It adds complexity, risks broken references, and does not leverage GitHub Actions' native monorepo capabilities, making it a poor choice for monorepo optimization.

Use workflow templates and composite actions

Why it fails: Workflow templates and composite actions improve reusability and maintainability, but they do not optimize when workflows run or limit execution to changed projects. They are a code-organization technique rather than a scoping solution, so on their own they still execute on every push unless combined with path filters.

Disable actions for the repository.

Why it fails: Disabling actions for the repository entirely stops all GitHub Actions workflows from executing, which would break any existing CI/CD pipelines. The goal is to control which actions are used, not to eliminate automation altogether, so this is far too restrictive and not a valid mitigating control.

Use environment protection rules.

Why it fails: Environment protection rules (e.g., required reviewers, wait timers, or deployment branches) apply to deployment jobs and environments, not to the selection or execution of actions within a workflow. They do not restrict which third-party or custom actions can be referenced, so they cannot mitigate the risk of untrusted actions running.

Store actions in encrypted secrets.

Why it fails: Secrets are encrypted key-value stores intended for sensitive data like API tokens, passwords, and certificates; they are not a mechanism for storing or executing action definitions. Even if you embedded action code in a secret, GitHub Actions does not interpret secret contents as executable actions—actions must be referenced from repositories or containers, so this does not control which actions run.

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.

Use parallel jobs in the pipeline

Why it fails: Parallel jobs (or parallel pipeline runs) distribute independent pieces across multiple agents to run simultaneously; they can improve throughput when there are many independent jobs, but they do not accelerate the execution of a single linear build. In a typical .NET Core build, the steps (restore, build, test, publish) are sequential and depend on each other; splitting them into parallel jobs would either require complex multi-job orchestration or duplicate work, and the restore step would still download the same packages from NuGet on every agent. Consequently, wall-clock time for a single pipeline run remains dominated by the same network-bound package restore.

Use a self-hosted agent with more CPU

Why it fails: A self-hosted agent with additional CPU cores accelerates CPU-bound steps like compilation and packaging, but the observed build time is dominated by network latency and bandwidth when downloading NuGet packages from external feeds. Upgrading the CPU does not increase network throughput or eliminate the need to fetch packages; the restore step will still wait on the same network I/O. Even with a faster processor, MSBuild's restore phase is I/O bound, and compilation is a comparatively small fraction once packages are available. Therefore, this option would not meaningfully reduce overall build duration.

Enable incremental builds

Why it fails: Incremental builds (via MSBuild's up-to-date checks or specifying `--no-restore` after a preceding restore) avoid recompiling unchanged projects, but the pipeline's slow stage is the `dotnet restore` that resolves and downloads NuGet packages from the network. Even if compilation is skipped entirely, the restore step must still query the package source and download the .nupkg files from scratch on every new agent or when the cache does not exist; incremental compilation does nothing to avoid that network fetch. The packages are typically the same each time, so an incremental build cannot reduce the time spent waiting on package acquisition.

The projects pattern '**/*.csproj' does not match any files

Why it fails: If the '**/*.csproj' pattern matched zero project files, the MSBuild or dotnet build task would fail immediately with a 'project(s) matching the pattern were not found' error. Because the build actually reached the artifact-publishing step, this pattern did match projects, so it cannot be the cause of the empty artifact.

The task 'PublishBuildArtifacts@1' is misspelled

Why it fails: The task name 'PublishBuildArtifacts@1' is a valid, built-in Azure DevOps task identifier. A misspelled task name would trigger a 'task not found' error during pipeline validation or execution, not a successful build that then produces an empty artifact, so this option is incorrect.

The artifact name 'drop' is invalid

Why it fails: Azure DevOps allows the artifact name 'drop'; in fact, 'drop' is the default artifact name in classic pipeline templates. If the name were invalid, the PublishBuildArtifacts task would reject it with a naming error, but an empty artifact from a valid publish step indicates the staging folder never received the build output, not an invalid name.

Create a new service connection with limited permissions and require that all pipeline runs use it. Use an Azure Policy to audit configuration changes.

Why it fails: Creating a service connection with limited permissions only restricts what Azure resources the pipeline can access; it does not enforce approval gates, because a user with pipeline edit permissions can simply switch to another connection or modify the pipeline to bypass approval requirements. Azure Policy can audit configuration changes, but it cannot govern the approval workflow inside Azure Pipelines, so this approach fails to satisfy the control requirement.

Configure environment-level approvals in the release pipeline and use Azure Policy to enforce that all deployments go through the environment. Use diagnostic settings on App Configuration to stream logs to Azure Monitor.

Why it fails: Environment-level approvals are only effective if the pipeline definition is locked down; since the pipeline remains editable by developers, they can remove or ignore the environment approvals entirely, and Azure Policy does not integrate with Azure Pipelines to force deployments through a specific environment. Enabling diagnostic settings on App Configuration streams operational logs to Azure Monitor but provides no mechanism for approval gating or prevention of unauthorized configuration changes, so this combination does not meet the compliance goal.

Implement a branch policy on the release pipeline's YAML file in the repository to require approval for changes. Use a webhook to send configuration change events to Azure Monitor.

Why it fails: Branch policies on the release pipeline's YAML file only govern changes to the code that defines the pipeline, but they do not enforce an approval gate on pipeline runs themselves. A user with edit permissions can still modify the pipeline definition directly in the Azure DevOps portal or push a change to a separate branch that bypasses the protected branch review, since branch policies do not lock down the pipeline resource. Additionally, a webhook alone merely fires an HTTP notification; it does not provide a durable, queryable audit log, and sending such events to Azure Monitor requires a proper data collector or HTTP Data Collector API, not just a webhook subscription. Thus this approach fails to ensure that all configuration changes are approved and logged in a compliant manner.

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.