Courseiva

CCNA Develop a security and compliance plan Questions

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

Practice these questionsDomain overviewAll questions
76
Multi-Selecthard

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

Select 3 answers
A.Use hardcoded secrets in workflow files for simplicity.
B.Enable secret scanning to detect secrets in code pushes.
C.Use the same secret across all environments to reduce management overhead.
D.Use OpenID Connect (OIDC) to authenticate to Azure without storing credentials.
E.Store secrets as GitHub repository secrets or organization secrets.
AnswersB, D, E

Enabling secret scanning on GitHub automatically detects known secret formats (e.g., Azure keys, GitHub tokens) during code pushes, alerts repository administrators and the secret owner, and can block the push or trigger remediation workflows, preventing secrets from being merged.

Why this answer

Option B is correct because enabling secret scanning (including push protection) lets GitHub detect and block credentials committed to the repository, catching accidental leaks before they are exploited. Option D is correct because configuring OpenID Connect (OIDC) with a federated identity credential allows GitHub Actions to authenticate to Azure via short-lived tokens, eliminating the need to store long-lived cloud credentials as secrets. Option E is correct because storing values as GitHub repository secrets or organization secrets keeps them encrypted at rest, masks them in logs, and injects them only at runtime rather than exposing them in workflow files.

Option A is wrong because hardcoding secrets in workflow YAML exposes them in plaintext to anyone with repository read access and in logs. Option C is wrong because reusing one secret across all environments removes isolation, so a compromise in a low-trust environment grants access to production.

Exam trap

The trap here is that candidates may confuse 'secret scanning' with 'secret management' and overlook that OIDC is a valid measure because it removes the need to store secrets altogether, while hardcoding secrets (Option A) seems convenient but is a critical security anti-pattern.

Practice this question →
77
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 →
78
Drag & Dropmedium

Drag and drop the steps to perform a blue-green deployment in Azure using App Service slots into the correct order.

Drag or tap steps into the slots.

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 →
79
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 →
80
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

A pipeline decorator injects a validation task into every pipeline across all projects automatically, failing runs whose secrets are not Key Vault-linked. This enforces centrally managed secrets organisation-wide with minimal administrative overhead, unlike per-pipeline YAML edits or periodic audit reviews.

Why this answer

A pipeline decorator is an organization-level extension that automatically injects tasks into every pipeline across all projects without modifying individual YAML files. By injecting a validation task at the start of each pipeline that checks whether secret variables are linked to Azure Key Vault and fails the run otherwise, it provides real-time enforcement, central management, and minimal administrative overhead — exactly matching the requirements.

Exam trap

AZ-400 often tests whether candidates confuse Azure Policy (which governs Azure resources) with Azure DevOps governance mechanisms (decorators, checks, approvals), so options invoking Azure Policy for pipeline control are classic distractors.

How to eliminate wrong answers

Option A is wrong because a custom task added manually to every pipeline YAML file does not scale across hundreds of pipelines in multiple projects and creates ongoing maintenance burden, violating the 'minimize administrative overhead' requirement. Option B is wrong because Azure Policy governs Azure resources (ARM), not Azure DevOps pipelines — Azure DevOps is not an Azure resource provider subject to Azure Policy evaluation, so this approach cannot enforce pipeline variable rules. Option C is wrong because periodic audit log review is detective, not preventive, and manual identification is slow, error-prone, and cannot block non-compliant pipelines from running.

Practice this question →
81
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 →
82
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 →
83
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 →
84
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 →
85
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

GitHub's commit signature verification uses GPG, SSH, or S/MIME keys to cryptographically sign commits and tags, and branch protection/rulesets can require signed commits before merging. This enforces that all code changes carry a verified signature tied to a trusted identity.

Exam trap

AZ-400 often tests the confusion between commit signature verification (authorship integrity) and code scanning/secret scanning (vulnerability and credential detection) — only signature verification enforces signed commits.

How to eliminate wrong answers

Option A is wrong because Dependabot automates dependency updates and has nothing to do with commit signing or merge enforcement. Option C is wrong because code scanning (CodeQL) analyzes code for vulnerabilities and does not verify commit signatures. Option D is wrong because secret scanning detects leaked credentials and does not enforce commit signing.

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

GitHub Advanced Security secret scanning alerts can be dismissed as 'false positive' directly in the GitHub UI (Security tab → Secret scanning → alert → Dismiss → False positive). This preserves the audit trail and prevents the alert from recurring as an open finding while documenting the reason.

Exam trap

AZ-400 often tests the overreaction of disabling scanning or revoking credentials when the correct action is to triage and dismiss the alert as a false positive in the UI.

How to eliminate wrong answers

Option A is wrong because disabling secret scanning for the entire repository removes protection for all secrets and is a disproportionate response to a single false positive. Option B is wrong because deleting and revoking the PAT assumes the alert is a real secret — the developer already determined it is a false positive, so revocation is unnecessary and disruptive. Option D is wrong because leaving the alert open clutters the security dashboard and does not communicate the triage decision, undermining the security workflow.

Practice this question →
87
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 MFA and enabling Conditional Access policies is the most secure way to manage access because it enforces strong authentication and context-aware access controls. Conditional Access can evaluate user, device, location, and risk to grant or block access, and MFA adds a critical layer beyond passwords. This combination aligns with Microsoft's Zero Trust model and is recommended for Azure DevOps access.

Exam trap

The trap is thinking that network-level restrictions (IP restrictions) or simple MFA alone are sufficient, but the most secure approach combines MFA with Conditional Access for adaptive, context-aware security.

How to eliminate wrong answers

Option B is wrong because disabling external user access does not secure internal accounts and may not be feasible for collaboration. Option C is wrong because IP restrictions alone can be bypassed and do not protect against compromised credentials. Option D is wrong because assigning Basic access level does not enforce authentication strength or conditional policies; it only controls feature access.

Practice this question →
88
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 →
89
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 →
90
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 →
91
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 →
92
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 →
93
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 →
94
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 →
95
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 →
96
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 · 96 questions total

Ready to test yourself?

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

Start 20-question session