Courseiva

CCNA Security Compliance Plan Questions

75 of 123 questions · Page 1/2 · Security Compliance Plan topic · Answers revealed

Practice these questionsExam hubAll 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

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 →
4
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 →
5
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 →
6
MCQmedium

Refer to the exhibit. Your organization has configured an Azure DevOps pipeline security setting that enforces a required template for all pipelines deploying to production and staging. The required template 'security-validation.yml' runs a series of security scans and compliance checks. A developer creates a new pipeline that deploys to a test environment, but the pipeline does not reference the required template. What will happen?

A.The pipeline will run normally because the required template enforcement only applies to production and staging environments.
B.The pipeline will run but the security scans will be automatically injected.
C.The pipeline will fail because it does not reference the required template.
D.The pipeline will prompt the developer to add the required template before running.
AnswerC

Incorrect. The pipeline will not fail because the required template enforcement is restricted to production and staging environment scopes only. Since this pipeline targets a test environment, it is outside the enforcement scope, so omitting the required template does not trigger a policy failure and the pipeline executes normally.

Why this answer

The Azure DevOps 'Required template' security setting is configured at the project or organization level and applies to all YAML pipelines, regardless of the deployment target environment. There is no native option to enforce it only for specific environments like production or staging. Therefore, a new pipeline deploying to test without referencing the required template would also fail.

Exam trap

The trap incorrectly claims that required template enforcement can be scoped to environments. In reality, the enforcement is global; once enabled, all pipelines must include the template.

How to eliminate wrong answers

Option B is wrong because Azure DevOps does not automatically inject security scans into pipelines that do not reference the required template; the enforcement is based on environment targeting, not automatic injection. Option C is wrong because the pipeline will not fail—the required template policy only blocks pipelines that deploy to production or staging without the template, not those targeting test environments. Option D is wrong because Azure DevOps does not prompt developers to add the required template; it either enforces the requirement at queue time (failing the run) or allows the run, depending on the environment scope.

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 steps to the numbered slots on the right, or tap a step then tap a slot.

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 team uses GitHub for source control and GitHub Actions for CI/CD. Security policy requires that all code changes must be signed by a verified contributor using a GPG key. You need to enforce this requirement at the organization level. However, some developers use SSH keys for authentication, and you want to allow them to continue. What should you do?

A.In GitHub organization settings, enable 'Require signed commits' and 'Require SSH keys for authentication'.
B.Enforce S/MIME signing via Microsoft Entra ID Conditional Access.
C.Add a branch protection rule for the default branch requiring signed commits.
D.Configure a GitHub Action that rejects unsigned commits in CI.
AnswerC

A branch protection rule on the default branch can require signed commits, enforcing that all commits pushed to that branch must be signed with a verified GPG key. This is a common and effective way to enforce the policy.

Why this answer

Adding a branch protection rule for the default branch that requires signed commits enforces that all commits to that branch must be signed with a verified GPG key. While this does not apply to the entire organization, it is the standard method to enforce signing on the most critical branch. Option A is incorrect because GitHub does not have an organization setting to 'Require SSH keys for authentication'; the setting mentioned is not valid.

Option B is incorrect because S/MIME signing via Microsoft Entra ID is not a native GitHub enforcement for commits. Option D is incorrect because a GitHub Action would only reject unsigned commits after they are pushed, not prevent them from being pushed.

Exam trap

The trap is that option A sounds plausible because it mentions both signed commits and SSH keys, but GitHub does not have a setting to 'require' SSH keys. The actual enforcement for signed commits is through the organization's 'Require signed commits' setting, which does not involve SSH key requirements.

Practice this question →
12
Multi-Selecthard

Your organization uses Azure Key Vault to store secrets and certificates used in Azure Pipelines. You need to implement a security and compliance plan that ensures secrets are rotated automatically and access is audited. Which THREE actions should you take?

Select 3 answers
A.Enable soft-delete and purge protection on the Key Vault.
B.Use a resource lock on the Key Vault to prevent deletion.
C.Use a Key Vault access policy to grant developers full access.
D.Use Managed Identity to authenticate Azure Pipelines to Key Vault.
E.Configure Key Vault certificate auto-rotation with a specified lifetime.
AnswersA, D, E

Soft-delete and purge protection are critical for compliance to recover deleted secrets and prevent permanent loss.

Why this answer

Enabling soft-delete and purge protection ensures deleted secrets and certificates can be recovered and permanent deletion is blocked, which is important for compliance and recovery. Using a managed identity for Azure Pipelines removes the need to store and rotate credentials, and each access is tied to a known identity, enabling access auditing. Configuring certificate auto-rotation with a specified lifetime ensures secrets are rotated automatically.

Together, these actions address recovery, secure access, and automatic rotation as required.

Exam trap

The trap here is that candidates often confuse resource locks (Option B) with soft-delete/purge protection, thinking that a resource lock alone satisfies compliance requirements, but it does not provide the recovery and audit capabilities required for secret rotation and access auditing.

Practice this question →
13
MCQmedium

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

A.Code scanning alerts in GitHub
B.Azure Policy for Pipelines
C.Branch protection rule with required status check
D.Pipeline security gate
AnswerC

In Azure Repos, branch protection rules (often called branch policies) allow you to require that a specific status check succeeds before a pull request can be merged. You can create a pipeline that runs your security scan on PRs and publishes a status named 'security-scan,' then configure the branch policy to require that check. This creates a hard enforcement gate: merges are blocked until the status check passes, ensuring only scanned code is merged into the protected branch. This is the correct approach for integrating a security scan into the merge workflow.

Why this answer

Branch protection rules in Azure Repos or GitHub can require a status check from a build pipeline. By configuring a required status check that runs a security scan, the pull request cannot be merged if the scan fails. Option A (Code scanning alerts in GitHub) is for identifying vulnerabilities in code, not blocking merges based on pipeline results.

Option B (Azure Policy for Pipelines) enforces governance on Azure resources, not pipeline security scans. Option D (Pipeline security gate) is not a feature in Azure DevOps.

Practice this question →
14
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

Sentinel playbooks (based on Azure Logic Apps) can automate responses to alerts, including calling the Azure DevOps REST API to disable a service connection. Option A is incorrect because an analytics rule with automated response can send notifications but cannot directly interact with Azure DevOps to disable a connection. Option B is incorrect because Azure DevOps service hooks trigger on pipeline events, not on Sentinel alerts.

Option C is incorrect because Azure Policy can prevent changes to service connections but cannot disable an existing active service connection.

Practice this question →
15
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 →
16
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 →
17
MCQeasy

Your organization uses Microsoft Defender for Cloud to monitor Azure resources. The compliance team needs to ensure that all Azure DevOps projects have their pipelines scanned for security issues before deployment. Which integration should you use?

A.Configure branch policies in Azure Repos to require a security scan.
B.Enable GitHub Advanced Security for Azure DevOps in Microsoft Defender for Cloud.
C.Configure deployment gates in Azure Pipelines to require a security scan.
D.Use Azure Policy to enforce scanning on Azure DevOps pipelines.
AnswerB

This integration provides code scanning and secret scanning for Azure DevOps pipelines and repos.

Why this answer

Enabling GitHub Advanced Security for Azure DevOps in Microsoft Defender for Cloud allows Defender for Cloud to ingest security alerts from Azure DevOps repositories and pipelines, including secret scanning, code scanning, and dependency scanning. This integration ensures that all Azure DevOps projects are monitored for security issues before deployment, meeting the compliance team's requirement for centralized visibility and enforcement.

Exam trap

The trap here is that candidates often confuse Azure Policy (which enforces compliance on Azure resources) with the ability to enforce pipeline scanning, but Azure Policy cannot directly control Azure DevOps pipeline behavior, whereas the Defender for Cloud integration with GitHub Advanced Security provides the required centralized monitoring and enforcement.

How to eliminate wrong answers

Option A is wrong because branch policies in Azure Repos can require a security scan to be run on pull requests, but they do not integrate with Microsoft Defender for Cloud for centralized compliance monitoring and reporting. Option C is wrong because deployment gates in Azure Pipelines can invoke security checks (e.g., via REST APIs or Azure Functions) but are not a native integration with Microsoft Defender for Cloud; they require custom logic and do not provide the unified security posture management that Defender for Cloud offers. Option D is wrong because Azure Policy can enforce resource compliance for Azure resources (e.g., VMs, storage accounts) but cannot directly enforce scanning on Azure DevOps pipelines; Azure Policy does not have a built-in effect to control pipeline behavior or integrate with Azure Repos.

Practice this question →
18
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 →
19
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 →
20
MCQhard

You are deploying a web app to Azure App Service using Azure Pipelines. The security team requires that all secrets are stored in Azure Key Vault and retrieved at deployment time. What is the best approach?

A.Add an Azure Key Vault task in the pipeline to download secrets
B.Store secrets in pipeline variables and mark them as secret
C.Use Variable Groups linked to Key Vault
D.Reference Key Vault secrets directly in App Service configuration
AnswerA

This retrieves secrets directly from Key Vault during the pipeline run.

Why this answer

The Azure Key Vault task in Azure Pipelines directly downloads secrets from Key Vault as pipeline variables at deployment time, ensuring secrets are never stored in the pipeline definition or source control. This meets the security team's requirement for retrieving secrets at deployment time without exposing them in logs or build artifacts.

Exam trap

The trap is that candidates may mistakenly believe that Variable Groups linked to Key Vault (Option C) do not retrieve secrets at deployment time, but they do; however, the Azure Key Vault task is the best approach because it provides explicit control over secret retrieval timing and minimizes exposure as pipeline variables.

How to eliminate wrong answers

Option B is wrong because storing secrets in pipeline variables, even if marked as secret, still stores them within the Azure DevOps project and can be exposed in logs or exported by users with edit permissions, violating the requirement to use Key Vault. Option C is wrong because Variable Groups linked to Key Vault retrieve secrets at pipeline runtime but require the variable group to be explicitly linked and authorized, which adds complexity and does not enforce retrieval at deployment time as directly as the Key Vault task. Option D is wrong because referencing Key Vault secrets directly in App Service configuration (e.g., using @Microsoft.KeyVault references) retrieves secrets at runtime in the App Service, not at deployment time in the pipeline, failing the requirement for retrieval at deployment time.

Practice this question →
21
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

Secret variables are masked in logs and output.

Why this answer

To protect secrets like API keys and passwords in Azure Pipelines, you should implement three key measures. First, mark variables as 'Secret' in pipeline YAML or UI definitions (Option B). This prevents the secret from being displayed in logs or output.

Second, use service connections with managed identity instead of personal access tokens (Option D). Managed identities eliminate the need to store credentials and reduce secret exposure. Third, store secrets in Azure Key Vault and reference them via a Key Vault task (Option E).

This centralizes secret management and allows fine-grained access control. Option A is incorrect because storing secrets as plain text in a Git repo, even with restricted access, is insecure—secrets should never be committed to source control. Option C is incorrect because environment variables are not encrypted by default and can be exposed in logs or to other pipeline tasks, making them unsafe for secret passing.

Practice this question →
22
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 →
23
MCQmedium

Your team uses Azure DevOps and wants to enforce branch protection policies for all repositories in a GitHub Advanced Security-enabled organization. Which approach should you use to ensure that pull requests require a successful status check from a required workflow?

A.Use GitHub Actions secrets to store the required status check name.
B.Define a repository rule in GitHub that requires a successful status check from a required workflow.
C.Create a branch protection rule in each repository's settings.
D.Configure branch policies in Azure DevOps project settings.
AnswerB

Repository rules (the modern replacement for individual protected branch settings) let you centrally define branch protection policies for all repositories in an organization. By creating a rule that requires a successful status check named after a required workflow, you enforce that check across every matching branch and repository, making it the correct organization-wide solution for this requirement.

Why this answer

GitHub repository rules (also known as repository rulesets) allow organizations to centrally enforce policies like required status checks across multiple repositories. To require a successful status check from a specific workflow on all pull requests, create an organization-level repository ruleset that includes the 'Require status checks to pass' rule and specify the workflow's check name. This applies to all selected repositories without per-repository configuration.

GitHub Advanced Security is not required for this feature; it is a separate security add-on.

Exam trap

Candidates may confuse Azure DevOps branch policies (which apply to Azure Repos) with GitHub repository rules. Option D is incorrect because Azure DevOps branch policies do not apply to GitHub repositories, even if the organization uses Azure DevOps.

How to eliminate wrong answers

Option A is wrong because GitHub Actions secrets are used to store sensitive data like tokens or passwords, not to enforce branch protection policies or required status checks. Option C is wrong because creating a branch protection rule in each repository's settings would require manual configuration per repository, which is not scalable for enforcing policies across all repositories in an organization. Option D is wrong because Azure DevOps project settings manage policies for Azure Repos, not for GitHub repositories; the question specifies a GitHub Advanced Security-enabled organization, so Azure DevOps policies are irrelevant.

Practice this question →
24
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 →
25
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 variables are masked in logs.

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 →
26
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

This follows least privilege by granting only necessary permissions.

Why this answer

Azure DevOps security groups allow administrators to assign specific permissions to groups rather than individuals, enabling granular control over who can perform actions like editing work items or managing pipelines. This directly supports the principle of least privilege by ensuring users have only the permissions necessary for their role. Option D is correct because restricting agent pool creation to a small admin team prevents unauthorized users from deploying agents that could execute arbitrary code or access sensitive resources, which is a common attack vector in CI/CD environments.

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 →
27
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

For ensuring Azure Pipelines artifacts are scanned for vulnerabilities before production deployment, the correct actions are A and C. Option A: Running dependency scanning on the artifact manifest (e.g., package.json, pom.xml) identifies known vulnerabilities in open-source dependencies. Option C: Using Microsoft Defender for Cloud to scan artifacts (such as container images) during the pipeline provides comprehensive vulnerability detection.

Option B is incorrect because signing artifacts with a code signing certificate ensures integrity and authenticity, not vulnerability scanning. Option D is incorrect because scanning Infrastructure as Code (IaC) templates addresses configuration security, not artifact vulnerabilities. Option E is incorrect because static code analysis examines source code for coding flaws, not dependencies or artifacts.

Practice this question →
28
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 →
29
MCQhard

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

A.Require pull request reviews before merging
B.Require status checks to pass before merging
C.Dismiss stale pull request approvals
D.Require a minimum number of reviewers
AnswerD

This enforces at least two reviewers from the security team.

Why this answer

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

Exam trap

The trap here is that candidates often confuse 'Require pull request reviews before merging' (which only requires at least one review) with the specific 'Require a minimum number of reviewers' rule, failing to recognize that the question explicitly demands a minimum of two reviewers from a specific team.

How to eliminate wrong answers

Option A is wrong because 'Require pull request reviews before merging' only mandates that at least one review is submitted, but it does not enforce a specific number of reviewers or restrict who can approve. Option B is wrong because 'Require status checks to pass before merging' is used to enforce CI/CD pipeline checks (e.g., tests, builds) and does not control human review requirements. Option C is wrong because 'Dismiss stale pull request approvals' automatically invalidates approvals after new commits, but it does not set a minimum number of reviewers or enforce security team involvement.

Practice this question →
30
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 enforce a formal approval process before deployment, providing the required change management and approval evidence for SOC 2 audits. Option A is incorrect because branch policies control code changes, not deployments. Option B is incorrect because pipeline retention policies only manage artifact storage, not approval process.

Option C is incorrect because audit logging records events but does not enforce an approval process.

Practice this question →
31
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 →
32
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 →
33
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 →
34
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 →
35
Multi-Selectmedium

Your organization uses Azure DevOps and Azure Policy to enforce compliance. You need to ensure that all Azure resources deployed by Azure DevOps pipelines have specific tags (e.g., CostCenter and Environment) applied. Which TWO approaches can achieve this? (Choose TWO.)

Select 2 answers
A.Configure the service connection to only allow deployments with tags.
B.Create an Azure Policy with the 'audit' effect to report non-compliant resources.
C.Create an Azure Policy with the 'deny' effect that requires the tags to be present at resource creation.
D.Add a pipeline task after resource creation that applies the required tags using Azure CLI or PowerShell.
E.Configure a branch policy on the main branch to require tag verification in pull requests.
AnswersC, D

Deny policy blocks deployment of non-compliant resources.

Why this answer

An Azure Policy with the 'deny' effect prevents the creation of any resource that does not include the required tags (e.g., CostCenter and Environment). This enforces compliance at the moment of deployment, blocking non-compliant resources from being provisioned by Azure DevOps pipelines. Option D is correct because adding a pipeline task (using Azure CLI or PowerShell) after resource creation programmatically applies the required tags, ensuring resources are tagged even if the initial deployment omitted them.

Exam trap

The trap here is that candidates often confuse Azure Policy effects (audit vs. deny) and overlook that a post-deployment task can also enforce tagging, leading them to select only the deny policy or incorrectly choose audit as a compliance enforcement mechanism.

Practice this question →
36
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 →
37
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 →
38
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 →
39
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 →
40
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 →
41
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 →
42
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 →
43
MCQhard

Refer to the exhibit. You have configured a Conditional Access policy in Microsoft Entra ID to require MFA for Azure DevOps. However, users report that they can still access Azure DevOps without MFA when using a PAT for authentication. What is the most likely reason?

A.The policy should include 'Require device to be marked as compliant'.
B.PATs are not subject to Conditional Access policies because they use legacy authentication.
C.The policy should be scoped to 'All cloud apps' instead of just Azure DevOps.
D.The Conditional Access policy is not enabled.
AnswerB

PATs are considered legacy authentication and do not satisfy the MFA requirement; they are not evaluated by Conditional Access.

Why this answer

B is correct because Personal Access Tokens (PATs) in Azure DevOps are considered legacy authentication tokens. Conditional Access policies in Microsoft Entra ID do not evaluate requests made using legacy authentication protocols, including PATs, OAuth device code flow, or IMAP/POP. Therefore, even if a Conditional Access policy requires MFA for Azure DevOps, users authenticating with a PAT bypass the policy entirely.

Exam trap

The trap here is that candidates may assume Conditional Access policies apply to all authentication methods equally, not realizing that legacy authentication protocols like PATs, IMAP, and POP are explicitly excluded from policy evaluation unless legacy authentication is blocked at the tenant level.

How to eliminate wrong answers

Option A is wrong because requiring a device to be marked as compliant is a separate grant control that does not address the fundamental issue of PATs bypassing Conditional Access; the policy already requires MFA but is not enforced for PAT-based requests. Option C is wrong because scoping the policy to 'All cloud apps' would not change the behavior—PATs are still legacy authentication and would continue to bypass Conditional Access regardless of the app scope. Option D is wrong because the question states the policy is configured, and if it were not enabled, users would not be prompted for MFA at all, but the specific report is that PATs allow access without MFA, which points to the legacy authentication bypass, not the policy being disabled.

Practice this question →
44
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 →
45
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 →
46
MCQhard

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

A.Set the repository to 'Require pull request reviews before merging' and rely on reviewers to check commit signatures.
B.Ask developers to configure GPG keys and sign commits manually.
C.Enable 'Require signed commits' in the branch protection rules for the default branch.
D.Use a GitHub Action that fails if commits are unsigned.
AnswerC

Enabling 'Require signed commits' in branch protection rules for the default branch enforces at the server level that every commit pushed to that branch must have a valid, verified signature. If a commit is unsigned or the signature cannot be verified, the push is rejected before the branch is updated. This is the correct, enforceable technical control.

Why this answer

GitHub allows repository administrators to enable 'Require signed commits' in branch protection rules. Option A is incorrect because it is not enforceable; commits can be unsigned. Option B is incorrect because it only encourages, not enforces.

Option D is incorrect because it does not enforce signing.

Practice this question →
47
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 →
48
MCQhard

A financial services company uses Azure DevOps and requires that all secrets (e.g., API keys, connection strings) be stored in Azure Key Vault. They have a pipeline that runs automated tests and deploys to staging. The pipeline uses a variable group linked to Key Vault to retrieve secrets. Recently, the pipeline failed with the error: 'Secret 'DbPassword' not found in Key Vault 'kv-prod'. Ensure the secret exists and the service principal has List permission.' The secret exists in the vault. What is the most likely cause?

A.The variable group is linked to the wrong Key Vault instance.
B.The variable name in the variable group does not exactly match the secret name in Key Vault (case-sensitive).
C.The service principal does not have Get permission on the secret.
D.The Key Vault is in a different Azure region than the Azure DevOps organization.
AnswerB

Azure DevOps maps variable names to secret names, and the match is case-sensitive.

Why this answer

Variable groups linked to Azure Key Vault in Azure DevOps require an exact case-sensitive match between the variable name in the variable group and the secret name in Key Vault. Even though the secret 'DbPassword' exists in the vault, if the variable group defines the variable as 'dbpassword' or 'DBPassword', the lookup will fail with the 'not found' error. The error message explicitly states the secret was not found, which is the typical symptom of a case mismatch, not a permissions or connectivity issue.

Exam trap

The trap here is that candidates assume the error 'secret not found' always means the secret is missing or permissions are wrong, but Azure DevOps specifically tests the case-sensitive mapping between variable group variable names and Key Vault secret names, which is a subtle but critical detail.

How to eliminate wrong answers

Option A is wrong because the error message specifically names Key Vault 'kv-prod', indicating the pipeline is targeting that vault; if the variable group were linked to a different vault, the error would reference that other vault's name. Option C is wrong because the error message mentions 'List permission', not 'Get permission'; the service principal must have both Get and List permissions on secrets, but the error explicitly says 'List permission' is required, and the secret exists, so the issue is not a missing Get permission. Option D is wrong because Azure Key Vault and Azure DevOps can operate across different Azure regions without any impact on secret retrieval; region mismatch does not cause 'secret not found' errors.

Practice this question →
49
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 →
50
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 →
51
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 →
52
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

This blocks PRs with high-severity code vulnerabilities.

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 →
53
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 →
54
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 →
55
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 like '##vso[task.setvariable]' can mask output.

Why this answer

Azure DevOps provides a logging command, `##vso[task.setvariable variable=mySecret;isSecret=true]value`, which masks the variable's value in pipeline logs. This ensures that even if a script echoes the secret, it is replaced with asterisks, preventing accidental exposure during execution.

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 →
56
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

Enabling Azure DevOps audit logging captures an immutable, timestamped record of pipeline and policy changes, which is essential evidence for compliance audits, enables detection of unauthorized modifications, and supports security investigations.

Why this answer

Azure DevOps audit logging captures a detailed, immutable record of changes to pipelines, policies, and other critical resources, which is essential for demonstrating compliance with frameworks like PCI DSS that require evidence of who made what change and when. Audit logs can be exported to SIEM tools or retained for forensic analysis, satisfying the 'audit trail' requirement without manual intervention. Additionally, using branch policies enforces mandatory code reviews and approvals for changes, ensuring that all modifications go through a controlled, auditable process.

Together, these practices provide both the immutable audit trail and the controlled change management required for regulatory compliance.

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 →
57
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 →
58
MCQmedium

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

A.Assign secret scanning alerts to the security team using the 'Assign to' feature in the alerts view.
B.Set up a webhook to send secret scanning alerts to a security team's email.
C.Disable secret scanning on repositories that do not contain secrets.
D.Configure secret scanning to automatically close alerts after 30 days.
AnswerA

Assignment ensures ownership and tracking of triage.

Why this answer

GitHub secret scanning allows you to assign alerts to specific team members using the 'Assign to' feature in the alerts view. This ensures that alerts are explicitly owned and triaged within the 30-day requirement. Option B is incorrect because webhooks merely send notifications; they do not guarantee that someone will review and triage the alert.

Option C is incorrect because disabling secret scanning on any repository would violate the requirement to scan all code pushed to main branch. Option D is incorrect because automatically closing alerts after 30 days could hide legitimate secrets that require investigation, which fails the security compliance goal.

Practice this question →
59
MCQhard

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

A.Azure Policy for Repos
B.Credential Scanner task in pipeline
C.Dependency Scanning
D.Secret Scanning
AnswerD

Secret Scanning is a GitHub Advanced Security feature, not a built-in Azure DevOps feature; the correct equivalent in Azure DevOps is the Credential Scanner task.

Why this answer

Azure DevOps Secret Scanning is the built-in feature that automatically detects secrets in Azure Repos and can block pull requests when secrets are found. While a Credential Scanner task can also be added to a pipeline, Secret Scanning is the native feature designed for this purpose and is the correct answer. Options A and C are unrelated, and B is a pipeline task, not the primary Azure DevOps feature.

Practice this question →
60
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 →
61
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 →
62
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

The most likely cause is that the developer's local Git email does not match the email associated with their GPG key in GitHub. When GitHub checks a signed commit, it verifies that the committer email matches one of the emails in the GPG key's UID. If they differ, the signature is considered unverified, even if the key is uploaded.

Option A is incorrect because an expired key would produce a different error. Option B is incorrect because the developer already has the key uploaded. Option D is incorrect because GitHub supports GPG, not just S/MIME.

Practice this question →
63
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 →
64
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 automatically redacts secrets in logs when referenced correctly.

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 →
65
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 →
66
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 →
67
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 →
68
MCQmedium

Your organization uses Microsoft Purview Data Loss Prevention (DLP) to protect sensitive data in Azure DevOps repositories. The compliance team has identified that source code containing credit card numbers (PCI data) was accidentally committed to a public repository. You need to implement a solution that meets the following requirements: (1) Automatically scan all new commits in Azure Repos for sensitive data types like credit card numbers. (2) If sensitive data is detected, automatically block the push and notify the security team. (3) The solution must be integrated with Microsoft Purview and Azure DevOps. Option A: Enable Microsoft Purview Data Loss Prevention for Azure DevOps, which automatically scans and blocks pushes containing sensitive data. Option B: Configure a branch policy in Azure Repos that runs a custom Azure Function via a service hook when a push occurs, and the function uses Purview APIs to scan the commit. Option C: Use GitHub Advanced Security secret scanning for Azure Repos, and configure a webhook to notify the security team. Option D: Install a third-party extension from Azure DevOps Marketplace that provides content scanning and configure it to block pushes. Which option is the most appropriate and efficient?

A.Enable Microsoft Purview Data Loss Prevention for Azure DevOps, which automatically scans and blocks pushes containing sensitive data
B.Configure a branch policy in Azure Repos that runs a custom Azure Function via a service hook when a push occurs, and the function uses Purview APIs to scan the commit
C.Use GitHub Advanced Security secret scanning for Azure Repos, and configure a webhook to notify the security team
D.Install a third-party extension from Azure DevOps Marketplace that provides content scanning and configure it to block pushes
AnswerA

This is the native Microsoft solution that meets all requirements.

Why this answer

Microsoft Purview DLP for Azure DevOps (currently in preview) provides native integration to automatically scan commits for sensitive data types like credit card numbers and block the push if detected, meeting all requirements natively without custom development. Option B describes a custom Azure Function approach which is more complex and not native, and may not integrate as seamlessly with Purview. Option C uses GitHub Advanced Security, which is not available for Azure Repos (it's for GitHub repositories).

Option D relies on a third-party extension, which may not have native Purview integration and could be less reliable. Therefore, Option A is the most appropriate and efficient solution.

Practice this question →
69
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 →
70
MCQeasy

Your team uses Azure Pipelines and wants to ensure that builds cannot access the internet to prevent data exfiltration. What should you do?

A.Create a private agent pool with no internet access
B.Use Microsoft-hosted agents with network isolation
C.Set the pipeline variable 'DisableInternetAccess' to true
D.Use self-hosted agents on an isolated network
AnswerA, B, D

This is similar to option A.

Why this answer

Microsoft-hosted agents with network isolation (B) is a valid Azure feature. However, using a private agent pool with no internet access (A) or self-hosted agents on an isolated network (D) are also valid methods to prevent internet access for builds. The question should be revised to specify a constraint that excludes these options, or the correct options should include A and D.

Exam trap

The provided trap note falsely claims that a private agent pool cannot address network access. In reality, private agent pools can be placed in isolated networks. The true trap is that multiple answer choices are correct.

How to eliminate wrong answers

Option A is wrong because a private agent pool simply refers to agents you manage; it does not inherently restrict internet access unless you configure the underlying network to block it. Option C is wrong because there is no built-in pipeline variable named 'DisableInternetAccess' in Azure Pipelines; this is a fictional setting. Option D is wrong because while self-hosted agents on an isolated network can block internet access, the question asks for a solution using Azure Pipelines, and Microsoft-hosted agents with network isolation provide a managed, scalable approach without requiring you to maintain your own infrastructure.

Practice this question →
71
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 →
72
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 →
73
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 →
74
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 →
75
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

Missing role assignments cause access denied errors.

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 →
Page 1 of 2 · 123 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Security Compliance Plan questions.

Start 20-question session