Courseiva

CCNA Security Compliance Plan Questions

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

Practice these questionsExam hubAll questions
76
MCQeasy

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

A.Microsoft Entra ID
B.Google Workspace
C.Microsoft account (MSA)
D.GitHub ID
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
77
MCQmedium

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

A.Add a validation step in Azure Pipelines
B.Enable Microsoft Defender for Cloud
C.Deploy Microsoft Sentinel
D.Configure branch policies in Azure Repos
AnswerD

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

Why this answer

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

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

Practice this question →
78
MCQhard

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

A.Configure Azure DevOps Audit Streaming to send logs to Microsoft Sentinel
B.Enable Microsoft Purview to scan Azure DevOps and detect changes
C.Export Azure DevOps audit logs to CSV and import to Sentinel daily
D.Create a service hook in Azure DevOps that calls a logic app to create incidents in Sentinel
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
79
MCQhard

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

A.Use a separate network segment for development
B.Configure content exclusions in the GitHub Copilot settings
C.Disable GitHub Copilot for all users
D.Enable audit logging for Copilot usage
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
80
Multi-Selectmedium

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

Select 3 answers
A.GitHub Pages
B.Branch protection rules
C.Secret scanning
D.Dependabot alerts and security updates
E.Code scanning (CodeQL)
AnswersC, D, E

Secret scanning detects credentials.

Why this answer

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

Exam trap

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

Practice this question →
81
MCQmedium

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

A.Define a required template for all pipelines that includes the service connection, and instruct developers to use it.
B.Set up a manual approval gate on the production environment stage in the pipeline.
C.Configure a branch policy on the main branch to require a successful build before merging.
D.Create an Azure Pipeline decorator that validates the service connection used in each task and fails the pipeline if it is not the approved one.
AnswerD

A pipeline decorator is an extension-based mechanism that injects a custom task into every pipeline run at the specified point (pre-job, post-job, or around a task). By defining a post-task decorator, you can read the inputs of each executed task—such as the `connectedServiceName` or `azureSubscription` input—and compare the referenced service connection to the organization's approved list. If the connection is not approved, the decorator can set the task result to `Failed` and stop the pipeline, providing a hard enforcement that ordinary YAML conventions cannot achieve. This works for any pipeline that uses the task, regardless of whether the author referenced a shared template.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
82
MCQmedium

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

A.Use pipeline settings to require authorization for the default pool
B.Set agent pool permissions to deny the default pool for all projects
C.Remove the default agent pool from the organization
D.Disable the default agent pool in project settings
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
83
MCQmedium

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

A.Use a library variable group linked to Key Vault and configure pipeline permissions with branch control.
B.Store secrets directly in pipeline variables and use 'Make secrets available to all pipelines' setting.
C.Assign pipeline-level permissions to the Key Vault using Azure RBAC.
D.Limit the number of agents in the custom agent pool.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
84
Multi-Selectmedium

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

Select 2 answers
A.Disable parallel jobs for the project.
B.Configure a pipeline approval gate on the production environment.
C.Set branch policies to require a pull request before merging to the main branch.
D.Limit the number of pipelines that can deploy from the main branch.
E.Use a single agent pool for all pipelines.
AnswersB, C

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

Why this answer

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

Exam trap

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

Practice this question →
85
MCQhard

Your Azure DevOps organization has multiple projects. You need to ensure that only approved extension versions are installed across all projects. What is the most efficient way to enforce this?

A.Restrict extension usage to specific pipelines via YAML.
B.Use the Azure DevOps extension management settings to mark approved extensions and block others.
C.Create an Azure Policy that audits extension installations.
D.Uninstall all extensions and only install them per project as needed.
AnswerB

Organization administrators can use the built-in Extension management settings in the Azure DevOps admin UI to enable or disable specific extensions and control who can install them. Marking approved extensions and blocking others is the native governance mechanism for curating the extension catalog across all projects, making this the correct answer.

Why this answer

Azure DevOps provides extension management settings at the organization level where administrators can mark specific extensions as approved and block all others. This is the most efficient way to enforce approved extension versions across all projects. Option A is wrong because extensions cannot be restricted to specific pipelines via YAML; YAML can only reference tasks from installed extensions.

Option C is wrong because Azure Policy does not manage Azure DevOps extensions; it manages Azure resources. Option D is wrong because uninstalling extensions per project is inefficient and does not enforce approved versions globally.

Practice this question →
86
MCQeasy

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

A.Dependabot alerts
B.GitHub Copilot
C.Code scanning
D.Secret scanning
AnswerD

Secret scanning automatically scans repositories for known patterns of secrets such as Expo access tokens, GitHub tokens, AWS keys, and connection strings, and alerts owners when a secret is detected. It can also block pushes containing secrets, making it the correct feature for detecting Expo secrets.

Why this answer

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

Exam trap

The trap here is that candidates often confuse Code scanning (which finds code vulnerabilities) with Secret scanning (which finds credentials), but Azure and GitHub treat them as separate features with distinct purposes and detection mechanisms.

How to eliminate wrong answers

Option A is wrong because Dependabot alerts focus on vulnerable dependencies and outdated packages, not on detecting exposed credentials or secrets in code. Option B is wrong because GitHub Copilot is an AI-powered code completion tool that suggests code snippets, not a security scanning feature for detecting credentials. Option C is wrong because Code scanning (powered by CodeQL) identifies code quality issues and security vulnerabilities like SQL injection or cross-site scripting, but it does not natively scan for hardcoded secrets or credentials; secret scanning is a separate, dedicated feature.

Practice this question →
87
MCQeasy

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

A.GitHub-Azure Boards integration
B.Azure Repos branch policy
C.Azure DevOps OAuth app
D.Azure Pipelines GitHub App
AnswerA

The GitHub-Azure Boards integration creates a bi-directional link between GitHub commits, pull requests, and issues and Azure Boards work items, and it allows you to enforce work item linking in GitHub PRs by adding a required check or branch protection rule that verifies every PR references a work item.

Why this answer

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

Exam trap

The trap here is that candidates might confuse the GitHub-Azure Boards integration with Azure Repos branch policies, assuming any branch policy can enforce work item linking, but branch policies only apply within Azure Repos, not GitHub Enterprise.

How to eliminate wrong answers

Option B is wrong because Azure Repos branch policies are used to enforce rules like required reviewers or status checks within Azure Repos, not GitHub Enterprise, and they cannot enforce work item linking across GitHub and Azure Boards. Option C is wrong because the Azure DevOps OAuth app provides authentication for API access but does not enforce or validate work item links in pull requests. Option D is wrong because the Azure Pipelines GitHub App integrates CI/CD pipelines with GitHub but does not manage work item linking or enforce pull request content requirements.

Practice this question →
88
MCQhard

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

A.Create a manual approval process for each new action.
B.Set the organization to disallow all third-party actions.
C.Configure the organization to allow only actions created by GitHub.
D.Use the 'Allow actions created by GitHub and verified partners' policy and add specific actions to the allow list.
AnswerD

This provides granular control over allowed actions.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
89
MCQhard

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

A.Require manual review of all pull requests for secrets
B.Enable secret scanning push protection
C.Configure Dependabot to flag secrets in dependencies
D.Enable code scanning alerts for secrets
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
90
MCQhard

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

A.Disable Microsoft Defender for Cloud for the agent pool.
B.Uninstall the self-hosted agents and use only Microsoft-hosted agents.
C.Apply the security updates recommended by Microsoft Defender for Cloud to the agent VMs.
D.Replace all self-hosted agents with Microsoft-hosted agents.
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
91
MCQmedium

Your company uses Microsoft Purview to manage data governance. You need to classify a new dataset containing personally identifiable information (PII) and apply a data loss prevention (DLP) policy. What should you do first?

A.Create a sensitivity label in Microsoft Purview
B.Add the data source to an Azure service tag
C.Define a DLP policy in Microsoft Purview
D.Register and scan the data source in Microsoft Purview
AnswerD

Registering the data source in Microsoft Purview establishes a metadata connection, and scanning it is the action that performs automated inspection to classify data using built-in classifiers such as credit card numbers or personally identifiable information. A scan extracts the resource's schema, lineage, and technical metadata, and it applies the registered source's classification rules to produce a searchable data catalog. This is the foundational first step because all other Purview governance features—including labels and DLP policies—depend on the cataloged assets derived from scanning.

Why this answer

To classify a new dataset containing PII and apply a DLP policy, the first step is to register and scan the data source in Microsoft Purview. Scanning automatically discovers and classifies sensitive data using built-in classifiers. Only after classification can you create sensitivity labels (option A) or define a DLP policy (option C).

Adding to an Azure service tag (option B) is unrelated to data classification. Therefore, option D is the correct first step.

Practice this question →
92
Multi-Selectmedium

A company is adopting Azure DevOps and needs to ensure that all pipelines comply with regulatory standards. The security team wants to enforce that every build includes a security scan and that deployment to production requires approval from a compliance officer. Which TWO actions should the DevOps engineer take?

Select 2 answers
A.Configure branch policies to require a security scan on pull requests.
B.Create a required template that includes the security scan task and mandate its use via a pipeline resource.
C.Add a variable group to store security scan results and reference it in the pipeline.
D.Configure a required reviewer approval on the production stage of the release pipeline.
E.Use a pipeline decorator to automatically run a security scan on every build.
AnswersB, D

Creating a required template with the security scan task and mandating its use via a pipeline resource ensures every pipeline inherits the security scan, enforcing compliance across all builds.

Why this answer

Creating a required template with the security scan task and mandating its use via a pipeline resource ensures every pipeline inherits the security scan. Option D is correct because configuring a required reviewer approval on the production stage enforces compliance officer approval. Options A, C, and E are incorrect: Branch policies (A) only apply to pull requests, not all builds; storing results (C) does not enforce the scan; and while a pipeline decorator (E) can run a scan on every build, it does not enforce the required approval for production deployment.

Exam trap

The trap here is that candidates often confuse branch policies (Option A) with build-level enforcement, not realizing that branch policies only apply to pull request validation, not to all builds triggered by other events like CI or scheduled triggers.

Practice this question →
93
MCQmedium

Your team uses GitHub Actions for CI/CD. Security policies require that secrets must be automatically rotated every 90 days. Which Azure DevOps feature should you integrate to enforce this requirement?

A.Microsoft Purview Compliance Manager
B.GitHub Actions secrets with scheduled workflows
C.Azure Key Vault with rotation policy
D.Azure Managed Identities
AnswerC

Azure Key Vault supports secret rotation policies that can be configured to rotate secrets automatically.

Why this answer

Azure Key Vault supports automated secret rotation policies that can be configured to rotate secrets at a specified interval, such as every 90 days. By integrating Azure Key Vault with GitHub Actions, you can enforce the security policy that secrets must be automatically rotated without manual intervention. This is the correct choice because it directly meets the requirement for automated rotation within Azure's ecosystem.

Exam trap

The trap here is that candidates might confuse scheduled workflows in GitHub Actions with automated secret rotation, but GitHub Actions secrets do not support native rotation policies, whereas Azure Key Vault does.

How to eliminate wrong answers

Option A is wrong because Microsoft Purview Compliance Manager is a compliance management tool that helps assess and manage regulatory compliance, but it does not provide automated secret rotation capabilities. Option B is wrong because GitHub Actions secrets with scheduled workflows can trigger actions on a schedule, but they do not natively support automated secret rotation; you would need to implement custom logic to rotate secrets, and GitHub Actions secrets themselves cannot be rotated automatically by the platform. Option D is wrong because Azure Managed Identities provide an identity for Azure resources to authenticate to services without storing credentials, but they do not handle secret rotation; they are used for authentication, not for managing or rotating secrets.

Practice this question →
94
MCQeasy

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

A.Configure approvals and checks on the production environment in Azure Pipelines.
B.Create a branch policy that requires approval for pull requests.
C.Use a service connection with a managed identity that requires approval.
D.Store the production credentials in a variable group with approval required.
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
95
Multi-Selectmedium

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

Select 3 answers
A.Restrict which pipelines can access the variable group
B.Log secret values to pipeline console for debugging
C.Use variable groups with locked variables
D.Link Azure Key Vault as a variable group
E.Store secrets in code as environment variables
AnswersA, C, D

Scoping access reduces exposure.

Why this answer

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

Exam trap

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

Practice this question →
96
MCQhard

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

A.The policy is disabled in the settings
B.The policy is not applied to the main branch
C.The main branch has a separate branch policy override that allows one approval
D.The 'creatorVoteCounts' setting is false, so the creator's approval is not counted
AnswerB

The policy's scope is set to "refs/heads/*", a wildcard that matches all branches, including "main". Therefore the policy does apply to the main branch, so this explanation cannot account for the reduced approval requirement.

Why this answer

Option B is correct. If the minimum approver count policy is configured for a branch other than `main` (or is scoped to a different branch pattern), it will not apply to pull requests targeting `main`. The branch naming policy works because that is a repository-level setting that applies to all branches.

There is no 'project-level' branch policy override in Azure Repos; branch policies are scoped to specific branches or patterns, and if multiple policies apply, all must be satisfied. A separate policy on main that allows one approval would not override an all-branches policy requiring two approvals — the stricter policy would still block. Therefore, the cause must be that the approval policy simply does not apply to main.

Exam trap

Do not confuse repository-level settings (like branch naming) with branch-level policies (like minimum reviewers). Policies are additive and cannot be 'overridden' by another policy.

Practice this question →
97
MCQeasy

A company uses Azure DevOps and needs to ensure that all pipelines use approved YAML templates from a central repository. The security team wants to prevent developers from referencing unapproved templates. What is the best way to enforce this?

A.Create a branch policy on the repository that requires all pull requests to be approved by security team members.
B.Configure a variable group with the approved template repository and require it in all pipelines.
C.Use a pipeline decorator to check the template origin and fail the pipeline if unapproved.
D.Set the 'Required template' repository setting in the Azure DevOps project to the approved central repository.
AnswerC

A custom pipeline decorator could technically inspect template origins and fail the build, but it requires you to write, publish, and maintain a private extension, which is complex and error-prone. The built-in 'Required template' repository setting provides the same enforcement more simply and reliably without custom code.

Why this answer

The correct approach is to use a pipeline decorator that runs at the start of every pipeline, inspects the YAML for template references, and fails the pipeline if any template is not from the approved central repository. The 'Required template' setting forces inclusion of a template but does not block additional unapproved template references.

Exam trap

The trap is that candidates may assume 'Required template' blocks all unapproved templates. In reality, it only enforces inclusion of a mandatory template. Pipeline decorators are a valid and robust way to enforce template origin restrictions.

How to eliminate wrong answers

Option A is wrong because a branch policy requiring pull request approval by security team members only controls changes to the repository's code, not the templates referenced in pipelines; developers could still merge code that references unapproved templates in other repositories. Option B is wrong because a variable group can store the approved repository URL, but it does not enforce that pipelines actually use it; developers can still hardcode or override the template source in their YAML files. Option C is wrong because pipeline decorators are injected at runtime and can check template origins, but they are not a native enforcement mechanism; they require custom scripting and maintenance, and can be bypassed if the decorator is not applied to all pipelines or if the pipeline agent has sufficient permissions.

Practice this question →
98
Drag & Dropmedium

Drag and drop the steps to perform a blue-green deployment in Azure using App Service slots 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

Blue-green deployment involves creating a slot, deploying to it, validating, swapping, and monitoring.

Practice this question →
99
Multi-Selecteasy

You are designing a plan to protect Azure DevOps pipelines from supply chain attacks. Which TWO measures should you implement?

Select 2 answers
A.Require approval for pipeline runs that use external resources
B.Use Dependabot to automatically update vulnerable dependencies
C.Implement code coverage thresholds in pull requests
D.Enable secret scanning for all repositories
E.Use release gates to validate deployment health
AnswersA, B

Approvals on pipeline runs that consume external resources (e.g., packages from public feeds, or services outside the organization) prevent unauthorized or malicious use of those resources. By adding an approval gate, you ensure that every run touching external dependencies is explicitly authorized, reducing the risk of supply chain attacks like typosquatting or compromised upstream packages.

Why this answer

Options A and B are correct. Option A requires approval for pipeline runs that use external resources, which helps prevent unauthorized or malicious external dependencies from being used in builds, directly reducing supply chain attack risk. Option B uses Dependabot to automatically update vulnerable dependencies, ensuring known vulnerabilities are patched promptly.

Option C is incorrect because code coverage thresholds are a code quality measure, not a supply chain security control. Option D is incorrect because secret scanning detects secrets in repositories but does not prevent supply chain attacks. Option E is incorrect because release gates validate deployment health, not supply chain integrity.

Practice this question →
100
MCQmedium

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

A.Add pipeline variables
B.Set up service connections
C.Configure branch policies
D.Use release gates in release pipelines
AnswerD

Release gates in Azure Pipelines run automated checks (e.g., querying work items, monitoring KPIs, or invoking Azure Monitor alerts) at a specified point in a release, and can pause the deployment until a condition is met. Combined with manual approval steps, release gates provide the necessary control to enforce compliance and quality before a production rollout begins.

Why this answer

Release gates in Azure Pipelines allow you to define automated checks (like security scans) and manual approvals before a deployment proceeds. Option A is incorrect because pipeline variables are used to store values, not to enforce deployment conditions. Option B is incorrect because service connections manage authentication to external services, not approval workflows.

Option C is incorrect because branch policies apply to pull requests in repositories, not to release pipelines.

Practice this question →
101
MCQeasy

The exhibit shows a draft Azure Monitor alert rule for Key Vault secret expiry. However, the query fails to return results for secrets that have already expired. What is the most likely reason?

A.The query does not include secrets that have no expiry date set.
B.The condition `DaysToExpiry > 0` excludes secrets that have already expired.
C.The query only checks secrets that are enabled.
D.The `limit 10` clause restricts to only 10 secrets, which may miss expired ones.
AnswerB

Expired secrets have a DaysToExpiry value that is negative because their expiry date is in the past. Using the condition DaysToExpiry > 0 filters out those negative values, so the alert rule excludes already expired secrets and only reports on those expiring in the future.

Why this answer

The query filters on `DaysToExpiry > 0`, which only returns secrets with a positive number of days remaining until expiry. Once a secret has expired, its `DaysToExpiry` becomes zero or negative, so it is excluded from the results. This is a logical filter error: the condition should be `DaysToExpiry <= 0` or remove the filter entirely to include expired secrets.

Exam trap

The trap here is that candidates focus on the syntax or limits of the query (like `limit 10`) rather than recognizing that the logical filter `DaysToExpiry > 0` inherently excludes the very data the alert is supposed to detect—expired secrets.

How to eliminate wrong answers

Option A is wrong because the query does not filter on whether a secret has an expiry date set; the issue is specifically about expired secrets, not those without an expiry date. Option C is wrong because the query does not include any condition that checks the enabled status of secrets; the problem is purely with the `DaysToExpiry` filter. Option D is wrong because the `limit 10` clause only affects the number of results returned, not the logical inclusion of expired secrets; even if more secrets were returned, expired ones would still be excluded by the `DaysToExpiry > 0` condition.

Practice this question →
102
MCQhard

You are a security engineer for a large financial institution. The organization uses Azure DevOps with multiple projects, each containing hundreds of pipelines. The security team recently discovered that several pipeline variables marked as 'Secret' were inadvertently printed to logs due to a custom script task that echoed the variable. Consequently, the compliance officer requires that all secrets used in pipelines must be centrally managed in Azure Key Vault, and any pipeline that references a variable not from Key Vault must be blocked from running. Additionally, the solution must minimize administrative overhead and provide real-time enforcement across all projects in the organization. You have the following options: Option A: Develop a custom pipeline task that checks at runtime whether all secret variables originate from Key Vault, and add it to every pipeline YAML file manually. Option B: Create an Azure Policy definition that audits pipelines for the use of non-Key Vault variables and attach it to the management group containing the Azure DevOps resources. Option C: Use Azure DevOps Audit Logs to periodically review pipeline runs and manually identify pipelines that use non-Key Vault secrets. Option D: Configure a pipeline decorator in the organization settings that injects a task at the beginning of every pipeline to validate that all secret variables are linked to Key Vault, and fail the pipeline if any are not. Which option meets the requirements most effectively?

A.Develop a custom pipeline task that checks at runtime whether all secret variables originate from Key Vault
B.Create an Azure Policy definition that audits pipelines for the use of non-Key Vault variables
C.Use Azure DevOps Audit Logs to periodically review pipeline runs
D.Configure a pipeline decorator in the organization settings that injects a task at the beginning of every pipeline to validate that all secret variables are linked to Key Vault
AnswerD

Pipeline decorators automatically apply to all pipelines and can enforce compliance in real time.

Why this answer

Configure a pipeline decorator is correct because it provides real-time enforcement at the organization level with minimal overhead. Option A is wrong because manual addition to each pipeline is high overhead and error-prone. Option B is wrong because Azure Policy does not apply to Azure DevOps pipeline configurations.

Option C is wrong because it is reactive and does not block non-compliant runs.

Practice this question →
103
MCQmedium

Refer to the exhibit. You executed the Azure CLI command to list variable groups. A security audit requires that all variable groups containing secrets are configured to be authorized for all pipelines. Which statement is true based on the output?

A.The variable group 'ProdVars' contains a secret variable, but the output does not indicate whether it is authorized for all pipelines
B.The variable group 'ProdVars' is not authorized for all pipelines because no such property exists
C.The variable group 'ProdVars' has exposed the secret value in the output
D.The variable group 'ProdVars' is authorized for all pipelines because it has secret variables
AnswerA

The `az pipelines variable-group show` command returns the variable group's metadata and variable definitions. For a secret variable, the value is returned as null (or an empty string depending on the CLI version), which confirms the variable is secret. However, the output does not include an authorization flag such as `isAuthorized` or `authorizedForAllPipelines`; that is a separate property managed at the pipeline/library level. Therefore, while the output clearly indicates the presence of a secret variable, it provides no information about whether the variable group has been authorized for use in all pipelines.

Why this answer

The JSON output shows that 'ProdVars' has an 'ApiKey' variable with a null value, indicating it is a secret variable (values are masked). The output does not include any authorization properties, so we cannot determine if it is authorized for all pipelines. Option B is incorrect because the property 'authorized' may exist but is not shown in the list command; you need to use 'az pipelines variable-group show' or check the settings separately.

Option C is incorrect because the secret value is masked (null), not exposed. Option D is incorrect because having secret variables does not automatically authorize the group for all pipelines; authorization must be explicitly configured.

Practice this question →
104
MCQeasy

Your company is migrating to Microsoft Entra ID and needs to manage secrets used in Azure Pipelines. Which service should you use to securely store and rotate secrets?

A.Azure Key Vault
B.GitHub Secrets
C.Azure App Configuration
D.Microsoft Purview
AnswerA

Azure Key Vault is the Azure-native service for securely storing and managing secrets, keys, and certificates. It integrates directly with Azure Pipelines through service connections or variable groups, providing centralized access control, auditing, and rotation of secrets used in pipeline tasks.

Why this answer

Azure Key Vault is the correct service to securely store and rotate secrets used in Azure Pipelines. It is natively integrated with Azure Pipelines via library variable groups, allowing secrets to be referenced in pipelines without exposing them. Option B, GitHub Secrets, is designed for GitHub Actions, not Azure Pipelines.

Option C, Azure App Configuration, manages feature flags and configuration settings, not secrets. Option D, Microsoft Purview, is for data governance and compliance, not secret management.

Practice this question →
105
MCQhard

Your organization uses GitHub Actions and has a repository containing sensitive infrastructure code. You need to ensure that only approved actions are used in workflows. Which two settings should you configure? (Select two.)

A.Allow actions created by GitHub.
B.Disable actions for the repository.
C.Allow actions from only specific approved repositories.
D.Use environment protection rules.
E.Store actions in encrypted secrets.
AnswerA, C

This is correct because it restricts the set of actions available in your workflows to only those published by GitHub itself (e.g., `actions/checkout`, `actions/setup-dotnet`). This significantly reduces supply-chain risk by excluding third-party actions, while still allowing all workflows to run with trusted, officially maintained actions.

Why this answer

This is a select-two question. The correct answers are A and C. Option A is correct because enabling 'Allow actions created by GitHub' restricts workflows to only use first-party actions published by GitHub, establishing a baseline security posture.

Option C is correct because further limiting actions to only those from specific approved repositories provides granular control over third-party actions that have been vetted by the organization. Together, these settings ensure that only approved actions can be used in workflows, meeting the compliance requirement.

Exam trap

The trap here is that candidates often confuse environment protection rules (which manage deployment approvals) with action source restrictions, or mistakenly think disabling actions entirely is a valid security measure when the repository still needs to run workflows.

How to eliminate wrong answers

Option B is wrong because disabling actions entirely would prevent all workflows from running, which is too restrictive for a repository that needs to execute CI/CD pipelines. Option D is wrong because environment protection rules control deployment approvals and gates, not which actions can be used in workflows; they are unrelated to action source restrictions. Option E is wrong because storing actions in encrypted secrets is not a valid concept—secrets are for sensitive data like tokens or passwords, not for storing action code or references.

Practice this question →
106
Matchingmedium

Match each YAML pipeline trigger to its behavior.

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

Concepts
Matches

Runs pipeline on code push

Runs pipeline on pull request creation

Runs pipeline at specified times

Runs pipeline after another pipeline completes

Why these pairings

In Azure Pipelines YAML, each trigger type has a distinct purpose: CI for push events, PR for pull requests, Schedules for cron-based runs, and Pipeline for cross-pipeline dependencies. Common confusions mix the behaviors of CI/PR or PR/Pipeline triggers.

Practice this question →
107
MCQeasy

Your team uses Azure DevOps and wants to automatically scan pull requests for secrets before they are merged. Which Azure DevOps feature should you use?

A.Azure Policy.
B.Secret scanning in Azure DevOps.
C.GitHub Advanced Security.
D.Branch policy with a required reviewer.
AnswerC

GitHub Advanced Security (GHAS) is a suite of security tools—including secret scanning, code scanning, and dependency review—that is tightly integrated with GitHub repositories, not with Azure Repos in Azure DevOps. Because GHAS secret scanning only works within the GitHub ecosystem and cannot be configured to scan Azure Repos, it is not applicable to this Azure DevOps pipeline scenario.

Why this answer

GitHub Advanced Security (GHAS) for Azure DevOps provides secret scanning that automatically detects secrets (e.g., API keys, passwords, connection strings) in pull requests before they are merged. This feature is integrated into Azure Repos when Advanced Security is enabled and triggers on PR creation, blocking the merge if secrets are found. Therefore, the correct choice is GitHub Advanced Security, not a separate 'Secret scanning in Azure DevOps' feature, which does not exist as a native built-in feature.

Exam trap

Candidates may confuse the built-in secret scanning with a standalone feature, but in Azure DevOps, secret scanning is only available through GitHub Advanced Security (which requires appropriate licensing).

How to eliminate wrong answers

Option A is wrong because Azure Policy is a governance tool for enforcing compliance rules on Azure resources (e.g., VM SKUs, resource locations), not for scanning code or pull requests for secrets. Option C is wrong because GitHub Advanced Security is a feature set for GitHub repositories (including secret scanning), but the question specifies Azure DevOps, which uses its own secret scanning feature, not GitHub Advanced Security. Option D is wrong because a branch policy with a required reviewer only mandates manual approval from a designated user; it does not perform automated secret scanning or content analysis.

Practice this question →
108
MCQhard

Your organization uses Azure DevOps and Azure Key Vault to manage secrets. You have a pipeline that deploys a web app to Azure App Service. The pipeline uses a variable group linked to Key Vault to retrieve the database connection string. Recently, the build started failing with the error: 'Access to Key Vault is denied. Please ensure the service connection has Get and List permissions on secrets.' The service connection uses a service principal. You have verified that the service principal has the correct Key Vault access policy with Get and List permissions. What is the most likely cause of the failure?

A.The service connection is configured to use the wrong Azure subscription.
B.The secret name in the variable group does not match the secret name in Key Vault.
C.The service principal used by the service connection does not have Contributor role on the Key Vault.
D.The build service identity does not have Get and List permissions on the Key Vault secrets.
AnswerD

The build service identity (project collection or project level) must be granted access to Key Vault for variable group resolution.

Why this answer

The error message indicates that the identity attempting to access Key Vault lacks the required permissions. Even though the service principal has the correct access policy, the pipeline may be using a different identity—the build service identity—to authenticate with Key Vault. In Azure DevOps, when a variable group is linked to Key Vault, the pipeline's build service identity (not the service connection's service principal) must have Get and List permissions on the Key Vault secrets.

This is a common misconfiguration where the service principal is granted permissions but the build service identity is not.

Exam trap

The trap here is that candidates assume the service principal configured in the service connection is the identity used to access Key Vault, but in reality, Azure DevOps uses the build service identity for variable group secret retrieval, leading to a permissions mismatch.

How to eliminate wrong answers

Option A is wrong because the Azure subscription configured in the service connection determines the scope for resource management, but Key Vault access is governed by its own access policies, not subscription-level settings. Option B is wrong because a mismatch between secret names would cause a different error (e.g., 'Secret not found') rather than an access denied error. Option C is wrong because the Contributor role on Key Vault is an Azure RBAC role that grants management-plane permissions (e.g., creating/deleting vaults), not data-plane permissions (e.g., reading secrets); Key Vault access policies or Azure RBAC data-plane roles are required for secret access.

Practice this question →
109
MCQmedium

Your organization must comply with SOC 2 requirements. You are using Azure DevOps and need to ensure that all pipeline runs are logged and that logs are retained for at least one year. Which configuration should you implement?

A.Increase the retention period of pipeline logs in the Azure DevOps UI.
B.Configure diagnostic settings for the Azure DevOps organization.
C.Disable the option to delete pipelines.
D.Enable audit streaming to a Log Analytics workspace and set retention to 365 days.
AnswerD

Audit streaming allows long-term retention and compliance.

Why this answer

SOC 2 requires audit logging and retention of pipeline execution history for at least one year. Azure DevOps audit streaming sends all audit events (including pipeline runs) to a Log Analytics workspace, where you can set a retention policy of 365 days. This satisfies both the logging and retention requirements without relying on pipeline-level retention settings that only cover build artifacts and logs, not audit events.

Exam trap

The trap here is that candidates confuse pipeline log retention (Option A) with audit log retention, not realizing that SOC 2 compliance requires immutable audit trails of all pipeline executions, not just the output logs of a build.

How to eliminate wrong answers

Option A is wrong because increasing the retention period of pipeline logs in the Azure DevOps UI only affects build and release logs, not the audit trail of who ran the pipeline or when; SOC 2 requires audit-level logging, not just pipeline log retention. Option B is wrong because configuring diagnostic settings for the Azure DevOps organization is not a valid action—Azure DevOps does not expose diagnostic settings at the organization level; audit streaming is the correct mechanism to send audit data to Log Analytics. Option C is wrong because disabling the option to delete pipelines does not create or retain audit logs; it only prevents manual deletion of pipeline definitions, which has no impact on logging or retention requirements.

Practice this question →
110
MCQeasy

Your organization requires that all code changes be signed using a valid code signing certificate before they can be merged. Which feature in GitHub should you enable to enforce this?

A.Dependabot.
B.Commit signature verification.
C.Code scanning.
D.Secret scanning.
AnswerB

Commit signature verification requires each commit to be cryptographically signed with a verified key (e.g., GPG, SSH, or S/MIME) and the signature to be verified by the repository host. Enabling this in Azure Repos or GitHub protects the integrity and authenticity of every change, directly ensuring that all code changes are signed.

Why this answer

Commit signature verification in GitHub enforces that commits are signed with a verified GPG or S/MIME key, which meets the requirement of signing code changes. Option A is wrong because Dependabot handles dependency updates, not signature enforcement. Option C is wrong because code scanning analyzes code for vulnerabilities, not for commit signatures.

Option D is wrong because secret scanning detects secrets in repositories, not signature enforcement.

Practice this question →
111
MCQhard

Your organization uses GitHub Advanced Security. A developer reports that a secret scanning alert for an Azure DevOps Personal Access Token (PAT) is a false positive. What should you do to handle this?

A.Disable secret scanning for the repository.
B.Delete the PAT from the repository and revoke it.
C.Mark the alert as false positive in the GitHub UI.
D.Ignore the alert and leave it open.
AnswerC

Marking the alert as false positive in the GitHub UI correctly dismisses the alert for that specific detected secret and provides feedback that helps reduce future false positives. This is the intended workflow when you determine the secret is not a real credential, such as a test value or sample string.

Why this answer

Marking the alert as a false positive in the GitHub UI closes the alert and helps train the detection algorithm for future scans. Option A is incorrect because disabling secret scanning entirely would stop detection for all secrets, which is not appropriate for a single false positive. Option B is incorrect because deleting the PAT might be necessary if it were real, but since it's a false positive, it is unnecessary and could break functionality.

Option D is incorrect because ignoring the alert leaves it open and does not resolve the false positive.

Practice this question →
112
MCQeasy

Your organization uses Microsoft Entra ID (formerly Azure AD) for identity management. You need to ensure that only authorized users can access the Azure DevOps organization. What is the most secure way to manage access?

A.Require all users to use multi-factor authentication (MFA) and enable Conditional Access policies.
B.Disable external user access and only allow internal users.
C.Use IP address restrictions to limit access to the corporate network.
D.Add users to the Azure DevOps organization and assign them to the 'Basic' access level.
AnswerA

Requiring multi-factor authentication (MFA) ensures users prove their identity via a second factor, and Conditional Access policies enforce context-aware conditions such as device compliance, sign-in risk, and location for Azure DevOps resources. This combined approach mitigates credential theft and provides adaptive, secure access controls directly integrated with Microsoft Entra ID.

Why this answer

Requiring multi-factor authentication (MFA) and enabling Conditional Access policies provides the most secure access control. MFA adds an extra layer of security beyond passwords, and Conditional Access allows granular policy enforcement based on user, device, location, and risk, ensuring only authorized users under secure conditions can access Azure DevOps. Option B is less secure as it does not enforce additional authentication.

Option C only restricts access by network location but does not prevent unauthorized access if an attacker is on the corporate network. Option D only grants basic access without security controls.

Practice this question →
113
MCQeasy

Your organization uses Azure DevOps and Microsoft Entra ID. The compliance team needs to ensure that access to Azure DevOps projects is governed by conditional access policies. Which Azure DevOps integration should you use?

A.Link the Azure DevOps organization to the Microsoft Entra ID tenant and configure conditional access policies in Microsoft Entra ID.
B.Configure service hooks to enforce conditional access.
C.Assign managed identities to users for conditional access.
D.Use OAuth tokens to authenticate users.
AnswerA

Linking the Azure DevOps organization to your Microsoft Entra ID tenant is the prerequisite that makes conditional access policies effective for Azure DevOps sign-ins. Once linked, Azure DevOps delegates authentication and authorization to Microsoft Entra ID, so conditional access policies you configure in Microsoft Entra ID — such as MFA, device compliance, or location-based restrictions — are evaluated during the interactive sign-in and token issuance flow. This applies organization-wide and covers all users who authenticate through the linked tenant, enforcing policy before users can access Azure DevOps resources.

Why this answer

To govern access to Azure DevOps projects with conditional access policies, you must link the Azure DevOps organization to the Microsoft Entra ID tenant. This integration makes Azure DevOps a registered application within the tenant, allowing conditional access policies (e.g., MFA, device compliance, location-based access) to be evaluated during authentication. Only then can the compliance team enforce organization-wide access rules via Microsoft Entra ID.

Exam trap

The trap here is that candidates confuse service hooks or OAuth tokens with identity governance features, not realizing that conditional access requires the resource to be a first-party or registered application in Microsoft Entra ID, not just any authentication method.

How to eliminate wrong answers

Option B is wrong because service hooks are used for integrating external services (e.g., Slack, Jenkins) via event-driven notifications, not for enforcing authentication or conditional access policies. Option C is wrong because managed identities are designed for Azure resources (e.g., VMs, Functions) to authenticate to Azure services without storing credentials, not for user-level conditional access enforcement. Option D is wrong because OAuth tokens are an authentication mechanism for granting delegated access to APIs; they do not by themselves enforce conditional access policies, which require the resource (Azure DevOps) to be integrated with Microsoft Entra ID as a relying party.

Practice this question →
114
MCQeasy

You need to ensure that only signed-in users can view Azure DevOps project wikis. Which setting should you configure?

A.Configure wiki permissions to deny anonymous users
B.Set project visibility to 'Private'
C.Set repository visibility to 'Private'
D.Use Microsoft Entra ID Application Proxy
AnswerB

Setting the project visibility to 'Private' in Azure DevOps is the definitive project-level setting that requires all users to authenticate before viewing any project data, including wikis, repos, boards, and pipelines. This ensures that anonymous users are completely barred from accessing Azure DevOps content, as private projects only allow authenticated members or explicitly added external users.

Why this answer

Setting the project visibility to 'Private' ensures that only authenticated users who are members of the Azure DevOps organization can access the project and its wikis. Anonymous or unauthenticated users are blocked entirely at the project level, which directly satisfies the requirement to restrict wiki viewing to signed-in users only.

Exam trap

The trap here is that candidates often confuse repository-level visibility with project-level visibility, assuming that setting a repo to private will also secure the wiki, when in fact the wiki is a project-level artifact and its access is governed by the project's visibility setting.

How to eliminate wrong answers

Option A is wrong because Azure DevOps wikis do not have a separate 'deny anonymous users' permission; anonymous access is controlled at the project visibility level, not through granular wiki permissions. Option C is wrong because repository visibility settings control access to the underlying Git repository, not the wiki itself; project wikis are provisioned as a separate service and are governed by project-level visibility. Option D is wrong because Microsoft Entra ID Application Proxy is used for publishing on-premises web applications externally, not for controlling access to Azure DevOps wikis.

Practice this question →
115
MCQhard

Your organization uses Microsoft Entra ID for identity and Azure DevOps for source control. You need to enforce that all code changes to the main branch require a pull request with at least two approvals and no failing checks. What should you configure?

A.Configure a Conditional Access policy in Microsoft Entra ID
B.Add an environment protection rule in Azure Pipelines
C.Set up a branch policy on the main branch in Azure Repos
D.Use a service hook to notify reviewers when a push occurs
AnswerC

Branch policies in Azure Repos provide a server-enforced compliance gate on pull requests targeting the main branch. You can configure a policy to require a minimum number of reviewers, enforce build validation by running a pipeline, and mandate linked work items. These policies block direct pushes to the main branch and prevent pull request completion until every defined criterion is satisfied, making them an authoritative mechanism for code review and build quality gates.

Why this answer

Azure Repos branch policies allow you to enforce required pull requests, minimum number of reviewers (e.g., two approvals), and status checks (e.g., no failing checks) on the main branch. This ensures that all code changes to the protected branch comply with the defined quality and security gates before merging.

Exam trap

The trap here is that candidates confuse environment protection rules (used for deployment approvals in release pipelines) with branch policies (used for source code merge requirements in Azure Repos), leading them to select Option B instead of C.

How to eliminate wrong answers

Option A is wrong because Conditional Access policies in Microsoft Entra ID control authentication and access to applications (e.g., requiring MFA or device compliance), not code review or merge requirements within Azure Repos. Option B is wrong because environment protection rules in Azure Pipelines govern deployment approvals and checks for release pipelines (e.g., manual approval before deploying to production), not source control branch policies for pull requests. Option D is wrong because service hooks are used to trigger external events (e.g., sending notifications to Slack or triggering a webhook) when a push occurs, but they do not enforce approval or check requirements on pull requests.

Practice this question →
116
MCQhard

Your organization uses Azure DevOps with classic pipelines. Security audit requires that all pipeline variables containing secrets (e.g., API keys) are stored in Azure Key Vault and referenced dynamically. Currently, secrets are stored as plain text in the pipeline UI. You need to migrate to Key Vault with minimal downtime and ensure that secret values are never exposed in logs. What should you do?

A.Store secrets in a secure file in Azure DevOps.
B.Create a variable group linked to Key Vault, mark variables as 'secret', and reference them in pipelines. Update pipeline steps to use the variable group.
C.Use the 'Azure Key Vault' task to download secrets as pipeline variables.
D.Add each secret as a pipeline variable with the 'secret' type.
AnswerB

Create a variable group linked to an Azure Key Vault and select the secrets to expose. The linked variable group automatically loads those secrets as pipeline variables, and each one is implicitly treated as secret, so Azure DevOps masks its value in every log. Update your pipeline steps to reference $(secret-name) instead of hardcoding values; this also lets you rotate secrets in Key Vault without redeploying pipelines and gives you centralized access control and auditing through the vault.

Why this answer

The correct approach is to create a variable group linked to Azure Key Vault in the Library, mark the variables as 'secret', and reference that variable group in the pipeline. This ensures secrets are stored in Key Vault (not in Azure DevOps) and masked in logs. Option A (secure file) still stores secrets in Azure DevOps and may not prevent log exposure.

Option C (Azure Key Vault task) downloads secrets as pipeline variables, which could expose them if not properly masked. Option D (secret pipeline variables) stores secrets in Azure DevOps, not Key Vault, and while masked, they remain in the pipeline definition.

Practice this question →
117
MCQhard

Your organization uses Microsoft Entra ID and Azure DevOps. You need to ensure that only users from specific Entra ID groups can create new Azure DevOps organizations. What should you configure?

A.Assign the Global Administrator role to the security group
B.Assign the Azure DevOps Administrator role to the security group
C.Configure Conditional Access policies to block non-group members
D.Use Azure DevOps security policies to restrict organization creation
AnswerB

The Azure DevOps Administrator role in Microsoft Entra ID is specifically designed to grant permissions to manage Azure DevOps organizations, including creation. Assigning this role to a security group enables group-based assignment, ensuring that members have the precise privileges needed without overreaching, following the least-privilege model.

Why this answer

The Azure DevOps Administrator role in Microsoft Entra ID is specifically designed to manage Azure DevOps service-level settings, including the ability to restrict who can create new Azure DevOps organizations. By assigning this role to a security group, only members of that group can create new organizations, which directly meets the requirement.

Exam trap

The trap here is that candidates often confuse Conditional Access policies (which control sign-in and access) with administrative roles (which control resource creation permissions), leading them to select option C instead of the correct role-based option B.

How to eliminate wrong answers

Option A is wrong because the Global Administrator role grants broad administrative access across all Entra ID services, which is excessive and not scoped to Azure DevOps organization creation. Option C is wrong because Conditional Access policies control authentication and access to applications, not the ability to create new Azure DevOps organizations; they cannot restrict organization creation at the Entra ID level. Option D is wrong because Azure DevOps security policies are scoped within an existing organization and cannot control the creation of new organizations at the tenant level.

Practice this question →
118
Multi-Selecteasy

Your team is adopting GitHub Copilot for code generation. The compliance team requires that all code generated by AI is reviewed and that proprietary code is not used as training data. Which TWO settings should you configure in your GitHub organization?

Select 2 answers
A.Configure a branch protection rule that requires all code to be reviewed before merging.
B.Disable Copilot for all repositories in the organization.
C.Disable the 'Allow GitHub to use my data for training' option in the organization's Copilot settings.
D.Enable 'Suggestions matching public code' to block suggestions that match public code.
E.Enable 'Allow GitHub to use my code snippets for product improvements' to improve Copilot.
AnswersA, C

Configuring a branch protection rule that requires at least one approved pull request review on protected branches (e.g., main) enforces a mandatory human review checkpoint before any Copilot-generated code can be merged. This ensures AI-suggested changes are inspected for correctness, security, and compliance, meeting the core safety requirement while still allowing Copilot usage.

Why this answer

Branch protection rules enforce mandatory pull request reviews before merging, which satisfies the compliance requirement that all AI-generated code must be reviewed by a human before entering the main branch. Additionally, disabling the 'Allow GitHub to use my data for training' option in the organization's Copilot settings prevents proprietary code from being used as training data, directly addressing the compliance requirement that proprietary code not be used for training. Together, these two settings allow the team to use GitHub Copilot safely while meeting compliance.

Exam trap

The trap here is that candidates might confuse the 'Suggestions matching public code' setting (which blocks suggestions that match public code to avoid license violations) with the data privacy setting that controls training data usage, or think that disabling Copilot entirely is the only way to meet compliance, when in fact the two correct settings allow safe usage without violating policies.

Practice this question →
119
MCQhard

Refer to the exhibit. You receive a secret scanning alert for an Azure DevOps PAT in a GitHub repository. The push_protection_bypass is false. What does this mean and what action should you take?

A.The secret was pushed but push protection was bypassed; you need to revoke the PAT and use git filter-branch to remove it from history.
B.The secret was pushed successfully; you need to rotate the PAT and audit the commit history.
C.The secret was pushed and push protection was not bypassed; you need to open a support ticket with GitHub to remove the secret.
D.The secret was blocked from being pushed; you should revoke the PAT and investigate the incident.
AnswerD

The GitHub Secret Scanning push protection alert (with push_protection_bypass: false) confirms the push was rejected before any commit landed in the repository, so the PAT never exists in the commit history. Nevertheless, the PAT was transmitted to GitHub in the blocked push payload and should be treated as exposed, so revoking it is the immediate security action. Investigating the alert helps determine who attempted the push, which repo/branch was targeted, and whether the PAT was compromised elsewhere.

Why this answer

When `push_protection_bypass` is `false`, it means the secret was blocked from being pushed by GitHub's push protection feature. The alert indicates the secret was detected and prevented from entering the repository, so the correct action is to revoke the compromised PAT and investigate the incident to prevent future occurrences. Option D correctly identifies that the secret was blocked and prescribes the appropriate remediation steps.

Exam trap

The trap here is confusing `push_protection_bypass` with the secret being pushed successfully; candidates often assume `false` means the secret was allowed through, but it actually means the push was blocked.

How to eliminate wrong answers

Option A is wrong because `push_protection_bypass` is `false`, meaning push protection was NOT bypassed; the secret was blocked, not pushed. Option B is wrong because the secret was not pushed successfully; it was blocked, so rotating the PAT and auditing commit history is unnecessary and misinterprets the alert. Option C is wrong because while the secret was not bypassed, opening a support ticket with GitHub is not the correct action; the PAT should be revoked and the incident investigated, not escalated to support.

Practice this question →
120
Multi-Selecthard

Which TWO actions should a DevOps engineer take to ensure that Azure DevOps pipelines comply with the principle of least privilege for service connections?

Select 2 answers
A.Create a service principal with permissions scoped to the minimum required Azure resources.
B.Use the Project Collection Build Service account for all pipeline runs.
C.Use Workload identity federation to avoid managing secrets.
D.Configure the service connection to be available only to specific pipelines.
E.Use the same service connection for both build and release pipelines.
AnswersA, D

Creating a service principal with permissions scoped to the minimum required Azure resources enforces least privilege by granting the pipeline identity only the specific RBAC roles needed on targeted resource groups or services, preventing over-permissioning and reducing the attack surface if credentials are compromised.

Why this answer

Creating a service principal with permissions scoped to the minimum required Azure resources directly implements the principle of least privilege. By assigning only the necessary roles (e.g., Contributor on a specific resource group) to the service principal used in the service connection, you ensure that the pipeline can only perform actions on those resources, reducing the attack surface. This aligns with Azure RBAC best practices for securing automated deployments.

Exam trap

The trap here is that candidates often confuse 'Workload identity federation' (which improves secret management) with 'least privilege' (which is about permission scoping), leading them to select option C instead of recognizing that federation does not automatically restrict permissions.

Practice this question →
121
MCQeasy

You need to ensure that only approved users can deploy to production from Azure Pipelines. What should you implement?

A.Pipeline approval gates
B.Microsoft Entra ID Conditional Access policies
C.Environment checks with required approvers
D.Branch protection rules in GitHub
AnswerC

In Azure Pipelines, an environment acts as a container for deployment targets and supports checks that control entry before a job executes. Adding an Approvals check to the Production environment lets you designate specific users or groups as required approvers; when a pipeline tries to deploy to that environment, the run pauses until one of those approvers explicitly approves or rejects the deployment. This is the native, supported mechanism that ensures only approved users can authorize releases to production, and it can be combined with other checks like branch control or time windows.

Why this answer

Azure Pipelines environment checks with required approvers allow you to enforce that only specific users or groups can approve deployments to a production environment. This is a native Azure DevOps feature that integrates with pipeline stages to gate deployments based on manual approval, ensuring that unauthorized users cannot trigger or approve production releases.

Exam trap

The trap here is that candidates often confuse pipeline approval gates (which are checks like monitoring or security scans) with environment-level required approvers (which are manual approval steps), leading them to select option A instead of C.

How to eliminate wrong answers

Option A is wrong because pipeline approval gates are a broader concept that can include manual approval checks, but they are not specifically designed to restrict which users can deploy to production; they are more about adding checks before a stage runs. Option B is wrong because Microsoft Entra ID Conditional Access policies control access to Azure resources and applications based on conditions like location or device compliance, but they do not directly integrate with Azure Pipelines to restrict who can approve or execute a deployment. Option D is wrong because branch protection rules in GitHub protect branches from direct pushes or merges without review, but they do not control who can deploy from Azure Pipelines to a production environment; they are a source control mechanism, not a deployment approval mechanism.

Practice this question →
122
MCQhard

You are a DevOps engineer for a financial services company with strict regulatory compliance requirements (e.g., PCI-DSS, SOX). The company uses Azure DevOps for CI/CD and manages multiple projects. Each project has its own set of service connections, variable groups, and agent pools. The security team recently audited the environment and found that several service connections have been granted Contributor rights at the subscription level, and some variable groups are accessible by all pipelines across all projects. Additionally, audit logs show that a former employee's service principal still has active service connections in two projects. You need to implement a security and compliance plan to address these issues. Which approach should you take?

A.Conduct a manual audit of all service connections and variable groups every quarter, and revoke any permissions that are not needed. Disable service connections associated with the former employee.
B.Immediately delete all service connections associated with the former employee and recreate them using service principals with the least privilege. Then, update all pipelines to use the new connections.
C.Restrict all service connections to use resource-group level scoped permissions instead of subscription-level. For variable groups, set them to be accessible only to specific pipelines.
D.Implement Azure Policy to enforce that service connections cannot have subscription-level Contributor role; instead, require specific resource group roles. Use Azure AD access reviews to automatically remove stale service principals. Use pipeline decorators to enforce branch policy and approval checks on variable groups that contain secrets.
AnswerD

This answer combines three complementary Azure native controls that together provide preventive, detective, and corrective governance. Azure Policy continuously audits and denies role assignments that grant subscription-level Contributor to service connections, enforcing least privilege automatically across all resources. Azure AD access reviews periodically evaluate service principal usage and automatically remove or disable stale principals, eliminating orphaned credentials like the former employee's. Pipeline decorators inject pre-execution steps into every pipeline run, enforcing branch policies and mandatory approval checks whenever a variable group containing secrets is referenced, even if the pipeline YAML does not explicitly include those checks.

Why this answer

It provides a comprehensive, automated, and scalable approach to enforcing least privilege and compliance. Azure Policy can audit and enforce that service connections are scoped to resource groups rather than subscriptions, preventing over-permissioned Contributor access. Azure AD access reviews automate the detection and removal of stale service principals, addressing the former employee issue without manual effort.

Pipeline decorators enforce mandatory approval checks and branch policies on variable groups containing secrets, ensuring that sensitive variables are not accessible to all pipelines across projects.

Exam trap

The trap here is that candidates often choose a manual or reactive approach (like Option A or B) because they focus on the immediate fix for the former employee, overlooking the need for automated, continuous enforcement that Azure Policy, access reviews, and pipeline decorators provide for long-term compliance.

How to eliminate wrong answers

Option A is wrong because a manual quarterly audit is reactive, error-prone, and does not scale across multiple projects; it fails to meet the strict regulatory compliance requirements that demand continuous enforcement. Option B is wrong because immediately deleting all service connections associated with the former employee could break running pipelines and does not address the root cause of over-permissioned service connections or variable group accessibility; it also lacks automation for ongoing compliance. Option C is wrong because restricting service connections to resource-group level scopes is a partial fix that does not enforce the change across existing connections, and setting variable groups to be accessible only to specific pipelines is a manual configuration that does not prevent future misconfigurations or provide audit trails.

Practice this question →
123
MCQmedium

You are using Microsoft Defender for Cloud to secure Azure Pipelines. You need to receive alerts when a pipeline run uses a service principal with excessive permissions. Which feature should you enable?

A.Enable Azure DevOps audit logs and review them manually.
B.Create an Azure Policy to deny over-privileged service principals.
C.Enable Microsoft Defender for Cloud's identity and access monitoring.
D.Configure Microsoft Entra ID Conditional Access policies.
AnswerC

Enabling Microsoft Defender for Cloud's identity and access monitoring activates continuous analysis of Azure AD identities and service principals, including their sign-in patterns, permissions, and usage anomalies. This feature leverages Microsoft Defender for Identity sensors to detect risky behaviors such as suspicious service principal credential usage and over-permissioned resource access, and it emits real-time security alerts. That gives the team the required detection and response capability for identity-based threats in Azure Pipelines.

Why this answer

Microsoft Defender for Cloud's identity and access monitoring continuously assesses the permissions of service principals used in Azure Pipelines and generates alerts when it detects over-privileged or anomalous usage. This feature is specifically designed to identify excessive permissions in real-time, enabling proactive security responses without manual log review or policy enforcement.

Exam trap

The trap here is that candidates often confuse Azure Policy (which enforces resource compliance) with identity monitoring (which detects permission misuse), leading them to select Option B instead of the correct identity-focused alerting feature.

How to eliminate wrong answers

Option A is wrong because manually reviewing Azure DevOps audit logs is reactive and does not provide automated, real-time alerts for over-privileged service principals; it requires constant human oversight. Option B is wrong because Azure Policy can enforce compliance on Azure resources but cannot directly deny or monitor pipeline runs that use over-privileged service principals; it operates at the resource management layer, not the pipeline execution layer. Option D is wrong because Microsoft Entra ID Conditional Access policies control authentication and access to applications based on conditions like location or device state, but they do not evaluate the permissions of service principals within Azure Pipelines or generate alerts for excessive privileges.

Practice this question →
← PreviousPage 2 of 2 · 123 questions total

Ready to test yourself?

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

Start 20-question session