AZ-400 Develop a security and compliance plan — 50 Questions

Question 1

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

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use secret pipeline variables and ensure the 'Log secret values in the pipeline' checkbox is unchecked.. Secret pipeline variables are the primary method to prevent sensitive information from being exposed in logs; Azure DevOps automatically masks their values. Option A is incorrect because setting 'Logging command' to 'ignore' only disables processing of special logging commands like ##vso[task.setvariable]; script output is still captured and could contain secrets. Option B is incorrect because variable groups do not automatically mask secrets; you must use secret variables. Option C is incorrect because read-only scope does not protect secrets in logs. Enabling Azure DevOps audit logging and sending logs to a SIEM (Option E) is a best practice for monitoring and auditing pipeline runs, allowing detection of potential exposures.

Answer

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

Answer

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

Answer

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

Question 2

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?

Accepted Answer

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.. The pipeline fails because the service principal used by the Azure DevOps service connection that links the variable group to Key Vault (not SP1, which is used for AKS deployments) does not have 'Get' and 'List' permissions on KV-Prod. When a variable group is linked to a Key Vault, Azure Pipelines fetches secrets using the Azure Resource Manager service connection configured for that variable group. That service principal must be explicitly granted Get and List permissions in the Key Vault access policy. SP1's permissions are irrelevant because it is not the identity used for secret retrieval.

Answer

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

Answer

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

Answer

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

Question 3

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?

Accepted Answer

Configure a second manual approval gate and enable immutable feed in Azure Artifacts.. The requirements are two approvals, immutable artifacts, and signed artifacts. Option C supplies two approval gates and an immutable feed but omits code signing. Option D only validates signing, not performs it. Branch policies (B) apply to pull requests, not deployment approvals. Key Vault (A) is for secrets, not artifacts. Therefore, a correct solution would require combining C with an explicit code-signing step, which is not offered. The question should be revised to include an option that covers all three requirements.

Answer

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

Answer

Use branch policies to require two reviewers on pull requests.

Answer

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

Question 4

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

Accepted Answer

Requires multi-factor authentication to approve use of secret variables in the 'MySecrets' variable group. The question prompt only states 'You are reviewing a compliance policy for Azure Pipelines' but does not describe what the policy enforces. Without the policy details, it is impossible to choose any of the options. Furthermore, Azure DevOps does not have a native feature that requires MFA specifically for approving secret variable usage; MFA is generally enforced through Azure AD Conditional Access. Therefore, the question is invalid as written.

Answer

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

Answer

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

Answer

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

Question 5

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

Accepted Answer

Contributor access to the build pipeline named 'Build-1'. The question as presented lacks the critical JSON snippet. Without it, it is impossible to verify any of the options. To make this question valid, the full permissions JSON must be provided in the stem, showing the explicit assignment for user@contoso.com. With that JSON, one could then determine whether they have Contributor to Build-1, Reader, etc.

Answer

Reader access to the build pipeline

Answer

Contributor access to all build pipelines

Answer

Reader access to the project

Question 6

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

Accepted Answer

Find the top 5 users who created the most projects in the last 30 days. No query is shown in the stem. Without the actual KQL query, none of the options can be confirmed as the purpose. The question is invalid as written.

Answer

List the top 5 most active users in Azure DevOps

Answer

Display detailed audit records of project creation with timestamps

Answer

Identify users who created projects and have admin role

Question 7

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?

Accepted Answer

Enable secret scanning alerts and require signed commits via branch protection rules.. The correct combination is A: Enable secret scanning alerts to detect secrets in code before merge, and use branch protection rules to require signed commits, ensuring all commits are GPG-signed. Push protection is more proactive but not required by the stated need to 'scan' secrets. 'Vigilant mode' is not a repository-level enforcement setting; the proper branch protection option is simply 'Require signed commits'.

Answer

Enable Dependabot alerts and require pull request reviews before merging.

Answer

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

Answer

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

Question 8

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?

Accepted Answer

Add a step to use 'Microsoft Defender for Cloud' container image scanning.. Both Microsoft Defender for Cloud and Trivy can be used as pipeline steps to scan container images for vulnerabilities before pushing to a registry. Since the stem does not restrict to a Microsoft-native solution, both A and D are correct.

Answer

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

Answer

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

Question 9

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

Accepted Answer

It denies creation of new pipelines. Azure Policy applies to Azure resources, not Azure DevOps pipelines. There is no Azure Policy definition that can directly deny pipeline creation. Therefore none of the listed effects are correct; the policy would have no effect on pipeline creation.

Answer

It denies creation of any Azure resource

Answer

It allows creation of all pipelines

Answer

It audits pipeline creation without blocking

Question 10

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?

Accepted Answer

Yes, because the condition ensures deployment only from main. The question stem does not include the actual YAML pipeline definition. The requirement to deploy only from main cannot be verified without inspecting the pipeline's stage conditions, branches, and trigger configurations. Since the YAML is absent, it is impossible to determine whether the pipeline meets the security requirement. None of the provided options can be considered correct.

Answer

Yes, because the Deploy stage always runs after Build

Answer

No, because the Build stage should also be conditioned

Answer

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

Question 11

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?

Accepted Answer

Use GitHub Enterprise Cloud with data residency add-on. To comply with data residency requirements, the only valid action among the options is to use GitHub Enterprise Cloud with the data residency add-on. Self-hosted runners only affect compute location, not GitHub-managed data storage. The other options (C, D, E) are unrelated to data residency. Therefore, the question incorrectly requests three actions.

Answer

Use self-hosted runners in the desired region

Answer

Enable GitHub Actions for all repositories

Answer

Enable push protection for secrets

Answer

Configure repository visibility and storage location in GitHub settings

Question 12

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?

Accepted Answer

Use the 'Azure Container Registry' task with the 'Scan' option to check vulnerabilities and fail the pipeline if critical vulnerabilities exist.. To ensure only compliant images are deployed, you must add a vulnerability scan step before deployment that fails the pipeline on critical findings. Microsoft Defender for Cloud scans images in ACR on push, and results can be queried via the Azure CLI or REST API. There is no built-in Azure Pipelines task named 'Azure Container Registry' with a 'Scan' action. A common pattern is to use an Azure CLI task to query scan results or integrate a third-party scanner like Trivy, then conditionally fail the pipeline. None of the listed options accurately describes this.

Answer

Set up Azure Policy to deny deployments of images without scan results.

Answer

Add a task that runs a vulnerability scan on the image after deployment.

Answer

Configure the AKS cluster to scan images after pulling.

Question 13

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

Accepted Answer

Enable secret scanning to detect secrets in code pushes.. GitHub secret scanning automatically detects and alerts on secrets (like API keys and tokens) pushed to repositories, preventing accidental exposure. This is a proactive security measure that integrates with GitHub's push protection to block commits containing known secret patterns. Additionally, storing secrets as GitHub repository secrets or organization secrets ensures they are encrypted and available only to authorized workflows, avoiding hardcoded values. Using OpenID Connect (OIDC) to authenticate to Azure without storing credentials is also a valid measure because it removes the need to store secrets altogether.

Answer

Use hardcoded secrets in workflow files for simplicity.

Answer

Use the same secret across all environments to reduce management overhead.

Question 14

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?

Accepted Answer

Azure Policy for Pipelines, secret variables, and geo-restricted agent pools. It directly addresses all three requirements: geo-restricted agent pools restrict Microsoft-hosted agents to a specific geo-region; Azure Policy for Pipelines can enforce that pipelines only use approved Docker images from a private Azure Container Registry (e.g., via container resource restrictions); and secret variables in Azure Pipelines are automatically masked, with the 'Logging command' option disabled to prevent any accidental logging. These features are native to Azure DevOps and work together to enforce the compliance plan.

Answer

Compliance gates in release pipelines, service connections, and audit logs

Answer

Agent pools with geo-filtering, Azure Policy for Repos to restrict image sources, and secret variables with 'Logging command' disabled

Answer

Entra ID Conditional Access, Azure Container Registry firewall, and pipeline decorators

Question 15

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?

Accepted Answer

Create a custom detection rule in Microsoft Defender XDR using the Azure DevOps identity provider logs. To alert on Azure DevOps group changes, stream Azure DevOps audit logs to a Log Analytics workspace and create an alert rule in Azure Monitor or Microsoft Sentinel. None of the options correctly describe this: A is compliance policy, B is manual, C incorrectly references Defender XDR and identity provider logs, D uses Azure Activity Logs which do not contain Azure DevOps group changes.

Answer

Set up a Microsoft Purview compliance policy for Azure DevOps

Answer

Run a weekly Azure DevOps audit log query manually

Answer

Configure a Log Analytics workspace with Azure Activity Logs

Question 16

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?

Accepted Answer

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. The correct answer is Option D as listed in the answer choices. It creates a conditional access policy targeting the Azure DevOps app, requiring MFA for all users, and excludes service accounts by user group. A separate policy for service accounts requires a compliant device, meeting the device-based, non-interactive authentication requirement while enforcing MFA for external users. Option A excludes Azure DevOps, so no MFA is enforced. Option B applies MFA to service accounts as well, violating the non-interactive requirement. Option C (the IP restriction option) does not use conditional access and does not meet MFA requirements.

Answer

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

Answer

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

Answer

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

Question 17

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?

Accepted Answer

Move all secrets to GitHub Secrets, configure the repository to require approval for all external contributions, and enable audit logging for secret usage. All options satisfy requirement 1 by moving secrets to GitHub Secrets. For requirement 2, GitHub does not pass secrets to workflows triggered by pull requests from forks, so no additional approval setting is required; however, a pull_request_target workflow can expose secrets, and only option A (or a similar fork-check condition) addresses that. For requirement 3, GitHub audit logging for secrets records only secret management events (creation, update, deletion) and does not log which workflow accessed which secret. Therefore, no option fully satisfies the auditor requirement, and the marked answer B is incorrect.

Answer

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

Answer

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

Answer

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

Question 18

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?

Accepted Answer

Enable push protection for secrets in GitHub Advanced Security for Azure Repos.. The correct two actions are to enable GitHub Advanced Security for Azure Repos (which includes secret scanning) and then enable push protection for secrets in the repository settings. Enabling public push protection in GitHub Advanced Security for Azure Repos blocks secrets before they are pushed. Branch policies, Key Vault, and Microsoft Purview Information Protection do not directly detect and block secrets pushed to Azure Repos.

Answer

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

Answer

Store all secrets in Azure Key Vault and reference them in pipelines.

Answer

Configure Microsoft Purview Information Protection to scan repositories.

Question 19

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?

Accepted Answer

Configure Azure DevOps to export all logs to Azure Log Analytics with a 7-year retention.. Azure Log Analytics retention does not provide immutability—data can be purged by administrators. It also does not cover artifacts, test results, or prevent deletion of pipeline runs. The correct solution would be to export all pipeline data to a customer-owned Azure Storage account configured with WORM (immutability) for 7 years and to enforce storage-level deletion prevention. No option describes this.

Answer

Use Azure Policy to enforce immutability on the storage account backing Azure DevOps artifacts, and set pipeline retention policy to 9999 days.

Answer

Assign the 'Project Collection Administrators' group a custom role that denies delete permissions.

Answer

Set branch policies to require approval before any deletion.

Question 20

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?

Accepted Answer

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.. Azure Pipeline decorators inject custom validation logic at runtime, allowing you to inspect each task's service connection and fail the pipeline if it does not match the approved one. This enforces the security requirement centrally without relying on developer compliance or manual gates.

Answer

Define a required template for all pipelines that includes the service connection, and instruct developers to use it.

Answer

Set up a manual approval gate on the production environment stage in the pipeline.

Answer

Configure a branch policy on the main branch to require a successful build before merging.