Select Two (Multi-Select) Questions

Use a manual intervention task in the pipeline.

Why wrong: Manual intervention is for pausing and waiting for input, not for approval control.

Set environment permissions to allow only specific users to create releases.

Why wrong: Release creation permissions don't control deployment approvals.

Configure deployment gates to check for user approval.

Why wrong: Gates evaluate health criteria, not user approvals.

Store secrets as plain text in a secure Git repo with restricted access

Why wrong: Storing secrets in Git, even with restricted access, is not secure.

Use environment variables in the pipeline to pass secrets at runtime

Why wrong: Environment variables can be logged if not properly handled.

Set up a webhook in Azure Repos to call Azure Logic Apps on pull request merge.

Why wrong: Webhooks require custom logic, not a built-in integration.

Configure a Service Hooks subscription in Azure DevOps to send pull request merge events to Azure Boards.

Why wrong: Service Hooks send events to external systems, not directly update work items.

Create an Azure Function that listens for pull request merge events and updates work items via the REST API.

Why wrong: This is a custom solution, not a built-in configuration.

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

Why wrong: Approval checks in Azure Pipelines can be assigned to individual users or to groups, including Azure AD 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 wrong: 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.

A deployment group target

Why wrong: Deployment groups are separate from agent pools.

Azure VM extension for Azure Pipelines Agent

Why wrong: The VM extension is one way to install the agent but not strictly required; you can install manually.

Use rolling deployment with manual step to approve each instance.

Why wrong: Manual approval for each instance is not practical for quick rollback.

Deploy directly to the production slot.

Why wrong: Direct deployment causes downtime.

Add a .gitattributes file

Why wrong: .gitattributes handles file normalization, not commit messages.

Set the default branch to main

Why wrong: Default branch does not enforce commit message conventions.

Set up an issue template

Why wrong: Issue templates are for issues, not commits.

Store the Key Vault name and secret names in a secure file in the repository.

Why wrong: Storing the Key Vault name and secret names in a secure file in the repository is insecure because the repository is a shared, version-controlled surface that can be accessed by many users; secret identifiers should be stored in pipeline variables or the Key Vault task configuration, not committed to source control.

Define secrets as pipeline variables and mark them as secret.

Why wrong: Marking secrets as secret pipeline variables obscures them in logs, but the values still reside in pipeline configuration and are managed by Azure DevOps, increasing exposure; best practice is to retrieve secrets at runtime from Azure Key Vault using the Key Vault task, which avoids storing secret values in pipeline settings.

Use the 'Azure CLI' task to run 'az keyvault secret show' for each secret.

Why wrong: Using the Azure CLI task to run 'az keyvault secret show' for each secret is inefficient and error-prone because you must manually capture and export each output, handle failures, and the method does not automatically map secrets to pipeline variables as the Azure Key Vault task does; the dedicated task is the recommended, secure approach.

HIPAA

Why wrong: HIPAA is a US healthcare regulation that applies to covered entities and business associates, but it is not a directly mapped compliance framework in Purview for Azure DevOps. While Azure itself has HIPAA attestation, Azure DevOps does not have a dedicated HIPAA template in Compliance Manager.

PCI DSS

Why wrong: PCI DSS is a payment card industry security standard, but it is not directly mapped to Azure DevOps in Purview Compliance Manager. Azure DevOps does not have a specific PCI DSS template, though the underlying Azure platform may have relevant attestations.

FedRAMP High

Why wrong: FedRAMP High is a US federal government cloud authorization that applies to cloud service providers, and Azure has a FedRAMP High authorization. However, Azure DevOps is not separately covered by a FedRAMP High template in Purview Compliance Manager, so it is not directly supported.

Pipeline decorators

Why wrong: Pipeline decorators automatically inject steps into every pipeline or selected stages, but they are static additions to the pipeline definition; they cannot introduce interactive approval gates or conditional authorization checks, so they do not enforce separation of duties between deployment initiators and approvers.

Service connections with different scopes

Why wrong: Service connections with different scopes provide the necessary credentials for deployment tasks but only grant access to resources; they do not include a workflow or approval mechanism, so they cannot enforce separation of duties or require a second person to authorize the deployment.

Branch policies on the main branch

Why wrong: Branch policies on the main branch, such as requiring pull request reviews or build validation, ensure code changes meet quality standards before merging, but they do not control who can deploy to an environment; deployment authorization is outside their scope, so they cannot enforce separation of duties.

Automatically compresses all files in the repository

Why wrong: Git LFS does not compress repository contents; it replaces large files with small pointer text and stores the actual bytes in external storage. Compression of Git objects is handled separately by Git's own zlib, which applies equally to repos with or without LFS.

Replaces .gitignore for excluding large files

Why wrong: Git LFS does not function as a replacement for .gitignore: .gitignore excludes files entirely from version control, while LFS deliberately tracks those files in the repository (as pointers) so they remain versioned. The two mechanisms solve opposite problems — one prevents tracking, the other enables tracking without storing the full file in history.

Speeds up diff operations for binary files

Why wrong: Git LFS does not improve diff performance for binary files; Git cannot meaningfully diff most binary formats, and LFS pointers are stored as text but the actual content remains external. The pointer diff only shows a change in the hash, not a content diff, and no speedup for binary diff operations is provided.

CopyFilesOverSSH

Why wrong: CopyFilesOverSSH is not a deployment task for Azure Web Apps; it uses Secure Copy Protocol (SCP) to copy files to a remote machine over SSH. While it can transfer files, it does not perform the web app deployment steps such as package installation, configuration, or starting the application, so it cannot deploy an Azure web app.

AzureFunctionApp

Why wrong: AzureFunctionApp is designed specifically for deploying to Azure Functions, which is an event-driven compute service, not a general web app. Even though both services are part of App Service, this task targets function apps and does not deploy standard web apps, making it incorrect for this scenario.

AzureVMAppDeployment

Why wrong: AzureVMAppDeployment is intended for deploying to Azure virtual machines, not Azure App Service Web Apps. It typically uses deployment scripts, DSC, or Chef to configure VMs, and it lacks the Azure App Service integration required to deploy a web app, so it is not a valid task for this purpose.

Enable HTTP access for performance

Why wrong: Enable HTTP access for performance: HTTP transmits all data, including secrets and authentication tokens, as plaintext, making it trivial to intercept on the network. Azure Key Vault does not support or allow HTTP; it requires TLS/HTTPS for all API calls, and the negligible performance gain from removing encryption is never worth the catastrophic security exposure.

Disable audit logging to reduce exposure

Why wrong: Disable audit logging to reduce exposure: Disabling diagnostic and audit logs removes your ability to detect unauthorized access, misuse, or exfiltration of secrets, and also breaks compliance requirements such as ISO 27001 or SOC 2. Security best practices mandate enabling Key Vault diagnostic logs and sending them to a SIEM or Log Analytics workspace for monitoring, so this option actually increases risk.

Enable soft-delete to recover deleted secrets

Why wrong: Enable soft-delete to recover deleted secrets: Soft-delete is a retention and recovery feature that lets you restore accidentally deleted secrets within a configurable retention period; it does not control who can access secrets. Access control is enforced by access policies or RBAC, whereas enabling soft-delete alone leaves a secret accessible to any principal that already has permission, so it does not address unauthorized access.

Use the Project Collection Build Service account for all pipeline runs.

Why wrong: Using the Project Collection Build Service account for all pipeline runs violates least privilege because that built-in account has broad access across all projects in the collection, increasing the blast radius of any exposure. Instead, use dedicated service principals with scoped permissions per pipeline or project.

Use Workload identity federation to avoid managing secrets.

Why wrong: Workload identity federation improves credential management by eliminating the need to manage and rotate client secrets, but it does not by itself limit the permission scope of the service principal. You must still assign narrow RBAC roles to the federated service principal, so it is a complementary practice rather than a substitute for least privilege.

Use the same service connection for both build and release pipelines.

Why wrong: Using the same service connection for both build and release pipelines often grants broader permissions than necessary, because build and release stages frequently require different levels of access to Azure resources. This violates least privilege; instead, create separate service connections scoped to the specific resources and actions each pipeline needs.

Require all users to use Personal Access Tokens (PATs)

Why wrong: Personal Access Tokens (PATs) are an authentication mechanism that verifies a user's identity when calling Azure DevOps REST APIs, but they do not provide authorization workflows or approval gates. Requiring PATs does not enforce reviews or restrict who can edit pipeline definitions, so it fails to meet the security compliance objective.

Enable audit logging for all pipeline changes

Why wrong: Enabling audit logging captures a tamper-evident record of pipeline changes for compliance and forensic investigation, but it only provides visibility after an action occurs. It is a detective control and does not block or prevent unauthorized modifications, so it is not sufficient on its own.

Enable OpenID Connect (OIDC) for pipeline authentication

Why wrong: OpenID Connect (OIDC) is an authentication protocol that eliminates secret-based credentials for pipeline connections, but it does not govern who may edit pipeline definitions or enforce approval workflows. It addresses identity and access for service principals, not change management, so it does not satisfy the compliance requirement.

The 'deployment' event trigger in a workflow.

Why wrong: The 'deployment' event trigger fires only when a deployment is created via the API or UI; it does not enforce approvals or block the deployment. It simply initiates a workflow run, meaning it is a reaction to deployment activity, not a protection mechanism.

Branch protection rules that require pull request reviews.

Why wrong: Branch protection rules that require pull request reviews govern code changes and merge eligibility on a branch; they do not influence workflow execution or environment-based deployment approvals. They protect the source code, not the deployment pipeline.

OpenID Connect (OIDC) for cloud provider authentication.

Why wrong: OpenID Connect (OIDC) is an authentication mechanism that lets GitHub Actions obtain short-lived tokens for cloud providers, replacing stored secrets. It addresses identity and access control only, not approval workflows, so it cannot enforce manual deployment approval.

Include multiple unrelated changes in a single pull request to reduce the number of PRs.

Why wrong: Bundling unrelated changes into one pull request obscures the intent of each change, makes code review significantly harder, and increases the risk of subtle bugs passing through. It also complicates reverting or cherry-picking individual features, since rollback requires untangling all the mixed modifications.

Assign as many reviewers as possible to ensure thoroughness.

Why wrong: Assigning too many reviewers can lead to redundant feedback, coordination overhead, and delayed decisions, while diluting accountability as each reviewer assumes another will catch issues. Optimal review efficiency is achieved with a small set of knowledgeable reviewers who have context relevant to the change.

Require that all team members review every pull request.

Why wrong: Requiring every team member to review every pull request causes unnecessary delays and wastes time for those without expertise in the affected code area, leading to shallow or rubber-stamp approvals. Review effort should be routed only to relevant stakeholders who can provide meaningful, authoritative feedback.

They are automatically scaled by GitHub.

Why wrong: GitHub does not automatically scale self-hosted runners; you must manually add or remove runner machines or implement custom auto-scaling solutions, such as scripts or cloud infrastructure features.

They are free and do not incur any costs.

Why wrong: Although GitHub Actions itself does not charge for self-hosted runners, you incur all infrastructure costs for the machines you provide, including compute, storage, and network, so they are not free overall.

Test plans.

Why wrong: Test plans are used for defining and running quality assurance tests, such as manual and automated test cases, to validate that a change behaves as expected. They do not provide change management controls, approvals, or auditability over the release process itself, so they are insufficient for implementing change management.

Project wiki.

Why wrong: Project wiki is a built-in knowledge base for creating and sharing documentation within a project, such as onboarding guides or architecture notes. It does not enforce approvals, track changes to code or releases, or provide any governance over what is deployed.

Code search.

Why wrong: Code search is a feature that lets users quickly locate code across repositories by keywords and filters, improving developer efficiency. It is purely a discovery tool and does not manage, approve, or record changes, so it cannot implement change management.

Enable pipeline log encryption

Why wrong: Pipeline logs are not encrypted by default.

Store secrets in YAML variable files

Why wrong: YAML files can be exposed in source control.