{"id":12527,"date":"2026-09-15T09:56:50","date_gmt":"2026-09-15T09:56:50","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=12527"},"modified":"2026-09-15T09:56:50","modified_gmt":"2026-09-15T09:56:50","slug":"microsoft-az-400-practice-test-questions-and-exam-dumps-part-9-q161-180","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/microsoft-az-400-practice-test-questions-and-exam-dumps-part-9-q161-180\/","title":{"rendered":"Microsoft AZ-400 Practice Test Questions and Exam Dumps Part 9 Q161-180"},"content":{"rendered":"<p><b>View Full <a href=\"https:\/\/www.examlabs.com\/az-400-exam-dumps\">Microsoft AZ-400 Exam Dumps<\/a> and Practice Test Dumps<\/b><\/p>\n<p>&nbsp;<\/p>\n<h3><b>Q161. Which Azure DevOps feature can administrators use to review changes and activities related to organizational resources and security?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Azure Boards<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Azure DevOps Audit Logs<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Azure Artifacts<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Azure Test Plans<\/span><\/p>\n<p><b>Correct Answer: 2)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Azure DevOps Audit Logs provide administrators with visibility into important organizational activities and changes. They can help track events related to users, permissions, security settings, repositories, pipelines, and other Azure DevOps resources. This information is particularly useful when investigating unexpected configuration changes, reviewing security-related activity, or supporting compliance requirements. Azure Boards focuses on work management, Azure Artifacts manages packages, and Azure Test Plans supports testing activities. Audit logging is therefore the most appropriate feature when an organization needs a historical record of administrative and security-related events.<\/span><\/p>\n<h3><b>Q162. An Azure DevOps administrator needs to grant permissions to manage repositories only within a specific project. Which approach is most appropriate?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Assign organization-level permissions to every developer<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Grant permissions at the project level<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Give users project collection administrator access<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Create a separate Azure subscription<\/span><\/p>\n<p><b>Correct Answer: 2)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Project-level permissions are appropriate when access should be limited to resources within a particular Azure DevOps project. This follows the principle of least privilege because users receive only the permissions necessary for their assigned project rather than broad organization-wide administrative access. Organization-level or project collection permissions may provide access to many unrelated projects and resources, increasing security risk. Creating a separate Azure subscription does not address Azure DevOps permission scope. Administrators should therefore configure project-specific permissions whenever the requirement is limited to repositories and other resources belonging to one project.<\/span><\/p>\n<h3><b>Q163. A pipeline references a protected service connection, but the pipeline fails because it has not been authorized to use the connection. What should an administrator configure?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Pipeline permissions for the service connection<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> A new Git repository<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> An additional build artifact<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> A branch naming convention<\/span><\/p>\n<p><b>Correct Answer: 1)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Azure DevOps service connections can be protected so that only authorized pipelines can use them. If a pipeline attempts to access a protected service connection without authorization, the pipeline can fail before the deployment begins. The administrator should review the service connection&#8217;s security settings and authorize the required pipeline or grant appropriate pipeline permissions. Creating a repository or artifact does not resolve this authorization problem. Properly configuring pipeline permissions helps prevent unauthorized deployments and limits which automation processes can access cloud resources through the service connection.<\/span><\/p>\n<h3><b>Q164. A project uses several Git repositories, and a pipeline needs source code from two of them during the same job. Which YAML capability should be used?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Deployment slots<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Variable groups<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Multi-repository checkout<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Azure Test Plans<\/span><\/p>\n<p><b>Correct Answer: 3)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Multi-repository checkout allows an Azure Pipelines job to retrieve content from multiple repositories during the same pipeline execution. This is useful when an application depends on shared libraries, infrastructure definitions, configuration repositories, or other centrally maintained source code. The pipeline can define additional repositories and check them out alongside the primary repository. Variable groups manage shared variables and secrets, while deployment slots are used for application deployment strategies. Azure Test Plans supports test management. Therefore, multi-repository checkout is the appropriate capability when a pipeline needs source code from multiple repositories.<\/span><\/p>\n<h3><b>Q165. In an Azure Pipelines YAML file, what is the primary purpose of defining a repository resource?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> To configure application monitoring<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> To define an external repository that the pipeline can reference<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> To create an Azure DevOps project<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> To store deployment secrets<\/span><\/p>\n<p><b>Correct Answer: 2)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A repository resource allows a pipeline to explicitly define another repository that it can use as part of its execution. This can support scenarios involving multiple repositories, external templates, shared pipeline configuration, or source dependencies. Defining repository resources also makes the pipeline structure clearer because referenced repositories are declared in the YAML configuration. Monitoring is handled through services such as Azure Monitor and Application Insights, while secrets can be managed through secure variables, variable groups, or Azure Key Vault. Therefore, repository resources are designed to establish additional repository dependencies for pipeline operations.<\/span><\/p>\n<h3><b>Q166. Which statement best describes a compile-time expression in an Azure Pipelines YAML file?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> It is evaluated only after a deployment finishes<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> It is evaluated during pipeline processing before runtime execution<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> It can only read application logs<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> It is evaluated by Azure Monitor<\/span><\/p>\n<p><b>Correct Answer: 2)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Compile-time expressions in Azure Pipelines are evaluated while the YAML pipeline is being processed, before the pipeline runs its jobs and tasks. They are commonly used with template expressions and parameters to determine which sections of a pipeline should be included or configured. Runtime expressions, by comparison, are evaluated while the pipeline is executing and can depend on runtime variables and conditions. Understanding the distinction is important when designing reusable and dynamic YAML pipelines. Compile-time logic is particularly useful for controlling pipeline structure before execution begins rather than reacting to information generated during a running job.<\/span><\/p>\n<h3><b>Q167. A development team wants to reduce the size of its Docker production image by separating build dependencies from runtime dependencies. Which technique is most appropriate?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Docker multi-stage builds<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Git tagging<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Azure Boards queries<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Branch policies<\/span><\/p>\n<p><b>Correct Answer: 1)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Docker multi-stage builds allow developers to use separate stages for compiling or building an application and for creating the final runtime image. Build tools, source files, and temporary dependencies can remain in the earlier stage, while only the required application files and runtime components are copied into the final image. This can significantly reduce image size and attack surface. Git tags identify source versions, Azure Boards queries organize work items, and branch policies control repository changes. Therefore, multi-stage Docker builds are an effective DevOps practice for producing smaller and cleaner production container images.<\/span><\/p>\n<h3><b>Q168. Which practice is most appropriate for ensuring that a production deployment references a specific, traceable container image version?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Rebuilding the image during deployment<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Using an immutable version tag or digest<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Using only the tag <\/span><span style=\"font-weight: 400;\">latest<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Changing the image name for every deployment<\/span><\/p>\n<p><b>Correct Answer: 2)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Using an immutable container image tag or digest helps ensure that a deployment references a specific image version. This improves traceability and reproducibility because the same image can be promoted across environments without unexpectedly changing its contents. Relying exclusively on the <\/span><span style=\"font-weight: 400;\">latest<\/span><span style=\"font-weight: 400;\"> tag can be risky because its underlying image may change over time. Rebuilding an image during deployment can also introduce differences between environments. Immutable references are therefore preferable for controlled release processes because teams can identify exactly which container image was tested, approved, and deployed to production.<\/span><\/p>\n<h3><b>Q169. Which Azure service can automatically build container images from source code and support automated container image workflows?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Azure Boards<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Azure Test Plans<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Azure Container Registry Tasks<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Azure Repos<\/span><\/p>\n<p><b>Correct Answer: 3)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Azure Container Registry Tasks provide automated workflows for building and managing container images directly with Azure Container Registry. They can be triggered by source code changes, base image updates, or other configured events, helping teams automate container image creation without requiring a dedicated build environment for every operation. Azure Repos provides source control, Azure Boards manages work items, and Azure Test Plans supports testing activities. ACR Tasks are therefore particularly useful when an organization wants to automate container image builds and related registry workflows as part of its DevOps process.<\/span><\/p>\n<h3><b>Q170. A deployment pipeline updates an application running in Kubernetes. Which command is useful for checking whether a Kubernetes deployment has successfully rolled out?<\/b><\/h3>\n<p><b>1)<\/b> <span style=\"font-weight: 400;\">kubectl rollout status<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b> <span style=\"font-weight: 400;\">git status<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b> <span style=\"font-weight: 400;\">az boards status<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b> <span style=\"font-weight: 400;\">docker history<\/span><\/p>\n<p><b>Correct Answer: 1)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The <\/span><span style=\"font-weight: 400;\">kubectl rollout status<\/span><span style=\"font-weight: 400;\"> command provides information about the progress of a Kubernetes deployment rollout. It can help determine whether the updated replicas have become available and whether the deployment has completed successfully. This is valuable in CI\/CD pipelines because a pipeline can monitor rollout progress before proceeding to subsequent stages or reporting deployment success. <\/span><span style=\"font-weight: 400;\">git status<\/span><span style=\"font-weight: 400;\"> displays the state of a Git working directory, while <\/span><span style=\"font-weight: 400;\">docker history<\/span><span style=\"font-weight: 400;\"> shows image layers. The Kubernetes rollout command is therefore the appropriate choice for verifying the progress and completion of a deployment update.<\/span><\/p>\n<h3><b>Q171. A Kubernetes application should receive traffic only after its container has successfully initialized and is ready to serve requests. Which mechanism should be configured?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> A Git hook<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> A readiness probe<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> A branch policy<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> A package feed<\/span><\/p>\n<p><b>Correct Answer: 2)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A Kubernetes readiness probe determines whether a container is ready to receive traffic. If the readiness probe fails, Kubernetes can prevent the associated pod from receiving traffic through the service until the application becomes ready. This is especially useful for applications that require initialization time, database connections, configuration loading, or other startup processes. A readiness probe differs from a liveness probe, which is primarily used to determine whether a container should be restarted. Git hooks, branch policies, and package feeds do not control Kubernetes traffic routing. Therefore, a readiness probe is the correct mechanism for this requirement.<\/span><\/p>\n<h3><b>Q172. A Helm chart needs different configuration values for development, testing, and production environments. Which Helm feature is designed for this purpose?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Git commits<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Kubernetes namespaces only<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Helm values files<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Azure Boards work items<\/span><\/p>\n<p><b>Correct Answer: 3)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Helm values files allow teams to provide environment-specific configuration to a Helm chart without changing the chart&#8217;s underlying templates. For example, development, testing, and production can use different replica counts, resource limits, image tags, or application settings while sharing the same chart structure. This supports consistent and reusable deployment definitions. Kubernetes namespaces can separate resources but do not replace Helm&#8217;s configuration mechanism. Git commits track source changes, and Azure Boards manages work items. Values files therefore provide a practical way to customize Helm deployments for different environments while maintaining a common deployment template.<\/span><\/p>\n<h3><b>Q173. An Infrastructure as Code deployment reports that the actual Azure environment differs from the configuration stored in source control. What concept describes this situation?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Code coverage<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Configuration drift<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Continuous integration<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Package caching<\/span><\/p>\n<p><b>Correct Answer: 2)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Configuration drift occurs when the actual infrastructure environment gradually differs from the desired configuration defined in Infrastructure as Code. This can happen when administrators manually modify resources, when external processes make changes, or when infrastructure updates are not properly recorded in source control. Drift can create deployment inconsistencies and make environments harder to reproduce. Detecting and correcting drift helps maintain infrastructure reliability and consistency. Code coverage measures testing, continuous integration focuses on integrating code changes, and package caching improves dependency retrieval. Therefore, the described difference between actual and declared infrastructure is known as configuration drift.<\/span><\/p>\n<h3><b>Q174. A Bicep project contains several reusable infrastructure definitions that are shared across applications. Which Bicep feature is most appropriate for organizing this reusable infrastructure?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Bicep modules<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Git stash<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Pull request comments<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Azure Boards dashboards<\/span><\/p>\n<p><b>Correct Answer: 1)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Bicep modules allow infrastructure definitions to be separated into reusable components. Teams can create modules for common resources such as networking, storage, monitoring, or security configurations and then reference those modules from multiple Bicep files. This improves consistency, maintainability, and reuse across infrastructure deployments. Git stash temporarily stores local changes, pull request comments support code review discussions, and Azure Boards dashboards provide work tracking information. Modules are therefore the appropriate Bicep feature when an organization wants to build reusable infrastructure components and avoid duplicating the same resource definitions across multiple projects.<\/span><\/p>\n<h3><b>Q175. In Terraform, which component is primarily responsible for tracking the current state of managed infrastructure?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Terraform state<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Dockerfile<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Git branch policy<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Azure Test Plan<\/span><\/p>\n<p><b>Correct Answer: 1)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Terraform state records information about infrastructure resources that Terraform manages and helps Terraform determine the difference between the desired configuration and the current environment. During planning and application operations, Terraform uses this state information to identify resources that need to be created, updated, or removed. Proper state management is therefore critical for reliable Infrastructure as Code workflows. In team environments, remote state storage is commonly used to provide controlled access and collaboration. Dockerfiles define container images, branch policies govern Git workflows, and Azure Test Plans support testing, so they do not serve as Terraform&#8217;s infrastructure state mechanism.<\/span><\/p>\n<h3><b>Q176. An engineer needs to query application and infrastructure logs stored in Azure Monitor to identify failed requests during the previous hour. Which language is commonly used in Log Analytics for this task?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> HTML<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> YAML<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Kusto Query Language (KQL)<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> PowerShell DSC only<\/span><\/p>\n<p><b>Correct Answer: 3)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Kusto Query Language, commonly called KQL, is used to query and analyze telemetry and log data in services such as Azure Monitor and Log Analytics. Engineers can use KQL to filter events by time, search for failures, group records, calculate statistics, and investigate application or infrastructure behavior. This makes it valuable for troubleshooting production issues and supporting observability practices. YAML is commonly used for pipeline configuration, HTML structures web content, and PowerShell DSC is used for configuration management. Therefore, KQL is the appropriate language when querying Azure Monitor or Log Analytics data to investigate failed requests.<\/span><\/p>\n<h3><b>Q177. A DevOps team wants an interactive Azure Monitor view containing charts, metrics, and log-query visualizations for tracking application health. Which feature is most appropriate?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Azure Monitor Workbooks<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Git tags<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Azure Repos branches<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Azure Artifacts feeds<\/span><\/p>\n<p><b>Correct Answer: 1)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Azure Monitor Workbooks provide interactive dashboards for combining metrics, logs, charts, text, and other visualizations into a single monitoring experience. They can help development and operations teams analyze application health, infrastructure performance, and operational trends. Workbooks can use Azure Monitor data and Log Analytics queries to provide customized views for different applications or environments. Git tags identify source versions, repositories manage source code, and artifact feeds manage packages. Therefore, Azure Monitor Workbooks are well suited for creating a centralized and interactive operational dashboard that supports observability and troubleshooting activities.<\/span><\/p>\n<h3><b>Q178. An Azure Monitor alert should notify the operations team and trigger an automated response when a critical condition occurs. Which feature defines these notification and automation targets?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Branch policies<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Action groups<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Variable templates<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Git tags<\/span><\/p>\n<p><b>Correct Answer: 2)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Azure Monitor action groups define the notifications and actions that should occur when an alert is triggered. An action group can include recipients such as email or SMS contacts and can also integrate with automation or other supported response mechanisms. This allows teams to standardize how critical alerts are communicated and handled. Branch policies govern source-control changes, variable templates support pipeline configuration reuse, and Git tags identify source versions. Therefore, action groups are the appropriate Azure Monitor feature when a team needs alerts to notify specific responders or initiate an automated operational response.<\/span><\/p>\n<h3><b>Q179. A team wants to regularly test whether an application endpoint is reachable and responding correctly from Azure. Which monitoring capability can provide this type of check?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Application Insights availability tests<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Git merge<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Azure Artifacts<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Pipeline variables<\/span><\/p>\n<p><b>Correct Answer: 1)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Application Insights availability tests can periodically check application endpoints to determine whether they are reachable and responding as expected. These tests provide useful monitoring information about availability and response behavior and can help teams detect outages before users report them. Availability monitoring is an important part of a proactive DevOps approach because it provides continuous feedback about application health. Git merge handles source-code integration, Azure Artifacts manages packages, and pipeline variables provide configuration values. Therefore, Application Insights availability tests are the appropriate capability for regularly validating endpoint availability.<\/span><\/p>\n<h3><b>Q180. A production service experiences a major outage, and the operations team needs a documented procedure for diagnosing and restoring the service. What should the team maintain?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> A package feed<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> A Git tag<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> A deployment branch<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> An incident response runbook<\/span><\/p>\n<p><b>Correct Answer: 4)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">An incident response runbook provides documented procedures that help teams respond consistently to operational incidents. It can contain diagnostic steps, escalation contacts, recovery procedures, validation checks, and rollback or mitigation instructions. Runbooks are particularly useful during high-pressure incidents because responders can follow established procedures instead of relying entirely on memory or improvisation. After an incident, teams can update the runbook based on lessons learned and improve future response processes. Package feeds manage dependencies, Git tags identify source versions, and deployment branches organize code changes. Therefore, an incident response runbook is the best choice for structured outage response.<\/span><\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>View Full Microsoft AZ-400 Exam Dumps and Practice Test Dumps &nbsp; Q161. Which Azure DevOps feature can administrators use to review changes and activities related to organizational resources and security? 1) Azure Boards 2) Azure DevOps Audit Logs 3) Azure Artifacts 4) Azure Test Plans Correct Answer: 2) Explanation: Azure DevOps Audit Logs provide administrators [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1648,1647],"tags":[],"_links":{"self":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/12527"}],"collection":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/comments?post=12527"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/12527\/revisions"}],"predecessor-version":[{"id":12534,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/12527\/revisions\/12534"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=12527"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=12527"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=12527"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}