AZ-400 Develop a security and compliance plan Practice Test 3 — 15 Questions

Question 1

Your company uses GitHub and wants to implement a compliance framework that requires signed commits for all repositories. Developers use various IDEs and Git clients. What is the best way to enforce signed commits across the organization?

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

Accepted Answer

Enable 'Require signed commits' in the branch protection rules for the default branch.. Enabling 'Require signed commits' in branch protection rules for the default branch is the only option that enforces signed commits at the platform level, rejecting any unsigned commit pushed to the protected branch regardless of IDE or Git client. This provides organization-wide, non-bypassable enforcement without relying on developer discipline or manual review.

Answer

Set the repository to 'Require pull request reviews before merging' and rely on reviewers to check commit signatures.

Answer

Ask developers to configure GPG keys and sign commits manually.

Answer

Use a GitHub Action that fails if commits are unsigned.

Question 2

Your team uses GitHub Actions for CI/CD and must ensure that only approved contributors can merge code to the main branch. You need to enforce a policy where every pull request must be reviewed by at least two members of the security team. Which branch protection rule should you configure?

Accepted Answer

Require a minimum number of reviewers. The 'Require a minimum number of reviewers' branch protection rule in GitHub directly enforces that a specified number of reviewers must approve a pull request before it can be merged. By setting this minimum to two and restricting review permissions to the security team, you ensure that only approved security team members can authorize merges to the main branch, meeting the policy requirement.

Answer

Require pull request reviews before merging

Answer

Require status checks to pass before merging

Answer

Dismiss stale pull request approvals

Question 3

Your team uses Azure Pipelines to deploy to production. You need to ensure that deployment only proceeds if a security scan passes and a manual approval is obtained. What is the best approach?

Accepted Answer

Use release gates in release pipelines. Release gates in Azure release pipelines are purpose-built to evaluate conditions such as security scan results and manual approvals before a deployment proceeds. A gate can call an external REST API (e.g., a vulnerability scanner) and require a successful response, and an approval gate can require a designated approver to sign off. This directly satisfies both requirements — security scan pass and manual approval — without custom scripting.

Answer

Add pipeline variables

Answer

Set up service connections

Answer

Configure branch policies

Question 4

Your team uses GitHub and wants to automatically detect exposed credentials in code. Which GitHub feature should you enable?

Accepted Answer

Secret scanning. Secret scanning is the correct answer because it is the GitHub feature specifically designed to automatically detect exposed credentials, such as API keys, tokens, and passwords, in code repositories. It scans for known patterns of secrets and can alert both the repository owner and the partner service (e.g., AWS, Azure) to revoke the compromised credential. This directly addresses the requirement to automatically detect exposed credentials in code.

Answer

Dependabot alerts

Answer

GitHub Copilot

Answer

Code scanning

Question 5

Your team uses GitHub Enterprise and GitHub Actions for CI/CD. You need to implement a security compliance plan. The organization has the following requirements: 1) All code pushed to the main branch must be scanned for secrets and vulnerabilities. 2) Developers must use signed commits. 3) Only approved GitHub Actions can be used. 4) Dependencies must be scanned for vulnerabilities. You have enabled secret scanning and code scanning (CodeQL) on all repositories. You have configured branch protection rules to require signed commits using GPG keys. To restrict actions, you have set an allowed list of actions in the organization settings. You have enabled Dependabot alerts. However, during an audit, a reviewer notes that secret scanning alerts are not being reviewed within 30 days. You need to ensure that secret scanning alerts are triaged within 30 days. What should you do?

Accepted Answer

Assign secret scanning alerts to the security team using the 'Assign to' feature in the alerts view.. GitHub secret scanning allows you to assign alerts to specific team members using the 'Assign to' feature in the alerts view. This ensures that alerts are explicitly owned and triaged within the 30-day requirement. Option B is incorrect because webhooks merely send notifications; they do not guarantee that someone will review and triage the alert. Option C is incorrect because disabling secret scanning on any repository would violate the requirement to scan all code pushed to main branch. Option D is incorrect because automatically closing alerts after 30 days could hide legitimate secrets that require investigation, which fails the security compliance goal.

Answer

Set up a webhook to send secret scanning alerts to a security team's email.

Answer

Disable secret scanning on repositories that do not contain secrets.

Answer

Configure secret scanning to automatically close alerts after 30 days.

Question 6

Your team is adopting a shift-left security approach in Azure Pipelines. They want to automatically detect secrets, such as API keys or connection strings, in source code before code is committed. Which Azure DevOps feature should be configured to scan pull requests for secrets and block the PR if any are found?

Accepted Answer

Secret Scanning. Secret Scanning in Azure DevOps is a native repository-level feature that automatically scans code pushed to Azure Repos for credentials, API keys, connection strings, and other secrets. When enabled, it runs on pull requests and can be configured with branch policies to block PR completion if secrets are detected, enforcing shift-left security before code is merged.

Answer

Azure Policy for Repos

Answer

Credential Scanner task in pipeline

Answer

Dependency Scanning

Question 7

Your organization uses Microsoft Defender XDR to secure Azure DevOps pipelines. You need to ensure that any build pipeline triggered by a pull request automatically runs a security scan and fails if critical vulnerabilities are found. What should you configure?

Accepted Answer

Branch protection rule with required status check. To ensure a build pipeline triggered by a pull request runs a security scan and fails on critical vulnerabilities, you configure a branch protection rule with a required status check. The status check ties the pipeline's security scan result to the PR, blocking merge if the scan fails. This enforces the gate at the branch level, which is the correct mechanism in Azure Repos.

Answer

Code scanning alerts in GitHub

Answer

Azure Policy for Pipelines

Answer

Pipeline security gate

Question 8

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 9

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 10

Your team is using GitHub Enterprise and wants to ensure that every pull request includes a link to a work item in Azure Boards. Which GitHub Apps or Azure DevOps Services integration should you configure?

Accepted Answer

GitHub-Azure Boards integration. The GitHub-Azure Boards integration is the correct choice because it connects GitHub repositories to Azure Boards, automatically linking commits and pull requests to work items when they mention an Azure Boards ID (e.g., 'AB#1234'). However, it does not enforce that every PR must include such a link. To enforce this, you would need an additional validation tool or branch protection rule, but among the given options, this is the only integration that provides the linking capability.

Answer

Azure Repos branch policy

Answer

Azure DevOps OAuth app

Answer

Azure Pipelines GitHub App

Question 11

Refer to the exhibit. You are reviewing the branch policies for the main branch in Azure Repos. The team reports that while the branch naming policy works, the approval policy does not block pull requests when only one person approves. What is the most likely cause?

Accepted Answer

The policy is not applied to the main branch. If the minimum approver count policy is configured for a branch other than `main` (or is scoped to a different branch pattern), it will not apply to pull requests targeting `main`. The branch naming policy works because that is a repository-level setting that applies to all branches. There is no 'project-level' branch policy override in Azure Repos; branch policies are scoped to specific branches or patterns, and if multiple policies apply, all must be satisfied. A separate policy on main that allows one approval would not override an all-branches policy requiring two approvals — the stricter policy would still block. Therefore, the cause must be that the approval policy simply does not apply to main.

Answer

The policy is disabled in the settings

Answer

The main branch has a separate branch policy override that allows one approval

Answer

The 'creatorVoteCounts' setting is false, so the creator's approval is not counted

Question 12

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 13

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 14

Your organization uses Microsoft Purview Data Loss Prevention (DLP) to protect sensitive data in Azure DevOps repositories. The compliance team has identified that source code containing credit card numbers (PCI data) was accidentally committed to a public repository. You need to implement a solution that meets the following requirements: (1) Automatically scan all new commits in Azure Repos for sensitive data types like credit card numbers. (2) If sensitive data is detected, automatically block the push and notify the security team. (3) The solution must be integrated with Microsoft Purview and Azure DevOps.

Option A: Enable Microsoft Purview Data Loss Prevention for Azure DevOps, which automatically scans and blocks pushes containing sensitive data.

Option B: Configure a branch policy in Azure Repos that runs a custom Azure Function via a service hook when a push occurs, and the function uses Purview APIs to scan the commit.

Option C: Use GitHub Advanced Security secret scanning for Azure Repos, and configure a webhook to notify the security team.

Option D: Install a third-party extension from Azure DevOps Marketplace that provides content scanning and configure it to block pushes.

Which option is the most appropriate and efficient?

Accepted Answer

Enable Microsoft Purview Data Loss Prevention for Azure DevOps, which automatically scans and blocks pushes containing sensitive data. Microsoft Purview DLP for Azure DevOps (currently in preview) provides native integration to automatically scan commits for sensitive data types like credit card numbers and block the push if detected, meeting all requirements natively without custom development. Option B describes a custom Azure Function approach which is more complex and not native, and may not integrate as seamlessly with Purview. Option C uses GitHub Advanced Security, which is not available for Azure Repos (it's for GitHub repositories). Option D relies on a third-party extension, which may not have native Purview integration and could be less reliable. Therefore, Option A is the most appropriate and efficient solution.

Answer

Configure a branch policy in Azure Repos that runs a custom Azure Function via a service hook when a push occurs, and the function uses Purview APIs to scan the commit

Answer

Use GitHub Advanced Security secret scanning for Azure Repos, and configure a webhook to notify the security team

Answer

Install a third-party extension from Azure DevOps Marketplace that provides content scanning and configure it to block pushes

Question 15

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.. Option A is correct because enabling push protection in GitHub Advanced Security for Azure Repos actively blocks commits containing detected secrets before they are pushed, which directly satisfies the requirement to automatically block secrets. Option D is correct because enabling secret scanning in GitHub Advanced Security for Azure Repos automatically detects secrets (such as passwords and keys) in the repository, satisfying the detection requirement; together with push protection it provides both detection and blocking. Option B is not correct because branch policies requiring pull requests only enforce review workflows and do not detect or block secrets. Option C is not correct because storing secrets in Azure Key Vault and referencing them in pipelines is a preventive best practice but does not automatically detect or block secrets already pushed to Azure Repos. Option E is not correct because Microsoft Purview Information Protection classifies and protects sensitive data but does not scan Azure Repos for secrets or block pushes.

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.