AZ-400 Question 179
Single answerYou manage a multi-stage Azure DevOps pipeline for a .NET Core web application that relies on an Azure SQL Database. The pipeline builds the code, runs unit tests, and then deploys the application to a QA environment for integration testing. You now want to automate database schema updates using a DACPAC file if the new schema passes the integration tests, ensuring the changes are easily configurable and auditable. Which approach should you recommend implementing for the pipeline?
- A
Use the built-in Azure SQL Database Deployment task in the stage after the integration tests pass.
- B
Use a script from the Build stage to apply database schema changes to every environment directly.
- C
Manually run database update scripts in each environment after tests complete.
- D
Embed the database schema update logic in the web application� startup code so it runs automatically on application launch.
Show answer and explanation
Correct answer: A
Explanation
Using the Azure SQL Database Deployment task in an Azure DevOps pipeline is a best practice for automating database changes. It allows you to integrate DACPAC-based deployments seamlessly into your CI/CD processes after successful integration testing. This approach is documented in the official Microsoft documentation (https://learn.microsoft.com/azure/devops/pipelines/tasks/deploy/sql-azure-dacpac-deployment) and ensures repeatable, auditable database deployments with minimal risk.
- A. Correct.
Correct: The built-in Azure SQL Database Deployment task (such as SqlAzureDacpacDeployment@ in YAML) is designed specifically for automating database change deployments. Placing this task in the stage after integration tests ensures that only validated code triggers the database updates. It also provides clear traceability and auditing in Azure DevOps.
- B. Incorrect.
Incorrect: Running the schema update script from the Build stage for every environment is not recommended. Database changes should be applied after tests, and each environment might require unique settings (e.g., security or connection strings). Bundling all database deploys in the Build stage can cause unnecessary risk if the code is not fully tested.
- C. Incorrect.
Incorrect: Manually running scripts in each environment negates the benefits of continuous integration and delivery. This approach is error-prone and does not provide automated traceability or standardized deployment practices.
- D. Incorrect.
Incorrect: Embedding database updates in the web application startup code can lead to unpredictable deployments and potential downtime. It also mixes application logic with database migration logic, which is harder to manage, audit, and troubleshoot.