{"id":12522,"date":"2026-09-15T09:58:37","date_gmt":"2026-09-15T09:58:37","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=12522"},"modified":"2026-09-15T09:58:37","modified_gmt":"2026-09-15T09:58:37","slug":"microsoft-az-400-practice-test-questions-and-exam-dumps-part-4-q61-80","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/microsoft-az-400-practice-test-questions-and-exam-dumps-part-4-q61-80\/","title":{"rendered":"Microsoft AZ-400 Practice Test Questions and Exam Dumps Part 4 Q61-80"},"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>Q61. Which Azure Pipelines component defines the individual actions performed within a job?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Tasks<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Stages<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Environments<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Repositories<\/span><\/p>\n<p><b>Correct Answer: 1)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Tasks are the individual units of work executed by Azure Pipelines jobs. A task can perform a specific operation such as running a script, compiling source code, executing tests, publishing an artifact, or deploying an application. Multiple tasks can be placed inside a job to create the required workflow. Stages organize larger phases of a pipeline, while environments represent deployment targets and repositories contain source code. Understanding the difference between stages, jobs, and tasks helps teams design clear and maintainable pipelines. Therefore, tasks are the components responsible for defining the individual actions that a pipeline job performs.<\/span><\/p>\n<h3><b>Q62. Which Azure DevOps feature is most appropriate for storing and managing NuGet, npm, Maven, or Python packages?<\/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 Artifacts<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Azure Repos<\/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 Artifacts provides package management capabilities for common package formats such as NuGet, npm, Maven, and Python packages. Teams can use feeds to store, share, and manage packages produced by their applications or consumed as dependencies. This provides a centralized approach to package management and can help organizations control access to internal packages. Azure Repos is used primarily for source-code repositories, Azure Boards supports work tracking, and Azure Test Plans supports testing activities. Therefore, Azure Artifacts is the appropriate Azure DevOps service for managing application packages and dependencies across development and delivery workflows.<\/span><\/p>\n<h3><b>Q63. What is the main benefit of using a multi-stage YAML pipeline?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> It eliminates the need for source control<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> It stores only application logs<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> It allows build, test, and deployment workflows to be defined together as code<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> It prevents all production failures<\/span><\/p>\n<p><b>Correct Answer: 3)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A multi-stage YAML pipeline allows teams to define multiple phases of software delivery within a single pipeline-as-code definition. For example, one pipeline can contain stages for building an application, running automated tests, performing security checks, and deploying to development and production environments. Because the pipeline definition is stored as code, it can be reviewed, versioned, and maintained alongside the application. YAML pipelines do not eliminate source control or guarantee that production failures will never occur. Their main advantage is providing a structured, repeatable, and version-controlled way to manage complex CI\/CD workflows.<\/span><\/p>\n<h3><b>Q64. Which Azure DevOps capability can automatically run a pipeline after another pipeline completes successfully?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Pipeline completion trigger<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Path filter<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Scheduled trigger<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Manual validation<\/span><\/p>\n<p><b>Correct Answer: 1)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A pipeline completion trigger allows one pipeline to start automatically when another pipeline finishes according to configured conditions. This is useful when software delivery is divided into multiple dependent pipelines. For example, one pipeline might build and publish an application artifact, while another pipeline deploys that artifact after the build pipeline completes successfully. This creates an automated dependency between pipeline workflows. Path filters respond to file changes, scheduled triggers respond to predefined times, and manual validation requires human intervention. Therefore, a pipeline completion trigger is the appropriate capability when one pipeline needs to react to the completion of another.<\/span><\/p>\n<h3><b>Q65. Which deployment job feature provides a history of deployments made to a specific environment?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Agent capability<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Environment deployment history<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Git commit history<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Variable group<\/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 environments provide deployment history that helps teams track which pipeline runs and deployments have targeted a particular environment. This information can be useful for auditing, troubleshooting, and understanding what version of an application was deployed and when. Environment history is especially valuable for production systems because teams can review previous deployments when investigating incidents or verifying release activity. Git commit history focuses on source-code changes, variable groups store shared configuration, and agent capabilities describe available agent features. Therefore, environment deployment history provides visibility into deployments made to a specific environment.<\/span><\/p>\n<h3><b>Q66. Which approach best supports secure access to Azure resources from a pipeline without storing long-lived credentials in scripts?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Hard-code a password in YAML<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Store credentials in source control<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Use an appropriate service connection or managed identity-based authentication<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Add credentials to every task manually<\/span><\/p>\n<p><b>Correct Answer: 3)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Using managed authentication mechanisms such as appropriately configured service connections or managed identity-based authentication can reduce the need to place long-lived credentials directly in pipeline scripts. Hard-coded passwords and credentials stored in source control create significant security risks because they can be exposed through repository history or logs. Centralized authentication mechanisms also make permissions easier to manage and audit. The exact authentication option depends on the Azure resource and pipeline architecture, but the general principle is to avoid embedding secrets directly into scripts. Therefore, using controlled identity-based authentication is a more secure approach to accessing Azure resources.<\/span><\/p>\n<h3><b>Q67. What is the primary purpose of code coverage reporting in a CI pipeline?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Measure how much of the code is exercised by tests<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Determine the number of developers<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Store deployment credentials<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Increase server capacity<\/span><\/p>\n<p><b>Correct Answer: 1)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Code coverage reporting indicates how much of an application&#8217;s source code is exercised when automated tests run. Teams can use coverage results to identify areas of code that may not have sufficient test coverage. Coverage does not prove that an application is defect-free, because a test can execute code without adequately validating its behavior. However, it provides a useful quality indicator when combined with test results and other engineering practices. Code coverage can also be incorporated into quality gates when organizations require minimum thresholds. Therefore, its primary purpose is to measure the portion of code exercised by automated tests.<\/span><\/p>\n<h3><b>Q68. Which Azure Pipelines option is most appropriate when a team needs complete control over installed software and network access on the build machine?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Microsoft-hosted agent<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Self-hosted agent<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Scheduled trigger<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Pipeline artifact<\/span><\/p>\n<p><b>Correct Answer: 2)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A self-hosted agent is appropriate when an organization requires greater control over the build or deployment machine. Teams can install specific software, SDK versions, command-line tools, certificates, or custom dependencies and can configure network connectivity according to organizational requirements. Self-hosted agents are also useful when pipeline jobs must access internal systems that cannot be reached from standard hosted infrastructure. The trade-off is that the organization becomes responsible for maintaining, securing, updating, and monitoring the agent. Therefore, a self-hosted agent is the best choice when specialized software or network requirements demand control over the execution environment.<\/span><\/p>\n<h3><b>Q69. What is the main purpose of using semantic versioning for application packages?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Encrypt package contents<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Identify package versions in a consistent and meaningful way<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Replace automated testing<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Configure deployment approvals<\/span><\/p>\n<p><b>Correct Answer: 2)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Semantic versioning provides a consistent method for identifying software releases using version numbers that communicate the type of change introduced. A commonly used structure is major, minor, and patch versions. Major changes generally indicate potentially breaking changes, while minor versions typically represent backward-compatible functionality and patch versions commonly represent fixes. Consistent package versioning makes it easier for teams and dependency-management systems to understand which package release is being consumed. Semantic versioning does not encrypt packages, replace testing, or configure deployment approvals. Its primary purpose is to provide a predictable and meaningful approach to identifying software versions.<\/span><\/p>\n<h3><b>Q70. Which practice helps ensure that production configuration changes are managed separately from application source code?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Configuration management<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Code duplication<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Manual source editing<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Removing environment variables<\/span><\/p>\n<p><b>Correct Answer: 1)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Configuration management separates environment-specific settings from application source code so the same application package can be deployed across different environments with appropriate configuration. Examples include database endpoints, service URLs, feature settings, and other environment-specific values. Keeping these settings separate reduces the need to modify source code for each deployment and improves consistency between environments. Configuration can be managed through pipeline variables, variable groups, configuration services, or other approved mechanisms. Manual source editing can introduce errors and reduce traceability. Therefore, configuration management is the recommended practice for handling environment-specific settings independently from application source code.<\/span><\/p>\n<h3><b>Q71. Which testing activity is designed to verify that an application continues to work after new changes are introduced?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Regression testing<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Capacity planning<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Secret scanning<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Package publishing<\/span><\/p>\n<p><b>Correct Answer: 1)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Regression testing verifies that existing application functionality continues to work after new code or configuration changes are introduced. New changes can unintentionally affect functionality that previously worked correctly, so regression tests help detect these side effects. Automated regression tests are particularly valuable in CI\/CD pipelines because they can run repeatedly whenever changes are submitted. Capacity planning focuses on resource requirements, secret scanning detects exposed credentials, and package publishing manages build outputs. Therefore, regression testing is an important quality practice for ensuring that new changes do not unintentionally break existing application behavior.<\/span><\/p>\n<h3><b>Q72. What does a deployment job in Azure Pipelines primarily represent?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> A source-code repository<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> A collection of work items<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> A job designed to deploy resources to an environment<\/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: 3)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A deployment job is a specialized Azure Pipelines job designed to perform deployments to an environment. It can work with environment resources and supports deployment-related capabilities such as deployment history, approvals, and checks. Deployment jobs are useful in multi-stage pipelines because they clearly separate deployment activities from ordinary build or test operations. A source repository stores application code, work items track project tasks, and package feeds store software packages. By using deployment jobs, teams can create more structured release workflows and gain better visibility into environment deployments. Therefore, a deployment job primarily represents work associated with deploying an application or infrastructure.<\/span><\/p>\n<h3><b>Q73. Which security practice is most closely associated with analyzing source code for known insecure coding patterns?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Dynamic load testing<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Static application security testing<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Deployment frequency<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Environment approval<\/span><\/p>\n<p><b>Correct Answer: 2)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Static application security testing, commonly called SAST, analyzes application source code or related representations to identify potentially insecure coding patterns without necessarily executing the application. It can detect issues such as certain injection risks, insecure functions, or other patterns associated with vulnerabilities. Integrating SAST into CI pipelines allows security checks to occur earlier in the development lifecycle, supporting a shift-left security approach. Dynamic testing evaluates an application while it is running, while deployment frequency and environment approvals address delivery processes rather than source-code security analysis. Therefore, SAST is the appropriate practice for identifying security weaknesses through source-code analysis.<\/span><\/p>\n<h3><b>Q74. What is the main purpose of retaining pipeline artifacts for a defined period?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Allow historical build outputs to remain available for troubleshooting, auditing, or redeployment<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Increase source-code complexity<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Automatically approve every deployment<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Replace version control<\/span><\/p>\n<p><b>Correct Answer: 1)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Artifact retention policies determine how long generated build and pipeline artifacts remain available. Keeping artifacts for an appropriate period can support troubleshooting, auditing, release investigation, and redeployment of previously generated outputs. For example, if a production issue is discovered, a team may need access to the exact package that was previously deployed. At the same time, retaining artifacts indefinitely can consume unnecessary storage, so organizations commonly establish policies based on business and operational requirements. Artifact retention does not replace source control or automatically approve deployments. Its primary purpose is to maintain useful historical build outputs for an appropriate period.<\/span><\/p>\n<h3><b>Q75. Which DevOps practice encourages identifying and addressing security issues early in the development lifecycle?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Shift-left security<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Manual deployment only<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Delayed testing<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Production-only validation<\/span><\/p>\n<p><b>Correct Answer: 1)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Shift-left security means integrating security activities earlier in the software development lifecycle instead of waiting until an application is ready for production. Security checks can be included in source control workflows, pull requests, CI pipelines, dependency management, and build processes. Examples include secret scanning, dependency vulnerability scanning, static application security testing, and container image scanning. Detecting issues earlier generally makes them easier and less costly to address. Waiting until production can allow vulnerabilities to progress further through the delivery process. Therefore, shift-left security is the practice of moving security validation earlier into development and CI\/CD workflows.<\/span><\/p>\n<h3><b>Q76. Which Azure DevOps feature can be used to connect pipeline events with external systems through HTTP-based notifications?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Service hooks<\/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;\"> Agent pools<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Test plans<\/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 hooks can send notifications to external services when specific events occur. Organizations can use them to integrate Azure DevOps with other applications, automation systems, collaboration platforms, or monitoring solutions. For example, an event involving a work item, build, release, or repository activity can trigger a configured external action. Service hooks help connect DevOps workflows with broader organizational processes. Variable groups manage reusable configuration, agent pools manage execution resources, and test plans support testing activities. Therefore, service hooks are the appropriate Azure DevOps capability when pipeline or project events need to communicate with external systems.<\/span><\/p>\n<h3><b>Q77. Which practice helps a team identify whether a deployment introduced an application failure?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Increasing the number of source files<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Monitoring deployment outcomes and application telemetry<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Removing automated tests<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Disabling logging<\/span><\/p>\n<p><b>Correct Answer: 2)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Monitoring deployment outcomes and application telemetry provides visibility into application behavior after changes are released. Metrics, logs, traces, alerts, and health indicators can help teams determine whether a deployment caused errors, performance degradation, or service interruptions. This information is especially valuable when combined with deployment records so that teams can correlate changes with observed incidents. Removing tests or disabling logging would make troubleshooting more difficult. Increasing source-file counts has no direct relationship to identifying deployment failures. Therefore, monitoring and telemetry are important practices for detecting and investigating problems that may have been introduced by a deployment.<\/span><\/p>\n<h3><b>Q78. What is the main purpose of using an Infrastructure as Code template in a deployment pipeline?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Manually configure every server<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Define infrastructure resources in a repeatable, version-controlled manner<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Replace application testing<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Store user passwords in source code<\/span><\/p>\n<p><b>Correct Answer: 2)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Infrastructure as Code allows infrastructure resources and their configuration to be described through code or declarative templates. These definitions can be stored in source control, reviewed, versioned, and deployed repeatedly through automated pipelines. This approach helps reduce configuration drift and improves consistency between environments. Depending on the platform, teams can use technologies such as Bicep, ARM templates, Terraform, or other infrastructure automation tools. IaC does not replace application testing and should never be used as a reason to store passwords directly in source code. Therefore, its primary purpose is to provide repeatable and version-controlled infrastructure provisioning.<\/span><\/p>\n<h3><b>Q79. Which metric measures the percentage of deployments that result in a failure or require remediation?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Deployment frequency<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Mean time to restore<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Change failure rate<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Lead time for changes<\/span><\/p>\n<p><b>Correct Answer: 3)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Change failure rate measures the proportion of deployments or changes that result in failures requiring remediation, rollback, or other corrective action. It is an important indicator of software delivery quality because deployment speed alone does not show whether changes are reliable. A team may deploy frequently but still experience poor outcomes if many deployments introduce problems. Deployment frequency measures how often deployments occur, mean time to restore focuses on recovery speed, and lead time measures the time required to deliver changes. Therefore, change failure rate is the metric that specifically evaluates how often deployments result in failures or require corrective action.<\/span><\/p>\n<h3><b>Q80. Which approach provides the strongest traceability between a code change, its build, and the resulting deployment?<\/b><\/h3>\n<p><b>1)<\/b><span style=\"font-weight: 400;\"> Building manually without records<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>2)<\/b><span style=\"font-weight: 400;\"> Using independent deployment packages with no versioning<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>3)<\/b><span style=\"font-weight: 400;\"> Linking commits, pipeline runs, artifacts, and deployments<\/span><span style=\"font-weight: 400;\"><br \/>\n<\/span> <b>4)<\/b><span style=\"font-weight: 400;\"> Deleting pipeline history after every release<\/span><\/p>\n<p><b>Correct Answer: 3)<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Linking source-code commits, pipeline runs, generated artifacts, and deployment records provides strong end-to-end traceability. This allows a team to determine which source revision produced a particular build, which artifact was tested, and where that artifact was deployed. Such traceability is valuable for troubleshooting, auditing, compliance, and release management. Automated pipelines can preserve these relationships more consistently than manual processes. Using unversioned packages or deleting pipeline history makes it difficult to reconstruct what happened during a release. Therefore, connecting commits, builds, artifacts, and deployments provides a reliable foundation for understanding the complete path of a software change.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>View Full Microsoft AZ-400 Exam Dumps and Practice Test Dumps &nbsp; Q61. Which Azure Pipelines component defines the individual actions performed within a job? 1) Tasks 2) Stages 3) Environments 4) Repositories Correct Answer: 1) Explanation: Tasks are the individual units of work executed by Azure Pipelines jobs. A task can perform a specific operation [&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\/12522"}],"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=12522"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/12522\/revisions"}],"predecessor-version":[{"id":12539,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/12522\/revisions\/12539"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=12522"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=12522"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=12522"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}