Sample questions
Microsoft Azure DevOps Engineer Expert AZ-400 practice questions
You have a multi-stage YAML pipeline that deploys to a Linux-based Azure App Service. The pipeline uses a 'Deploy to Azure App Service' task. You need to ensure that the deployment uses the Kudu REST API with ZIP deployment. Which value should you set for the 'packageForLinux' task input?
Trap 1: Set 'enableCustomDeployment' to true
This enables custom deployment scripts, not specifically ZIP deployment via Kudu for Linux.
Trap 2: Set 'useWebDeploy' to false
This disables Web Deploy, but does not enable ZIP deployment for Linux.
Trap 3: Set 'enableKuduDeploy' to true
There is no such input 'enableKuduDeploy' in the Azure Web App task.
- A
Set 'enableCustomDeployment' to true
Why wrong: This enables custom deployment scripts, not specifically ZIP deployment via Kudu for Linux.
- C
Set 'useWebDeploy' to false
Why wrong: This disables Web Deploy, but does not enable ZIP deployment for Linux.
- D
Set 'enableKuduDeploy' to true
Why wrong: There is no such input 'enableKuduDeploy' in the Azure Web App task.
A development team uses a forking workflow in Azure Repos. They want to ensure that only specific users can create forks of the main repository. How can they achieve this?
Trap 1: Set branch policies on the main branch to prevent forks
Branch policies do not control fork creation.
Trap 2: Configure the repository to disable forks globally
Disabling forks is all or nothing; cannot restrict to specific users.
Trap 3: Remove the 'Create Fork' permission from all users except the…
There is no explicit 'Create Fork' permission in Azure Repos.
- A
Use branch security to restrict who can create forks
Under repository settings, you can set security by group for 'Create Fork' permission.
- B
Set branch policies on the main branch to prevent forks
Why wrong: Branch policies do not control fork creation.
- C
Configure the repository to disable forks globally
Why wrong: Disabling forks is all or nothing; cannot restrict to specific users.
- D
Remove the 'Create Fork' permission from all users except the required group
Why wrong: There is no explicit 'Create Fork' permission in Azure Repos.
A team is migrating from TFVC to Git. They have a large codebase with many branches. What is the recommended approach to preserve the history during migration?
Trap 1: Copy the latest version of the code to a new Git repository and…
Loses all history.
Trap 2: Use the Git-TF tool to clone the TFVC repository
Git-TF is deprecated; git-tfs is recommended.
Trap 3: Export TFVC as a Git bundle and import with --no-metadata
Bundles are for Git-to-Git, not TFVC.
- A
Copy the latest version of the code to a new Git repository and start fresh
Why wrong: Loses all history.
- B
Use the Git-TF tool to clone the TFVC repository
Why wrong: Git-TF is deprecated; git-tfs is recommended.
- C
Use the git-tfs tool to clone the TFVC repository with changesets
git-tfs converts TFVC changesets into Git commits preserving history.
- D
Export TFVC as a Git bundle and import with --no-metadata
Why wrong: Bundles are for Git-to-Git, not TFVC.
A development team is transitioning from a centralized version control system to Git in Azure Repos. The team lead wants to ensure that the branch structure supports both feature development and hotfix releases, with the ability to stabilize a release candidate before final deployment. Which branch strategy should the team implement?
Trap 1: Use trunk-based development with short-lived feature branches that…
Trunk-based does not have release branches for stabilization.
Trap 2: Use a forking workflow where each developer forks the repository…
Forking workflow is for external contributions, not internal release management.
Trap 3: Use GitHub Flow with feature branches and pull requests directly to…
GitHub Flow lacks release branches for stabilization.
- A
Use trunk-based development with short-lived feature branches that merge directly to main.
Why wrong: Trunk-based does not have release branches for stabilization.
- B
Use a forking workflow where each developer forks the repository and creates pull requests.
Why wrong: Forking workflow is for external contributions, not internal release management.
- C
Use Git Flow with feature, develop, release, and main branches.
Git Flow provides release branches for stabilization before merging to main.
- D
Use GitHub Flow with feature branches and pull requests directly to main.
Why wrong: GitHub Flow lacks release branches for stabilization.
A team uses Azure Boards to manage work items. They want to automatically update the state of a work item when a related pull request is merged in Azure Repos. Which TWO actions should they configure to enable this integration?
Trap 1: Set up a webhook in Azure Repos to call Azure Logic Apps on pull…
Webhooks require custom logic, not a built-in integration.
Trap 2: Configure a Service Hooks subscription in Azure DevOps to send pull…
Service Hooks send events to external systems, not directly update work items.
Trap 3: Create an Azure Function that listens for pull request merge events…
This is a custom solution, not a built-in configuration.
- A
Set up a webhook in Azure Repos to call Azure Logic Apps on pull request merge.
Why wrong: Webhooks require custom logic, not a built-in integration.
- B
Add a branch policy that requires a linked work item for pull requests.
This ensures every PR has a work item, and on merge, the work item state can be updated.
- C
In the pull request description, use the #mention syntax to reference the work item.
This links the PR to the work item, enabling automatic updates on merge.
- D
Configure a Service Hooks subscription in Azure DevOps to send pull request merge events to Azure Boards.
Why wrong: Service Hooks send events to external systems, not directly update work items.
- E
Create an Azure Function that listens for pull request merge events and updates work items via the REST API.
Why wrong: This is a custom solution, not a built-in configuration.
Which THREE are benefits of using a monorepo vs multiple repositories?
Trap 1: Reduced risk of configuration drift
Multiple repos can also have configuration management; monorepo doesn't inherently reduce drift.
Trap 2: Faster clone times due to smaller repository size
Monorepos are typically larger, leading to slower clones.
- A
Easier code sharing and refactoring across projects
Shared code is in the same repo, simplifying updates.
- B
Reduced risk of configuration drift
Why wrong: Multiple repos can also have configuration management; monorepo doesn't inherently reduce drift.
- C
Simplified dependency management across projects
All code in one repo makes it easier to manage cross-project dependencies.
- D
Faster clone times due to smaller repository size
Why wrong: Monorepos are typically larger, leading to slower clones.
- E
Atomic commits that span multiple components
Changes across projects can be committed together.
A financial services company uses Azure DevOps and requires that all secrets (e.g., API keys, connection strings) be stored in Azure Key Vault. They have a pipeline that runs automated tests and deploys to staging. The pipeline uses a variable group linked to Key Vault to retrieve secrets. Recently, the pipeline failed with the error: 'Secret 'DbPassword' not found in Key Vault 'kv-prod'. Ensure the secret exists and the service principal has List permission.' The secret exists in the vault. What is the most likely cause?
Trap 1: The variable group is linked to the wrong Key Vault instance.
If linked to wrong vault, the error would still be 'not found' but would mention the other vault.
Trap 2: The service principal does not have Get permission on the secret.
The error indicates 'not found', not 'access denied'.
Trap 3: The Key Vault is in a different Azure region than the Azure DevOps…
Region does not affect secret retrieval.
- A
The variable group is linked to the wrong Key Vault instance.
Why wrong: If linked to wrong vault, the error would still be 'not found' but would mention the other vault.
- B
The variable name in the variable group does not exactly match the secret name in Key Vault (case-sensitive).
Azure DevOps maps variable names to secret names, and the match is case-sensitive.
- C
The service principal does not have Get permission on the secret.
Why wrong: The error indicates 'not found', not 'access denied'.
- D
The Key Vault is in a different Azure region than the Azure DevOps organization.
Why wrong: Region does not affect secret retrieval.
You are designing a compliance strategy for Azure DevOps pipelines that deploy to production. The company policy requires that all production deployments must be reviewed by a security lead. Additionally, the deployment must use a specific release pipeline that has been pre-approved. How should you implement this?
Trap 1: Create a branch policy that requires the security lead to approve…
PR approval does not cover deployment approval.
Trap 2: Use a Classic release pipeline with a pre-deployment approval gate…
Classic pipelines are legacy; YAML is recommended.
Trap 3: Store the approved pipeline definition in a variable group and…
Variable groups cannot enforce approval processes.
- A
Create a branch policy that requires the security lead to approve the pull request before merging.
Why wrong: PR approval does not cover deployment approval.
- B
Define a 'production' environment in Azure DevOps and configure an approval check that requires the security lead. Have the pipeline deploy to that environment.
Environment approvals provide the required manual review gate.
- C
Use a Classic release pipeline with a pre-deployment approval gate for the production stage.
Why wrong: Classic pipelines are legacy; YAML is recommended.
- D
Store the approved pipeline definition in a variable group and reference it in all pipelines.
Why wrong: Variable groups cannot enforce approval processes.
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?
Trap 1: Define a required template for all pipelines that includes the…
Templates are not enforced; developers could still bypass them.
Trap 2: Set up a manual approval gate on the production environment stage…
Approval gates control manual approval, not which service connection is used.
Trap 3: Configure a branch policy on the main branch to require a…
Branch policies do not validate service connections used in pipelines.
- A
Define a required template for all pipelines that includes the service connection, and instruct developers to use it.
Why wrong: Templates are not enforced; developers could still bypass them.
- B
Set up a manual approval gate on the production environment stage in the pipeline.
Why wrong: Approval gates control manual approval, not which service connection is used.
- C
Configure a branch policy on the main branch to require a successful build before merging.
Why wrong: Branch policies do not validate service connections used in pipelines.
- 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.
A decorator can inject validation tasks into every pipeline to enforce the use of a specific service connection.
You see the above YAML pipeline trigger configuration in an Azure Pipeline. The repository uses Git Flow with branches: feature/new-feature, develop, release/v1.0, and main. A developer pushes a commit to the branch feature/new-feature. Which action will trigger the pipeline?
Exhibit
Refer to the exhibit.
```json
{
"resources": {
"repositories": {
"self": {
"ref": "refs/heads/feature/*"
}
}
},
"trigger": {
"batch": true,
"branches": {
"include": ["main", "release/*"]
}
},
"pr": {
"branches": {
"include": ["main"]
}
}
}
```Trap 1: A CI trigger will start because the branch name starts with…
The trigger does not include 'feature/*' branches.
Trap 2: A PR trigger will start because the branch name contains 'feature'.
PR triggers only run when a PR is created, not on push.
Trap 3: A CI trigger will start for all branches because batch is set to…
Batch does not affect branch inclusion; it only batches multiple commits.
- A
A CI trigger will start because the branch name starts with 'feature/'.
Why wrong: The trigger does not include 'feature/*' branches.
- B
No trigger will start.
The push to feature/new-feature does not match any branch in the trigger include list, and the PR trigger only applies to PRs.
- C
A PR trigger will start because the branch name contains 'feature'.
Why wrong: PR triggers only run when a PR is created, not on push.
- D
A CI trigger will start for all branches because batch is set to true.
Why wrong: Batch does not affect branch inclusion; it only batches multiple commits.
Your organization uses Azure DevOps and Azure Policy to enforce compliance. You need to ensure that all Azure resources deployed by Azure DevOps pipelines have specific tags (e.g., CostCenter and Environment) applied. Which TWO approaches can achieve this? (Choose TWO.)
Trap 1: Configure the service connection to only allow deployments with…
Service connections don't enforce tagging.
Trap 2: Create an Azure Policy with the 'audit' effect to report…
Audit only reports, does not enforce.
Trap 3: Configure a branch policy on the main branch to require tag…
Branch policies do not affect Azure resource deployment.
- A
Configure the service connection to only allow deployments with tags.
Why wrong: Service connections don't enforce tagging.
- B
Create an Azure Policy with the 'audit' effect to report non-compliant resources.
Why wrong: Audit only reports, does not enforce.
- C
Create an Azure Policy with the 'deny' effect that requires the tags to be present at resource creation.
Deny policy blocks deployment of non-compliant resources.
- D
Add a pipeline task after resource creation that applies the required tags using Azure CLI or PowerShell.
This remediates missing tags post-deployment.
- E
Configure a branch policy on the main branch to require tag verification in pull requests.
Why wrong: Branch policies do not affect Azure resource deployment.
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?
Trap 1: The service connection is configured to use the wrong Azure…
The subscription is used for targeting Azure resources, not for Key Vault access.
Trap 2: The secret name in the variable group does not match the secret…
A mismatch would cause 'secret not found', not 'access denied'.
Trap 3: The service principal used by the service connection does not have…
Key Vault uses access policies, not Azure RBAC (unless configured), and the error is about secrets, not the vault itself.
- A
The service connection is configured to use the wrong Azure subscription.
Why wrong: The subscription is used for targeting Azure resources, not for Key Vault access.
- B
The secret name in the variable group does not match the secret name in Key Vault.
Why wrong: A mismatch would cause 'secret not found', not 'access denied'.
- C
The service principal used by the service connection does not have Contributor role on the Key Vault.
Why wrong: Key Vault uses access policies, not Azure RBAC (unless configured), and the error is about secrets, not the vault itself.
- D
The build service identity does not have Get and List permissions on the Key Vault secrets.
The build service identity (project collection or project level) must be granted access to Key Vault for variable group resolution.
You are configuring Application Insights for a .NET Core web application deployed to Azure App Service. The application must capture telemetry for all HTTP requests, exceptions, and dependency calls with minimal code changes. What should you do?
Trap 1: Configure diagnostics logging in the App Service and stream logs to…
Diagnostics logging captures only logs, not full telemetry.
Trap 2: Install the Microsoft.ApplicationInsights.AspNetCore NuGet package…
This requires code changes, which the scenario wants to minimize.
Trap 3: Add the Application Insights JavaScript SDK to each page.
This only captures client-side telemetry, not server-side.
- A
Enable the Application Insights site extension in the App Service 'Application Insights' blade.
The site extension enables auto-instrumentation with no code changes.
- B
Configure diagnostics logging in the App Service and stream logs to Application Insights.
Why wrong: Diagnostics logging captures only logs, not full telemetry.
- C
Install the Microsoft.ApplicationInsights.AspNetCore NuGet package and add services.AddApplicationInsightsTelemetry() in Startup.cs.
Why wrong: This requires code changes, which the scenario wants to minimize.
- D
Add the Application Insights JavaScript SDK to each page.
Why wrong: This only captures client-side telemetry, not server-side.
Your team uses Azure DevOps for CI/CD. You need to ensure that every build publishes telemetry to Application Insights, including build duration, test pass rate, and deployment frequency. Which approach should you use?
Trap 1: Call the Azure DevOps REST API from a custom script in the pipeline…
Possible but not the recommended approach; Analytics is built for this.
Trap 2: Run the Azure DevOps CLI command 'az devops telemetry publish' in a…
No such CLI command exists.
Trap 3: Use the built-in 'Pipeline Telemetry' dashboard in Azure DevOps.
Built-in charts are pre-defined and cannot be customized.
- A
Call the Azure DevOps REST API from a custom script in the pipeline to capture telemetry.
Why wrong: Possible but not the recommended approach; Analytics is built for this.
- B
Run the Azure DevOps CLI command 'az devops telemetry publish' in a build task.
Why wrong: No such CLI command exists.
- C
Use the built-in 'Pipeline Telemetry' dashboard in Azure DevOps.
Why wrong: Built-in charts are pre-defined and cannot be customized.
- D
Use the Azure DevOps Analytics OData endpoint to query pipeline telemetry and send to Application Insights via a release task.
OData provides structured telemetry data that can be streamed.
Which THREE of the following are valid techniques to reduce the volume of telemetry data sent to Application Insights while preserving diagnostic value?
Trap 1: Aggregate telemetry into 1-minute buckets before sending
Application Insights does not accept pre-aggregated telemetry.
Trap 2: Set a maximum telemetry throughput limit on the Application…
No such limit setting exists.
- A
Aggregate telemetry into 1-minute buckets before sending
Why wrong: Application Insights does not accept pre-aggregated telemetry.
- B
Configure fixed-rate sampling
Keeps only a percentage of telemetry.
- C
Enable adaptive sampling
Automatically adjusts sampling rate based on traffic.
- D
Set a maximum telemetry throughput limit on the Application Insights instance
Why wrong: No such limit setting exists.
- E
Use ITelemetryProcessor to filter out low-importance telemetry
Custom filters can drop unwanted events.
You are designing a centralized logging strategy for multiple microservices hosted in Azure Kubernetes Service (AKS). Each microservice writes logs in JSON format to stdout/stderr. The operations team needs to query logs across all services and correlate them with application performance metrics. Which solution provides the best integration?
Trap 1: Configure AKS to send logs to Azure Blob Storage and use Azure…
Blob Storage doesn't support efficient log querying.
Trap 2: Stream logs to Azure Event Hubs and then to Azure Data Explorer for…
Event Hubs is a transport, not a storage/query solution.
Trap 3: Deploy the Application Insights agent as a DaemonSet in AKS and…
Application Insights is not designed for bulk log ingestion.
- A
Configure AKS to send logs to Azure Blob Storage and use Azure Storage Analytics for querying.
Why wrong: Blob Storage doesn't support efficient log querying.
- B
Enable Container Insights in Azure Monitor to collect stdout/stderr logs and metrics into a Log Analytics workspace.
Container Insights provides integrated log and metric collection with querying via KQL.
- C
Stream logs to Azure Event Hubs and then to Azure Data Explorer for analysis.
Why wrong: Event Hubs is a transport, not a storage/query solution.
- D
Deploy the Application Insights agent as a DaemonSet in AKS and send logs directly to Application Insights.
Why wrong: Application Insights is not designed for bulk log ingestion.
You have deployed an Azure Resource Manager (ARM) template for a scheduled query rule as shown. The rule is enabled and targets an Application Insights resource. However, no alerts are firing despite HTTP 500 errors occurring. What is the most likely cause?
Exhibit
Refer to the exhibit.
```json
{
"properties": {
"name": "test-rule",
"description": "Alert when error rate > 5%",
"severity": 2,
"enabled": true,
"scopes": ["/subscriptions/.../resourceGroups/.../providers/microsoft.insights/components/myapp"],
"criteria": {
"allOf": [
{
"metricName": "requests/count",
"metricNamespace": "microsoft.insights/components",
"operator": "GreaterThan",
"threshold": 100,
"timeAggregation": "Total",
"dimensions": [
{
"name": "request/resultCode",
"operator": "Include",
"values": ["500"]
}
]
}
]
}
}
}
```Trap 1: The severity is set to 2, which suppresses the alert.
Severity 2 is valid and does not suppress alerts.
Trap 2: The metric name 'requests/count' is misspelled; it should be…
The metric name is correct.
Trap 3: The dimension filter for 'request/resultCode' includes '500' but…
Using '500' is valid; it doesn't need wildcard.
- A
The severity is set to 2, which suppresses the alert.
Why wrong: Severity 2 is valid and does not suppress alerts.
- B
The threshold of 100 is too high; the rule should use a percentage-based condition on error rate.
The rule should be based on failed requests percentage, not absolute count.
- C
The metric name 'requests/count' is misspelled; it should be 'requests/count' (correct).
Why wrong: The metric name is correct.
- D
The dimension filter for 'request/resultCode' includes '500' but should also include '5xx' wildcard.
Why wrong: Using '500' is valid; it doesn't need wildcard.
You have an Azure DevOps pipeline that deploys a web app to Azure App Service. You want to capture deployment frequency and change failure rate as metrics in Application Insights. Which built-in analytics view should you use?
Trap 1: Application Dashboard
General overview, not specific to deployment metrics.
Trap 2: Time to Restore Service
This tracks MTTR, not deployment frequency.
Trap 3: Azure DevOps Pipeline Telemetry
Not a standard analytics view in Application Insights.
- A
Deployment Frequency
It provides the requested metrics.
- B
Application Dashboard
Why wrong: General overview, not specific to deployment metrics.
- C
Time to Restore Service
Why wrong: This tracks MTTR, not deployment frequency.
- D
Azure DevOps Pipeline Telemetry
Why wrong: Not a standard analytics view in Application Insights.
Your organization uses Azure DevOps for a multi-tier web application. The application consists of a React frontend, a Node.js API, and a SQL database. The security team has mandated the following: (1) All code changes must be scanned for secrets before merging to the main branch. (2) Infrastructure-as-code templates (ARM) must be validated for security compliance before deployment. (3) Production deployments must use a service connection with a managed identity that has only the required permissions. You have set up a CI/CD pipeline with two stages: Build and Release. The Build stage runs on pull requests and the Release stage deploys to a production environment. Recently, a developer accidentally committed a secret (API key) to a configuration file. The secret was not caught by the pipeline, and the code was merged to main. You need to prevent this in the future. What should you do?
Trap 1: Configure a branch policy to require at least two reviewers on pull…
Reviewers may not catch secrets; automated scanning is needed.
Trap 2: Implement a manual approval gate on the Release stage to review…
Manual review is slow and error-prone; automation is required.
Trap 3: Use a pipeline decorator to inject a validation step that runs…
Azure Policy applies to Azure resources, not code content.
- A
Configure a branch policy to require at least two reviewers on pull requests to the main branch.
Why wrong: Reviewers may not catch secrets; automated scanning is needed.
- B
Implement a manual approval gate on the Release stage to review each deployment for secrets.
Why wrong: Manual review is slow and error-prone; automation is required.
- C
Use a pipeline decorator to inject a validation step that runs Azure Policy on the code repository.
Why wrong: Azure Policy applies to Azure resources, not code content.
- D
Add a 'Credential Scanner' task to the Build pipeline and configure it to fail the build if any secrets are found. Also, move all secrets to Azure Key Vault and reference them via variable groups.
Automated secret scanning prevents secrets from being merged, and Key Vault centralizes secret management.
You are debugging a production issue using Application Insights Snapshot Debugger. The exhibit shows a snapshot from a NullReferenceException. The variable _dbContext is null. What is the most likely root cause?
Exhibit
Refer to the exhibit.
```
Application Insights Snapshot Debugger
Snapshot 1:
Thread: 1234
Exception: NullReferenceException
Stack:
Contoso.Web.Pages.Index.OnGet() line 42
Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker.InvokeHandlerMethod()
...
Local variables:
_dbContext: null (Contoso.Data.AppDbContext)
```Trap 1: The call to the database is not awaited, causing a race condition.
NullReferenceException is due to null reference, not async.
Trap 2: The database connection string is invalid in appsettings.json.
A bad connection string would cause a different exception at runtime.
Trap 3: The OnGet method is missing a null check for _dbContext before…
Null check is a workaround, not root cause.
- A
The call to the database is not awaited, causing a race condition.
Why wrong: NullReferenceException is due to null reference, not async.
- B
The Index page model is not registered in the dependency injection container.
If the page model isn't registered, DI can't inject _dbContext.
- C
The database connection string is invalid in appsettings.json.
Why wrong: A bad connection string would cause a different exception at runtime.
- D
The OnGet method is missing a null check for _dbContext before usage.
Why wrong: Null check is a workaround, not root cause.
A company uses Azure Pipelines to deploy microservices to Azure Kubernetes Service (AKS). They want to implement a canary deployment strategy. What should they use?
Trap 1: Use Azure Front Door to route traffic between clusters
Front Door can route between regions but not for canary inside a single AKS cluster.
Trap 2: Use deployment slots in Azure App Service
Slots are for App Service, not AKS.
Trap 3: Use Azure Container Instances as a staging environment
ACI is useful for isolated containers but not for canary within AKS.
- A
Use Kubernetes native deployment strategies with multiple replica sets and traffic splitting
Kubernetes supports canary deployments via service mesh, multiple deployments, and traffic routing.
- B
Use Azure Front Door to route traffic between clusters
Why wrong: Front Door can route between regions but not for canary inside a single AKS cluster.
- C
Use deployment slots in Azure App Service
Why wrong: Slots are for App Service, not AKS.
- D
Use Azure Container Instances as a staging environment
Why wrong: ACI is useful for isolated containers but not for canary within AKS.
You run the Azure CLI command shown in the exhibit. What is the output?
Trap 1: An error because the query syntax is incorrect
The query syntax is valid.
Trap 2: A list of all VMs in the subscription
The query filters by location 'eastus'.
Trap 3: A list of all VMs in the westus location
The query filters by eastus.
- A
An error because the query syntax is incorrect
Why wrong: The query syntax is valid.
- B
A table showing VM names and resource groups for VMs in eastus
The command filters by eastus and projects name and resource group.
- C
A list of all VMs in the subscription
Why wrong: The query filters by location 'eastus'.
- D
A list of all VMs in the westus location
Why wrong: The query filters by eastus.
You are troubleshooting an intermittent performance issue in a web application. Application Insights shows a high number of failed dependency calls to Azure SQL Database. The errors are SqlException with error code -2 (timeout). What is the most likely cause and recommended fix?
Trap 1: The SQL Server firewall is blocking the application IP; add a…
Firewall issues cause login failures, not timeouts.
Trap 2: The database is experiencing deadlocks; enable read committed…
Deadlocks cause error 1205, not timeout.
Trap 3: The database DTU limit is being exceeded; scale up the service tier.
DTU throttling causes different errors.
- A
The application is exhausting the connection pool; increase Max Pool Size in the connection string.
Timeouts often indicate pool exhaustion.
- B
The SQL Server firewall is blocking the application IP; add a firewall rule.
Why wrong: Firewall issues cause login failures, not timeouts.
- C
The database is experiencing deadlocks; enable read committed snapshot isolation.
Why wrong: Deadlocks cause error 1205, not timeout.
- D
The database DTU limit is being exceeded; scale up the service tier.
Why wrong: DTU throttling causes different errors.
A team wants to enforce that all Azure resource groups in a subscription are tagged with 'CostCenter' and 'Environment'. They need a solution that automatically applies these tags to any new resource group and ensures compliance without manual intervention. What should they use?
Trap 1: Azure RBAC
RBAC controls permissions, not resource configuration like tags.
Trap 2: Azure Blueprints
Azure Blueprints deploy environments but do not enforce tags in real-time during resource group creation.
Trap 3: Azure Resource Graph
Resource Graph is a query tool, not a compliance enforcement mechanism.
- A
Azure Policy
Azure Policy can enforce tagging rules via 'deny' or 'append' effects on resource groups.
- B
Azure RBAC
Why wrong: RBAC controls permissions, not resource configuration like tags.
- C
Azure Blueprints
Why wrong: Azure Blueprints deploy environments but do not enforce tags in real-time during resource group creation.
- D
Azure Resource Graph
Why wrong: Resource Graph is a query tool, not a compliance enforcement mechanism.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.