Knowledge + Practice

CCNA Develop a security and compliance plan Questions

75 of 96 questions · Page 1/2 · Develop a security and compliance plan · Answers revealed

Practice these questions Domain overview All questions

1

MCQeasy

Your organization is adopting GitHub Copilot and wants to ensure that no proprietary code is used to train models. Which setting should you configure in the GitHub organization?

A.Enable secret scanning.

B.Enable Dependabot alerts.

C.Disable GitHub Copilot for the organization.

D.Opt out of allowing GitHub to use code snippets for product improvement.

AnswerD

Opting out of allowing GitHub to use code snippets for product improvement is the exact setting that prevents Copilot from using your code as training data. This is the correct action when you want to retain Copilot's functionality while ensuring your proprietary code is not used to improve the model.

Why this answer

GitHub provides an organization-level setting to opt out of allowing GitHub to use code snippets for product improvement, which prevents Copilot from training on that code. Option A is incorrect because secret scanning is unrelated to model training. Option B is incorrect because Dependabot alerts focus on dependency vulnerabilities, not data usage.

Option C is incorrect because disabling Copilot prevents its use but does not address the underlying data usage for training; the organization may still want to use Copilot while preventing training on proprietary code.

Practice this question →

2

MCQhard

You are analyzing Azure DevOps audit logs with the KQL query above. Your security team wants to ensure that only approved service connections are used. After running the query, you find multiple service connections created by a user who is not on the approved list. What should you do next?

A.Immediately delete all service connections created by that user.

B.Disable the user's account in Microsoft Entra ID.

C.Review each unapproved service connection's permissions and usage.

D.Modify the query to also include the user's email address.

AnswerC

Reviewing each unapproved service connection's permissions and usage is the correct response because it enables you to determine whether the connection is malicious, misconfigured, or a legitimate access grant that requires tracking. By examining scopes, used-by pipelines, and activity logs, you can assess risk and decide which connections to revoke, modify, or leave in place with proper oversight.

Why this answer

The immediate priority is to assess the risk of each unapproved service connection before taking action. Service connections in Azure DevOps can have varying permissions and may be used by pipelines, so blindly deleting them could break critical deployments. The correct next step is to review each connection's permissions (e.g., who can use it, which service principals are linked) and its usage history (e.g., which pipelines reference it) to determine whether it is malicious or simply an oversight.

Exam trap

The trap here is that candidates often jump to a punitive action (deleting connections or disabling accounts) instead of following a structured incident response process that first investigates and validates the risk before taking corrective measures.

How to eliminate wrong answers

Option A is wrong because immediately deleting all service connections created by that user could disrupt running pipelines and deployments, and it bypasses the necessary investigation to confirm whether any of those connections are legitimate or approved for specific use cases. Option B is wrong because disabling the user's account in Microsoft Entra ID is a drastic measure that may be premature; the user might have created connections with proper authorization for a different project, and disabling the account could block other legitimate work without addressing the specific service connections. Option D is wrong because modifying the query to include the user's email address does not resolve the security concern; it only provides more information for analysis, but the question asks what to do next after finding unapproved connections, not how to improve the query.

Practice this question →

3

MCQhard

You are a DevOps engineer at a company that uses Azure DevOps. The security team requires that all code commits to the main branch are signed and verified. You need to enforce this using branch policies. Which policy should you configure?

A.Require approval from a specific user or group.

B.Require a minimum number of reviewers.

C.Check for linked work items.

D.Require signed commits.

AnswerD

The 'Require signed commits' branch policy ensures that all commits pushed to the protected branch have a valid GPG or SSH signature. This directly enforces that commits are signed and verified, meeting the security team's requirement. It prevents unsigned commits from being merged, ensuring integrity and authenticity.

Why this answer

The 'Require signed commits' branch policy is the only policy that enforces cryptographic signing of commits. It ensures that every commit to the protected branch is signed and verified, providing authenticity and integrity. Other policies focus on review, work item linking, or approvals, none of which verify signatures.

Exam trap

The trap here is confusing commit signing with other branch policies that provide security, such as required reviewers or linked work items, but these do not verify signatures.

Practice this question →

4

MCQhard

Your organization uses Azure DevOps with multiple teams. You are tasked with creating a security and compliance plan. The environment includes: Azure Repos for source control, Azure Pipelines for CI/CD, and Azure Artifacts for package management. Requirements: 1) All code changes to the main branch must be reviewed by at least one member of the security team. 2) Deployment to production requires approval from a manager. 3) Secrets must be stored securely and rotated every 90 days. 4) Pipeline logs must be retained for 1 year for audit purposes. You have configured branch policies requiring a minimum number of reviewers and mandatory security team review. For production deployments, you have added a manual approval gate. Secrets are stored in Azure Key Vault with automatic rotation. However, the audit team reports that pipeline logs are only retained for 30 days. You need to extend log retention to 1 year. What should you do?

A.Export pipeline logs to Azure Blob Storage and set a lifecycle policy to retain for 365 days.

B.Configure diagnostic settings in Azure Monitor to stream pipeline logs to a Log Analytics workspace.

C.In Azure DevOps project settings, navigate to Pipelines > Retention and releases, and set the retention policy to 365 days.

D.Enable Azure DevOps audit logs and export them to a Log Analytics workspace with a 365-day retention.

AnswerC

To retain pipeline logs for 365 days, use the project-level retention policy under Project Settings > Pipelines > Retention and releases, setting the maximum retention for pipeline runs and logs to the desired number of days.

Why this answer

In Azure DevOps, pipeline retention policies for runs are configured at the project level under Project Settings > Pipelines > Retention and releases. Setting the retention to 365 days will keep pipeline run records and logs for one year. Option A is incorrect because exporting pipeline logs to Azure Blob Storage is not a built-in feature; pipeline logs are retained according to DevOps retention policies.

Option B is incorrect because diagnostic settings in Azure Monitor stream Azure resource logs, not Azure DevOps pipeline logs. Option D is incorrect because audit logs capture events like changes to policies, not pipeline execution logs, and they have separate retention settings.

Practice this question →

5

Multi-Selectmedium

Your company uses Azure Key Vault to store secrets. Which TWO actions should you take to ensure secure access? (Select TWO.)

Select 2 answers

A.Restrict access using Key Vault access policies

B.Use managed identities to authenticate applications

C.Enable HTTP access for performance

D.Disable audit logging to reduce exposure

E.Enable soft-delete to recover deleted secrets

AnswersA, B

Restrict access using Key Vault access policies: Access policies are evaluated for each principal, allowing fine-grained permissions such as get, list, and set on secrets, certs, and keys. By assigning only the minimum required permissions to each user, group, or service principal, you implement least privilege and directly reduce the attack surface for unauthorized secret access.

Why this answer

Restricting access using Key Vault access policies (Option A) is correct because Azure Key Vault uses a granular permission model where you assign specific permissions (e.g., GET, LIST, SET) to individual security principals (users, groups, or service principals) at the vault level. This ensures that only authorized identities can read or manage secrets, keys, and certificates, following the principle of least privilege. Using managed identities (Option B) is correct because they provide an automatically managed identity in Azure AD for applications to authenticate to Key Vault without storing credentials in code or configuration, eliminating the risk of secret leakage.

Exam trap

The trap here is that candidates often confuse data protection features (like soft-delete) with access control mechanisms, or mistakenly think enabling HTTP improves performance without realizing Key Vault enforces HTTPS exclusively, leading them to select options that address recovery or monitoring rather than secure authentication and authorization.

Practice this question →

6

MCQeasy

Your team uses GitHub and wants to automatically detect and block secrets pushed to repositories. Which GitHub feature should you enable?

A.Dependabot alerts

B.Code scanning

C.Push protection

D.Secret scanning

AnswerC

Push protection is not an independent feature; it is a layer built into secret scanning that blocks git pushes when a known secret is detected. It relies entirely on secret scanning's detection engine, so it cannot be the feature that automatically detects secrets by itself.

Why this answer

Push protection is the GitHub feature that automatically detects known types of secrets in pushed content and blocks the push, preventing exposure. Secret scanning, on the other hand, scans for secrets and alerts after they exist in the repository but does not block the push unless push protection is enabled. Since the requirement is to 'automatically detect and block secrets pushed', the feature to enable is Push protection.

Exam trap

A common mistake is selecting 'Secret scanning' because it is a broader feature, but the question specifically requires blocking. Push protection is the sub-feature that actually blocks the push, while secret scanning provides the underlying detection mechanism. You can enable push protection as part of secret scanning, but the blocking action is performed by push protection.

How to eliminate wrong answers

Option A is wrong because Dependabot alerts are focused on vulnerable dependencies and outdated package versions, not on detecting secrets in code. Option B is wrong because Code scanning uses CodeQL to find code quality and security vulnerabilities (e.g., SQL injection, XSS), but it does not scan for hardcoded secrets or block pushes. Option C is wrong because Push protection is a sub-feature of Secret scanning that blocks pushes containing secrets, not a standalone feature; the question asks which feature to enable, and the parent feature is Secret scanning.

Practice this question →

7

MCQmedium

Your organization uses Azure DevOps to manage CI/CD pipelines. The security team requires that all pipeline runs use a specific service connection that references a managed identity in Microsoft Entra ID. However, some developers have been using personal access tokens (PATs) in their pipelines, bypassing the managed identity. What should you implement to enforce the use of the managed identity service connection?

A.Configure a branch policy on the main branch to require a specific service connection.

B.Use a pipeline decorator to validate the service connection and fail the pipeline if an unauthorized connection is used.

C.Restrict the use of PATs by setting an agent pool-level permission.

D.Store the service connection ID in a variable group and reference it in each pipeline.

AnswerB

Pipeline decorators are injected into every job at execution time, allowing you to add a validation step that inspects the service connection ID used by tasks such as AzureCLI or AzurePowerShell. Because the decorator runs as part of the job definition, you can compare the connection against an approved list and call an error to fail the pipeline before deployment proceeds. This control is centralized at the organization level and cannot be bypassed by a repository without modifying the decorator itself, making it the only enforceable option.

Why this answer

Pipeline decorators allow you to inject custom validation steps into every pipeline run at the organization or project level. By using a decorator that checks the service connection ID used in each job and fails the run if it does not match the approved managed identity connection, you can enforce compliance without relying on developer cooperation or manual policy configuration.

Exam trap

The trap here is that candidates confuse branch policies (which control code changes) with runtime enforcement mechanisms, overlooking that only pipeline decorators can inject mandatory validation into every pipeline execution.

How to eliminate wrong answers

Option A is wrong because branch policies apply to pull request validation and merge gates, not to the service connection used during pipeline execution; they cannot enforce which connection is used at runtime. Option C is wrong because agent pool-level permissions control who can use or manage the pool, not which authentication method (PAT vs. managed identity) is used in pipeline tasks. Option D is wrong because storing the service connection ID in a variable group does not enforce its use; developers can still reference a different connection directly in their YAML or override the variable.

Practice this question →

8

Drag & Dropmedium

Drag and drop the steps to configure Azure Monitor alerts for application performance into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Alert setup begins with enabling monitoring, creating rule, setting condition, action groups, and testing.

Practice this question →

9

MCQeasy

Your organization uses Microsoft Purview to classify and protect sensitive data. You need to ensure that source code in Azure DevOps repositories containing credit card numbers is detected and flagged. What should you configure?

A.Create a Data Loss Prevention (DLP) policy in Microsoft 365.

B.Set up Microsoft Sentinel to monitor Azure DevOps logs.

C.Configure a Microsoft Purview Data Classification scan for Azure DevOps repositories.

D.Enable Microsoft Defender for Cloud to scan repositories.

AnswerC

Microsoft Purview provides data governance and classification capabilities, and its data map can register and scan Azure DevOps repositories to automatically classify sensitive data such as credentials, connection strings, and personal information. This directly aligns with the requirement to classify and protect sensitive information in your organization's code repositories.

Why this answer

Microsoft Purview Data Classification scans can be configured to scan Azure DevOps repositories for sensitive data types, such as credit card numbers, using built-in or custom sensitive information types. This allows the organization to detect and flag source code containing credit card numbers directly within the repository, aligning with the requirement to classify and protect sensitive data under a compliance plan.

Exam trap

The trap here is that candidates often confuse Microsoft Purview Data Classification (which can scan Azure DevOps repositories) with Microsoft 365 DLP policies (which are limited to Microsoft 365 workloads), leading them to select Option A incorrectly.

How to eliminate wrong answers

Option A is wrong because Data Loss Prevention (DLP) policies in Microsoft 365 are designed to protect data in Microsoft 365 services (e.g., Exchange, SharePoint, OneDrive) and do not natively scan Azure DevOps repositories for sensitive data. Option B is wrong because Microsoft Sentinel is a Security Information and Event Management (SIEM) tool that monitors security logs and alerts, not a data classification service for scanning source code content in repositories. Option D is wrong because Microsoft Defender for Cloud focuses on cloud security posture management and workload protection, not on scanning source code for sensitive data classification like credit card numbers.

Practice this question →

10

MCQhard

You are reviewing an Azure Policy assignment in a DevOps environment. The exhibit shows the policy assignment JSON. The policy set includes the built-in policy 'Allowed Locations' with effect Deny. During a pipeline deployment, a resource creation fails with a policy violation error. The resource being deployed is a storage account in the 'centralus' region. What is the most likely reason for the failure?

A.The policy assignment is misconfigured because it does not specify a policy set definition.

B.The resource being deployed is in a region that is not allowed by the policy assignment parameters.

C.The resource group is located in a region that overrides the policy assignment.

D.The policy set definition does not include the 'Allowed Locations' policy.

AnswerB

The allowedLocations parameter in the policy assignment restricts permissible deployment regions to eastus and westus only. Since the resource being deployed is in centralus, which is not included in those parameters, the 'Allowed Locations' policy denies the deployment as non-compliant.

Why this answer

The policy assignment includes the built-in 'Allowed Locations' policy with the Deny effect. The resource being deployed (a storage account) is in the 'centralus' region, but the policy assignment parameters likely specify a list of allowed regions that does not include 'centralus'. Since the Deny effect prevents any non-compliant resource creation, the deployment fails with a policy violation error.

This is the most direct and common cause of such failures in Azure Policy.

Exam trap

The trap here is that candidates may assume the resource group's location influences policy evaluation, but Azure Policy evaluates each resource's location independently, and the resource group's location is irrelevant unless explicitly referenced in the policy rule.

How to eliminate wrong answers

Option A is wrong because the exhibit shows the policy assignment JSON includes a 'policySetDefinitionId' field, so the assignment is correctly linked to a policy set definition. Option C is wrong because the resource group's location does not override a policy assignment; Azure Policy evaluates resources individually based on the policy rules, not the resource group's location. Option D is wrong because the policy set definition explicitly includes the 'Allowed Locations' policy, as shown in the exhibit's 'policyDefinitions' array.

Practice this question →

11

MCQmedium

Your company uses Microsoft Sentinel for security monitoring. Azure DevOps pipelines deploy resources to production. You need to create an automated response that triggers when Sentinel detects a high-severity alert related to unauthorized pipeline changes. The response should temporarily disable the service connection used by the pipeline and notify the security team. What should you do?

A.Configure a Sentinel analytics rule with the alert and use automated response to send an email.

B.Set up an Azure DevOps service hook that triggers on pipeline events.

C.Use Azure Policy to deny changes to service connections.

D.Create a Sentinel playbook using Azure Logic Apps that calls the Azure DevOps REST API to update the service connection status.

AnswerD

This is correct because a Sentinel playbook is an Azure Logic Apps workflow specifically designed to automate incident response to Sentinel alerts. By calling the Azure DevOps REST API endpoint for service endpoints (e.g., PUT https://dev.azure.com/{organization}/{project}/_apis/serviceendpoint/endpoints/{endpointId}?api-version=7.1) and setting the `isReady` field to false or updating the service endpoint status to disabled, the playbook can immediately revoke access. It can also send a notification email afterwards, satisfying both the disable and notify requirements in a single automated response.

Why this answer

A Sentinel playbook built with Azure Logic Apps can be triggered by a Sentinel alert and execute custom actions, such as calling the Azure DevOps REST API to disable a service connection and sending notifications. This provides the automated response required. The playbook integrates with Sentinel's automation rules to run when the high-severity alert fires.

Exam trap

AZ-400 often tests the confusion between notification-only responses and actual remediation actions; candidates may pick email alerts thinking they satisfy 'automated response' when the question requires disabling a resource.

How to eliminate wrong answers

Option A is wrong because sending an email only notifies; it does not disable the service connection. Option B is wrong because an Azure DevOps service hook triggers on pipeline events, not on Sentinel alerts, and cannot disable a service connection. Option C is wrong because Azure Policy denies changes to resources but does not respond to security alerts or disable existing service connections.

Practice this question →

12

MCQhard

You are evaluating an Azure Policy assignment for Azure Pipelines. What does this policy audit?

A.Whether secure files are rotated within 90 days

B.Whether pipelines use secure files with extensions other than .pfx, .p12, or .cer

C.Whether secure files are encrypted at rest

D.Whether secure files are used in production pipelines

AnswerB

The policy is designed to audit which file extensions are allowed for secure files in Azure Pipelines, specifically restricting to .pfx, .p12, or .cer. Any secure file with a different extension (e.g., .txt, .key, .pem) would be non-compliant. This directly matches the policy's scope of validating file types used as secure inputs.

Why this answer

The Azure Policy for Azure Pipelines audits whether secure files have file extensions other than .pfx, .p12, or .cer. This policy is designed to enforce that only certificate-related secure files (which are typically used for code signing or TLS) are allowed, preventing the upload of arbitrary file types that could introduce security risks or misconfiguration.

Exam trap

The trap here is that candidates may confuse the audit of file extensions with other security controls like encryption or rotation, leading them to select options that describe general best practices rather than the specific policy behavior.

How to eliminate wrong answers

Option A is wrong because Azure Policy does not audit rotation intervals for secure files; rotation policies are managed separately via pipeline settings or manual processes, not through built-in policy definitions. Option C is wrong because encryption at rest for secure files is a platform-level guarantee provided by Azure DevOps (using Azure Storage encryption), not something that Azure Policy audits—the policy focuses on file extension compliance, not encryption status. Option D is wrong because the policy does not differentiate between production and non-production pipelines; it applies to all pipelines using secure files, regardless of environment, and audits the file extension, not the pipeline usage context.

Practice this question →

13

MCQhard

Your company uses GitHub Enterprise and wants to implement a secret scanning policy to detect and block secrets (e.g., API keys) in code pushes. The policy must allow exceptions for test repositories that use fake secrets. What is the recommended approach?

A.Use a pre-commit hook to detect secrets and allow developers to bypass it.

B.Implement a GitHub Actions workflow that scans for secrets and fails the push.

C.Enable secret scanning for all repositories, then manually disable it for test repositories.

D.Configure secret scanning with custom patterns and use the 'secret_scanning_push_protection' setting with an allow-list for test repositories.

AnswerD

Secret scanning with custom patterns is a server-side, centrally enforced feature that can detect organization-specific secrets, and enabling the `secret_scanning_push_protection` setting blocks pushes containing matching secrets while an allow-list lets you exempt designated test repositories from the block without disabling detection—so real secrets are blocked, and test exceptions are managed predictably.

Why this answer

GitHub Enterprise's secret scanning push protection can be configured with custom patterns and an allow-list (via the `secret_scanning_push_protection` setting in the repository's security settings or through the API). This allows you to block pushes containing secrets across all repositories while explicitly exempting test repositories that use fake secrets, meeting the requirement for exceptions without manual intervention.

Exam trap

The trap here is that candidates confuse client-side pre-commit hooks (which are bypassable) with server-side push protection (which is enforced), or mistakenly think GitHub Actions can block a push before it completes.

How to eliminate wrong answers

Option A is wrong because pre-commit hooks are client-side and can be bypassed by developers (e.g., using `--no-verify`), providing no enforcement at the server level. Option B is wrong because GitHub Actions workflows run after a push is accepted, not before; they cannot block the push itself, only react to it (e.g., by creating an issue). Option C is wrong because manually disabling secret scanning for test repositories is not scalable and violates the requirement for a policy that automatically allows exceptions; it also does not leverage the push protection feature to block secrets in non-test repos.

Practice this question →

14

MCQmedium

You need to implement a compliance framework that ensures Azure Pipelines build agents are always patched with the latest security updates. What should you use?

A.Azure Update Management to schedule patching

B.Azure VM Image Builder to create patched images

C.Azure Policy to enforce that agents must be patched

D.Azure Automation State Configuration to enforce desired state

AnswerA

Azure Update Management, part of Azure Automation, is the appropriate solution here because it directly schedules and orchestrates the installation of OS updates on Azure VMs and on-premises servers, with compliance reporting and maintenance window control.

Why this answer

Azure Update Management is the correct choice because it provides a native, scheduled patching solution for Azure Pipelines build agents. It integrates with Azure Automation and Log Analytics to assess missing updates and deploy them on a recurring schedule, ensuring agents remain compliant with the latest security patches without manual intervention.

Exam trap

The trap here is that candidates often confuse 'enforcing compliance' (Azure Policy) with 'actually performing the patching action' (Azure Update Management), or they mistake image creation (VM Image Builder) for ongoing patch management, leading them to select a tool that only audits or provisions rather than schedules updates.

How to eliminate wrong answers

Option B is wrong because Azure VM Image Builder creates and maintains custom VM images with pre-applied patches, but it does not provide ongoing, scheduled patching for existing build agents; it is used for image lifecycle management, not runtime patching. Option C is wrong because Azure Policy enforces compliance rules (e.g., requiring agents to be patched) but cannot actually deploy patches; it only audits or denies non-compliant resources, leaving the patching action unaddressed. Option D is wrong because Azure Automation State Configuration (DSC) enforces a desired state configuration (e.g., ensuring specific software is installed), but it is not designed for recurring security update deployment; it focuses on configuration drift correction rather than scheduled patch management.

Practice this question →

15

MCQmedium

You are designing a compliance plan for Azure DevOps. The compliance officer requires that all changes to build pipelines are audited and cannot be reverted without approval. What should you implement?

A.Enable Azure DevOps audit logs

B.Store pipeline YAML in a repository with branch policies

C.Use release approval gates

D.Set pipeline retention policies

AnswerB

Storing the pipeline YAML in a Git repository with branch policies enforces mandatory peer review and approval for any pull request that modifies the pipeline definition. This creates a gated change process with full traceability, ensures separation of duties, and directly prevents unauthorized or accidental reverts, making it the appropriate compliance control for protecting pipeline definitions.

Why this answer

Storing pipeline YAML in a repository with branch policies ensures that every change to the pipeline definition goes through a pull request (PR) process, which is auditable and requires approval before merging. Once merged, the change is recorded in the Git history, and reverting it requires another PR with approval, meeting the compliance requirement that changes cannot be reverted without approval.

Exam trap

The trap here is confusing audit logging (which only records events) with enforcement mechanisms (like branch policies) that actually prevent unapproved changes and reverts.

How to eliminate wrong answers

Option A is wrong because enabling Azure DevOps audit logs captures who performed what action and when, but it does not prevent reverts or enforce approval for changes to build pipelines. Option C is wrong because release approval gates control the deployment of releases to stages, not changes to the pipeline definition itself. Option D is wrong because pipeline retention policies control how long pipeline runs and artifacts are kept, not how changes to the pipeline are audited or reverted.

Practice this question →

16

Multi-Selectmedium

Which THREE measures should you implement to protect secrets (e.g., API keys, passwords) used in Azure Pipelines?

Select 3 answers

A.Store secrets as plain text in a secure Git repo with restricted access

B.Mark variables as 'Secret' in pipeline YAML or UI definitions

C.Use environment variables in the pipeline to pass secrets at runtime

D.Use service connections with managed identity instead of personal access tokens

E.Store secrets in Azure Key Vault and reference them via a Key Vault task

AnswersB, D, E

Marking variables as secret encrypts their values at rest and masks them in logs, preventing accidental exposure during pipeline runs. This directly satisfies the stem's requirement to protect API keys and passwords stored in Azure Pipelines.

Why this answer

Option B is correct because marking variables as 'Secret' in the pipeline YAML (using the secret variable syntax) or in the UI variable group causes Azure Pipelines to encrypt the value at rest, mask it in logs, and avoid exposing it in plain text during runs. Option D is correct because service connections backed by managed identity (or workload identity federation) eliminate long-lived personal access tokens and stored credentials, letting the pipeline authenticate to Azure resources without embedding secrets. Option E is correct because Azure Key Vault centralizes secret storage with access policies/RBAC and auditing, and the AzureKeyVault@2 task (or Key Vault variable group linking) retrieves secrets at runtime so they are never committed to the repo.

Option A is not appropriate because storing secrets as plain text in Git—even a restricted repo—leaves them in version history and readable by anyone with repo access. Option C is not a distinct protection measure because environment variables alone do not encrypt, mask, or vault the secret; without the 'Secret' marking or Key Vault integration the value can still leak into logs or process listings.

Exam trap

AZ-400 often tests the misconception that environment variables or restricted Git repos are secure for secrets, tempting candidates to choose options that still expose credentials.

Practice this question →

17

MCQmedium

Your organization uses GitHub Actions for CI/CD. The security team requires that all workflows are stored in a central repository and that only approved actions can be used. What should you implement?

A.Configure the repository to use only self-hosted runners.

B.Store all workflows in a central repository and use branch protection rules.

C.In the organization settings, configure the 'Actions permissions' to 'Allow specified actions' and add the approved actions to the allow list.

D.Enable 'Allow GitHub Actions to create and approve pull requests' in the repository settings.

AnswerC

Configuring 'Actions permissions' to 'Allow specified actions' in the organization's Actions settings builds an explicit allowlist that only permits pre-approved actions in all workflows. Any action not on the list is blocked, which enforces the security requirement by preventing use of unapproved third-party actions.

Why this answer

The security team's requirement to restrict workflows to only approved actions is directly met by configuring 'Actions permissions' in the organization settings to 'Allow specified actions' and then populating the allow list with the approved actions. This enforces a policy where any workflow, regardless of where it is stored, can only reference actions that have been explicitly allowed, preventing the use of unverified or malicious third-party actions.

Exam trap

The trap here is that candidates often confuse controlling where workflows are stored (centralization) with controlling which actions are allowed to execute, mistakenly thinking branch protection or runner restrictions can substitute for an explicit action allow list.

How to eliminate wrong answers

Option A is wrong because using only self-hosted runners controls the execution environment but does not restrict which actions can be used in workflows; workflows can still reference any action from the marketplace or external sources. Option B is wrong because storing workflows in a central repository and using branch protection rules controls who can modify the workflows but does not restrict which actions those workflows can call; a workflow in the central repo could still reference an unapproved action. Option D is wrong because enabling 'Allow GitHub Actions to create and approve pull requests' is a permission setting for automation, not a security control for restricting which actions are allowed to run.

Practice this question →

18

Multi-Selecthard

Which TWO actions should you take to ensure that Azure Pipelines artifacts are securely stored and access is audited?

Select 2 answers

A.Configure the storage account firewall to only allow access from Azure Pipelines IP ranges

B.Use Azure Policy to enforce that artifacts are only deployed to production storage accounts

C.Enable Azure Artifacts retention policies to automatically delete old artifact versions

D.Enable customer-managed keys (CMK) for artifact encryption

E.Configure audit logging for artifact downloads via Azure DevOps audit logs

AnswersC, E

Enabling Azure Artifacts retention policies automatically deletes old artifact versions, reducing the attack surface and limiting the window in which outdated or potentially vulnerable artifacts can be downloaded or exploited. This is a security best practice that ensures only recent, vetted versions remain available to the pipeline.

Why this answer

Azure Artifacts retention policies allow you to automatically delete older versions of packages, reducing the attack surface and ensuring that only current, approved artifacts are stored. This is a key security practice to prevent outdated or vulnerable artifacts from being accessed. Option E is correct because enabling audit logging for artifact downloads via Azure DevOps audit logs provides a detailed, immutable record of who accessed which artifact and when, which is essential for compliance and security investigations.

Exam trap

The trap here is that candidates often confuse Azure Policy with pipeline governance (e.g., deployment gates) or assume that network-level controls like storage firewalls are the primary security mechanism for Azure Artifacts, when in fact Azure Artifacts is a PaaS service within Azure DevOps that does not expose a direct storage account endpoint for artifact downloads.

Practice this question →

19

MCQmedium

Your team uses Azure Pipelines to deploy a web app to Azure App Service. You need to ensure that secrets (e.g., connection strings) are not exposed in the pipeline logs. What is the recommended approach?

A.Remove all logging from the pipeline.

B.Use secret pipeline variables and reference them in the pipeline.

C.Store secrets in Azure Key Vault and retrieve them in the pipeline, then log them for debugging.

D.Store secrets as environment variables in the pipeline.

AnswerB

Secret pipeline variables are stored encrypted and automatically masked in Azure Pipelines logs, so connection strings never appear in plain text during task execution. Referencing them via `$(variableName)` satisfies the stem's requirement that secrets stay hidden from logs, unlike plain variables which are echoed verbatim.

Why this answer

Azure Pipelines supports secret pipeline variables that are masked in logs, preventing exposure of sensitive data like connection strings. When you mark a variable as secret, its value is automatically hidden from pipeline output, and you can reference it securely using $(variableName) syntax. This is the recommended approach for handling secrets directly within the pipeline without additional service dependencies.

Exam trap

The trap here is that candidates may think storing secrets in Azure Key Vault automatically prevents log exposure, but the retrieval and subsequent logging of those values in the pipeline still leaks them unless they are explicitly marked as secret variables.

How to eliminate wrong answers

Option A is wrong because removing all logging eliminates valuable debugging and auditing information, which is not a practical or recommended security practice; Azure Pipelines provides selective masking instead. Option C is wrong because logging secrets for debugging directly contradicts the goal of preventing exposure; even if retrieved from Key Vault, logging them would still leak sensitive data. Option D is wrong because environment variables in the pipeline are not automatically masked; they can appear in logs if echoed or printed, unlike secret variables which are explicitly hidden.

Practice this question →

20

Multi-Selectmedium

Your organization is implementing a security compliance plan for Azure DevOps. Which TWO actions help enforce the principle of least privilege?

Select 2 answers

A.Allow all team members to edit security permissions

B.Use Azure DevOps security groups to grant minimal permissions

C.Use built-in roles without customizing

D.Restrict who can create new agent pools to a small admin team

E.Grant Project Collection Administrators group to all developers

AnswersB, D

Azure DevOps security groups let you assign permissions to teams rather than individuals, granting only the access each role needs. This directly enforces least privilege by scoping rights to group membership instead of broad default permissions.

Why this answer

Option B is correct because Azure DevOps security groups (such as Project Administrators, Contributors, or custom groups) let you assign only the specific permissions each team needs, directly implementing least privilege instead of granting broad access. Option D is correct because restricting agent pool creation to a small admin team limits a powerful, organization- or project-level capability (managing agent pools and their security) to the few users who require it, reducing the attack surface. Option A is wrong because allowing all team members to edit security permissions grants everyone the ability to change ACLs, which violates least privilege.

Option C is wrong because using built-in roles without customizing can over-grant permissions, since built-in roles often include more rights than a given user needs. Option E is wrong because Project Collection Administrators is the highest-privilege group in Azure DevOps and should be tightly limited, not assigned to all developers.

Exam trap

The trap here is that candidates often assume built-in roles are always the safest choice (Option C), but Azure DevOps built-in roles like 'Project Administrators' grant broad permissions that exceed least privilege, whereas custom security groups with minimal permissions are more secure.

Practice this question →

21

Multi-Selecthard

Which TWO actions should you take to ensure that Azure Pipelines artifacts are scanned for vulnerabilities before production deployment? (Choose two.)

Select 2 answers

A.Run dependency scanning on the artifact manifest

B.Sign the artifacts with a code signing certificate

C.Use Microsoft Defender for Cloud to scan the artifact during the pipeline

D.Scan the infrastructure as code templates

E.Run static code analysis on the source code

AnswersA, C

Dependency scanning on the artifact manifest examines the SBOM or dependency lock files (e.g., package-lock.json, packages.lock.json) to identify known Common Vulnerabilities and Exposures (CVEs) in third-party libraries. In Azure Pipelines, this is done with tools like Trivy or OWASP Dependency Check, ensuring that the exact dependency versions that ship in the artifact are assessed for vulnerabilities.

Why this answer

Option A is correct because running dependency scanning on the artifact manifest inspects the exact third-party packages and versions recorded in the artifact (e.g., via tools like Trivy, Grype, or OWASP Dependency-Check against SBOM/manifest files), catching known CVEs in the components that will actually ship to production. Option C is correct because Microsoft Defender for Cloud (specifically Defender for DevOps/Defender for Containers) integrates with Azure Pipelines to scan artifacts such as container images and IaC during the build/release flow and surface vulnerability findings before deployment. Option B is not correct because code signing provides integrity and authenticity assurance, not vulnerability detection.

Option D is not correct because scanning IaC templates finds misconfigurations in infrastructure definitions, not vulnerabilities in the deployed artifact itself. Option E is not correct because static code analysis examines source code for coding flaws, not the built artifact that is promoted to production.

Exam trap

The trap is substituting adjacent security practices — code signing, IaC scanning, or SAST — for actual artifact vulnerability scanning; only manifest/dependency scanning and Defender for Cloud artifact scanning detect CVEs in the built artifact.

Practice this question →

22

MCQmedium

Your organization requires compliance with SOC 2 and needs to audit all changes to Azure Pipelines. What should you enable?

A.Azure Policy

B.Microsoft Purview

C.Azure Blueprints

D.Azure DevOps audit logs

AnswerD

Azure DevOps audit logs capture security-relevant events such as pipeline run changes, permission modifications, and user access updates, and they can be exported to Log Analytics or SIEM tools for SOC 2 compliance. They provide the immutable, timestamped record of who did what and when, directly meeting the audit requirement.

Why this answer

Azure DevOps audit logs capture all changes to pipelines and can be exported for compliance with SOC 2. Option A is incorrect because Azure Policy enforces governance rules on Azure resources, not pipeline changes. Option B is incorrect because Microsoft Purview is a data governance service, not for auditing DevOps changes.

Option C is incorrect because Azure Blueprints (now deprecated) were used to define repeatable Azure environments, not for audit logging.

Practice this question →

23

MCQhard

Your company uses Azure DevOps and must comply with SOC 2. The auditor requires proof that all production deployments went through a change management process with approval. What should you implement?

A.Use branch policies to require pull request approvals

B.Set pipeline retention policies to keep deployment records

C.Enable audit logging for all pipelines

D.Configure release approval gates in Azure Pipelines

AnswerD

Release approval gates in Azure Pipelines require designated approvers to explicitly approve a release stage before it continues, directly enforcing a formal sign-off step for production deployments—this aligns with SOC 2's change-management and authorization requirements by making approval a mandatory precondition.

Why this answer

Release approval gates in Azure Pipelines allow you to define approvers who must approve a deployment before it proceeds. This enforces a change management process with documented approval, providing an audit trail that satisfies SOC 2 requirements. Approval gates can be configured for specific environments or stages, ensuring that all production deployments are reviewed.

Exam trap

AZ-400 often tests the difference between code review approvals (branch policies) and deployment approvals (release gates), and candidates may incorrectly choose branch policies for deployment change management.

How to eliminate wrong answers

Option A is wrong because branch policies require pull request approvals, which are for code changes, not specifically for production deployments; they do not enforce approval at the deployment stage. Option B is wrong because retention policies only control how long records are kept, not whether approvals occurred. Option C is wrong because audit logging records activities but does not enforce approvals; it is a detective control, not a preventive one.

Practice this question →

24

MCQeasy

Your organization uses Microsoft Entra ID. You want to ensure that only users from specific countries can access Azure DevOps. Which security feature should you configure?

A.Microsoft Entra ID Conditional Access policies

B.Azure Network Security Group (NSG) rules

C.Azure DevOps security groups with allowed IP ranges

D.Microsoft Intune compliance policies

AnswerA

Microsoft Entra ID Conditional Access policies evaluate signals like user location, device state, and risk at sign-in time, allowing you to enforce restrictions such as blocking access from untrusted IP ranges or requiring MFA when users connect from outside the corporate network.

Why this answer

Microsoft Entra ID Conditional Access policies allow you to enforce location-based access controls by specifying allowed countries or IP ranges. By configuring a Conditional Access policy that targets Azure DevOps (as a cloud app) and setting the condition to 'Locations' with 'Selected countries,' you can restrict sign-ins to only users from those countries. This is the correct approach because Azure DevOps relies on Entra ID for authentication, and Conditional Access is the native mechanism to control access based on geographic location.

Exam trap

The trap here is that candidates often confuse network-level controls (NSGs) or IP allowlisting in Azure DevOps with identity-based location policies, overlooking that Conditional Access is the correct mechanism for restricting access by country in a SaaS context like Azure DevOps.

How to eliminate wrong answers

Option B is wrong because Azure Network Security Group (NSG) rules operate at the network layer (L3/L4) to filter traffic to Azure resources like VMs or virtual networks, but they cannot restrict user authentication to Azure DevOps, which is a SaaS service accessed over the internet. Option C is wrong because Azure DevOps security groups do not support IP range restrictions; IP allowlisting is configured at the organization level via 'Organization settings > Policies > Security policies,' not through security groups, and it applies to all users, not per-group. Option D is wrong because Microsoft Intune compliance policies are designed to enforce device compliance (e.g., OS version, encryption) for managed devices, not to restrict access based on user location or country.

Practice this question →

25

MCQmedium

Your organization uses Microsoft Purview to manage sensitive data in Azure DevOps repositories. The compliance team needs to automatically classify and label source code that contains personally identifiable information (PII). Which solution should you use?

A.Use Azure Policy to enforce PII labeling on repositories.

B.Use Microsoft Purview Information Protection to automatically scan and label repositories.

C.Use Microsoft Sentinel to detect PII in repositories.

D.Use Microsoft Defender for Cloud to scan for PII.

AnswerB

Purview Information Protection can automatically classify and label sensitive data in source code.

Why this answer

Microsoft Purview Information Protection provides built-in data classification and labeling capabilities that can automatically scan Azure DevOps repositories for sensitive data such as PII. It uses sensitive information types and machine learning classifiers to detect patterns like social security numbers or credit card numbers, then applies the appropriate sensitivity label directly to the source code files. This meets the compliance team's requirement for automatic classification and labeling without custom development.

Exam trap

The trap here is that candidates often confuse Microsoft Purview Information Protection (which handles data classification and labeling) with Azure Policy (which handles resource governance) or Microsoft Defender for Cloud (which handles security posture), leading them to select a tool that cannot perform content-level scanning or labeling.

How to eliminate wrong answers

Option A is wrong because Azure Policy is used to enforce organizational standards and assess compliance at the resource level (e.g., requiring HTTPS on repos), but it cannot scan file contents or apply sensitivity labels to source code. Option C is wrong because Microsoft Sentinel is a SIEM/SOAR tool for security incident detection and response, not for scanning and labeling data within Azure DevOps repositories. Option D is wrong because Microsoft Defender for Cloud focuses on cloud security posture management and workload protection (e.g., vulnerability scanning, threat detection), not on classifying or labeling PII in source code.

Practice this question →

26

MCQeasy

Your team uses Azure Pipelines to deploy to multiple environments. You need to ensure that deployment to the production environment requires approval from the security team. What should you configure?

A.Add a branch policy to the production branch

B.Add an environment approval check for the production environment

C.Use a condition in the YAML pipeline to check a variable

D.Configure a service connection with restricted permissions

AnswerB

An environment approval check adds a required manual approval step before any jobs targeting that environment are executed. The pipeline pauses, and only after an authorized user or group explicitly approves the deployment does it proceed to the production stage, directly fulfilling the need for human sign-off on production deployments.

Why this answer

Environment approval checks in Azure Pipelines allow you to require manual approval before a deployment proceeds to a specific environment, such as production. By adding an approval check to the production environment, you ensure that the security team must explicitly approve the deployment, meeting the requirement without modifying the pipeline code or branch policies.

Exam trap

The trap here is confusing branch policies (which govern code changes) with environment approval checks (which govern deployment gates), leading candidates to incorrectly select a branch policy for deployment control.

How to eliminate wrong answers

Option A is wrong because a branch policy controls code changes to a branch (e.g., requiring pull request reviews) but does not gate deployments to an environment; it operates at the source code level, not the deployment stage. Option C is wrong because a YAML condition checking a variable can skip or run stages based on runtime values, but it cannot enforce a manual approval process; it is purely automated and lacks human intervention. Option D is wrong because a service connection with restricted permissions controls which identities can deploy to a resource, but it does not provide a manual approval gate; it is a security boundary for authentication, not a workflow approval step.

Practice this question →

27

Multi-Selecthard

You are designing a security compliance plan for a GitHub Enterprise environment. Which THREE practices should you implement? (Select THREE.)

Select 3 answers

A.Disable two-factor authentication for automation accounts

B.Allow repository admins to bypass branch protection rules

C.Configure branch protection rules to require pull request reviews

D.Enable Dependabot alerts for dependency vulnerability monitoring

E.Enable secret scanning to detect accidental credential commits

AnswersC, D, E

Requiring pull request reviews ensures that every change is reviewed by at least one other collaborator before merging, enforcing code quality and reducing the risk of introducing vulnerabilities or broken code. It also provides a clear audit trail of who approved each change, which is essential for compliance.

Why this answer

Branch protection rules with required pull request reviews enforce mandatory code review before merging, Dependabot alerts automatically monitor dependency vulnerabilities, and secret scanning detects accidental credential commits. Together these practices strengthen security compliance in GitHub Enterprise.

Exam trap

The trap here is that candidates may confuse automation account security with human user security, incorrectly assuming that 2FA can be disabled for automation accounts, or they may think bypassing branch protection is acceptable for admins, when in fact compliance requires consistent enforcement across all users.

Practice this question →

28

MCQhard

Your organization uses Azure DevOps and wants to enforce that all pipelines use a specific set of approved tasks. How can you achieve this?

A.Use the task restrictions feature in Azure DevOps to block unapproved tasks

B.Assign permissions to the task group to limit who can add tasks

C.Create a YAML template with the approved tasks and require all pipelines to use it

D.Configure a service hook to notify when an unapproved task is used

AnswerA

Use the task restrictions feature in Azure DevOps to block unapproved tasks: This organization-level policy lets you explicitly whitelist approved task IDs; any pipeline attempt to use a task outside the list is blocked or produces a warning, providing actual enforcement at the pipeline execution level rather than relying on user compliance.

Why this answer

Use the task restrictions feature in Azure DevOps to block unapproved tasks. Azure DevOps provides a 'Task restrictions' policy under Organization Settings > Policies > Add new policy, where you can specify which tasks are allowed or blocked across all pipelines. This enforces that only approved tasks are used.

Option B is incorrect because assigning permissions to a task group only controls who can modify the group, not which tasks are used in pipelines. Option C is incorrect because while YAML templates can standardize tasks, they do not enforce mandatory usage; pipelines can still be created without the template. Option D is incorrect because service hooks only trigger notifications when an unapproved task is used, but do not block its usage.

Practice this question →

29

MCQmedium

You are designing a security compliance plan for Azure Pipelines. The plan must ensure that no pipeline can use variables containing secrets unless those variables are stored in Azure Key Vault and referenced via a variable group linked to Key Vault. What is the best way to enforce this across all pipelines in an Azure DevOps organization?

A.Create a YAML template that mandates the use of Key Vault references.

B.Implement an Azure Policy that audits variable groups and requires Key Vault integration.

C.Require manual approval for all pipeline runs that use variables.

D.Use branch policies to prevent merging code that contains secrets.

AnswerA

A YAML template can enforce secure secret management across all pipelines by defining a standard structure that must be extended. Using the Azure DevOps 'required template' feature (under project settings or via pipeline decorators), you can force every pipeline to use a template that injects an AzureKeyVault task or a Key Vault-linked variable group, and optionally includes a script that fails the build if any inline secrets are detected. This gives you a central, versioned mechanism to mandate Key Vault references, which is enforceable at queue time rather than relying on manual review.

Why this answer

You can enforce a YAML template at the organization level using required template policies. This ensures all pipelines include a template that mandates Key Vault references for secrets, providing a scalable enforcement mechanism. Option B is incorrect because Azure Policy applies to Azure resources, not Azure DevOps constructs like variable groups.

Option C is incorrect because manual approvals do not enforce Key Vault usage. Option D is incorrect because branch policies control code, not variable usage during execution.

Practice this question →

30

MCQhard

Refer to the exhibit. You run a KQL query in Microsoft Sentinel to audit Azure Container Registry login failures. The result shows 15 failed push attempts to the 'contoso/webapp' repository and 3 failed pull attempts to 'contoso/api'. What is the most likely security implication?

A.The audit logs are not enabled for the container registry.

B.The container registry is misconfigured and allowing anonymous pushes.

C.The 'contoso/api' repository has been successfully pulled by an unauthorized user.

D.An attacker is attempting to push malicious images to the 'contoso/webapp' repository.

AnswerD

Multiple consecutive failed push events targeting the 'contoso/webapp' repository strongly indicate an attacker is attempting to upload malicious images using compromised or guessed credentials; although the pushes are failing, the systematic pattern of unauthorized write attempts is a clear security threat.

Why this answer

The query shows 15 failed push attempts to 'contoso/webapp' and 3 failed pull attempts to 'contoso/api'. Repeated failed push attempts to a specific repository are a classic indicator of an attacker trying to upload malicious images, as push operations require authentication and authorization. The high number of failures suggests a brute-force or credential-stuffing attack targeting the push operation, which is the most direct path to compromising the registry with unauthorized content.

Exam trap

The trap here is that candidates may misinterpret failed pull attempts as evidence of a successful breach (Option C), but the query explicitly shows failures, not successes, and the real threat is the repeated push failures indicating an active attack.

How to eliminate wrong answers

Option A is wrong because the query itself is auditing login failures, which means audit logs are already enabled and capturing the events. Option B is wrong because anonymous pushes would not generate login failures; anonymous access would either succeed or be blocked at the registry level without authentication attempts. Option C is wrong because the query shows failed pull attempts, not successful ones, so there is no evidence that an unauthorized user successfully pulled from 'contoso/api'.

Practice this question →

31

Multi-Selecteasy

Which TWO tools can be used to enforce branch protection policies in GitHub repositories? (Choose two.)

Select 2 answers

A.Azure Pipelines branch policies

B.Microsoft Intune compliance policies

C.GitHub branch protection rules

D.Microsoft Purview data classification

E.GitHub Actions workflows

AnswersA, C

Azure Pipelines branch policies are a correct tool because, when a repository is hosted on GitHub, Azure Pipelines can integrate directly with GitHub's branch protection system. It enables required status checks (such as successful pipeline builds) to be mandatory for pull request completion, effectively enforcing policies like 'build must pass' on protected branches.

Why this answer

Azure Pipelines branch policies allow you to enforce requirements such as requiring a minimum number of reviewers, checking for linked work items, or requiring a successful build before merging pull requests into protected branches. This integrates directly with GitHub repositories to enforce compliance and code quality standards.

Exam trap

The trap here is that candidates often confuse GitHub Actions workflows with branch protection rules, but workflows are event-driven automation and cannot enforce merge restrictions, whereas branch protection rules and Azure Pipelines branch policies are specifically designed for that purpose.

Practice this question →

32

MCQmedium

You receive a GitHub Dependabot alert as shown. The repository 'my-app' is internal. What is the best immediate action to mitigate the risk?

A.Dismiss the alert as it is a false positive

B.Create a private fork of the repository

C.Enable secret scanning on the repository

D.Update the lodash dependency to the latest patched version

AnswerD

Updating the lodash dependency to the latest patched version is the direct remediation, as the patched release resolves the specific vulnerability identified by the alert. This requires modifying the package manifest and lock file to reference a fixed version and then redeploying the application to ensure the vulnerable code is no longer in use.

Why this answer

The Dependabot alert indicates a known vulnerability in the lodash dependency. The best immediate action is to update lodash to the latest patched version, which directly resolves the security issue by applying the fix provided by the maintainers. This aligns with the principle of remediating vulnerabilities at the source rather than implementing workarounds.

Exam trap

The trap here is that candidates may confuse Dependabot alerts with secret scanning or think that changing repository visibility (forking) mitigates a dependency vulnerability, when the correct action is always to update the vulnerable package.

How to eliminate wrong answers

Option A is wrong because Dependabot alerts are based on GitHub's advisory database and are not false positives unless explicitly verified; dismissing without investigation ignores a real security risk. Option B is wrong because creating a private fork does not address the vulnerability; it only changes the repository's visibility and does not update the vulnerable dependency. Option C is wrong because secret scanning detects exposed secrets (e.g., tokens, keys), not vulnerable dependencies; it is unrelated to the lodash vulnerability.

Practice this question →

33

MCQmedium

You are designing a compliance strategy for Azure DevOps pipelines that deploy to production. The company policy requires that all production deployments must be reviewed by a security lead. Additionally, the deployment must use a specific release pipeline that has been pre-approved. How should you implement this?

A.Create a branch policy that requires the security lead to approve the pull request before merging.

B.Define a 'production' environment in Azure DevOps and configure an approval check that requires the security lead. Have the pipeline deploy to that environment.

C.Use a Classic release pipeline with a pre-deployment approval gate for the production stage.

D.Store the approved pipeline definition in a variable group and reference it in all pipelines.

AnswerB

Environment approval checks in YAML pipelines create a standardized, auditable manual gate before any deployment to the production environment. This integrates directly with pipeline runs, ensures the security lead explicitly approves each release, and provides full traceability, fulfilling the compliance requirement.

Why this answer

Azure DevOps environments allow you to define approval checks that must be satisfied before a deployment proceeds. By creating a 'production' environment and adding a pre-deployment approval check requiring the security lead, you enforce the mandatory review. The pipeline then deploys to that environment, ensuring only the pre-approved release pipeline is used.

Exam trap

The trap here is that candidates often confuse branch policies (which control code changes) with deployment approvals (which control release execution), leading them to choose Option A instead of the environment-based approval check in Option B.

How to eliminate wrong answers

Option A is wrong because a branch policy requiring pull request approval only controls code merging, not the actual deployment to production; it does not enforce a pre-approved release pipeline or a security lead review at deployment time. Option C is wrong because Classic release pipelines are legacy and do not integrate with modern YAML-based environments and their approval checks; the question implies a modern pipeline approach, and Classic pipelines lack the same granular environment-based approval controls. Option D is wrong because storing the pipeline definition in a variable group does not enforce any approval or review process; it merely centralizes configuration and does not prevent unauthorized deployments.

Practice this question →

34

MCQeasy

Your team uses Microsoft Defender for Cloud to monitor Azure resources. You need to ensure that all Azure DevOps pipelines are scanned for security misconfigurations before deployment. Which integration should you enable?

A.Connect Azure DevOps to Microsoft Sentinel.

B.Enable the 'Defender for DevOps' integration in Microsoft Defender for Cloud.

C.Deploy Microsoft Intune policies to Azure DevOps agents.

D.Configure Microsoft Purview to scan Azure DevOps repositories.

AnswerB

Microsoft Defender for Cloud's Defender for DevOps integration provides actionable security recommendations for Azure DevOps and GitHub environments, scanning repositories and pipelines for misconfigurations, exposed secrets, and vulnerabilities in infrastructure-as-code templates. Enabling this integration directly addresses the need to monitor and harden Azure DevOps pipelines against security issues.

Why this answer

Microsoft Defender for Cloud includes a 'Defender for DevOps' integration that allows you to connect Azure DevOps environments and scan pipelines for security misconfigurations, such as Infrastructure as Code (IaC) template issues or exposed secrets, before deployment. This integration provides built-in security posture assessments and actionable recommendations directly within the Defender for Cloud dashboard, enabling shift-left security practices.

Exam trap

The trap here is that candidates confuse Microsoft Sentinel (a SIEM) with Defender for Cloud's DevOps scanning capabilities, or assume that a data governance tool like Purview can perform security configuration scanning, when in fact only the dedicated Defender for DevOps integration provides this specific pipeline scanning functionality.

How to eliminate wrong answers

Option A is wrong because Microsoft Sentinel is a SIEM/SOAR solution for security incident detection and response, not a tool for scanning pipeline configurations or IaC templates before deployment. Option C is wrong because Microsoft Intune is a mobile device management (MDM) and mobile application management (MAM) service for managing endpoints, not for scanning Azure DevOps pipelines for security misconfigurations. Option D is wrong because Microsoft Purview is a data governance and compliance solution focused on data classification and lineage, not on scanning DevOps pipelines for security misconfigurations.

Practice this question →

35

MCQeasy

Your organization uses Azure DevOps Services. The compliance team requires that all code changes to the main branch of a critical repository must be reviewed by at least two members of the security team before they can be merged. You need to configure this requirement with the least administrative effort. What should you do?

A.Use a required template to enforce that pull requests include a note listing two security team members.

B.Configure a build validation policy on the main branch that runs a script to check the number of approvers.

C.Create a branch policy on the main branch that requires a minimum number of reviewers, and specify the security team as required reviewers.

D.Set up a status check policy that requires a successful status from an external service that tracks security team approvals.

AnswerC

This is correct because branch policies in Azure Repos allow you to enforce a minimum number of reviewers and designate specific users or groups as required. By setting the security team as required reviewers and requiring at least two approvals, you ensure that two security team members must approve each pull request to main.

Why this answer

The requirement is to enforce that at least two security team members approve changes to the main branch. Azure Repos branch policies provide a built-in way to require a minimum number of reviewers and to specify required reviewers. Configuring a branch policy with the security team as required reviewers and a minimum count of two directly satisfies this with minimal effort.

Exam trap

The trap here is thinking that build validation or status checks can enforce human approvals, when only branch policies with required reviewers can do that.

Practice this question →

36

MCQeasy

Your team uses GitHub repositories and wants to ensure that all code changes are signed by a verified contributor before merging. Which branch protection rule should you enable?

A.Require signed commits

B.Require pull request reviews before merging

C.Require linear history

D.Restrict who can push to matching branches

AnswerA

Requiring signed commits enforces a branch protection rule that every commit on the protected branch must be signed with a GPG or S/MIME key that GitHub can verify; unsigned commits are blocked, ensuring cryptographically verified authorship.

Why this answer

Requiring signed commits ensures that each commit is cryptographically verified using a GPG or S/MIME key linked to the contributor's GitHub account. This enforces non-repudiation and confirms the identity of the author, directly addressing the requirement that all code changes be signed by a verified contributor before merging.

Exam trap

The trap here is confusing identity verification (signed commits) with access control (restrict pushes) or process approval (pull request reviews), leading candidates to pick a rule that controls who can push rather than what cryptographic proof is required.

How to eliminate wrong answers

Option B is wrong because requiring pull request reviews before merging enforces code review approval, not cryptographic signing of commits. Option C is wrong because requiring a linear history enforces a clean, non-merge-commit history but does not verify the identity or signing of commits. Option D is wrong because restricting who can push to matching branches controls write access via teams or users, but does not enforce that commits are signed or verified.

Practice this question →

37

MCQmedium

Your organization uses Azure DevOps for a multi-tier web application. The application consists of a React frontend, a Node.js API, and a SQL database. The security team has mandated the following: (1) All code changes must be scanned for secrets before merging to the main branch. (2) Infrastructure-as-code templates (ARM) must be validated for security compliance before deployment. (3) Production deployments must use a service connection with a managed identity that has only the required permissions. You have set up a CI/CD pipeline with two stages: Build and Release. The Build stage runs on pull requests and the Release stage deploys to a production environment. Recently, a developer accidentally committed a secret (API key) to a configuration file. The secret was not caught by the pipeline, and the code was merged to main. You need to prevent this in the future. What should you do?

A.Configure a branch policy to require at least two reviewers on pull requests to the main branch.

B.Implement a manual approval gate on the Release stage to review each deployment for secrets.

C.Use a pipeline decorator to inject a validation step that runs Azure Policy on the code repository.

D.Add a 'Credential Scanner' task to the Build pipeline and configure it to fail the build if any secrets are found. Also, move all secrets to Azure Key Vault and reference them via variable groups.

AnswerD

Adding a Credential Scanner task to the Build pipeline and configuring it to fail the build when secrets are found automatically blocks hardcoded credentials from being merged into the codebase. Moving secrets to Azure Key Vault and referencing them via variable groups centralizes secret management and removes the need to store sensitive values in source code.

Why this answer

It directly addresses the root cause: secrets were not being scanned before merge. The Credential Scanner task (part of Microsoft Security Code Analysis) scans for hardcoded secrets and can fail the build, preventing the merge. Moving secrets to Azure Key Vault and referencing them via variable groups (linked to the vault) ensures secrets are never stored in the repository, eliminating the risk of accidental commits.

Exam trap

The trap here is that candidates may confuse Azure Policy (which governs Azure resource compliance) with code scanning tools, or mistakenly think that manual reviews or approval gates are sufficient to catch secrets before merge, when automated scanning is required by the mandate.

How to eliminate wrong answers

Option A is wrong because requiring two reviewers does not prevent a secret from being committed; reviewers may not catch a secret in a configuration file. Option B is wrong because a manual approval gate on the Release stage only catches secrets after they have already been merged to main, which violates the mandate to scan before merging. Option C is wrong because Azure Policy is used for governance of Azure resources (e.g., ARM template compliance), not for scanning code repositories for secrets; a pipeline decorator cannot run Azure Policy on a Git repository.

Practice this question →

38

MCQeasy

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

A.Code scanning.

B.Dependabot.

C.Secret scanning.

D.GitHub Actions.

AnswerC

Secret scanning is GitHub's native security feature that applies pattern recognizers—curated definitions provided by GitHub and partner organizations—to identify known credential formats such as API keys, access tokens, OAuth secrets, and private keys across the repository, including new pushes and existing history. When an Expo API key is committed, secret scanning triggers an immediate alert and, if push protection is enabled for the repository, even blocks the push itself to prevent the secret from ever being stored. This detection is format-specific and proactive, giving organizations a chance to revoke the exposed key before attackers can exploit it, which is exactly the correct mechanism for identifying an exposed Expo API key.

Why this answer

Secret scanning is the correct GitHub feature because it is specifically designed to automatically detect exposed credentials, tokens, and other secrets in code repositories. It scans for known patterns of sensitive data, such as AWS keys, GitHub tokens, and private keys, and alerts repository administrators when a match is found. This directly addresses the requirement to detect exposed credentials without needing custom workflows or additional configuration.

Exam trap

The trap here is that candidates often confuse Code scanning (which finds code vulnerabilities) with Secret scanning (which finds credentials), because both are security-related features under GitHub's Advanced Security suite, but they serve fundamentally different purposes.

How to eliminate wrong answers

Option A is wrong because Code scanning uses CodeQL to analyze code for security vulnerabilities and bugs, not specifically to detect exposed credentials or secrets. Option B is wrong because Dependabot is focused on monitoring and updating dependencies for known vulnerabilities, not scanning for hardcoded secrets in the codebase. Option D is wrong because GitHub Actions is a CI/CD automation platform that can run custom workflows, but it does not natively detect exposed credentials; you would need to integrate a third-party secret scanning tool or write custom logic to achieve this.

Practice this question →

39

Multi-Selecteasy

Which TWO compliance frameworks are directly supported by Microsoft Purview Compliance Manager for Azure DevOps?

Select 2 answers

A.ISO 27001

B.HIPAA

C.PCI DSS

D.FedRAMP High

E.SOC 2

AnswersA, E

ISO 27001 is a widely adopted information security management standard, and Purview Compliance Manager includes a template that maps Azure DevOps controls to it. You can use this template to assess and manage your DevOps compliance posture against ISO 27001 requirements.

Why this answer

Microsoft Purview Compliance Manager directly supports ISO 27001 and SOC 2 as built-in compliance templates for Azure DevOps. These frameworks are pre-configured with control mappings, assessment templates, and automated testing actions that align with Azure DevOps security and audit capabilities. This allows organizations to continuously monitor and manage compliance posture against these standards without manual configuration.

Exam trap

The trap here is that candidates often assume any major compliance framework (like HIPAA or PCI DSS) is directly supported, but Microsoft Purview Compliance Manager for Azure DevOps only provides pre-built templates for a specific subset of frameworks, including ISO 27001 and SOC 2, while others require custom assessments or are covered at the Azure platform level rather than the Azure DevOps service level.

Practice this question →

40

MCQhard

Your company, Contoso Ltd., is a financial services firm that must comply with PCI DSS. You manage a Azure DevOps organization with over 200 projects. Each project uses a service principal to deploy to Azure using service connections stored in library variable groups. Recently, an auditor flagged that a developer used a service principal with Contributor rights on a production subscription to accidentally delete a storage account. The developer had been granted access to the variable group containing that service principal's credentials. You are tasked with implementing a security and compliance plan to prevent this from recurring. The solution must minimize administrative overhead and follow the principle of least privilege. Current environment: All service principals are created in Azure AD and assigned to variable groups. Developers are granted 'User' access level in Azure DevOps and are members of various teams. You have the ability to create Azure AD groups and custom roles. Which course of action should you take?

A.Remove all variable groups and require developers to use their own Azure AD accounts for deployments, granting them Contributor rights only on non-production environments.

B.Require all pipeline runs that use production service connections to be approved by a security team via Azure Pipelines approval gates.

C.Implement Azure DevOps pipeline decorators to inject a security task that checks the service connection's role before each deployment, and fail the pipeline if the role is Contributor or higher.

D.Create custom Azure RBAC roles with minimal required permissions for each service principal, restrict service connections to specific pipelines using Azure DevOps security settings (e.g., 'Use' permission), and assign developers only the 'Use' permission to the service connections they need, not the variable groups containing credentials.

AnswerD

This approach aligns with least privilege by creating custom Azure RBAC roles that include only the exact actions required for each deployment, rather than using broad built-in roles like Contributor. Restricting service connections to specific pipelines via Azure DevOps security settings (e.g., the 'Use' permission) ensures that a compromised pipeline can only use its designated connection, and developers are not granted access to variable groups containing credentials, reducing the risk of secret leakage.

Why this answer

It enforces the principle of least privilege by creating custom Azure RBAC roles with minimal permissions, restricting service connections to specific pipelines via Azure DevOps security settings (e.g., 'Use' permission), and assigning developers only the 'Use' permission to the service connections rather than the variable groups containing credentials. This prevents developers from directly accessing or modifying the service principal credentials, eliminating the risk of accidental or malicious use of high-privilege roles like Contributor.

Exam trap

The trap here is that candidates often confuse approval gates (Option B) as a sufficient security control, but they fail to address the root cause—excessive permissions on the service principal itself—and overlook the need to restrict access to the service connection credentials at the Azure DevOps permission level.

How to eliminate wrong answers

Option A is wrong because removing variable groups and granting developers Contributor rights on non-production environments still violates least privilege—developers should not have Contributor rights on any environment if they only need to deploy, and using their own Azure AD accounts for deployments introduces security risks like credential exposure and lack of audit separation. Option B is wrong because requiring approval gates for all pipeline runs using production service connections adds administrative overhead and does not prevent a developer from accidentally using a Contributor role in a pipeline that has been approved; it only adds a manual check, not a technical control. Option C is wrong because pipeline decorators that check the service connection's role before each deployment can be bypassed if the developer modifies the pipeline YAML or if the decorator is not applied to all pipelines; also, failing the pipeline after the role check does not prevent the service principal from having excessive permissions in the first place.

Practice this question →

41

MCQmedium

You are reviewing a pipeline YAML file. The variable 'prod-db-password' is stored in a variable group linked to Azure Key Vault. However, the pipeline fails with an error that the secret cannot be accessed. What is the most likely cause?

A.The YAML syntax for referencing the variable is incorrect.

B.The pipeline's authorized service principal lacks 'Get' permission on the Key Vault.

C.The variable group 'prod-variables' does not exist.

D.The secret name in Key Vault does not match 'prod-db-password'.

AnswerB

When a variable group is linked to an Azure Key Vault, the Azure DevOps task attempts to retrieve secrets using the service principal associated with the pipeline's service connection. If that service principal lacks the 'Get' permission in the Key Vault's access policy for the secret, the task will fail specifically with an authorization error, making this the likely root cause.

Why this answer

The most likely cause is that the pipeline's authorized service principal lacks 'Get' permission on the Key Vault. When a variable group is linked to Azure Key Vault, Azure Pipelines uses a service principal (the pipeline's identity) to retrieve secrets. Even if the variable group and secret name are correct, the pipeline will fail if the service principal does not have the 'Get' secret permission in the Key Vault access policy.

This is a common misconfiguration because the variable group link only establishes the mapping, not the actual access rights.

Exam trap

The trap here is that candidates often assume the variable group link automatically grants access to Key Vault secrets, overlooking the separate requirement to configure Key Vault access policies for the pipeline's service principal.

How to eliminate wrong answers

Option A is wrong because the YAML syntax for referencing a variable from a linked variable group is simply $(variableName) or ${{ variables.variableName }}, and the error message about 'cannot be accessed' indicates a permissions issue, not a syntax error. Option C is wrong because the question states the variable 'prod-db-password' is stored in a variable group linked to Azure Key Vault, implying the variable group exists; if it did not, the error would be about the group not being found, not about secret access. Option D is wrong because if the secret name in Key Vault did not match, the pipeline would typically fail with a 'secret not found' error, not a 'cannot be accessed' error, and the variable group mapping would have been validated at creation time.

Practice this question →

42

MCQmedium

You are using GitHub Advanced Security. The security team wants to prevent developers from introducing code with high-severity vulnerabilities. What is the best way to enforce this?

A.Enable Dependabot and require pull request reviews for dependency updates

B.Enable code scanning and configure a quality gate to fail PRs with high-severity alerts

C.Enable push protection for all repositories

D.Enable secret scanning and block pushes with high-confidence secrets

AnswerB

Code scanning analyses pull requests and raises alerts; a branch protection rule or ruleset requiring the code scanning check to pass blocks merges while high-severity alerts remain. This enforces the gate before vulnerable code reaches the main branch.

Why this answer

Enabling code scanning with a quality gate that fails pull requests (PRs) on high-severity alerts directly prevents vulnerable code from being merged. This enforces security policy at the PR merge point, using GitHub's CodeQL analysis to detect vulnerabilities before they reach the main branch. Dependabot and secret scanning address different risks (outdated dependencies and leaked secrets) and do not block code with high-severity vulnerabilities.

Exam trap

The trap here is that candidates confuse Dependabot or secret scanning with code vulnerability prevention, but only code scanning with a quality gate directly blocks high-severity code vulnerabilities at the PR level.

How to eliminate wrong answers

Option A is wrong because Dependabot only automates dependency updates and requires PR reviews for those updates, but it does not scan custom code for vulnerabilities or block PRs based on severity. Option C is wrong because push protection prevents secrets from being pushed to repositories, not code vulnerabilities; it is a secret scanning feature, not a code quality gate. Option D is wrong because secret scanning blocks pushes with high-confidence secrets, which addresses credential leaks, not code vulnerabilities; it does not analyze code for security flaws.

Practice this question →

43

Multi-Selecthard

Your organization is implementing a security compliance plan for Azure DevOps. Which TWO actions should you take to ensure that only authorized users can modify build pipelines?

Select 2 answers

A.Require all users to use Personal Access Tokens (PATs)

B.Configure branch policies to require reviews for changes to pipeline YAML files

C.Set pipeline permissions to restrict editing to specific security groups

D.Enable audit logging for all pipeline changes

E.Enable OpenID Connect (OIDC) for pipeline authentication

AnswersB, C

Configuring branch policies on the repository that contains your pipeline YAML files requires pull request reviews, successful builds, and approved changes before merging, directly enforcing mandatory peer review. This is a preventive control that ensures any change to pipeline definitions is vetted, making it the correct answer for a security compliance plan.

Why this answer

Branch policies in Azure Repos enforce required reviews for changes to YAML pipeline files stored in the repository. This ensures that any modification to the pipeline definition must be approved by authorized reviewers before merging, preventing unauthorized or accidental changes. Option C is correct because pipeline permissions in Azure DevOps allow you to restrict editing of a pipeline to specific security groups (e.g., 'Build Administrators'), directly controlling who can modify the pipeline through the web interface or API.

Exam trap

The trap here is that candidates often confuse authentication mechanisms (PATs, OIDC) with authorization controls, or mistake auditing (detective) for prevention, leading them to select options that do not actually restrict who can modify pipelines.

Practice this question →

44

Multi-Selectmedium

Your team is implementing a security and compliance plan for Azure DevOps. Which TWO actions should you take to meet regulatory requirements for audit logging and access control?

Select 2 answers

A.Enable anonymous access to project boards for external stakeholders.

B.Enable Azure DevOps audit log to track changes to security policies and user permissions.

C.Configure Azure AD Conditional Access policy to require multi-factor authentication for Azure DevOps.

D.Grant all users Project Collection Administrator role to simplify access management.

E.Disable auditing for the project to reduce log volume.

AnswersB, C

Audit logs are essential for compliance tracking.

Why this answer

Enabling the Azure DevOps audit log (option B) is essential for regulatory compliance because it records changes to security policies, user permissions, and other critical events, providing an immutable trail for forensic analysis and reporting. This directly meets audit logging requirements by capturing who did what and when, which is necessary for standards like SOC 2, ISO 27001, or GDPR.

Exam trap

Microsoft often tests the misconception that enabling anonymous access or simplifying permissions (like granting admin roles to all users) is acceptable for compliance, when in fact these actions directly violate audit logging and access control requirements.

Practice this question →

45

Multi-Selectmedium

Your team uses Azure DevOps and needs to ensure that secrets are not exposed in pipeline logs. Which THREE practices should you implement?

Select 3 answers

A.Use logging commands to mask secrets in scripts

B.Enable pipeline log encryption

C.Mark variables as 'secret' in pipeline variables

D.Store secrets in YAML variable files

E.Use Azure Key Vault to store secrets

AnswersA, C, E

Logging commands such as ##vso[task.setsecret] register values with the agent so they are masked in pipeline output. This satisfies the requirement to prevent secrets appearing in logs, since the agent replaces registered values with asterisks.

Why this answer

Option A is correct because Azure Pipelines supports the logging command `##vso[task.setsecret]value` (and the older `##vso[task.setvariable variable=name;issecret=true]`) to explicitly register a value with the agent so it is masked as `***` anywhere it appears in pipeline logs. Option C is correct because marking a variable as 'secret' in pipeline variables (via the UI lock icon or `issecret=true` in YAML) causes Azure DevOps to encrypt the value at rest and automatically mask it in logs. Option E is correct because Azure Key Vault stores secrets outside the pipeline definition and, when linked via a variable group or the `AzureKeyVault@2` task, the retrieved values are automatically treated as secrets and masked in logs, while also enforcing access control and rotation.

Option B is not a real Azure DevOps feature — pipeline logs are not configured via a 'log encryption' toggle; masking is achieved through secret variables and logging commands. Option D is incorrect because storing secrets in plain YAML variable files commits them to the repository in cleartext, which is exactly the exposure the team must avoid.

Exam trap

The trap here is that candidates confuse log masking with encryption, assuming that enabling 'pipeline log encryption' is a real Azure DevOps feature, when in fact the platform relies on secret variable masking and Azure Key Vault integration for secret management.

Practice this question →

46

Multi-Selecteasy

Which TWO practices should you follow to ensure compliance with regulatory requirements (e.g., PCI DSS) when using Azure DevOps? (Choose two.)

Select 2 answers

A.Manually track changes to pipelines in a spreadsheet.

B.Allow all users to create and modify pipelines without restrictions.

C.Enable Azure DevOps audit logging to track changes to pipelines and policies.

D.Disable audit logging to reduce storage costs.

E.Use branch policies to enforce code reviews and approvals for all changes.

AnswersC, E

Audit logging records every change to pipelines, policies and permissions, producing the tamper-evident trail PCI DSS requires for accountability and forensic review. It satisfies the stem's regulatory compliance constraint by evidencing who altered build definitions and when, which access reviews and branch policies alone cannot demonstrate.

Why this answer

Option C is correct because enabling Azure DevOps audit logging captures a tamper-evident trail of events such as pipeline modifications, policy changes, permission updates, and user access, which is essential for demonstrating compliance with regulatory frameworks like PCI DSS that require monitoring and traceability of changes to systems handling cardholder data. Option E is correct because branch policies enforce mandatory code reviews, minimum approver counts, and build validation before changes merge, providing the segregation of duties and change-control evidence that PCI DSS requires for modifications to production pipelines and code. Option A is not appropriate because manually tracking pipeline changes in a spreadsheet is error-prone, unauditable, and lacks the integrity and automation of native Azure DevOps audit logs.

Option B is incorrect because unrestricted pipeline creation and modification violates the principle of least privilege and PCI DSS change-control requirements. Option D is incorrect because disabling audit logging removes the very evidence needed for compliance and directly contradicts regulatory monitoring obligations.

Exam trap

The trap here is that candidates may confuse 'audit logging' with a cost-saving measure (Option D) or think manual tracking (Option A) is acceptable, while the exam expects you to recognize that automated, immutable audit trails and enforced branch policies are the only reliable ways to meet regulatory compliance in a DevOps context.

Practice this question →

47

MCQmedium

Your team uses GitHub. You need to automatically remove a user's access to all repositories when they leave the company. What is the most efficient approach?

A.Assign the user to a 'Leaver' team and remove all repository permissions

B.Manually remove the user from each repository

C.Configure SAML single sign-on (SSO) with Microsoft Entra ID

D.Enable SCIM provisioning from Microsoft Entra ID to GitHub

AnswerD

Enabling SCIM provisioning from Microsoft Entra ID to GitHub is the correct solution because SCIM automatically creates, updates, and deactivates GitHub user accounts based on Entra ID group membership, so when a user is removed from the source group or disabled in Entra ID, GitHub automatically revokes their access without manual intervention.

Why this answer

SCIM (System for Cross-domain Identity Management) provisioning from Microsoft Entra ID to GitHub automates user lifecycle management. When a user is disabled or removed from Entra ID, SCIM automatically deprovisions their access across all GitHub resources, including repositories, without manual intervention. This is the most efficient approach because it is event-driven and scales to thousands of users.

Exam trap

The trap here is that candidates confuse SAML SSO (which only handles authentication) with SCIM (which handles provisioning), leading them to choose SAML as the solution for deprovisioning access.

How to eliminate wrong answers

Option A is wrong because assigning a user to a 'Leaver' team and removing repository permissions is a manual, error-prone process that does not scale and does not leverage automated identity lifecycle management. Option B is wrong because manually removing the user from each repository is inefficient, time-consuming, and prone to human error, especially in large organizations with many repositories. Option C is wrong because SAML SSO only controls authentication (who can sign in) but does not automatically deprovision access to repositories when a user is removed from the identity provider; it requires additional SCIM provisioning to synchronize group membership and access rights.

Practice this question →

48

MCQhard

Your team uses GitHub Actions and needs to enforce that all workflows must use approved actions from a curated list. What is the best way to implement this?

A.Configure branch protection rules

B.Set up an allowed list of actions in organization settings

C.Enable Dependabot alerts

D.Use OpenID Connect (OIDC)

AnswerB

In GitHub organization settings, under Actions > General, you can choose 'Allow only selected actions' and specify an allowlist of actions and reusable workflows. This restricts all workflows in the organization to only use approved actions, directly enforcing the required policy.

Why this answer

GitHub Organizations allow administrators to define an 'allowed list' of actions under Settings > Actions > Policies, restricting workflow execution to only approved actions from the curated list. This directly enforces the requirement that all workflows use only approved actions, preventing the use of unverified or malicious third-party actions.

Exam trap

The trap here is confusing branch protection rules (which control code changes) with action governance policies (which control which actions can run), leading candidates to incorrectly select branch protection as the enforcement mechanism.

How to eliminate wrong answers

Option A is wrong because branch protection rules control who can push to branches and require pull request reviews, but they do not restrict which actions can be used in workflows. Option C is wrong because Dependabot alerts notify about vulnerable dependencies in your repository, but they do not enforce a curated list of approved actions. Option D is wrong because OpenID Connect (OIDC) is used for federated authentication to access cloud resources without storing secrets, not for restricting which actions can be executed in workflows.

Practice this question →

49

Multi-Selecteasy

Your team uses Azure Pipelines and needs to comply with SOC 2 requirements. Which TWO features should you use to meet audit log requirements? (Select TWO.)

Select 2 answers

A.Configure network security groups to block public access

B.Automate secret rotation for service connections

C.Enable Azure DevOps audit logging

D.Create service principals for pipeline authentication

E.Stream audit logs to Azure Monitor Log Analytics

AnswersC, E

Enabling Azure DevOps audit logging records user and service principal actions across the organization, such as pipeline creation, permission changes, and policy edits, into the Audit log, which is the foundational mechanism for meeting SOC compliance evidence requirements.

Why this answer

Azure DevOps audit logging (Option C) captures a detailed, immutable record of events such as pipeline runs, permission changes, and access attempts, which is essential for SOC 2 audit log requirements. Streaming these logs to Azure Monitor Log Analytics (Option E) enables long-term retention, advanced querying, and alerting, satisfying the need for secure log storage and monitoring.

Exam trap

The trap here is that candidates confuse security controls (like network security groups or secret rotation) with audit logging features, mistakenly thinking any security measure fulfills audit log requirements, when only dedicated logging and log export features satisfy SOC 2 audit trail mandates.

Practice this question →

50

MCQeasy

Your team uses GitHub Enterprise with GitHub Actions. Compliance requires that all contributors sign commits with a verified GPG key. You have enabled 'Require signed commits' on the repository. However, a developer reports that their commits are being rejected even though they have configured a GPG key. The error says 'Commit must have a valid signature.' The developer's GPG key is listed in their GitHub account settings. What is the most likely cause?

A.The developer's GPG key has expired.

B.The developer's GPG key is not uploaded to GitHub.

C.The developer's local Git email does not match the email associated with the GPG key in GitHub.

D.GitHub only supports S/MIME, not GPG.

AnswerC

GitHub verifies a GPG signature by checking that the email associated with the public key matches the author and committer email addresses embedded in the Git commit. If the developer's local Git user.email differs from the email linked to the GPG key in GitHub, the signature is cryptographically valid but GitHub marks the commit as 'unverified' because the identity does not match.

Why this answer

GitHub verifies a GPG signature by matching the signing key's associated email (and key ID) against the commit's author/committer email. If the developer's local Git user.email does not match the email registered with the GPG key in GitHub, GitHub marks the signature as unverified and the 'Require signed commits' rule rejects the push with 'Commit must have a valid signature.' The key being present in GitHub settings is not sufficient — the email binding must also match.

Exam trap

The trap is assuming that uploading the GPG key is sufficient — AZ-400 tests the subtle email-binding requirement, so candidates overlook that the commit email must match the key's email in GitHub.

How to eliminate wrong answers

Option A is wrong because an expired key would typically produce a different error (e.g., signature expired or key expired) and GitHub would still recognize the key; the question states the key is listed, and expiry is not indicated. Option B is wrong because the scenario explicitly says the GPG key is listed in the developer's GitHub account settings, so it has been uploaded. Option D is wrong because GitHub supports both GPG and S/MIME (and SSH signing); claiming GPG is unsupported is factually incorrect.

Practice this question →

51

Matchingmedium

Match each Azure DevOps extension type to its example.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

SonarQube analysis

Burnup chart

Slack integration on work item update

Terraform task for Azure Pipelines

Why these pairings

In this matching exercise, the correct pairs are: Build task → NuGet Tool Installer, Dashboard widget → Sprint Burndown, and Service hook → Notify Slack on build completion. The distractors incorrectly assign Sprint Burndown as a build task and NuGet Tool Installer as a dashboard widget, testing your ability to distinguish between extension types based on their purpose. Build tasks execute during pipeline runs, dashboard widgets display information on dashboards, and service hooks trigger external actions on events.

Practice this question →

52

MCQmedium

Your team uses GitHub Actions for CI/CD and needs to ensure that secrets such as Azure service principal credentials are not exposed in logs. What is the best practice to prevent secret exposure?

A.Store secrets as GitHub Actions secrets and reference them in workflows

B.Store secrets in the workflow YAML file

C.Use environment protection rules to mask secrets

D.Encrypt workflow logs after the run completes

AnswerA

GitHub Actions secrets are encrypted at rest and automatically masked in logs, so referencing them via secrets context prevents credential exposure. Hardcoding values or echoing them would leak the service principal credentials the stem warns against.

Why this answer

GitHub Actions secrets are encrypted environment variables that are automatically masked in workflow logs when referenced. By storing Azure service principal credentials as GitHub Actions secrets and using the `${{ secrets.SECRET_NAME }}` syntax in workflows, the actual secret values are never written to logs, preventing exposure. This is the recommended approach for handling sensitive data in GitHub Actions CI/CD pipelines.

Exam trap

The trap here is that candidates may confuse environment protection rules (which control deployment gates and approvals) with the built-in secret masking feature of GitHub Actions secrets, leading them to incorrectly select option C.

How to eliminate wrong answers

Option B is wrong because storing secrets directly in the workflow YAML file exposes them in plaintext in the repository, making them visible to anyone with access to the repository and potentially leaking them in logs or pull request comments. Option C is wrong because environment protection rules control deployment approvals and branch restrictions, but they do not mask or redact secrets from logs; secret masking is a built-in feature of GitHub Actions secrets, not environment rules. Option D is wrong because encrypting workflow logs after the run completes does not prevent secrets from being displayed in plaintext during the run or in the unencrypted logs before encryption; the secret would still be exposed in the log output.

Practice this question →

53

Multi-Selectmedium

Your team uses GitHub Advanced Security to identify vulnerabilities in code. Which TWO actions can you take to ensure that critical security alerts are addressed before code is merged?

Select 2 answers

A.Enable secret scanning push protection.

B.Create a repository rule that allows bypassing pull request requirements.

C.Configure branch protection rules to require status checks from code scanning.

D.Enable Dependabot auto-merge for pull requests.

E.Use pull request annotations to display code scanning alerts.

AnswersC, E

Configuring branch protection rules to require code scanning status checks creates a hard merge gate: if CodeQL or other scanning tools detect critical vulnerabilities, the status check fails and the pull request is blocked. This enforces alert resolution before code can enter the protected branch, making it the correct answer.

Why this answer

Branch protection rules can require passing status checks from code scanning and secret scanning. Pull request annotations show alerts directly in the PR. Dependabot auto-merge and repository rules for bypassing are not relevant for blocking merges based on security alerts.

Practice this question →

54

MCQeasy

Your DevOps team is using Microsoft Defender for Cloud to monitor Azure resources. Which of the following is a security recommendation that Defender for Cloud might provide?

A.Allow all inbound traffic on port 22 for SSH

B.Enable Transparent Data Encryption (TDE) on SQL databases

C.Disable auditing on storage accounts to reduce overhead

D.Configure web apps to use HTTP instead of HTTPS

AnswerB

Enabling Transparent Data Encryption (TDE) encrypts SQL database data files, transaction logs, and backups at rest, protecting against data exfiltration if storage is compromised. This is a recommended security control in Defender for Cloud and helps meet compliance requirements for encryption at rest.

Why this answer

Microsoft Defender for Cloud provides security recommendations based on best practices and compliance frameworks. Enabling Transparent Data Encryption (TDE) on SQL databases is a standard security recommendation because it encrypts data at rest, protecting against unauthorized access to the physical database files. This aligns with the 'Develop a security and compliance plan' domain, as TDE helps meet regulatory requirements like GDPR or HIPAA.

Exam trap

The trap here is that candidates may confuse security recommendations with operational shortcuts, such as disabling auditing or using HTTP, thinking they reduce overhead, when in fact Defender for Cloud always promotes security hardening and compliance.

How to eliminate wrong answers

Option A is wrong because allowing all inbound traffic on port 22 (SSH) is a security risk, not a recommendation; Defender for Cloud would recommend restricting SSH access to specific IP ranges or using just-in-time (JIT) VM access. Option C is wrong because disabling auditing on storage accounts reduces visibility for security monitoring and compliance, whereas Defender for Cloud recommends enabling auditing to track access and changes. Option D is wrong because configuring web apps to use HTTP instead of HTTPS exposes data in transit to interception and man-in-the-middle attacks; Defender for Cloud recommends enforcing HTTPS to ensure encrypted communication.

Practice this question →

55

MCQeasy

Your organization is adopting DevSecOps and wants to integrate security scanning into the CI/CD pipeline. Which tool should you use to scan container images for vulnerabilities?

A.Azure Monitor

B.GitHub Copilot

C.Microsoft Defender for Cloud

D.Azure Logic Apps

AnswerC

Microsoft Defender for Cloud, specifically through Microsoft Defender for Containers, includes vulnerability scanning for container images in Azure Container Registry (ACR) and other registries. It uses Microsoft Defender Vulnerability Management to detect OS and language-level CVEs and can be integrated into a CI/CD pipeline as a quality gate, blocking vulnerable images from being promoted to production.

Why this answer

Microsoft Defender for Cloud (Option C) is the correct tool for scanning container images for vulnerabilities in a CI/CD pipeline, as it integrates with Azure Container Registry to perform vulnerability assessments. Option A (Azure Monitor) is incorrect because it is a monitoring and observability service, not a security scanner. Option B (GitHub Copilot) is incorrect as it is an AI code completion tool.

Option D (Azure Logic Apps) is incorrect because it is a workflow automation service, not a security scanning tool.

Practice this question →

56

MCQhard

Your company uses Microsoft Defender for Cloud to monitor Azure DevOps environments. You receive an alert that a service principal has excessive permissions. What is the first step you should take to investigate and remediate?

A.Reduce the service principal's permissions to the minimum required.

B.Review the Microsoft Entra ID audit logs for the service principal.

C.Immediately delete the service principal.

D.Reset the service principal's credentials.

AnswerB

Reviewing the Microsoft Entra ID audit logs is the correct first step because these logs provide a detailed trail of the service principal's sign-ins, granted permissions, and activities, allowing you to determine whether the alert indicates a real threat or normal operation before taking any corrective action.

Why this answer

Reviewing the Microsoft Entra ID audit logs is the correct first step because it allows you to investigate the service principal's activity, such as which resources it accessed, when, and from where, before taking any remediation action. This forensic analysis is essential to understand the scope of the excessive permissions and to ensure that reducing permissions or other actions do not inadvertently disrupt legitimate operations. Without this step, you risk breaking functionality or missing evidence of misuse.

Exam trap

The trap here is that candidates often jump to immediate remediation (reducing permissions or deleting the principal) without first performing a forensic investigation, failing to recognize that the first step in incident response is always to gather evidence via audit logs to understand the scope and impact.

How to eliminate wrong answers

Option A is wrong because reducing permissions immediately without first investigating the audit logs could disrupt legitimate automated processes or deployments that depend on those permissions, and it skips the necessary forensic step to understand the context of the alert. Option C is wrong because immediately deleting the service principal is a drastic action that could cause widespread service outages, as the service principal may be essential for CI/CD pipelines or other automated tasks, and it destroys the ability to audit past activities. Option D is wrong because resetting the service principal's credentials (e.g., client secret or certificate) addresses credential compromise but does not remediate the root cause of excessive permissions, and it should be done only after investigation to avoid breaking active sessions without understanding the impact.

Practice this question →

57

MCQeasy

Your team uses GitHub Copilot for code suggestions. To comply with your organization's data protection policies, you need to ensure that code snippets and prompts sent to Copilot are not stored or used by Microsoft for service improvement. What should you configure?

A.Set a compliance grade in Microsoft Defender for Cloud

B.Enable the 'Data Exclusion' setting in Copilot's enterprise settings

C.Apply a Microsoft Purview Data Loss Prevention policy

D.Configure Azure OpenAI Service content filtering

AnswerB

Enabling the 'Data Exclusion' setting in Copilot's enterprise settings is the correct action because it instructs GitHub not to store or use your code snippets for service improvement purposes, aligning with your requirement to ensure code is not retained or used for model training. This setting is specifically designed to prevent Microsoft from retaining or using your code data beyond what is necessary to provide the Copilot service.

Why this answer

GitHub Copilot's enterprise settings include a 'Data Exclusion' feature that, when enabled, prevents Microsoft from storing or using your code snippets and prompts for service improvement. This directly addresses the data protection policy requirement by ensuring that your organization's code is not retained or analyzed by Microsoft beyond the immediate suggestion generation.

Exam trap

The trap here is that candidates may confuse data protection controls for Copilot with broader Microsoft security tools like Defender for Cloud or Purview DLP, which address different compliance aspects and do not directly control Copilot's data storage behavior.

How to eliminate wrong answers

Option A is wrong because Microsoft Defender for Cloud compliance grades assess the security posture of cloud resources, not the data handling policies of third-party tools like GitHub Copilot. Option C is wrong because Microsoft Purview Data Loss Prevention (DLP) policies are designed to prevent sensitive data from being shared or leaked across services like email or SharePoint, but they do not control how GitHub Copilot processes or stores code snippets. Option D is wrong because Azure OpenAI Service content filtering applies to content moderation in Azure OpenAI deployments, not to GitHub Copilot's data storage or usage policies.

Practice this question →

58

MCQmedium

Your organization uses Azure DevOps and requires that all pipelines enforce branch policy for pull requests. A developer creates a pipeline that builds and tests code on push to any branch. The security team wants to ensure that no code can be deployed to production without passing through a pull request with required reviewers. Which action should you take to meet this requirement?

A.Disable CI triggers on the pipeline and require manual builds.

B.Modify the service connection to require admin approval.

C.Set the pipeline to require approval from the security team before running.

D.Configure branch policy on the main branch to require a pull request with a minimum number of reviewers.

AnswerD

Branch policies on the main branch are the correct Azure DevOps mechanism to enforce pull request requirements, including a minimum number of reviewers; once configured, any update to the main branch must go through a PR that meets the required reviewer count, preventing unreviewed changes from being merged.

Why this answer

Azure DevOps branch policies enforce that all changes to the main branch must go through a pull request with required reviewers. This ensures no code can be deployed to production without passing through the defined review process, meeting the security team's requirement.

Exam trap

The trap here is that candidates confuse pipeline-level approvals (like pre-deployment gates) with branch policies, which are the correct mechanism to enforce pull request workflows at the source control level.

How to eliminate wrong answers

Option A is wrong because disabling CI triggers and requiring manual builds does not enforce pull request review; it only prevents automatic builds on push, leaving the deployment path unsecured. Option B is wrong because modifying the service connection to require admin approval controls access to Azure resources but does not enforce a pull request workflow or code review before deployment. Option C is wrong because setting the pipeline to require approval from the security team before running adds a manual gate but does not prevent direct pushes to the main branch or enforce a pull request with reviewers.

Practice this question →

59

MCQmedium

You are reviewing an Azure Policy definition that denies pipeline creation if the pipeline template path is not '/pipeline-templates/my-template.yml'. What does this policy do?

A.Denies pipelines that use an outdated template version.

B.Allows only pipelines that use a specific YAML template.

C.Allows only pipelines in the pipeline-templates folder.

D.Denies any pipeline that does not use a specific YAML template.

AnswerD

This is correct because the policy definition uses a deny effect that triggers when the pipeline's YAML template path does not equal the specified value. As a result, any pipeline creation or update that references a different template or a non-matching path is blocked, effectively forcing all pipelines to use that exact YAML template.

Why this answer

This Azure Policy definition uses a 'deny' effect with a condition that checks whether the pipeline references a specific YAML template. If the pipeline does not reference that template, the policy denies the pipeline creation or update. Option D is correct because the policy explicitly denies any pipeline that does not use the specified YAML template, enforcing compliance by blocking non-compliant pipelines.

Exam trap

The trap here is that candidates often confuse 'deny' with 'audit' or 'allow' effects, or misinterpret the condition as restricting folder paths instead of template references, leading them to select options that describe permissive or location-based policies.

How to eliminate wrong answers

Option A is wrong because the policy does not check template version; it checks for the presence of a specific YAML template reference, not its version. Option B is wrong because the policy uses the 'deny' effect, not 'allow' or 'audit'; it blocks non-compliant pipelines rather than allowing only those that match. Option C is wrong because the policy does not restrict pipelines to a specific folder; it evaluates the YAML template reference in the pipeline definition, not the file path location.

Practice this question →

60

MCQmedium

You are implementing a secrets management strategy for a multi-cloud deployment. You need to securely store and rotate API keys for a third-party service. Which Azure service should you use?

A.Azure Key Vault

B.Microsoft Entra ID

C.Azure App Configuration

D.Azure Storage Blob

AnswerA

Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. It provides centralized secret management, fine-grained access policies, and built-in rotation capabilities, making it the appropriate choice for implementing a secrets management strategy.

Why this answer

Azure Key Vault is the correct service because it is designed specifically for securely storing and managing secrets, including API keys, with built-in support for automatic rotation via integration with Azure Event Grid and Azure Functions. It provides hardware security module (HSM)-backed encryption, access policies, and auditing, making it ideal for multi-cloud secrets management.

Exam trap

The trap here is that candidates often confuse Azure App Configuration's encrypted storage with Key Vault's secrets management, but App Configuration lacks automatic rotation and HSM-backed security, making it unsuitable for API keys.

How to eliminate wrong answers

Option B is wrong because Microsoft Entra ID (formerly Azure AD) is an identity and access management service for authentication and authorization, not a secrets store; it cannot natively store or rotate API keys. Option C is wrong because Azure App Configuration is optimized for managing application configuration settings and feature flags, not secrets; it lacks automatic rotation capabilities and HSM-backed encryption. Option D is wrong because Azure Storage Blob is an unstructured object storage service with no native secrets management features, rotation policies, or access control granularity required for API keys.

Practice this question →

61

MCQeasy

A company uses Azure DevOps and has a security policy that all pipeline runs must use a specific service connection scoped to a resource group. A developer reports that a pipeline fails with the error: 'The service connection does not have permission to access the resource.' What is the most likely cause?

A.The Azure subscription linked to the service connection is disabled.

B.The service connection name is misspelled in the pipeline YAML.

C.The variable group in the library does not include the service connection ID.

D.The service principal used by the service connection does not have the required role assignment on the resource group.

AnswerD

The service connection's service principal lacks a role assignment (such as Contributor) scoped to the target resource group, so Azure RBAC denies access. Granting the required role on that resource group resolves the permission error.

Why this answer

The error 'The service connection does not have permission to access the resource' indicates that the service principal associated with the service connection lacks the necessary Azure RBAC role assignment on the target resource group. In Azure DevOps, a service connection authenticates via a service principal, and that principal must have a role (e.g., Contributor) explicitly assigned at the resource group scope to perform actions like deploying resources. Without this role assignment, the pipeline fails with an access-denied error.

Exam trap

The trap here is that candidates often confuse service connection authentication (which always works if the connection is valid) with authorization (RBAC role assignments), leading them to pick options about disabled subscriptions or misspelled names instead of the missing role assignment.

How to eliminate wrong answers

Option A is wrong because a disabled Azure subscription would cause a different error (e.g., 'Subscription not found' or 'Authorization failed'), not a specific permission-denied message on a resource group. Option B is wrong because a misspelled service connection name in the YAML would result in a 'Service connection not found' error, not a permission error. Option C is wrong because variable groups in the library store variables, not service connection IDs; service connections are referenced by name in the pipeline, and the ID is not required for permission checks.

Practice this question →

62

MCQeasy

You need to ensure that only authorized users can access the Azure DevOps organization. Which identity provider should you configure for single sign-on (SSO)?

A.Microsoft Entra ID

B.Google Workspace

C.Microsoft account (MSA)

D.GitHub ID

AnswerA

Microsoft Entra ID (formerly Azure AD) is the native identity provider for Azure DevOps, enabling enterprise-grade SSO, conditional access, and multi-factor authentication. It is the only supported option for centrally managing user permissions and access control across an Azure DevOps organization, making it the correct choice.

Why this answer

Microsoft Entra ID (formerly Azure AD) is the required identity provider for configuring single sign-on (SSO) for Azure DevOps organizations. Azure DevOps relies on Entra ID to authenticate users and enforce conditional access policies, ensuring only authorized identities from your tenant can sign in. This integration also supports SAML-based SSO and OAuth 2.0 flows, making it the native and only supported IdP for Azure DevOps SSO.

Exam trap

The trap here is that candidates may confuse personal Microsoft accounts (MSA) or external identity providers like Google Workspace as valid SSO options, but Azure DevOps SSO exclusively requires a Microsoft Entra ID tenant for organizational access control.

How to eliminate wrong answers

Option B (Google Workspace) is wrong because Azure DevOps does not support Google Workspace as a direct identity provider for SSO; it can only be used as an external identity source if federated through Microsoft Entra ID. Option C (Microsoft account, MSA) is wrong because MSAs are personal accounts and cannot be used for organizational SSO; Azure DevOps requires a tenant-backed identity for centralized access control and policy enforcement. Option D (GitHub ID) is wrong because GitHub IDs are used for GitHub authentication, not for Azure DevOps; while Azure DevOps and GitHub can be linked, SSO for the Azure DevOps organization itself must be configured via Microsoft Entra ID.

Practice this question →

63

MCQmedium

Your Azure DevOps organization contains multiple teams. You need to ensure that code reviews require approval from a member of the security team before merging to the main branch. What is the best way to implement this?

A.Add a validation step in Azure Pipelines

B.Enable Microsoft Defender for Cloud

C.Deploy Microsoft Sentinel

D.Configure branch policies in Azure Repos

AnswerD

In Azure Repos, branch policies on the main branch can require a minimum number of reviewers and specific approvers for pull requests. Configuring such policies enforces that designated team members must approve changes before merging, directly satisfying the requirement.

Why this answer

Configuring branch policies in Azure Repos (option D) is the correct approach because branch policies allow you to require specific reviewers—such as members of the security team—for pull requests targeting the main branch. This ensures that every merge to main must be approved by the security team. Option A is incorrect: Azure Pipelines is designed for continuous integration and delivery (CI/CD), not for enforcing code review requirements.

Option B is incorrect: Microsoft Defender for Cloud focuses on cloud security posture management and threat protection, not on code review policies. Option C is incorrect: Microsoft Sentinel is a security information and event management (SIEM) tool for security analytics and threat intelligence, not for managing branch-level review policies.

Practice this question →

64

MCQhard

Your organization uses Azure Boards and requires that all changes to work items in the 'Security' area path be audited. Which solution ensures that any modification to a work item triggers an audit event in Microsoft Sentinel?

A.Configure Azure DevOps Audit Streaming to send logs to Microsoft Sentinel

B.Enable Microsoft Purview to scan Azure DevOps and detect changes

C.Export Azure DevOps audit logs to CSV and import to Sentinel daily

D.Create a service hook in Azure DevOps that calls a logic app to create incidents in Sentinel

AnswerA

This is the native Azure DevOps integration that continuously streams audit events (such as project, pipeline, and permission changes) to your Log Analytics workspace for Microsoft Sentinel. It provides real-time, automatic ingestion with no custom code, enabling immediate security monitoring and alerting, which directly satisfies the requirement.

Why this answer

Azure DevOps Audit Streaming is the correct solution because it natively streams audit events (including work item modifications) to Microsoft Sentinel via the Azure Event Hubs or Log Analytics workspace integration. This ensures real-time, continuous auditing without manual intervention, meeting the requirement for all changes in the 'Security' area path to trigger audit events in Sentinel.

Exam trap

The trap here is that candidates may confuse service hooks (which are event-driven but require custom logic) with native audit streaming, or assume that manual CSV exports are sufficient for real-time auditing, missing the requirement for automated, continuous audit event ingestion into Sentinel.

How to eliminate wrong answers

Option B is wrong because Microsoft Purview is a data governance and cataloging service, not an audit log streaming solution; it cannot detect or forward Azure DevOps work item modifications to Sentinel. Option C is wrong because exporting audit logs to CSV and importing them daily introduces latency and manual effort, failing to provide real-time or automated audit event triggering in Sentinel. Option D is wrong because service hooks in Azure DevOps can trigger external actions (e.g., Logic Apps) but do not directly stream audit events to Sentinel; they would require custom development and do not leverage the native audit log pipeline, making them less reliable and scalable than Audit Streaming.

Practice this question →

65

MCQhard

Your organization is adopting GitHub Copilot for developers. Which security measure should you implement to ensure that no proprietary code is inadvertently shared with the AI model?

A.Use a separate network segment for development

B.Configure content exclusions in the GitHub Copilot settings

C.Disable GitHub Copilot for all users

D.Enable audit logging for Copilot usage

AnswerB

By configuring content exclusions, organizations can define specific repositories or files that Copilot will not access or use as context for generating suggestions, thereby preventing sensitive code from being transmitted to GitHub's AI service. This is a targeted control that directly mitigates data exfiltration risks while allowing developers to continue using Copilot for non-excluded code.

Why this answer

GitHub Copilot's content exclusions allow administrators to specify files or repositories that should not be sent to the AI model for code completion suggestions. This prevents proprietary or sensitive code from being transmitted to GitHub's servers, ensuring compliance with security policies. Other options like network segmentation or audit logging do not directly block code from being shared with the AI.

Exam trap

The trap here is that candidates often confuse security controls like network segmentation or audit logging with data loss prevention mechanisms, failing to recognize that content exclusions are the specific Copilot feature designed to prevent code from being sent to the AI model.

How to eliminate wrong answers

Option A is wrong because using a separate network segment for development does not prevent Copilot from sending code to the AI model; it only isolates network traffic, which does not address data exfiltration at the application layer. Option C is wrong because disabling Copilot for all users is an overreaction that eliminates productivity benefits without addressing the need for selective protection; content exclusions provide a targeted solution. Option D is wrong because enabling audit logging for Copilot usage only records events after they occur, it does not prevent proprietary code from being shared with the AI model in the first place.

Practice this question →

66

Multi-Selectmedium

Your organization is adopting GitHub Advanced Security. Which THREE features should you enable to improve security?

Select 3 answers

A.GitHub Pages

B.Branch protection rules

C.Secret scanning

D.Dependabot alerts and security updates

E.Code scanning (CodeQL)

AnswersC, D, E

Secret scanning detects credentials.

Why this answer

Secret scanning (Option C) is a GitHub Advanced Security feature that automatically detects exposed secrets (e.g., API keys, tokens, private keys) in repositories by matching against known patterns and partner-defined signatures. It helps prevent credential leaks from reaching production or being exploited, directly improving the security posture of your codebase.

Exam trap

The trap here is that candidates may confuse standard GitHub features (like branch protection rules) with GitHub Advanced Security features, or assume that any security-related setting (e.g., GitHub Pages with HTTPS) qualifies as an Advanced Security improvement, when only secret scanning, Dependabot alerts/updates, and code scanning (CodeQL) are the three core Advanced Security capabilities tested on the AZ-400.

Practice this question →

67

MCQmedium

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?

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

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

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

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.

AnswerD

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.

Why this answer

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.

Exam trap

The trap here is that candidates confuse process-based controls (templates, approvals, branch policies) with runtime enforcement, overlooking that only a decorator can programmatically validate and block unauthorized service connections at execution time.

How to eliminate wrong answers

Option A is wrong because a required template is a guideline that developers can bypass or modify, not an enforceable control. Option B is wrong because a manual approval gate only pauses the pipeline for human approval; it does not validate which service connection was used in the tasks. Option C is wrong because a branch policy on the main branch ensures code quality before merging but does not inspect or restrict the service connection used during pipeline execution.

Practice this question →

68

MCQmedium

Your company uses Azure DevOps and must enforce that all pipelines use approved agent pools. The security team wants to prevent the use of the default agent pool. What should you do?

A.Use pipeline settings to require authorization for the default pool

B.Set agent pool permissions to deny the default pool for all projects

C.Remove the default agent pool from the organization

D.Disable the default agent pool in project settings

AnswerB

Setting agent pool permissions to deny the 'Use' permission for the default pool across all projects explicitly prevents any pipeline in those projects from queuing jobs on that pool, making it the correct way to enforce the restriction.

Why this answer

Setting agent pool permissions to deny the default pool for all projects explicitly blocks its use across the organization. This enforces the security policy by preventing any pipeline from selecting the default agent pool, while still allowing administrators to manage the pool if needed. In Azure DevOps, agent pool permissions control which users, teams, or projects can use a pool, and setting 'Deny' overrides any inherited 'Allow' permissions.

Exam trap

The trap here is that candidates often confuse 'requiring authorization' (which still allows use after approval) with 'denying permissions' (which blocks use entirely), or they mistakenly think the default agent pool can be removed or disabled like a custom pool.

How to eliminate wrong answers

Option A is wrong because requiring authorization for the default pool only adds an approval step before pipelines can use it, but does not prevent its use entirely—pipelines could still be approved to run on the default pool, violating the security policy. Option C is wrong because removing the default agent pool from the organization is not possible; Azure DevOps requires at least one agent pool, and the default pool is a system pool that cannot be deleted. Option D is wrong because disabling the default pool in project settings is not a valid action; Azure DevOps does not provide a 'disable' toggle for agent pools at the project level—you can only manage permissions or remove agents from the pool.

Practice this question →

69

MCQmedium

A company's Azure DevOps project uses a custom agent pool with self-hosted agents. The security team discovers that pipeline runs can access secrets stored in Azure Key Vault, but the team wants to ensure that secrets are only accessible to approved pipelines. Which configuration should the team implement?

A.Use a library variable group linked to Key Vault and configure pipeline permissions with branch control.

B.Store secrets directly in pipeline variables and use 'Make secrets available to all pipelines' setting.

C.Assign pipeline-level permissions to the Key Vault using Azure RBAC.

D.Limit the number of agents in the custom agent pool.

AnswerA

A library variable group linked to Azure Key Vault centralizes secret storage, and configuring pipeline permissions with branch controls and approval checks ensures only approved pipelines on specific branches can retrieve those secrets. This provides granular, auditable, and policy-driven secret governance, making it the correct security approach.

Why this answer

The correct configuration is to create a library variable group linked to Azure Key Vault and then use pipeline permissions to grant access only to approved pipelines. This restricts secret access at the pipeline level. Branch-specific restrictions are not available on variable groups; to limit access by branch, the pipeline YAML must conditionally include the variable group (e.g., using an `if` expression based on the source branch) or separate pipelines must be used.

Exam trap

The real trap is confusing Azure RBAC on the Key Vault with Azure DevOps pipeline permissions. RBAC controls access to the key vault itself, while pipeline permissions control which pipelines can read the variable group. Note that variable groups do not support approval checks or branch filters; those are features of other protected resources.

How to eliminate wrong answers

Option B is wrong because storing secrets directly in pipeline variables and enabling 'Make secrets available to all pipelines' would expose secrets to every pipeline in the project, violating the requirement to restrict access to approved pipelines only. Option C is wrong because assigning pipeline-level permissions to Key Vault using Azure RBAC is not a supported configuration; Key Vault access is managed via access policies or RBAC at the vault level for service principals or managed identities, not at the pipeline level. Option D is wrong because limiting the number of agents in the custom agent pool does not control which pipelines can access secrets; it only affects concurrency and resource availability, not secret authorization.

Practice this question →

70

Multi-Selectmedium

Which TWO actions should you take to ensure that only approved pipelines can deploy to production in Azure DevOps? (Choose two.)

Select 2 answers

A.Disable parallel jobs for the project.

B.Configure a pipeline approval gate on the production environment.

C.Set branch policies to require a pull request before merging to the main branch.

D.Limit the number of pipelines that can deploy from the main branch.

E.Use a single agent pool for all pipelines.

AnswersB, C

Configuring an approval gate on the production environment adds a pre-deployment check that requires designated approvers to manually review and approve the deployment before it proceeds. This directly satisfies the need for an explicit approval process, and in Azure Pipelines it can be set as an environment check.

Why this answer

Configuring a pipeline approval gate on the production environment ensures that every deployment to production requires explicit approval from designated reviewers, preventing unauthorized or unapproved pipelines from deploying. Option C is correct because setting branch policies to require a pull request before merging to the main branch enforces code review and validation, ensuring that only approved changes reach the main branch, which is typically the source for production deployments.

Exam trap

The trap here is that candidates often confuse branch policies (which control code merging) with deployment controls (which control release execution), leading them to incorrectly select options like limiting pipeline counts or disabling parallel jobs instead of recognizing that approval gates and branch policies are the two distinct mechanisms for securing production deployments.

Practice this question →

71

MCQhard

Your organization uses GitHub Actions and needs to enforce that only approved actions from the GitHub Marketplace can be used in workflows. Developers have been using custom actions from third-party repositories. What is the most effective way to control which actions are allowed?

A.Create a manual approval process for each new action.

B.Set the organization to disallow all third-party actions.

C.Configure the organization to allow only actions created by GitHub.

D.Use the 'Allow actions created by GitHub and verified partners' policy and add specific actions to the allow list.

AnswerD

A repository or organisation action policy restricts execution to GitHub-authored and verified-creator actions, then an allow list permits specific third-party actions. This directly blocks unapproved marketplace actions while retaining sanctioned ones, satisfying the requirement to control which actions workflows may use.

Why this answer

The 'Allow actions created by GitHub and verified partners' policy, combined with an explicit allow list, provides granular control over which actions can run in workflows. This approach blocks unverified third-party actions by default while permitting specific approved actions from the Marketplace, directly addressing the need to enforce only approved actions without unnecessarily restricting all third-party actions.

Exam trap

The trap here is that candidates often choose Option B (disallow all third-party actions) thinking it is the most secure, but the question specifically requires allowing approved actions from the Marketplace, which includes verified partners, making the granular allow-list approach in Option D the correct balance of security and flexibility.

How to eliminate wrong answers

Option A is wrong because a manual approval process for each new action is not a native GitHub Actions policy; it would require custom scripting or external tooling, is not scalable, and does not prevent unapproved actions from being used in workflows until after the fact. Option B is wrong because disallowing all third-party actions would also block verified partners and any custom actions that might be necessary, which is overly restrictive and not aligned with the requirement to allow approved actions from the Marketplace. Option C is wrong because allowing only actions created by GitHub excludes verified partner actions and any custom actions that could be safely allowed, which is too restrictive and does not match the need to control which actions are allowed while still permitting some third-party actions.

Practice this question →

72

MCQhard

Your company uses GitHub Advanced Security. You need to ensure that all code in the main branch is free of high-severity secrets before deployment. What is the most efficient way to enforce this?

A.Require manual review of all pull requests for secrets

B.Enable secret scanning push protection

C.Configure Dependabot to flag secrets in dependencies

D.Enable code scanning alerts for secrets

AnswerB

Secret scanning push protection uses a pre-receive hook to detect supported secret patterns (e.g., GitHub tokens, AWS access keys) in commits before they are pushed, blocking the push and preventing the secret from ever reaching the remote repository. This makes it an effective, automated control for keeping secrets out of git history—even before a PR is opened.

Why this answer

Secret scanning push protection (option B) is the most efficient way to enforce that no high-severity secrets reach the main branch because it blocks the push at the Git level before the commit is accepted. This prevents secrets from ever entering the repository, eliminating the need for post-hoc detection or manual review. Other options either rely on reactive detection or do not address secrets in code.

Exam trap

The trap here is that candidates may confuse 'secret scanning alerts' (which detect secrets after they are committed) with 'push protection' (which blocks secrets before they are committed), leading them to choose option D instead of B.

How to eliminate wrong answers

Option A is wrong because requiring manual review of all pull requests for secrets is inefficient, error-prone, and does not scale; it relies on human vigilance rather than automated enforcement. Option C is wrong because Dependabot is designed to manage dependency vulnerabilities, not to detect or block secrets in source code; it has no capability to scan for secrets. Option D is wrong because code scanning alerts for secrets are reactive — they detect secrets after they have already been committed, which does not prevent them from reaching the main branch.

Practice this question →

73

MCQhard

A company uses Microsoft Defender for Cloud to assess the security posture of Azure Pipelines agents. They notice that self-hosted agents are flagged as having high-severity vulnerabilities. What is the recommended action to remediate these findings while minimizing downtime?

A.Disable Microsoft Defender for Cloud for the agent pool.

B.Uninstall the self-hosted agents and use only Microsoft-hosted agents.

C.Apply the security updates recommended by Microsoft Defender for Cloud to the agent VMs.

D.Replace all self-hosted agents with Microsoft-hosted agents.

AnswerC

Applying the security updates recommended by Microsoft Defender for Cloud directly remediates the identified vulnerabilities on the agent VMs by patching the operating system and installed software. This eliminates known exploit paths, reduces the attack surface, and aligns the environment with security best practices.

Why this answer

Microsoft Defender for Cloud identifies vulnerabilities on the VMs hosting self-hosted Azure Pipelines agents and provides specific security update recommendations. Applying these updates directly remediates the high-severity findings without requiring agent replacement or disabling security monitoring, thus minimizing downtime by patching in-place.

Exam trap

The trap here is that candidates may assume replacing agents with Microsoft-hosted agents is the only secure option, but the question specifically asks for remediation while minimizing downtime, and patching the existing VMs is the least disruptive and most direct action.

How to eliminate wrong answers

Option A is wrong because disabling Microsoft Defender for Cloud for the agent pool would stop vulnerability assessments and security monitoring, leaving the agents exposed and violating security compliance requirements. Option B is wrong because uninstalling self-hosted agents and using only Microsoft-hosted agents is an unnecessary and disruptive migration that does not address the root cause of the vulnerabilities on the existing infrastructure. Option D is wrong because replacing all self-hosted agents with Microsoft-hosted agents is an overreaction that ignores the ability to patch the underlying VMs, and it introduces migration overhead and potential downtime that can be avoided by applying the recommended updates.

Practice this question →

74

MCQeasy

Your team uses Azure Pipelines to deploy to multiple environments. The compliance team requires that all deployments to the production environment are approved by a security officer. Which feature should you use?

A.Configure approvals and checks on the production environment in Azure Pipelines.

B.Create a branch policy that requires approval for pull requests.

C.Use a service connection with a managed identity that requires approval.

D.Store the production credentials in a variable group with approval required.

AnswerA

Approvals and checks in Azure Pipelines environments allow you to require manual sign-off and/or automated gates (e.g., Azure Monitor alerts) before any deployment job targeting that environment runs. This is the native mechanism to gate deployments to production, providing control and auditability without affecting source control or artifact release processes.

Why this answer

Approvals and checks in Azure Pipelines allow you to require manual approval before a deployment to a specific environment, such as production. By configuring an approval on the production environment, you ensure that a designated security officer must approve the deployment before it proceeds, meeting the compliance team's requirement.

Exam trap

The trap here is confusing environment-level approvals (which gate the deployment itself) with branch policies or secret management features, which address different compliance concerns like code review or credential access.

How to eliminate wrong answers

Option B is wrong because a branch policy that requires approval for pull requests controls code merging into a branch, not deployment approvals to an environment. Option C is wrong because a service connection with a managed identity handles authentication but does not enforce manual approval gates for deployments. Option D is wrong because storing production credentials in a variable group with approval required controls access to secrets, not the deployment approval process itself.

Practice this question →

75

Multi-Selectmedium

Which THREE measures should be implemented to protect secrets in Azure Pipelines? (Choose three.)

Select 3 answers

A.Restrict which pipelines can access the variable group

B.Log secret values to pipeline console for debugging

C.Use variable groups with locked variables

D.Link Azure Key Vault as a variable group

E.Store secrets in code as environment variables

AnswersA, C, D

Scoping access reduces exposure.

Why this answer

Restricting which pipelines can access a variable group ensures that only authorized pipelines can use secrets stored in that group, preventing unauthorized access or accidental exposure. This is a key security measure in Azure Pipelines to enforce the principle of least privilege.

Exam trap

The trap here is that candidates may think logging secrets is acceptable for debugging or that storing secrets in environment variables is safe, but both practices directly contradict Azure security best practices and can lead to credential leakage.

Practice this question →

Page 1 of 2 · 96 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Develop a security and compliance plan questions.

Start 20-question session