How should I use these Develop a security and compliance plan practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

AZ-400 · topic practice

Develop a security and compliance plan practice questions

Q: Can I practise just Develop a security and compliance plan questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Develop a security and compliance plan domain.

Practise Microsoft Azure DevOps Engineer Expert AZ-400 Develop a security and compliance plan practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

20 questionsDomain: Develop a security and compliance plan

Practice 10 questions Browse domain →

What the exam tests

What to know about Develop a security and compliance plan

Develop a security and compliance plan questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Develop a security and compliance plan exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Develop a security and compliance plan questions

20 questions · select your answer, then reveal the explanation

Question 1hardmulti select

Read the full Develop a security and compliance plan explanation →

A company uses Azure DevOps and requires that all pipeline runs are audited and that sensitive information (e.g., passwords, keys) is never exposed in logs. Which TWO actions should you take? (Choose TWO.)

Trap 1: In tasks that run scripts, set the 'Logging command' option to…

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.

Trap 2: Store all sensitive information in a variable group and reference…

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.

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

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.

Study all Develop a security and compliance plan common traps →

A
In tasks that run scripts, set the 'Logging command' option to 'ignore' to prevent script output from being captured in the log.
Why wrong: 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.
B
Store all sensitive information in a variable group and reference it in the pipeline.
Why wrong: 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.
C
Configure the service connection to use 'Read-only' scope.
Why wrong: 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.
D
Use secret pipeline variables and ensure the 'Log secret values in the pipeline' checkbox is unchecked.
Secret pipeline variables are encrypted at rest and injected into the agent runtime as environment variables. With the 'Log secret values in the pipeline' checkbox unchecked, the agent's log filter masks the variable's value in all stdout, stderr, and task output, even if a script echoes it. This is the built-in, supported mechanism for protecting credentials because it combines access-controlled storage with output redaction. Always ensure the variable is marked secret; non-secret variables are not masked.
E
Enable Azure DevOps audit logging and send logs to a security information and event management (SIEM) system.
Azure DevOps audit logging records a feed of events including pipeline changes, variable group access, and service connection use. By streaming these logs to a SIEM via Azure Monitor or Event Hubs, security teams can set up correlation rules and alerts for suspicious activity, such as a secret being added to a log or a pipeline running with unintended access. This does not prevent leakage but provides detection and forensic evidence for incidents, which is essential for incident response and compliance. It complements secret masking rather than replacing it.

Full breakdown with real-world context →

Question 2hardmultiple choice

Read the full Develop a security and compliance plan explanation →

You are a DevOps engineer at a healthcare company that must comply with HIPAA. The company uses Azure DevOps with YAML pipelines to deploy a multi-tier application to Azure Kubernetes Service (AKS). The application stores sensitive patient data. The security team requires that all secrets (e.g., database passwords, API keys) must be stored in Azure Key Vault and never hardcoded in the pipeline. The pipeline currently uses a service principal (SP1) for AKS deployments. The pipeline has a variable group 'VG-Prod' linked to Key Vault 'KV-Prod' with secrets: 'DbPassword', 'ApiKey'. The pipeline runs successfully in non-production environments. However, when you run the pipeline for production, it fails at the stage that deploys to AKS with the error: 'Error: failed to get secret 'DbPassword' from Key Vault: Forbidden'. You have verified that the secret exists and the variable group is correctly linked. The service principal SP1 has the 'Get' and 'List' permissions on KV-Prod secrets. The AKS cluster is in a different subscription than the Key Vault. What is the most likely cause and how should you fix it?

Trap 1: The variable group VG-Prod is not properly linked to KV-Prod;…

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.

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

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.

Trap 3: The service principal SP1 does not have 'Get' and 'List'…

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.

Study all Develop a security and compliance plan common traps →

A
The variable group VG-Prod is not properly linked to KV-Prod; re-link it.
Why wrong: 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.
B
The service principal used by the Azure Resource Manager service connection that links the variable group to Key Vault does not have 'Get' and 'List' permissions on KV-Prod; add it to the Key Vault access policy.
Azure DevOps resolves Key Vault-backed variable groups using the project's build service identity (e.g., 'Project Collection Build Service (org)') rather than the user or a custom service principal such as SP1. When the pipeline triggers, the agent invokes Azure Key Vault's REST API to fetch secrets like DbPassword, and that API returns HTTP 403 Forbidden if the calling identity lacks the required 'Get' and 'List' access policy permissions on the vault. Because the error is Forbidden (not NotFound), the secret exists, but the build service identity cannot read it, so the fix is to add that identity to KV-Prod's access policy with 'Get' and 'List' permissions—exactly what the correct option states.
C
The secret 'DbPassword' does not exist in KV-Prod; create it.
Why wrong: 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.
D
The service principal SP1 does not have 'Get' and 'List' permissions on KV-Prod; add them.
Why wrong: 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.

Full breakdown with real-world context →

Question 3hardmultiple choice

Read the full Develop a security and compliance plan explanation →

A financial services company uses Azure DevOps to manage CI/CD pipelines for a critical application. The security team requires that all production deployments be approved by two different managers, and that the build artifacts are immutable and signed. Currently, the pipeline uses a manual approval gate with one approver and stores artifacts in Azure Artifacts. What should the DevOps engineer implement to meet the security requirements?

Trap 1: Store artifacts in Azure Key Vault and use access policies to…

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.

Trap 2: Use branch policies to require two reviewers on pull requests.

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.

Trap 3: Add a pipeline decorator that injects a validation step for code…

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.

Study all Develop a security and compliance plan common traps →

A
Store artifacts in Azure Key Vault and use access policies to control deployment.
Why wrong: 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.
B
Use branch policies to require two reviewers on pull requests.
Why wrong: 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.
C
Configure a second manual approval gate and enable immutable feed in Azure Artifacts.
Configuring a second manual approval gate in a release pipeline ensures two independent human approvals before deployment, while enabling immutable feed in Azure Artifacts prevents artifacts from being overwritten or deleted, guaranteeing a tamper-proof and auditable artifact history for financial compliance.
D
Add a pipeline decorator that injects a validation step for code signing.
Why wrong: 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.

Full breakdown with real-world context →

Question 4mediummultiple choice

Read the full Develop a security and compliance plan explanation →

You are reviewing a compliance policy for Azure Pipelines. What does this policy enforce?

Exhibit

Refer to the exhibit.

```json
{
  "policy": {
    "name": "Require MFA for pipeline variables",
    "scope": [
      "variableGroup:MySecrets"
    ],
    "effects": {
      "requireMFA": {
        "on": "variableGroup:MySecrets",
        "action": "approve"
      }
    }
  }
}
```

Trap 1: Enforces MFA for all pipeline runs that use the 'MySecrets'…

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.

Trap 2: Requires MFA to edit variables in the 'MySecrets' variable group

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.

Trap 3: Blocks all access to the 'MySecrets' variable group unless MFA is…

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.

Study all Develop a security and compliance plan common traps →

A
Enforces MFA for all pipeline runs that use the 'MySecrets' variable group
Why wrong: 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.
B
Requires multi-factor authentication to approve use of secret variables in the 'MySecrets' variable group
This is correct because Azure Pipelines allows you to require approval on a variable group, and the approval action can be configured to require MFA. When a pipeline tries to consume the secret variables from MySecrets, the run pauses until an authorized approver completes an MFA-backed approval, after which the secrets are made available.
C
Requires MFA to edit variables in the 'MySecrets' variable group
Why wrong: 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.
D
Blocks all access to the 'MySecrets' variable group unless MFA is used
Why wrong: 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.

Full breakdown with real-world context →

Question 5mediummultiple choice

Read the full Develop a security and compliance plan explanation →

You are reviewing an Azure DevOps permissions JSON. What access does the user 'user@contoso.com' have?

Exhibit

Refer to the exhibit.

```json
{
  "permissions": [
    {
      "role": "Reader",
      "identity": {
        "type": "group",
        "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
      },
      "scope": "project"
    },
    {
      "role": "Contributor",
      "identity": {
        "type": "user",
        "id": "user@contoso.com"
      },
      "scope": "build:Build-1"
    }
  ]
}
```

Trap 1: Reader access to the build pipeline

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.

Trap 2: Contributor access to all build pipelines

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.

Trap 3: Reader access to the project

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.

Study all Develop a security and compliance plan common traps →

A
Contributor access to the build pipeline named 'Build-1'
The permissions JSON explicitly assigns the Contributor role on the build pipeline resource named 'Build-1', granting the user rights to view, edit, and queue builds for that pipeline only. This is the correct interpretation because the scope is clearly set to the pipeline's access control list, not to any broader project or collection-level permission.
B
Reader access to the build pipeline
Why wrong: 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.
C
Contributor access to all build pipelines
Why wrong: 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.
D
Reader access to the project
Why wrong: 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.

Full breakdown with real-world context →

Question 6hardmultiple choice

Read the full Develop a security and compliance plan explanation →

You are analyzing Azure DevOps audit logs with a KQL query. What is the purpose of this query?

Exhibit

Refer to the exhibit.

```kql
AzureDevOpsAuditLogs
| where TimeGenerated > ago(30d)
| where OperationName == "Project.Create"
| where ResultType == "Success"
| project TimeGenerated, ProjectName, ActorUPN
| summarize Count = count() by ActorUPN
| top 5 by Count desc
```

Trap 1: List the top 5 most active users in Azure DevOps

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.

Trap 2: Display detailed audit records of project creation with timestamps

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.

Trap 3: Identify users who created projects and have admin role

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.

Study all Develop a security and compliance plan common traps →

A
List the top 5 most active users in Azure DevOps
Why wrong: 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.
B
Display detailed audit records of project creation with timestamps
Why wrong: 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.
C
Identify users who created projects and have admin role
Why wrong: 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.
D
Find the top 5 users who created the most projects in the last 30 days
The query filters audit logs for successful project creation events in the last 30 days, groups by user, counts the creations, and returns the top five, exactly matching the statement.

Full breakdown with real-world context →

Question 7hardmultiple choice

Read the full Develop a security and compliance plan explanation →

Your team uses GitHub Enterprise to manage source code. You need to implement a security and compliance plan that ensures all commits are signed using GPG keys and that secrets are scanned before code is merged. Which GitHub features should you combine?

Trap 1: Enable Dependabot alerts and require pull request reviews before…

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.

Trap 2: Configure branch protection rules to require code owners review and…

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.

Trap 3: Enable push protection for secret scanning and configure branch…

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.

Study all Develop a security and compliance plan common traps →

A
Enable secret scanning alerts and require signed commits via branch protection rules.
Secret scanning alerts only notify after a secret has been pushed and are passive; they do not block the vulnerable data from entering the repository history. Requiring signed commits through branch protection ensures that commits are signed, but it does not prevent secrets from being committed in the first place, nor does it scan commit contents for sensitive information. Thus, while the branch protection aspect is valid, the secret protection side remains reactive and leaves the repository exposed to leaked credentials.
B
Enable Dependabot alerts and require pull request reviews before merging.
Why wrong: 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.
C
Configure branch protection rules to require code owners review and enable automatic security fixes.
Why wrong: 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.
D
Enable push protection for secret scanning and configure branch protection rules with 'Require signed commits' and 'Vigilant mode'.
Why wrong: 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.

Full breakdown with real-world context →

Question 8easymultiple choice

Read the full Develop a security and compliance plan explanation →

Your organization needs to ensure that all containers built in Azure Pipelines are scanned for vulnerabilities before being pushed to a container registry. Which step should you add to the pipeline?

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

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.

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

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.

Study all Develop a security and compliance plan common traps →

A
Add a step to use 'Microsoft Defender for Cloud' container image scanning.
Microsoft Defender for Cloud container image scanning is the correct choice because it provides native, built-in vulnerability scanning that can be added as a step in an Azure Pipeline. This ensures every image is scanned before it is pushed to a registry or deployed, with findings integrated into pipeline results and available for policy gating.
B
Add a step to create an Azure Container Registry task for scanning.
Why wrong: 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.
C
Add a step to push the image to Docker Hub for scanning.
Why wrong: 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.
D
Add a step to run Trivy to scan the image.
Trivy is a third-party tool; while possible, the question asks for a native Azure solution.

Full breakdown with real-world context →

Question 9easymultiple choice

Read the full Develop a security and compliance plan explanation →

You are reviewing an Azure Policy definition applied to an Azure DevOps organization. What is the effect of this policy?

Exhibit

Refer to the exhibit.

```json
{
  "properties": {
    "description": "Policy to restrict pipeline creation",
    "policyType": "Custom",
    "mode": "All",
    "displayName": "Deny Pipeline Creation",
    "policyRule": {
      "if": {
        "field": "type",
        "equals": "Microsoft.DevOps/pipelines"
      },
      "then": "Deny"
    }
  }
}
```

Trap 1: It denies creation of any Azure resource

This option is incorrect because the Azure Policy definition's rule targets a specific resource type—namely Microsoft.DevOps/pipelines—rather than all Azure resource types. The 'Deny' effect only blocks the creation of that particular resource, leaving all other Azure resources unaffected.

Trap 2: It allows creation of all pipelines

This option is incorrect and reverses the actual behavior: the policy definition uses the 'Deny' effect, so any attempt to create a pipeline resource matching the rule condition is explicitly blocked. Rather than allowing creation, the policy actively prevents new pipelines from being provisioned.

Trap 3: It audits pipeline creation without blocking

This option is incorrect because it conflates the 'Audit' effect with the 'Deny' effect: 'Audit' merely logs compliance events and does not block deployment, whereas the policy in question uses 'Deny' to actively prohibit creation. Therefore, pipeline creation is stopped entirely rather than simply being logged for review.

Study all Develop a security and compliance plan common traps →

A
It denies creation of any Azure resource
Why wrong: This option is incorrect because the Azure Policy definition's rule targets a specific resource type—namely Microsoft.DevOps/pipelines—rather than all Azure resource types. The 'Deny' effect only blocks the creation of that particular resource, leaving all other Azure resources unaffected.
B
It allows creation of all pipelines
Why wrong: This option is incorrect and reverses the actual behavior: the policy definition uses the 'Deny' effect, so any attempt to create a pipeline resource matching the rule condition is explicitly blocked. Rather than allowing creation, the policy actively prevents new pipelines from being provisioned.
C
It denies creation of new pipelines
This is the correct answer because the policy rule specifies a condition that matches the Microsoft.DevOps/pipelines resource type and applies the 'Deny' effect. As a result, any Azure DevOps pipeline creation attempt that falls within the policy's scope is denied, preventing the resource from being created.
D
It audits pipeline creation without blocking
Why wrong: This option is incorrect because it conflates the 'Audit' effect with the 'Deny' effect: 'Audit' merely logs compliance events and does not block deployment, whereas the policy in question uses 'Deny' to actively prohibit creation. Therefore, pipeline creation is stopped entirely rather than simply being logged for review.

Full breakdown with real-world context →

Question 10hardmultiple choice

Read the full Develop a security and compliance plan explanation →

You are auditing an Azure Pipeline YAML file. The security team requires that deployments to the 'Prod' environment only occur from the main branch. Does this pipeline meet that requirement?

Exhibit

Refer to the exhibit.

```yaml
# azure-pipelines.yml
variables:
- group: ProductionSecrets
- name: environment
  value: 'prod'
stages:
- stage: Build
  jobs:
  - job: BuildJob
    steps:
    - script: echo Building...
- stage: Deploy
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  jobs:
  - deployment: DeployJob
    environment: Prod
    strategy:
      runOnce:
        deploy:
          steps:
          - script: echo Deploying...
```

Trap 1: Yes, because the Deploy stage always runs after Build

In Azure Pipelines, stage execution order is not guaranteed solely by listing Build before Deploy; stages run based on `dependsOn` relationships and `condition` evaluations, and the default is that a stage runs after all previous stages succeed if no conditions are specified. Without confirming the actual YAML, you cannot claim the Deploy stage 'always' runs, and even if it does run after Build, that ordering does not restrict deployments to the main branch—branch filtering must come from a condition. Therefore, this answer is incorrect because it conflates stage order with branch protection.

Trap 2: No, because the Build stage should also be conditioned

This answer incorrectly assumes that the Build stage must have the same main-branch condition as Deploy for the pipeline to be secure. In practice, Build stages are typically run for every branch to compile and test code, while only the Deploy stage is gated to main; separate conditions per stage are supported through `condition:` expressions. The audit question asks whether the deployment is restricted to main, not whether every stage is restricted, so a missing condition on Build does not make the pipeline insecure.

Trap 3: No, because the condition should be 'succeeded()' only

The condition `succeeded()` only ensures that all dependencies have succeeded (e.g., the Build stage finished successfully), but it does nothing to restrict the branch from which deployment occurs. If the Deploy stage's condition were only `succeeded()`, a pipeline run from a non-main branch could still deploy after a successful build, which would violate the security requirement. Therefore, suggesting `succeeded()` only is incorrect; the proper security condition must also check `Build.SourceBranch` equals `refs/heads/main`.

Study all Develop a security and compliance plan common traps →

A
Yes, because the Deploy stage always runs after Build
Why wrong: In Azure Pipelines, stage execution order is not guaranteed solely by listing Build before Deploy; stages run based on `dependsOn` relationships and `condition` evaluations, and the default is that a stage runs after all previous stages succeed if no conditions are specified. Without confirming the actual YAML, you cannot claim the Deploy stage 'always' runs, and even if it does run after Build, that ordering does not restrict deployments to the main branch—branch filtering must come from a condition. Therefore, this answer is incorrect because it conflates stage order with branch protection.
B
No, because the Build stage should also be conditioned
Why wrong: This answer incorrectly assumes that the Build stage must have the same main-branch condition as Deploy for the pipeline to be secure. In practice, Build stages are typically run for every branch to compile and test code, while only the Deploy stage is gated to main; separate conditions per stage are supported through `condition:` expressions. The audit question asks whether the deployment is restricted to main, not whether every stage is restricted, so a missing condition on Build does not make the pipeline insecure.
C
Yes, because the condition ensures deployment only from main
Under Azure Pipelines YAML, a stage can include a condition such as `condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')`, which makes the Deploy stage execute only when the source branch is `main`. This is an effective way to prevent deployments from feature branches or release branches, satisfying the security requirement. Because the YAML in question contains that condition on the Deploy stage, the answer is Yes—the deployment is correctly limited to the main branch.
D
No, because the condition should be 'succeeded()' only
Why wrong: The condition `succeeded()` only ensures that all dependencies have succeeded (e.g., the Build stage finished successfully), but it does nothing to restrict the branch from which deployment occurs. If the Deploy stage's condition were only `succeeded()`, a pipeline run from a non-main branch could still deploy after a successful build, which would violate the security requirement. Therefore, suggesting `succeeded()` only is incorrect; the proper security condition must also check `Build.SourceBranch` equals `refs/heads/main`.

Full breakdown with real-world context →

Question 11hardmulti select

Read the full Develop a security and compliance plan explanation →

Your company uses GitHub and must comply with data residency requirements. Which THREE actions should you take to ensure data stays within a specific geographic region?

Trap 1: Use self-hosted runners in the desired region

Self-hosted runners execute GitHub Actions workflows on infrastructure you control, so source code, build artifacts, and logs are processed and stored within the configured region, meeting data residency requirements. Because the runner fetches jobs from GitHub but runs locally, no workspace data is persisted in GitHub's cloud environment, except for workflow logs which you can route to your own storage.

Trap 2: Enable GitHub Actions for all repositories

Enabling GitHub Actions for all repositories does not control where workflow compute or data is stored; by default, GitHub-hosted runners run in GitHub-managed data centers that may be outside your required region. This action only permits workflows to run, not to enforce data residency, so it is not a valid solution.

Trap 3: Enable push protection for secrets

Push protection for secrets is a security feature that scans for leaked credentials and blocks pushes containing them; it has no effect on where repository data is stored or processed. Data residency is about geographic storage, not secret scanning, so enabling this does not satisfy the requirement.

Study all Develop a security and compliance plan common traps →

A
Use self-hosted runners in the desired region
Why wrong: Self-hosted runners execute GitHub Actions workflows on infrastructure you control, so source code, build artifacts, and logs are processed and stored within the configured region, meeting data residency requirements. Because the runner fetches jobs from GitHub but runs locally, no workspace data is persisted in GitHub's cloud environment, except for workflow logs which you can route to your own storage.
B
Use GitHub Enterprise Cloud with data residency add-on
GitHub Enterprise Cloud's data residency add-on allows you to choose the geographic region where your enterprise's code and metadata are stored, such as the EU or US. This ensures that repository content, issues, pull requests, and Actions artifacts reside in the selected region, satisfying compliance mandates for data sovereignty.
C
Enable GitHub Actions for all repositories
Why wrong: Enabling GitHub Actions for all repositories does not control where workflow compute or data is stored; by default, GitHub-hosted runners run in GitHub-managed data centers that may be outside your required region. This action only permits workflows to run, not to enforce data residency, so it is not a valid solution.
D
Enable push protection for secrets
Why wrong: Push protection for secrets is a security feature that scans for leaked credentials and blocks pushes containing them; it has no effect on where repository data is stored or processed. Data residency is about geographic storage, not secret scanning, so enabling this does not satisfy the requirement.
E
Configure repository visibility and storage location in GitHub settings
Why wrong: Configuring repository visibility affects who can see the repo, not the physical location of its stored data, so it does not enforce data residency. While GitHub Enterprise Cloud offers a data residency add-on for storage location, the repository settings UI alone does not provide a storage region control; you must use the add-on or self-hosted runners.

Full breakdown with real-world context →

Question 12mediummultiple choice

Read the full Develop a security and compliance plan explanation →

Your team uses Azure Pipelines to deploy to Azure Kubernetes Service (AKS). The security team requires that all container images be scanned for vulnerabilities before deployment. You have configured a container registry with Microsoft Defender for Cloud integration. What should you add to your pipeline to ensure only compliant images are deployed?

Trap 1: Set up Azure Policy to deny deployments of images without scan…

Azure Policy can audit or deny resource creation on AKS, but it operates at the cluster/resource level and cannot fail an Azure Pipelines build or release before the image is deployed. By the time policy blocks a pod, the deployment attempt has already left the pipeline, so it does not serve as a pre-deployment gate.

Trap 2: Add a task that runs a vulnerability scan on the image after…

Running a vulnerability scan on the image after it has already been deployed is purely reactive: it detects issues only once the container is running, and it does not automatically stop or roll back the deployment. This approach gives no protection against pushing a vulnerable image to production and violates the goal of gating deployments before they occur.

Trap 3: Configure the AKS cluster to scan images after pulling.

Configuring AKS to scan images after pulling is not a pipeline-level control and, as with post-deployment scanning, only surfaces vulnerabilities after the image has been pulled and started. AKS has no native built-in scan-on-pull mechanism that blocks execution, so this cannot prevent a vulnerable image from being deployed via the pipeline.

Study all Develop a security and compliance plan common traps →

A
Set up Azure Policy to deny deployments of images without scan results.
Why wrong: Azure Policy can audit or deny resource creation on AKS, but it operates at the cluster/resource level and cannot fail an Azure Pipelines build or release before the image is deployed. By the time policy blocks a pod, the deployment attempt has already left the pipeline, so it does not serve as a pre-deployment gate.
B
Add a task that runs a vulnerability scan on the image after deployment.
Why wrong: Running a vulnerability scan on the image after it has already been deployed is purely reactive: it detects issues only once the container is running, and it does not automatically stop or roll back the deployment. This approach gives no protection against pushing a vulnerable image to production and violates the goal of gating deployments before they occur.
C
Configure the AKS cluster to scan images after pulling.
Why wrong: Configuring AKS to scan images after pulling is not a pipeline-level control and, as with post-deployment scanning, only surfaces vulnerabilities after the image has been pulled and started. AKS has no native built-in scan-on-pull mechanism that blocks execution, so this cannot prevent a vulnerable image from being deployed via the pipeline.
D
Use the 'Azure Container Registry' task with the 'Scan' option to check vulnerabilities and fail the pipeline if critical vulnerabilities exist.
The Azure Container Registry task's Scan option runs a vulnerability assessment on the image during the pipeline and can be configured to fail the pipeline if critical vulnerabilities are found. This gate executes before the image is deployed to AKS, ensuring non-compliant containers are blocked in the pipeline and never reach the cluster.

Full breakdown with real-world context →

Question 13hardmulti select

Read the full Develop a security and compliance plan explanation →

Which THREE measures should you implement to protect secrets used in GitHub Actions workflows? (Choose three.)

Trap 1: Use hardcoded secrets in workflow files for simplicity.

Hardcoding secrets in workflow files exposes them to anyone with repository read access, persists them in Git history, and fails to mask them in logs, leading to credential leakage and potential unauthorized access to Azure resources.

Trap 2: Use the same secret across all environments to reduce management…

Reusing one secret across all environments removes the isolation that Azure identity and access management is designed to provide, so a developer who compromises the dev environment gains the exact same access to production data and management plane operations. This violates least privilege and defense in depth: a single exposed secret forces an immediate, organization-wide rotation that impacts every dependent workload and CI/CD pipeline, turning a localized incident into a global outage and forensic nightmare. Instead, use separate, short-lived credentials or Azure managed identities per environment, with distinct access policies, so a dev leak never escalates to a production breach.

Study all Develop a security and compliance plan common traps →

A
Use hardcoded secrets in workflow files for simplicity.
Why wrong: Hardcoding secrets in workflow files exposes them to anyone with repository read access, persists them in Git history, and fails to mask them in logs, leading to credential leakage and potential unauthorized access to Azure resources.
B
Enable secret scanning to detect secrets in code pushes.
Enabling secret scanning on GitHub automatically detects known secret formats (e.g., Azure keys, GitHub tokens) during code pushes, alerts repository administrators and the secret owner, and can block the push or trigger remediation workflows, preventing secrets from being merged.
C
Use the same secret across all environments to reduce management overhead.
Why wrong: Reusing one secret across all environments removes the isolation that Azure identity and access management is designed to provide, so a developer who compromises the dev environment gains the exact same access to production data and management plane operations. This violates least privilege and defense in depth: a single exposed secret forces an immediate, organization-wide rotation that impacts every dependent workload and CI/CD pipeline, turning a localized incident into a global outage and forensic nightmare. Instead, use separate, short-lived credentials or Azure managed identities per environment, with distinct access policies, so a dev leak never escalates to a production breach.
D
Use OpenID Connect (OIDC) to authenticate to Azure without storing credentials.
Using OpenID Connect (OIDC) for GitHub Actions to Azure eliminates the need to store static credentials in GitHub by exchanging a short-lived token from the GitHub Actions workflow with an Azure AD identity. Configure the Azure AD app or user-assigned managed identity with federated credentials that trust the specific GitHub repository, branch, or environment; at runtime, the workflow uses the OIDC token to request an Azure AD access token. This leverages conditional access and least-privilege federation, ensures tokens expire in minutes rather than months, and removes the rotation burden entirely — the secret that never gets stored is the one that cannot leak.
E
Store secrets as GitHub repository secrets or organization secrets.
Storing secrets as GitHub repository or organization secrets provides encryption at rest with AES-256, automatic log masking, and strict access controls that prevent exposure in workflow files and Git history. These secrets are injected into the workflow's environment only during the job runtime via the secrets context, and they are not available to pull requests from forks, mitigating malicious PR attacks. Organization-level secrets allow centralized management across multiple repositories while still honoring environment-based scoping like GitHub Environments, so you can enforce branch protection rules and require manual approval before sensitive values are released.

Full breakdown with real-world context →

Question 14hardmultiple choice

Read the full Develop a security and compliance plan explanation →

You are designing a security compliance plan for Azure Pipelines. The plan must ensure that all pipelines: (1) run on Microsoft-hosted agents in a specific geo-region, (2) use approved Docker images from a private Azure Container Registry, and (3) enforce that pipeline variables containing secrets are never logged. Which combination of Azure DevOps features should you use?

Trap 1: Compliance gates in release pipelines, service connections, and…

Compliance gates in release pipelines enforce pre-deployment approvals, checkpoints, or manual validation, but they do not control the geographic location of Microsoft-hosted or self-hosted agents, nor do they constrain which container images or code sources are allowed. Service connections are merely credential vaults for connecting to Azure resources or external systems; they grant access but provide no geo-restriction or image-source policy. Audit logs, while useful for incident investigations, are retrospective and cannot proactively enforce compliance with agent geography or image provenance requirements.

Trap 2: Agent pools with geo-filtering, Azure Policy for Repos to restrict…

This answer is correct because it addresses all three core requirements: agent pools with geo-filtering restrict pipeline execution to agents in approved Azure regions, ensuring data residency and compliance boundaries. Azure Policy for Repos can enforce policies that restrict which image sources are permitted, for example only allowing images from designated Azure Container Registry instances. Additionally, using secret variables with the 'Logging command' option disabled ensures that secrets are not exposed in pipeline logs, which is a critical security control for credential handling.

Trap 3: Entra ID Conditional Access, Azure Container Registry firewall, and…

Entra ID Conditional Access controls user and sign-in risk by enforcing MFA, device compliance, or session policies, but it does not govern what happens inside an Azure Pipeline execution context. An Azure Container Registry firewall restricts network access to the registry, but it does not stop a pipeline from pulling an unapproved image from another registry or from using an agent in a forbidden region. Pipeline decorators can inject steps or variables into every pipeline, but they are a tool for consistency, not for geo-limiting agent pools or validating image source compliance.

Study all Develop a security and compliance plan common traps →

A
Compliance gates in release pipelines, service connections, and audit logs
Why wrong: Compliance gates in release pipelines enforce pre-deployment approvals, checkpoints, or manual validation, but they do not control the geographic location of Microsoft-hosted or self-hosted agents, nor do they constrain which container images or code sources are allowed. Service connections are merely credential vaults for connecting to Azure resources or external systems; they grant access but provide no geo-restriction or image-source policy. Audit logs, while useful for incident investigations, are retrospective and cannot proactively enforce compliance with agent geography or image provenance requirements.
B
Agent pools with geo-filtering, Azure Policy for Repos to restrict image sources, and secret variables with 'Logging command' disabled
Why wrong: This answer is correct because it addresses all three core requirements: agent pools with geo-filtering restrict pipeline execution to agents in approved Azure regions, ensuring data residency and compliance boundaries. Azure Policy for Repos can enforce policies that restrict which image sources are permitted, for example only allowing images from designated Azure Container Registry instances. Additionally, using secret variables with the 'Logging command' option disabled ensures that secrets are not exposed in pipeline logs, which is a critical security control for credential handling.
C
Entra ID Conditional Access, Azure Container Registry firewall, and pipeline decorators
Why wrong: Entra ID Conditional Access controls user and sign-in risk by enforcing MFA, device compliance, or session policies, but it does not govern what happens inside an Azure Pipeline execution context. An Azure Container Registry firewall restricts network access to the registry, but it does not stop a pipeline from pulling an unapproved image from another registry or from using an agent in a forbidden region. Pipeline decorators can inject steps or variables into every pipeline, but they are a tool for consistency, not for geo-limiting agent pools or validating image source compliance.
D
Azure Policy for Pipelines, secret variables, and geo-restricted agent pools
Azure Policy for Pipelines is not an actual Azure service; Azure Policy applies to Azure resources such as VMs, storage, and containers, and for repository governance you would use Azure Policy for Repos (or branch policies). While secret variables and geo-restricted agent pools are legitimate and desirable controls, the mention of a non-existent feature invalidates this option. Even if the other components are correct, the plan cannot be implemented as described because that policy type does not exist.

Full breakdown with real-world context →

Question 15mediummultiple choice

Read the full Develop a security and compliance plan explanation →

Your organization uses Microsoft Defender XDR for security monitoring. You need to configure an alert that fires whenever a user with high privileges (e.g., Project Collection Administrators) is added to an Azure DevOps group. What is the most efficient approach?

Trap 1: Set up a Microsoft Purview compliance policy for Azure DevOps

Microsoft Purview centers on data classification, retention, and eDiscovery across M365 and broader data estates, not real-time security alerting. It does not natively ingest Azure DevOps audit events, and even with configured policies, it lacks the detection and response automation that Defender XDR provides, making it an incorrect fit for real-time security alerts.

Trap 2: Run a weekly Azure DevOps audit log query manually

Manually querying the Azure DevOps audit log weekly introduces a detection gap of up to seven days and depends entirely on an administrator's discipline and ability to interpret results. Manual queries are neither automated nor real-time, so they cannot satisfy a requirement for immediate alerting on identity anomalies or suspicious DevOps activities.

Trap 3: Configure a Log Analytics workspace with Azure Activity Logs

Azure Activity Log is a subscription-level control-plane log for Azure resource operations; it does not include Azure DevOps audit events such as pipeline runs, project access, or identity changes. Configuring Log Analytics with Activity Logs alone would therefore miss DevOps-specific security signals and would not enable the required real-time detection in Defender XDR.

Study all Develop a security and compliance plan common traps →

A
Set up a Microsoft Purview compliance policy for Azure DevOps
Why wrong: Microsoft Purview centers on data classification, retention, and eDiscovery across M365 and broader data estates, not real-time security alerting. It does not natively ingest Azure DevOps audit events, and even with configured policies, it lacks the detection and response automation that Defender XDR provides, making it an incorrect fit for real-time security alerts.
B
Run a weekly Azure DevOps audit log query manually
Why wrong: Manually querying the Azure DevOps audit log weekly introduces a detection gap of up to seven days and depends entirely on an administrator's discipline and ability to interpret results. Manual queries are neither automated nor real-time, so they cannot satisfy a requirement for immediate alerting on identity anomalies or suspicious DevOps activities.
C
Create a custom detection rule in Microsoft Defender XDR using the Azure DevOps identity provider logs
Custom detection rules in Microsoft Defender XDR can consume Azure DevOps audit and identity provider logs—for example, via the Microsoft Graph API or a connected data source—and trigger alerts automatically. This approach provides near-real-time coverage for suspicious activities like anomalous sign-ins or unauthorized access, directly meeting the stated security monitoring requirement.
D
Configure a Log Analytics workspace with Azure Activity Logs
Why wrong: Azure Activity Log is a subscription-level control-plane log for Azure resource operations; it does not include Azure DevOps audit events such as pipeline runs, project access, or identity changes. Configuring Log Analytics with Activity Logs alone would therefore miss DevOps-specific security signals and would not enable the required real-time detection in Defender XDR.

Full breakdown with real-world context →

Question 16mediummultiple choice

Read the full VPN explanation →

Your company is migrating from on-premises TFS to Azure DevOps Services in the cloud. The security policy mandates that all access to Azure DevOps must go through a conditional access policy that requires multi-factor authentication (MFA) for users outside the corporate network. Additionally, the policy requires that service accounts (used for automated deployments) must use device-based authentication and cannot be interactive. You are configuring Microsoft Entra ID (formerly Azure AD) conditional access. The Azure DevOps organization is connected to the corporate Entra ID tenant. You have the following options:

Option A: Create a conditional access policy that applies to all users and service principals, requiring MFA for all cloud apps, and exclude the Azure DevOps app from the policy.

Option B: Create a conditional access policy that targets the Azure DevOps app, grant access requiring MFA for all users, and create a separate policy for service accounts that requires device compliance.

Option C: Create a conditional access policy that applies to the Azure DevOps app, requiring MFA for all users, and exclude service accounts by user group. Then create a separate policy for service accounts that requires a compliant device.

Option D: Use Azure DevOps IP address restrictions to block external traffic and rely on VPN for external users.

Which option best meets the requirements?

Trap 1: Create a conditional access policy that applies to all users and…

This policy would miss Azure DevOps altogether. By explicitly excluding the Azure DevOps application from the policy, no Conditional Access evaluation occurs for the app, so users can sign in without MFA. Additionally, targeting 'all cloud apps' while excluding Azure DevOps leaves a clear gap for this specific application. A policy must target the Azure DevOps app (or an approved client app) to enforce MFA on its sign-ins.

Trap 2: Create a conditional access policy that targets the Azure DevOps…

The MFA policy for all users is on the right track, but pairing it with a device compliance policy for service accounts is unenforceable for automation. Service accounts—especially service principals or non-interactive users—are not tied to an enrolled, compliant device and cannot complete interactive device compliance challenges. Device-based Conditional Access controls only work for interactive user sign-ins on managed devices; requiring compliance on a separate service-account policy would block automated builds or force an impossible device enrollment.

Trap 3: Use Azure DevOps IP address restrictions to block external traffic…

IP restrictions in Azure DevOps only control where traffic originates, not who is requesting access. If a user's credentials are compromised, an attacker on a corporate network or VPN could still gain access without MFA. Reliance on VPN for external users does not add a second authentication factor and creates a maintenance overhead for administrators. This approach abandons the MFA requirement entirely and should be rejected.

Study all Develop a security and compliance plan common traps →

A
Create a conditional access policy that applies to all users and service principals, requiring MFA for all cloud apps, and exclude the Azure DevOps app
Why wrong: This policy would miss Azure DevOps altogether. By explicitly excluding the Azure DevOps application from the policy, no Conditional Access evaluation occurs for the app, so users can sign in without MFA. Additionally, targeting 'all cloud apps' while excluding Azure DevOps leaves a clear gap for this specific application. A policy must target the Azure DevOps app (or an approved client app) to enforce MFA on its sign-ins.
B
Create a conditional access policy that targets the Azure DevOps app, grant access requiring MFA for all users, and create a separate policy for service accounts that requires device compliance
Why wrong: The MFA policy for all users is on the right track, but pairing it with a device compliance policy for service accounts is unenforceable for automation. Service accounts—especially service principals or non-interactive users—are not tied to an enrolled, compliant device and cannot complete interactive device compliance challenges. Device-based Conditional Access controls only work for interactive user sign-ins on managed devices; requiring compliance on a separate service-account policy would block automated builds or force an impossible device enrollment.
C
Use Azure DevOps IP address restrictions to block external traffic and rely on VPN for external users
Why wrong: IP restrictions in Azure DevOps only control where traffic originates, not who is requesting access. If a user's credentials are compromised, an attacker on a corporate network or VPN could still gain access without MFA. Reliance on VPN for external users does not add a second authentication factor and creates a maintenance overhead for administrators. This approach abandons the MFA requirement entirely and should be rejected.
D
Create a conditional access policy that applies to the Azure DevOps app, requiring MFA for all users, and exclude service accounts by user group. Then create a separate policy for service accounts that requires a compliant device
This is the correct design because it separates interactive user policy from non-interactive service account policy. The first policy applies to the Azure DevOps app and requires MFA for all normal users, blocking credential theft from regular accounts. The second policy exempts only the service account group from MFA and instead requires the service accounts' sign-ins to come from a compliant device, preserving automation while adding device-based security.

Full breakdown with real-world context →

Question 17easymultiple choice

Read the full Develop a security and compliance plan explanation →

Your development team uses GitHub Enterprise with GitHub Actions for CI/CD. The security team wants to ensure that all secrets used in workflows are stored in GitHub Secrets and that they are not accessible to forked repositories. Currently, some workflows reference secrets directly in YAML files. You need to implement a solution that meets the following requirements: (1) Secrets must be stored in GitHub Secrets, not in YAML files. (2) Workflows triggered from forked repositories must not have access to organization secrets. (3) Auditors must be able to see which workflows access which secrets.

Option A: Move all secrets to GitHub Secrets, configure the repository to require approval for all external contributions, and enable audit logging for secret usage.

Option B: Move all secrets to GitHub Secrets, and in the repository settings, disable 'Allow GitHub Actions to create and approve pull requests' and enable 'Fork pull request workflows from outside collaborators' to require approval.

Option C: Move all secrets to GitHub Secrets, and in the organization settings, enable 'Private repository fork policy' to only allow forks from within the organization, and use environment secrets with required reviewers.

Option D: Move all secrets to GitHub Secrets, and for each workflow that uses secrets, add a condition to check if the event is from a fork, and if so, skip the step.

Which option best satisfies all requirements?

Trap 1: Move all secrets to GitHub Secrets, and for each workflow that uses…

This approach is brittle because it relies on manually maintained job-level conditions (e.g., github.event.pull_request.head.repo.fork == true) that malicious actors can bypass by modifying the workflow file, and it does not provide centralized audit logging or enforced approval for secret access. It also creates no organization-wide security boundary, making secret exposure likely if the condition is omitted or incorrectly written.

Trap 2: Move all secrets to GitHub Secrets, and in the repository settings,…

Disabling 'Allow GitHub Actions to create and approve pull requests' and enabling fork workflow approval only adds a manual approval gate before the workflow runs; once an approver approves the run, the forked code executes with full access to all configured GitHub secrets. This does not enforce least-privilege or provide audit logging, and a malicious fork can still use the approved workflow to read secrets or leak them to an external endpoint.

Trap 3: Move all secrets to GitHub Secrets, and in the organization…

This only restricts who can fork, but if a fork is made, secrets might still be accessible.

Study all Develop a security and compliance plan common traps →

A
Move all secrets to GitHub Secrets, and for each workflow that uses secrets, add a condition to check if the event is from a fork, and if so, skip the step
Why wrong: This approach is brittle because it relies on manually maintained job-level conditions (e.g., github.event.pull_request.head.repo.fork == true) that malicious actors can bypass by modifying the workflow file, and it does not provide centralized audit logging or enforced approval for secret access. It also creates no organization-wide security boundary, making secret exposure likely if the condition is omitted or incorrectly written.
B
Move all secrets to GitHub Secrets, configure the repository to require approval for all external contributions, and enable audit logging for secret usage
This meets all requirements: secrets in GitHub Secrets, fork access controlled via approval, and audit logging available.
C
Move all secrets to GitHub Secrets, and in the repository settings, disable 'Allow GitHub Actions to create and approve pull requests' and enable 'Fork pull request workflows from outside collaborators' to require approval
Why wrong: Disabling 'Allow GitHub Actions to create and approve pull requests' and enabling fork workflow approval only adds a manual approval gate before the workflow runs; once an approver approves the run, the forked code executes with full access to all configured GitHub secrets. This does not enforce least-privilege or provide audit logging, and a malicious fork can still use the approved workflow to read secrets or leak them to an external endpoint.
D
Move all secrets to GitHub Secrets, and in the organization settings, enable 'Private repository fork policy' to only allow forks from within the organization, and use environment secrets with required reviewers
Why wrong: This only restricts who can fork, but if a fork is made, secrets might still be accessible.

Full breakdown with real-world context →

Question 18easymulti select

Read the full Develop a security and compliance plan explanation →

Your organization uses Microsoft Defender for Cloud and Azure DevOps. Security teams need to automatically detect and block secrets (e.g., passwords, keys) pushed to Azure Repos. Which TWO actions should you take?

Trap 1: Set branch policies to require a pull request for all changes.

Branch policies enforce a mandatory pull request workflow and can require reviewers, build validation, and work item linking, but they do not inspect the content of the diff for secret patterns by default. A pull request can introduce a secret that passes through unnoticed unless a custom build pipeline task (like a secret-scanning step) is explicitly added. Therefore, while it improves code quality and governance, it provides no inherent secret detection or blocking.

Trap 2: Store all secrets in Azure Key Vault and reference them in…

Azure Key Vault is a secure store for managing secrets, keys, and certificates, and pipelines can reference them via linked service connections or Variable Groups. However, it does not scan source code repositories for hardcoded secrets, nor does it prevent a developer from copying a secret value into a configuration file or source file. The security control is about centralized storage and rotation, not about discovering secrets that already exist in code.

Trap 3: Configure Microsoft Purview Information Protection to scan…

Microsoft Purview Information Protection (formerly Azure Information Protection) is designed for classifying and protecting documents and emails by applying sensitivity labels and encryption (e.g., in Microsoft 365 apps). It does not natively integrate with Azure Repos or scan git repositories for secrets, nor does it understand Git push events. While it can classify files in SharePoint or OneDrive, it is not a code security tool and offers no real-time secret detection or push blocking.

Study all Develop a security and compliance plan common traps →

A
Enable push protection for secrets in GitHub Advanced Security for Azure Repos.
Correct. Push protection for secrets is configured in GitHub Advanced Security for Azure Repos and blocks secrets from being pushed.
B
Set branch policies to require a pull request for all changes.
Why wrong: Branch policies enforce a mandatory pull request workflow and can require reviewers, build validation, and work item linking, but they do not inspect the content of the diff for secret patterns by default. A pull request can introduce a secret that passes through unnoticed unless a custom build pipeline task (like a secret-scanning step) is explicitly added. Therefore, while it improves code quality and governance, it provides no inherent secret detection or blocking.
C
Store all secrets in Azure Key Vault and reference them in pipelines.
Why wrong: Azure Key Vault is a secure store for managing secrets, keys, and certificates, and pipelines can reference them via linked service connections or Variable Groups. However, it does not scan source code repositories for hardcoded secrets, nor does it prevent a developer from copying a secret value into a configuration file or source file. The security control is about centralized storage and rotation, not about discovering secrets that already exist in code.
D
Enable secret scanning in GitHub Advanced Security for Azure Repos.
Secret scanning, also part of GitHub Advanced Security for Azure Repos, continuously monitors the repository for any committed secrets—including those added in past commits. When enabled, it notifies security administrators and can be configured to either alert or block pushes, depending on the push protection setting. It also scans for secrets in the entire commit history, making it a necessary complement to push protection for discovering exfiltration that may have already occurred.
E
Configure Microsoft Purview Information Protection to scan repositories.
Why wrong: Microsoft Purview Information Protection (formerly Azure Information Protection) is designed for classifying and protecting documents and emails by applying sensitivity labels and encryption (e.g., in Microsoft 365 apps). It does not natively integrate with Azure Repos or scan git repositories for secrets, nor does it understand Git push events. While it can classify files in SharePoint or OneDrive, it is not a code security tool and offers no real-time secret detection or push blocking.

Full breakdown with real-world context →

Question 19hardmultiple choice

Read the full Develop a security and compliance plan explanation →

Your company is deploying Azure DevOps pipelines for a critical financial application. Compliance requires that all pipeline runs are immutable and auditable. You must ensure that once a pipeline completes, its logs, artifacts, and test results cannot be modified or deleted by anyone, including administrators, for 7 years. You also need to prevent any pipeline runs from being deleted. Azure DevOps retention policies are currently set to 30 days. What should you do?

Trap 1: Use Azure Policy to enforce immutability on the storage account…

Azure Policy cannot be applied to the Microsoft-managed storage account backing Azure DevOps artifacts. The storage is not under your control.

Trap 2: Assign the 'Project Collection Administrators' group a custom role…

Project Collection Administrators (PCAs) are a built-in administrative group in Azure DevOps with organization-wide permissions that override most security restrictions. Azure DevOps does not use Azure RBAC custom roles for pipeline deletion; permissions are granted via built-in security namespaces, and admins can always reassign permissions or bypass deny rules, making this approach ineffective for enforcing immutability or preventing deletion.

Trap 3: Set branch policies to require approval before any deletion.

Branch policies control approval workflows for code changes (e.g., pull requests) and protect branches from unauthorized merges or direct pushes; they do not cover the deletion of pipeline runs, logs, or artifacts. Retention of pipeline execution history is managed by pipeline retention policies in Azure DevOps settings, not by branch-level approvals, so this option fails to address the compliance requirement.

Study all Develop a security and compliance plan common traps →

A
Use Azure Policy to enforce immutability on the storage account backing Azure DevOps artifacts, and set pipeline retention policy to 9999 days.
Why wrong: Azure Policy cannot be applied to the Microsoft-managed storage account backing Azure DevOps artifacts. The storage is not under your control.
B
Assign the 'Project Collection Administrators' group a custom role that denies delete permissions.
Why wrong: Project Collection Administrators (PCAs) are a built-in administrative group in Azure DevOps with organization-wide permissions that override most security restrictions. Azure DevOps does not use Azure RBAC custom roles for pipeline deletion; permissions are granted via built-in security namespaces, and admins can always reassign permissions or bypass deny rules, making this approach ineffective for enforcing immutability or preventing deletion.
C
Set branch policies to require approval before any deletion.
Why wrong: Branch policies control approval workflows for code changes (e.g., pull requests) and protect branches from unauthorized merges or direct pushes; they do not cover the deletion of pipeline runs, logs, or artifacts. Retention of pipeline execution history is managed by pipeline retention policies in Azure DevOps settings, not by branch-level approvals, so this option fails to address the compliance requirement.
D
Configure Azure DevOps to export all logs to Azure Log Analytics with a 7-year retention.
Exporting logs to Azure Log Analytics (a customer-owned service) allows you to configure retention and immutability policies. This aligns with the requirement to store data in a customer-controlled location with enforced immutability.

Full breakdown with real-world context →

Question 20mediummultiple choice

Read the full Develop a security and compliance plan explanation →

A company uses Azure DevOps for CI/CD. The security team requires that all pipeline runs must use a specific service connection (ServiceConnection-Prod) that has been approved for production deployments. However, developers are accidentally using unapproved connections. You need to enforce that only the approved service connection can be used in any pipeline that deploys to the production environment. What should you do?

Trap 1: Define a required template for all pipelines that includes the…

A required template is at best a convention; Azure DevOps does not provide an enforce-template setting that blocks pipelines which do not call the template. The `extends` keyword can force a structured hierarchy if you also control repository permissions and prevent contributors from creating new pipelines or bypassing the template owner, but simply telling developers to use a shared template leaves room for ad-hoc YAML that references unapproved service connections directly. Because the template only runs when a pipeline actually invokes it, it cannot guarantee that the approved connection is used across all pipelines, and misconfiguration can easily go unnoticed. Thus, this approach relies on developer compliance rather than being a robust control.

Trap 2: Set up a manual approval gate on the production environment stage…

Manual approval gates on a production environment require human sign-off before deployment, but they do not evaluate or restrict which service connection is used by pipeline tasks; a pipeline could still reference an unapproved service connection while the gate only checks for authorization.

Trap 3: Configure a branch policy on the main branch to require a…

Branch policies on the main branch validate PRs and builds before merging, but they do not inspect the service connection references inside pipeline definitions, and they only protect the branch after the pipeline runs, leaving the actual connection usage ungoverned.

Study all Develop a security and compliance plan common traps →

A
Define a required template for all pipelines that includes the service connection, and instruct developers to use it.
Why wrong: A required template is at best a convention; Azure DevOps does not provide an enforce-template setting that blocks pipelines which do not call the template. The `extends` keyword can force a structured hierarchy if you also control repository permissions and prevent contributors from creating new pipelines or bypassing the template owner, but simply telling developers to use a shared template leaves room for ad-hoc YAML that references unapproved service connections directly. Because the template only runs when a pipeline actually invokes it, it cannot guarantee that the approved connection is used across all pipelines, and misconfiguration can easily go unnoticed. Thus, this approach relies on developer compliance rather than being a robust control.
B
Set up a manual approval gate on the production environment stage in the pipeline.
Why wrong: Manual approval gates on a production environment require human sign-off before deployment, but they do not evaluate or restrict which service connection is used by pipeline tasks; a pipeline could still reference an unapproved service connection while the gate only checks for authorization.
C
Configure a branch policy on the main branch to require a successful build before merging.
Why wrong: Branch policies on the main branch validate PRs and builds before merging, but they do not inspect the service connection references inside pipeline definitions, and they only protect the branch after the pipeline runs, leaving the actual connection usage ungoverned.
D
Create an Azure Pipeline decorator that validates the service connection used in each task and fails the pipeline if it is not the approved one.
A pipeline decorator is an extension-based mechanism that injects a custom task into every pipeline run at the specified point (pre-job, post-job, or around a task). By defining a post-task decorator, you can read the inputs of each executed task—such as the `connectedServiceName` or `azureSubscription` input—and compare the referenced service connection to the organization's approved list. If the connection is not approved, the decorator can set the task result to `Failed` and stop the pipeline, providing a hard enforcement that ordinary YAML conventions cannot achieve. This works for any pipeline that uses the task, regardless of whether the author referenced a shared template.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Develop a security and compliance plan sessions

Start a Develop a security and compliance plan only practice session

Every question in these sessions is drawn from the Develop a security and compliance plan domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Develop a security and compliance plan questions →Mixed AZ-400 session

Frequently asked questions

What does the AZ-400 exam test about Develop a security and compliance plan?: Develop a security and compliance plan questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Develop a security and compliance plan questions in a focused session?: Yes — the session launcher on this page draws every question from the Develop a security and compliance plan domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other AZ-400 topics?: Use the topic links above to move to related areas, or go back to the AZ-400 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the AZ-400 exam covers. They are not copied from any real exam or dump site.

Develop a security and compliance plan only

10 questions 20 questions 30 questions 50 questions

Mixed AZ-400 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All AZ-400 questions Develop a security and compliance plan domain overview AZ-400 exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Develop a security and compliance plan practice questions

What to know about Develop a security and compliance plan

Common Develop a security and compliance plan exam traps

Develop a security and compliance plan questions

A company uses Azure DevOps and requires that all pipeline runs are audited and that sensitive information (e.g., passwords, keys) is never exposed in logs. Which TWO actions should you take? (Choose TWO.)

You are reviewing a compliance policy for Azure Pipelines. What does this policy enforce?

Exhibit

You are reviewing an Azure DevOps permissions JSON. What access does the user 'user@contoso.com' have?

Exhibit

You are analyzing Azure DevOps audit logs with a KQL query. What is the purpose of this query?

Exhibit

Your team uses GitHub Enterprise to manage source code. You need to implement a security and compliance plan that ensures all commits are signed using GPG keys and that secrets are scanned before code is merged. Which GitHub features should you combine?

Your organization needs to ensure that all containers built in Azure Pipelines are scanned for vulnerabilities before being pushed to a container registry. Which step should you add to the pipeline?

You are reviewing an Azure Policy definition applied to an Azure DevOps organization. What is the effect of this policy?

Exhibit

You are auditing an Azure Pipeline YAML file. The security team requires that deployments to the 'Prod' environment only occur from the main branch. Does this pipeline meet that requirement?

Exhibit

Your company uses GitHub and must comply with data residency requirements. Which THREE actions should you take to ensure data stays within a specific geographic region?

Which THREE measures should you implement to protect secrets used in GitHub Actions workflows? (Choose three.)

Your organization uses Microsoft Defender XDR for security monitoring. You need to configure an alert that fires whenever a user with high privileges (e.g., Project Collection Administrators) is added to an Azure DevOps group. What is the most efficient approach?

Your organization uses Microsoft Defender for Cloud and Azure DevOps. Security teams need to automatically detect and block secrets (e.g., passwords, keys) pushed to Azure Repos. Which TWO actions should you take?

Track your progress over time

Start a Develop a security and compliance plan only practice session

Related AZ-400 topic practice pages

Configure processes and communications practice questions

Design and implement source control practice questions