Develop a security and compliance plan practice questions

The service connection is configured to use the wrong Azure subscription.

Why it fails: The subscription is used for targeting Azure resources, not for Key Vault access.

The secret name in the variable group does not match the secret name in Key Vault.

Why it fails: A mismatch would cause 'secret not found', not 'access denied'.

The service principal used by the service connection does not have Contributor role on the Key Vault.

Why it fails: Key Vault uses access policies, not Azure RBAC (unless configured), and the error is about secrets, not the vault itself.

The variable group is linked to the wrong Key Vault instance.

Why it fails: If linked to wrong vault, the error would still be 'not found' but would mention the other vault.

The service principal does not have Get permission on the secret.

Why it fails: The error indicates 'not found', not 'access denied'.

The Key Vault is in a different Azure region than the Azure DevOps organization.

Why it fails: Region does not affect secret retrieval.

Configure the service connection to only allow deployments with tags.

Why it fails: Service connections don't enforce tagging.

Create an Azure Policy with the 'audit' effect to report non-compliant resources.

Why it fails: Audit only reports, does not enforce.

Configure a branch policy on the main branch to require tag verification in pull requests.

Why it fails: Branch policies do not affect Azure resource deployment.

In tasks that run scripts, set the 'Logging command' option to 'ignore' to prevent script output from being captured in the log.

Why it fails: The 'Logging command' option 'ignore' tells the agent to disregard special logging commands like ##vso[task.setvariable] in script output, but it has no effect on normal stdout/stderr streams. A script that executes 'echo $password' will still print the secret to the pipeline log regardless of this setting. To prevent output leakage, you must use secret variables (which are masked by the agent) or explicitly redact the value in the script. This option is about command processing, not about log suppression.

Store all sensitive information in a variable group and reference it in the pipeline.

Why it fails: Variable groups let you group variables for reuse across pipelines, and you can mark individual variables as secret during creation. However, simply storing sensitive information in a variable group without also toggling the secret flag leaves those values as plaintext, which Azure DevOps will display in the logs when referenced. Even if you do mark them as secret, the group itself does not guarantee masking; the 'Log secret values' checkbox and the variable's secret type determine output redaction. The real requirement is marking values as secret, not just storing them in a group.

Configure the service connection to use 'Read-only' scope.

Why it fails: A service connection with Read-only scope restricts the permissions of the connected resource (e.g., Azure Service Management API) to read-only operations, preventing unintended modifications. However, this authorization control does not affect the pipeline's log output; if a task prints the service connection's client secret or token, it will appear in plaintext. Read-only scope addresses what actions the connection can perform, not what information appears in logs, so it is not a solution for protecting sensitive data in logs.

The variable group VG-Prod is not properly linked to KV-Prod; re-link it.

Why it fails: The variable group's Key Vault link is just a reference to vault name and secret names; since the same variable group resolves fine in non-production, the link itself is not misconfigured. The pipeline fails with Forbidden because the build service identity lacks Key Vault permissions, not because the variable group is incorrectly linked.

The secret 'DbPassword' does not exist in KV-Prod; create it.

Why it fails: Azure Key Vault returns a 'Forbidden' (403) error when the caller lacks 'Get' and 'List' permissions, whereas a nonexistent secret would produce a 'Not Found' (404) error. Because the pipeline reports Forbidden, the secret exists but the build service identity cannot read it, so recreating or creating 'DbPassword' would not change the outcome.

The service principal SP1 does not have 'Get' and 'List' permissions on KV-Prod; add them.

Why it fails: Key Vault variable groups in Azure DevOps are resolved by the build service identity for the project, not by a user-defined service principal such as SP1. SP1 may be used for other pipeline tasks, but the Key Vault access policy must grant 'Get' and 'List' to the build service identity, so adding permissions to SP1 does not address the actual authorization failure.

Store artifacts in Azure Key Vault and use access policies to control deployment.

Why it fails: Azure Key Vault is designed to securely store secrets, keys, and certificates, not binary build artifacts; using access policies there only controls who can read those secrets and does not provide immutability or enforce deployment approval gates, so artifacts should reside in an Azure Artifacts feed where release gates and retention policies can be applied.

Use branch policies to require two reviewers on pull requests.

Why it fails: Branch policies with two reviewers on pull requests govern code review and merge quality in the source repository, but they do not operate in the release pipeline; the requirement for two manual approval gates must be implemented as release-level pre-deployment or post-deployment gates in Azure Pipelines, not via branch policies.

Add a pipeline decorator that injects a validation step for code signing.

Why it fails: Pipeline decorators automatically inject additional steps into every pipeline definition, but they cannot enforce interactive manual approvals; they might add a code-signing validation step, yet this only verifies artifact signatures and does not implement the required multiple approval gates or immutability controls.

Configure branch policies to require a security scan on pull requests.

Why it fails: Configuring branch policies to require a security scan on pull requests only applies to pull request validation, not to all builds triggered by other events like CI or scheduled triggers, so it does not ensure every build includes a security scan.

Add a variable group to store security scan results and reference it in the pipeline.

Why it fails: A variable group stores shared variables, not enforcement logic, so it cannot mandate a security scan or gate production deployment on compliance approval. It is tempting because variable groups legitimately centralise secrets and configuration across pipelines, which would be the right choice when many pipelines must reference the same values rather than satisfy approval requirements.

Use a pipeline decorator to automatically run a security scan on every build.

Why it fails: Using a pipeline decorator to automatically run a security scan on every build does not enforce compliance officer approval for production deployment, and it does not ensure the scan is part of a standardized, required template.

Microsoft Purview Compliance Manager

Why it fails: Microsoft Purview is for data governance and compliance, not secret rotation.

GitHub Actions secrets with scheduled workflows

Why it fails: GitHub Actions secrets do not support automatic rotation natively.

Azure Managed Identities

Why it fails: Managed Identities provide authentication, not secret rotation.

Enforces MFA for all pipeline runs that use the 'MySecrets' variable group

Why it fails: The policy does not enforce MFA on every pipeline run that references the MySecrets variable group; it only requires MFA during the approval step for using the secret variables. Pipeline runs that are already approved or do not trigger the approval flow are not individually gated by MFA.

Requires MFA to edit variables in the 'MySecrets' variable group

Why it fails: The approval-based MFA policy applies to the pipeline's access to the MySecrets variable group at run time, not to editing variables in the Azure DevOps UI. Editing variable values is governed by permission settings and does not trigger the variable group's MFA approval requirement.

Blocks all access to the 'MySecrets' variable group unless MFA is used

Why it fails: The policy does not block all access to the variable group unless MFA is used; rather, it adds an MFA-required approval step specifically when secret variables are accessed during a pipeline run. Users with appropriate permissions can still view or manage the variable group in the UI without this approval flow, so it is not a blanket access gate.

Reader access to the build pipeline

Why it fails: The role assigned in the JSON is Contributor, not Reader, so the user has more than read-only access. Reader access would only allow viewing pipeline definitions and build results, without the ability to modify the pipeline or trigger new builds, which contradicts the granted Contributor privileges.

Contributor access to all build pipelines

Why it fails: Contributor access is scoped exclusively to the build pipeline 'Build-1', not inherited or applied to all build pipelines in the project. In Azure DevOps, pipeline-level permissions are resource-specific, and the JSON shows an explicit ACL entry for that single pipeline, so it does not grant any rights to other build pipelines.

Reader access to the project

Why it fails: The permissions JSON describes user-level permissions on an individual build pipeline, not project-level group membership. Reader access at the project scope would grant read-only visibility across all project areas, but the JSON specifically shows a Contributor role assigned to the 'Build-1' pipeline, which is a finer-grained, resource-level permission.

List the top 5 most active users in Azure DevOps

Why it fails: The query specifically counts only project creation events aggregated per user, so it cannot represent overall user activity across all Azure DevOps actions; therefore it is not a general list of the most active users.

Display detailed audit records of project creation with timestamps

Why it fails: This query uses summarize to produce per-user counts and then top 5, so it does not output individual audit log records; as a result, it cannot display detailed records with timestamps.

Identify users who created projects and have admin role

Why it fails: The query filters only on project creation events and user identity, with no predicate on administrative role; therefore it cannot identify which project creators hold an admin role.

Enable Dependabot alerts and require pull request reviews before merging.

Why it fails: Dependabot alerts specifically target known vulnerabilities in third-party dependencies and are unrelated to secret scanning or commit signature verification. Requiring pull request reviews improves code quality but does not enforce that commits are signed, and a human reviewer cannot reliably identify all secrets or leaked credentials in a large diff. Since the scenario requires both active secret blocking and commit authenticity enforcement, Dependabot plus PR reviews address neither requirement and are therefore insufficient.

Configure branch protection rules to require code owners review and enable automatic security fixes.

Why it fails: Code owner review ensures the correct individuals approve changes but provides no mechanism to detect or block secrets that are contained in a commit. Automatic security fixes, such as Dependabot security updates, only address dependency vulnerabilities and do not scan for secrets or guarantee that commit signatures are verified. This option conflates dependency management and administrative control with secret scanning and commit signing, leaving the core security gaps intact.

Enable push protection for secret scanning and configure branch protection rules with 'Require signed commits' and 'Vigilant mode'.

Why it fails: Push protection for secret scanning proactively blocks Git pushes that contain known secret patterns, such as API keys, tokens, or passwords, before they ever reach the remote repository. Branch protection rules with 'Require signed commits' refuse to merge or accept commits that are not cryptographically signed, and enabling Vigilant mode on GitHub Enterprise additionally marks commits with unverified signatures as unverified, allowing branch protection to block those as well. Together these mechanisms actively prevent secret leakage and enforce a trusted, verified commit history, satisfying the scenario's core security requirements.

Use a resource lock on the Key Vault to prevent deletion.

Why it fails: A resource lock prevents deletion or modification of the Key Vault at the Azure Resource Manager level, but it does not automate secret or certificate rotation, enforce least privilege, or provide audited access controls. It also cannot recover deleted keys, secrets, or certificates, so it fails to address data-loss compliance requirements that soft-delete and purge protection fulfill.

Use a Key Vault access policy to grant developers full access.

Why it fails: Granting developers full Key Vault access violates the principle of least privilege and lets them read, update, or delete secrets and certificates beyond what is required for pipeline or application operation. It introduces a security risk and does not automate certificate rotation or provide compliance-grade auditing, making it an incorrect choice for secure secret management.

Disable Copilot for all repositories in the organization.

Why it fails: Disabling Copilot for all repositories in the organization is an unnecessarily drastic control that eliminates the productivity gains of AI assistance without addressing the underlying risks. Instead, safe use can be achieved through targeted policies such as requiring code reviews, restricting data usage, and disabling training-data sharing, so a complete organization-wide ban is not required for compliance.

Enable 'Suggestions matching public code' to block suggestions that match public code.

Why it fails: This feature is on by default to block suggestions that match public code, but does not address training data usage.

Enable 'Allow GitHub to use my code snippets for product improvements' to improve Copilot.

Why it fails: Enabling 'Allow GitHub to use my code snippets for product improvements' would explicitly grant GitHub permission to retain and use your code snippets for training/improving Copilot models, which directly conflicts with your compliance requirement to keep code out of training data. This setting should be left disabled; note that it is separate from the public-code-matching filter, which only blocks suggestions that duplicate public code and does not affect data usage.

The pipeline will run normally because the required template enforcement only applies to production and staging environments.

Why it fails: Required template enforcement is configured per pipeline or via environment checks, and a pipeline that omits the template fails validation before running, regardless of target environment. The enforcement is not scoped to production and staging alone. This option misreads the check's scope.

The pipeline will run but the security scans will be automatically injected.

Why it fails: Incorrect. Required template enforcement does not automatically inject any templates or security scans; it only verifies that a pipeline references the required template when the deployment targets a scoped environment. The test pipeline, being outside the production/staging enforcement scope, runs exactly as defined without any automatic addition of security scan steps.

The pipeline will prompt the developer to add the required template before running.

Why it fails: Incorrect. Azure DevOps does not prompt developers to modify pipeline definitions before a run; policy enforcement either blocks the run with an error (when in scope) or permits it without interaction (when out of scope). Because the test pipeline is outside the production/staging enforcement scope, no prompt or blocking occurs and the run proceeds as usual.

Configure branch policies in Azure Repos to require a security scan.

Why it fails: Branch policies gate pull requests merging into a branch; they cannot scan build or release pipeline stages before deployment. Branch policies suit code review and build validation on PRs. Pipeline scanning requires a Defender for Cloud DevOps security connector, which surfaces findings across all projects.

Configure deployment gates in Azure Pipelines to require a security scan.

Why it fails: Deployment gates evaluate conditions such as Azure Monitor alerts or REST API checks before a stage, but they do not themselves scan pipelines for security issues. Gates suit release health checks. Defender for Cloud's DevOps security connector is what scans Azure DevOps pipelines and surfaces findings.

Use Azure Policy to enforce scanning on Azure DevOps pipelines.

Why it fails: Azure Policy evaluates and enforces configuration of Azure resources; it has no visibility into Azure DevOps pipelines or their scans. Azure Policy suits resource governance, such as requiring diagnostic settings. Scanning pipelines requires the Defender for Cloud DevOps security connector for Azure DevOps.

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

Why it fails: Adding device compliance would not affect PAT authentication.

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

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

The Conditional Access policy is not enabled.

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

Add a step to create an Azure Container Registry task for scanning.

Why it fails: An Azure Container Registry task is designed for automating image builds and maintenance operations, not for scanning. Even though ACR can integrate with Defender for Cloud for scanning, that scan occurs after the image is pushed to the registry, which fails to meet the requirement to scan before the image is pushed.

Add a step to push the image to Docker Hub for scanning.

Why it fails: Pushing the image to Docker Hub for scanning is not an Azure-native solution and introduces security and compliance concerns by sending container images to an external registry. Additionally, Docker Hub scanning happens only after the image has been pushed, so it cannot serve as a pre-push validation step within the Azure Pipelines workflow.

Create a sensitivity label in Microsoft Purview

Why it fails: Sensitivity labels classify and protect documents and emails after content has been discovered and understood, but they are a downstream action—you must first identify what data you have. In Microsoft Purview, applying a sensitivity label manually to an unregistered data source is ineffective because the label cannot attach to an asset that has not been scanned and mapped. Scanning is the prerequisite that enables label auto-classification based on matched file types and content patterns.

Add the data source to an Azure service tag

Why it fails: Azure service tags are network security constructs used to define inbound or outbound rules for Azure resources, such as allowing traffic from a specific Azure service's IP range. They have no role in data governance, classification, or cataloging, and adding a data source to a service tag would not cause Purview to inspect or index any files or schemas. This option confuses network access controls with data discovery and classification, so it cannot satisfy the requirement to manage data governance.

Define a DLP policy in Microsoft Purview

Why it fails: A DLP policy in Microsoft Purview is designed to monitor and prevent data loss by acting on content that has already been classified and labeled, not to discover unknown data sources. Without a scanned and registered source, there is nothing for the DLP policy to inspect—it can only evaluate data that Purview knows about. Therefore, defining a DLP policy before scanning the source would result in empty or ineffective coverage, making it a premature step in the data governance workflow.

Store secrets in pipeline variables and mark them as secret

Why it fails: Pipeline variables marked secret are stored in Azure DevOps, not Azure Key Vault, so the security team's storage requirement is unmet. It is tempting because secret variables are masked in logs and are the standard way to pass credentials between pipeline tasks when Key Vault is not mandated.

Use Variable Groups linked to Key Vault

Why it fails: Variable Groups linked to Key Vault do retrieve secrets at deployment time, but they are not the best approach because the Azure Key Vault task is more direct and recommended for downloading secrets during deployment. Option C is incorrect because the question asks for the best approach.

Reference Key Vault secrets directly in App Service configuration

Why it fails: App Service Key Vault references resolve at runtime for the running app, not at deployment time as the stem requires, and they bypass Azure Pipelines entirely. It is tempting because Key Vault references are the correct pattern when an application must read secrets during execution.