Design and implement build and release pipelines practice questions

The pipeline does not trigger because the `docs/` path is excluded and includes a change.

Why wrong: This is incorrect because Azure Pipelines evaluates path filters against the complete set of files changed in the push, not per file. Although a changed file under `docs/` would be excluded, the push also contained a change to `src/Controllers/HomeController.cs`, which is not in any excluded path. As long as at least one changed file is not excluded, the CI trigger fires; the presence of an excluded file does not cancel the trigger. If the commit had touched only `docs/` or `tests/`, the pipeline would indeed not trigger.

The pipeline triggers only if the change is on a branch matching `release/*`.

Why wrong: This is too restrictive because the trigger's branch include list contains `main` in addition to `release/*` (or at least `main` is clearly enabled). Branch filters are additive in Azure Pipelines: a push to any branch that matches one of the include patterns triggers the pipeline, so a change on `main` also fires it. The `release/*` wildcard does not exclude or override the `main` include; it merely adds release branches as additional trigger sources.

The pipeline triggers but runs only tests because the build is skipped due to excluded paths.

Why wrong: This misunderstands the scope of path filters: they only determine whether the pipeline is triggered by the push, not which tasks or jobs execute inside the run. Once the trigger fires, all steps in the pipeline's stages and jobs run according to their normal `condition` values; Azure Pipelines does not automatically skip the build because a changed file is in an excluded path. To run only tests in such a scenario, you would need explicit task conditions or a separate pipeline, not path-filter behavior.

Set the connection string as a secret variable in the pipeline UI and reference it in the integration test step.

Why wrong: Storing the connection string as a secret variable in the pipeline UI means the secret is saved in Azure DevOps project settings. This is insecure because anyone with 'Edit pipeline' permission can view the secret in plaintext, and it cannot be rotated independently of the pipeline. Additionally, secret variables are injected into the environment of all tasks in the job, increasing the attack surface, and are not integrated with Azure Key Vault's access control and auditing. The recommended approach is to retrieve the secret from Key Vault at runtime.

Use a PowerShell script to read the secret from Key Vault using the service principal.

Why wrong: Using a PowerShell script to retrieve secrets directly, whilst technically feasible via `Get-AzKeyVaultSecret`, bypasses Azure Pipelines' native Key Vault task. This task securely injects secrets as pipeline variables, adhering to security best practises by avoiding direct script exposure of secret retrieval logic. PowerShell scripts are valuable for custom Azure automation or complex scenarios where a dedicated pipeline task does not exist, but for standard secret retrieval within a pipeline, the built-in task offers superior security and integration.

Azure App Service manage: Start staging slot

Why wrong: Starting the staging slot ensures it is running and accepting requests before validation or swap. A stopped staging slot would cause health checks or swap warm-up to fail, so this step is required to prepare the slot for traffic.

Azure App Service manage: Delete staging slot

Why wrong: Deleting the staging slot would remove the deployment target before the swap, breaking the workflow. You need the staging slot to exist to host the new release and swap it into production; deletion is only appropriate after a successful swap if you are cleaning up temporary resources.

Azure CLI: Run az webapp deployment slot swap

Why wrong: While this Azure CLI command does swap slots, the pipeline task 'Azure App Service manage: Swap slots' is the built-in Azure DevOps task that wraps this operation without requiring CLI installation. Using a CLI step introduces additional overhead and is not the standard or correct task selection for a slot swap in a release pipeline.

trigger: branches: include: - main

Why wrong: Configuring a branch trigger on main only starts the pipeline when new commits are pushed to that branch, not when an artifact changes. It ignores artifact or file modifications elsewhere, so it fails to meet the requirement of triggering on artifact change.

pr: branches: include: - main

Why wrong: A pull request trigger fires on creation or updates of PRs targeting main, not on artifact changes in the repository. It's a build validation for PRs, not a CI trigger for artifact modifications, so it does not accomplish the desired behavior.

resources: containers: - container: myContainer

Why wrong: Declaring a container resource makes a Docker container available to jobs but does not define any trigger condition. It has no effect on when the pipeline runs, so it cannot cause the pipeline to trigger on artifact changes.

Use the 'Azure Key Vault' task to download secrets and assign to variables

Why wrong: Although the 'Azure Key Vault' task can download secrets to pipeline variables, it is deprecated and less secure than a linked variable group. It requires a separate service principal, can bloat logs with secret values, and does not provide the same seamless integration or automatic secret rotation as the Key Vault variable group.

Store the secret as a plain text variable and mark it as 'secret'

Why wrong: This is insecure because marking a plain text variable as 'secret' only masks it in logs; the value remains stored in the pipeline's configuration, visible to anyone with edit permissions. It lacks the encryption, audit trail, and access management features that Azure Key Vault provides, making it unfit for production secrets.

Reference the secret directly as $(SecretName) from a library variable group

Why wrong: Referencing $(SecretName) directly from a library variable group without linking to Key Vault stores the secret in plain text in the variable group definition, which is vulnerable to unauthorized access. This method circumvents Azure Key Vault's centralized key management and secure access policies, so it should never be used for sensitive information.

Configure backups, then identify critical apps and RTO/RPO, then enable geo-replication, then configure failover, then test failover.

Why wrong: Incorrect. Starting with backup configuration is premature because you haven't identified which applications are critical or defined the RTO/RPO, so you can't choose appropriate backup frequency or retention. Without this assessment, the backup and subsequent replication layers may be misaligned with business requirements, potentially failing to meet recovery targets. The correct order is to define your DR requirements first, then implement backups, geo-replication, failover, and finally test the plan.

Identify critical apps and RTO/RPO, then enable geo-replication, then configure backups, then configure failover, then test failover.

Why wrong: Incorrect. Geo-replication should not be enabled before backups because it is a complementary layer that operates on a live or initial copy of data, not a replacement for backup. Backups are necessary to provide point-in-time recovery granularity and to protect against logical corruption, while geo-replication only offers continuous replication to a secondary site. If you set up geo-replication before backups, you have no baseline or restore point mechanism to fall back on, so the correct sequence is backups first, then geo-replication.

Identify critical apps and RTO/RPO, then configure backups, then configure failover, then enable geo-replication, then test failover.

Why wrong: Incorrect. Configuring failover before enabling geo-replication is logically flawed because failover requires an active, replicated secondary target—geo-replication is what creates and maintains that target in a different region. Without geo-replication, failover has no destination and no data consistency to switch to, making the configuration ineffective. The correct order is to establish geo-replication first, then configure failover to direct traffic to the replica, and only after that validate the process through testing.

Configure a branch policy on the main branch

Why wrong: Branch policies in Azure Repos enforce code quality and review requirements on pull requests to the main branch, such as requiring reviewers or successful builds. They operate at the source-code level and have no effect on release pipeline execution or approval workflows, so they cannot gate production deployments after staging succeeds.

Assign a deployment group to the production stage

Why wrong: A deployment group is a logical set of target machines or VM resources used for deployment tasks in a release pipeline, defining where the application is installed. It does not provide any approval or gate mechanism that blocks pipeline progression based on staging results, so it cannot ensure a manual sign-off before production.

Add a post-deployment approval gate on the staging stage

Why wrong: Adding a post-deployment approval gate on the staging stage requires a designated approver to manually sign off only after the staging deployment completes successfully, before the pipeline proceeds to production. This gate directly enforces the manual quality checkpoint after staging verification, aligning with the requirement to control the transition from staging to production.

Enable continuous integration (CI) trigger on the build pipeline

Why wrong: Enabling a continuous integration (CI) trigger on the build pipeline is not sufficient for a gated check because CI builds run automatically on every push to a branch, but they do not block the merge or act as a policy-based gate. CI validates the pushed code after the fact, whereas gated check-in requires the build to pass as a prerequisite for merging, so this action alone does not implement a gated check.

Set the build to run a 'pre-merge' validation

Why wrong: Setting the build to run a 'pre-merge' validation is not a separate action in Azure DevOps; it is a description of what build validation policies do. To actually implement a gated check, you must configure the build validation policy on the branch, which already includes pre-merge validation as part of its behavior, so this option does not represent an additional distinct step.

Require a manual build before merging

Why wrong: Requiring a manual build before merging is incorrect for gated check-in because gated checks are automated and driven by branch policies, not by human intervention. A manual build depends on a developer to trigger it and does not enforce a hard gate that prevents the merge, so it fails to provide the consistent, policy-based validation required for a gated check.

Add the secret as a plain text variable in the pipeline YAML.

Why wrong: Incorrect. Adding a secret as plain text in pipeline YAML directly exposes it in the source code and logs. This defeats security. Variable groups linked to Key Vault automatically mask secrets, but plain text variables do not.

Use a Key Vault task to fetch the secret and map it to a pipeline variable marked 'secret'.

Why wrong: The Azure Key Vault task retrieves the secret from Azure Key Vault during pipeline execution and assigns it to a pipeline variable that is explicitly marked as secret. This marking causes Azure DevOps to mask the value in all logs, build output, and error messages, so it cannot be accidentally leaked when tasks echo variables or write diagnostic information. Because the secret is fetched at runtime, it never appears in the YAML definition or source repository, and access is governed by Azure Key Vault permissions and a service principal with minimal privileges.

Add the secret to the repository's .env file and use a script to read it.

Why wrong: Committing a .env file to the repository places the secret into source control, where it becomes part of commit history and is visible to everyone with access to the repository. Even if the current file is removed, the secret remains in older commits and can be exposed through logs if the script prints environment variables or if the pipeline artifact retains the file. This directly violates the core security principle that secrets must never be stored in files under version control; Azure Pipelines offers secure alternatives such as the Key Vault task or variable groups linked to Key Vault, which keep the secret external and masked at runtime.

Deployment rollback is disabled, preventing automatic deployments.

Why wrong: Deployment rollback is a separate App Service setting that controls whether a previous deployment is restored after a failed update; it does not determine whether Git pushes trigger automatic deployments. The output indicates the source branch, but continuous deployment sync is not enabled, which is the actual cause of the issue.

The branch is set to 'main' but commits are pushed to 'master'.

Why wrong: The command output explicitly lists the branch as 'main', and the repository's default branch is also 'main', so there is no branch mismatch. Even if commits were pushed to 'master', the deployed branch would still be 'main' if that is the configured branch, but the real problem is that continuous deployment sync is not enabled.

The repo URL uses GitHub but Azure Web Apps only supports Azure Repos.

Why wrong: Azure App Service fully supports GitHub as a deployment source in addition to Azure Repos, so the use of a GitHub URL is not a limitation. The repository connection can be valid while continuous deployment sync remains disabled, which is why the command does not show an active deployment sync despite the GitHub source.

The pull request trigger is enabled for the feature branch.

Why wrong: A pull request trigger in Azure Pipelines only runs the pipeline when a pull request is created or updated, not when commits are pushed directly to a branch. Therefore, even if PR triggers are configured for the feature branch, they cannot cause automatic builds on ordinary branch pushes, so this option does not explain the behavior.

Path filters are configured to include all paths.

Why wrong: Path filters in a pipeline trigger determine which files or directories must change to initiate a build; they do not restrict which branches trigger builds. Configuring path filters to include all paths merely means any file change can trigger the pipeline, but it has no bearing on branch-level filtering, so it cannot be the cause of builds triggering on all branches.

The CI trigger is disabled in the pipeline YAML.

Why wrong: If the CI trigger were disabled in the pipeline YAML (for example, using 'trigger: none'), the pipeline would not automatically start on any branch push, which would prevent unwanted builds rather than cause them. Since builds are indeed occurring on all branches, the CI trigger must be enabled, making this option directly contradictory to the observed behavior.

The buildConfiguration variable is not set.

Why wrong: The pipeline definition includes a 'variables' section where 'buildConfiguration' is explicitly defined as 'Release', so the variable is indeed set and available to all tasks. Therefore, the assertion that the buildConfiguration variable is not set is factually incorrect.

The pipeline definition is in JSON format, which is not supported by Azure Pipelines.

Why wrong: Azure Pipelines does not support JSON format for pipeline definitions; it expects YAML for YAML pipelines or a classic UI definition. The provided definition is a JSON object, which is not a valid pipeline format, making this the primary reason why the pipeline would fail.

The DotNetCoreCLI task requires a specific version.

Why wrong: The DotNetCoreCLI task does not require a specific version to be specified in the pipeline definition; if no version is specified, the task uses a default version. Therefore, the claim that a specific version is required is incorrect, as the task is capable of running with its default settings.

The 'project' clause filters out relevant rows.

Why wrong: The 'project' clause in KQL is used to select specific columns, not filter rows. Row-level filtering is done with 'where'; therefore, this option incorrectly describes the function of 'project'.

The 'contains' operator is case-sensitive.

Why wrong: In KQL, the 'contains' operator performs a case-insensitive substring match. To perform a case-sensitive search, you would use 'contains_cs' instead.

The KQL syntax is incorrect.

Why wrong: The query follows correct KQL syntax because 'project' and 'contains' are used appropriately, and the query is valid. If there were a syntax error, Log Analytics would return an error message; however, an empty result typically indicates a data collection issue.

Canary deployment with traffic splitting via Istio.

Why wrong: Canary releases via Istio are gradual and can limit blast radius, but they demand substantial operational complexity: you must configure virtual services, destination rules, and metric-driven traffic shifting, which is over-engineered when a simpler full-environment switch meets the goal.

Immutable infrastructure with new cluster per deployment.

Why wrong: Immutable infrastructure with a new cluster per deployment is technically clean because it eliminates drift, but it is prohibitively expensive and slow—provisioning an AKS cluster can take minutes and requires re-establishing networking, ingress, and secrets each time, making it impractical for frequent releases.

Blue-green deployment to AKS using Kubernetes namespaces for isolation.

Why wrong: Blue-green deployment to AKS using namespaces is correct because it runs the new version in a separate namespace while the current production namespace remains untouched, allowing independent validation and an atomic traffic switch via service selectors or ingress updates; rollback is instantaneous by switching traffic back to the blue namespace.

The parameter values must be defined in a separate file.

Why wrong: This is incorrect because Azure Pipelines allows parameters to be defined inline in the YAML file itself using the `parameters` keyword, and they can be referenced with `${{ parameters.name }}`. A separate file is only needed if you choose to use a template, not for the parameter definitions themselves.

The 'AzureWebApp@1' task inputs are incorrectly formatted.

Why wrong: This is wrong because the `inputs` for the `AzureWebApp@1` task are specified as key-value pairs under the `inputs` object, following standard YAML syntax such as `appServiceName`, `package`, and `connectionString`. The snippet's input formatting is valid and does not cause a schema error.

The 'stage' keyword should be 'stageName'.

Why wrong: No, `stage` is the correct YAML keyword in the stages list to define a stage, and the stage's identifier is given after the colon, e.g., `- stage: build`. `stageName` is not a valid keyword in the Azure Pipelines YAML schema, so this option is incorrect.

Configure a Build Retention Policy to keep only the latest build.

Why wrong: A Build Retention Policy determines how long completed pipeline runs and their artifacts are kept, but it does not affect dependency resolution or restore time. It simply cleans up old builds after the retention window, so it cannot reduce the time needed to re-download packages on each new build.

Use Pipeline Artifacts to store dependencies between builds.

Why wrong: Pipeline Artifacts are designed to pass files between jobs or stages within a single pipeline run, not to persist dependencies across separate builds. They are tied to a specific run and do not act as a reusable cache, so each new build would still need to restore the full dependency set.

Enable Incremental builds in the pipeline settings.

Why wrong: Azure Pipelines does not expose a built-in 'Incremental builds' setting; incremental compilation is a feature of the underlying build tool (e.g., MSBuild). Even where available, it only skips recompiling unchanged source code and does not cache external dependencies such as npm packages, so it would not solve the dependency restore bottleneck.

Manual trigger via the DevOps portal

Why wrong: A manual trigger via the DevOps portal requires a user to explicitly click the 'Run pipeline' button, which is not an automatic execution model. It depends on human intervention and therefore cannot start a pipeline without direct user action, disqualifying it as an automatic trigger.

The service connection does not have 'Website Contributor' role on the App Service.

Why wrong: This option is incorrect because the 403 error occurs when the pipeline attempts to download the artifact from Azure Artifacts, not during any deployment step. The service connection's role on the target App Service (such as 'Website Contributor') is an Azure RBAC permission used only by deployment tasks like 'Azure Web App Deploy' to modify the web app. Since the failure happens before any deployment action, a missing Website Contributor role cannot produce a 403 Forbidden error from the artifact feed; the error is unrelated to App Service permissions.

The pipeline has 'Limit job authorization scope to current project' enabled, restricting access to the artifact.

Why wrong: The 'Limit job authorization scope to current project' setting controls the scope of the pipeline's OAuth access token, which is used for project-level resources like repos or pipelines. It does not affect the permissions of service connection principals, and Azure Artifacts downloads authenticate via the service connection, not the pipeline token, so this setting cannot cause a 403 from the feed.

The artifact is stored in a different Azure region than the App Service, causing a cross-region access error.

Why wrong: Azure Artifacts feeds are not regional resources; they are hosted and served as part of the Azure DevOps service and are accessible globally regardless of where the consuming App Service is deployed. Artifact feeds do not enforce any region-level access restrictions, so a cross-region scenario cannot produce a 403 Forbidden error.

schedules: - cron: "0 0 * * *" branches: include: - develop

Why wrong: The `schedules` block defines a scheduled trigger that runs the pipeline at a specified cron interval (here, midnight UTC daily). It does not react to new commits pushed to the develop branch, so it is incorrect for automatically triggering on a push.

pr: branches: include: - develop

Why wrong: The `pr` block configures a pull request trigger that runs the pipeline when a PR targeting the included branches is created or updated. It is not triggered by direct pushes to the branch, so it fails to meet the requirement of triggering on a new commit to develop.