Select Two (Multi-Select) 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.

Built-in secrets management for connection strings.

Why it fails: Deployment groups orchestrate agent installation and rolling deployment across target machines; they provide no secret store. Secrets management is handled by Azure Key Vault or pipeline variable groups. This option is tempting because deployment groups do carry per-target configuration, but that is machine targeting, not credential protection.

Reduced cost because VMs are shut down when not in use.

Why it fails: Deployment groups register existing machines as agents and do not manage their power state, so no shutdown or cost saving occurs. Cost reduction comes from scale sets or auto-shutdown schedules. It is tempting because deployment groups target many machines, which sounds economical, yet they simply tag and deploy to whatever is already running.

Automatic scaling of virtual machines based on load.

Why it fails: Deployment groups perform no autoscaling; they deploy to a fixed set of registered target machines. Autoscaling is provided by virtual machine scale sets or AKS node pools. It is tempting because deployment groups handle many machines, implying elasticity, but membership changes only when machines are manually registered or removed.

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 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.

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Test plans.

Why it fails: 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 it fails: 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 it fails: 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.

Log secret values to pipeline console for debugging

Why it fails: Logging secrets exposes them.

Store secrets in code as environment variables

Why it fails: Secrets in code are not secure.

Use separate documentation repositories for each team.

Why it fails: Separate documentation repositories fragment knowledge, create information silos, and hinder cross-team discovery, making it harder to maintain a single source of truth. In DevOps, shared documentation promotes transparency and reduces duplication, while separate repos increase context switching and inconsistency.

Send monthly status reports via email.

Why it fails: Monthly email status reports are too infrequent to support the rapid feedback loops and continuous coordination required for DevOps, and they lack interactivity for resolving blockers. They can serve as a periodic summary but cannot replace real-time channels and regular synchronous check-ins.

Remove team chat channels to reduce noise.

Why it fails: Removing chat channels eliminates a key real-time communication surface, increasing friction and reducing visibility into ongoing discussions and decisions. While channel hygiene and governance are useful, outright removal damages collaboration and pushes noise into less traceable channels.

Work item linking

Why it fails: Work item linking enforces traceability between commits and backlog items. It suits teams requiring every change tied to tracked work. It does not enforce reviewer counts or build validation, which the release branch's approval and build policies must provide.

Require a clean fast-forward merge

Why it fails: Requiring a clean fast-forward merge governs history linearity, preventing merge commits. It suits teams wanting a linear commit graph. It enforces neither the two-approver minimum nor build success before merging, so it fails the stated requirements.

Require a merge commit

Why it fails: Requiring a merge commit controls commit topology, not approvals or build validation. It suits teams wanting an explicit merge node in history. The scenario needs minimum reviewer counts and build policies, which this setting does not enforce.

Fast-forward only

Why it fails: Fast-forward only is not exposed as a standalone completion strategy in Azure Repos pull requests. A pure fast-forward simply moves the target branch pointer to the source branch's latest commit, which is only possible when the source branch contains the target branch's history as a subset; otherwise, a merge or rebase step is required. Azure Repos instead offers 'Rebase and fast-forward' as an explicit strategy that first replays source commits onto the latest target before doing the fast-forward, and the semi-linear merge method rebases then creates a merge commit. Because a raw fast-forward option would silently skip an integration record and cannot be applied when branches diverge, it is not offered as a separate pull request completion choice in Azure Repos.

Rebase only

Why it fails: Rebase only is not a valid standalone merge strategy in Azure Repos; rebasing is performed as an internal step within the semi-linear merge strategy. Azure Repos does not offer a separate 'rebase only' completion option for pull requests, so this selection is incorrect.

Store production secrets as pipeline variables marked as 'Secret'.

Why it fails: Storing production secrets as pipeline variables marked as 'Secret' is risky because secrets can be inadvertently exposed in pipeline logs or via variable group access, and they do not support automatic rotation; instead, use Azure Key Vault to centrally manage and rotate secrets.

Enable PR triggers for the production stage to validate changes.

Why it fails: Enabling PR triggers for the production stage is wrong because PR triggers are designed for validating code changes in branches, not for controlling production deployments; they could allow unauthorized changes if the PR validation pipeline has elevated permissions, and deployment should be gated by approvals, not PR triggers.

Use self-hosted agents running on-premises for all pipelines.

Why it fails: Using self-hosted agents running on-premises for all pipelines is not a security measure and can introduce additional risk if the agents are not properly secured, patched, or isolated; agent location does not prevent unauthorized access, and managed, scalable Microsoft-hosted agents with proper identity and access controls are often more secure.