1. A Fabric workspace is configured with a database project for a SQL analytics endpoint. A data engineer wants to publish schema changes (adding a new table and modifying a stored procedure) to the Test workspace without affecting the Production workspace. Which approach follows best practice for schema management using database projects in Fabric?
- A. Make the schema changes directly in the Production SQL analytics endpoint and then export a DACPAC to apply to Test
- B. Edit the database project files locally, commit to a feature branch, create a pull request to the test branch, and use the deployment pipeline to promote to Test after review✓ Correct
- C. Use the Fabric Admin portal to clone the Production workspace schema to Test, then apply changes in the Test workspace directly
- D. Modify the schema in the Development workspace SQL analytics endpoint manually, then copy the DDL scripts and run them manually in Test and Production
Explanation
The best practice is to manage schema changes as code in the database project, use Git branching (feature → test branch) with pull requests for review, and use deployment pipelines to promote validated changes to each stage. This ensures traceability, peer review, and consistent promotion. Making changes directly in Production (A) bypasses change control and risks errors. The Fabric Admin portal (C) does not offer a 'clone workspace schema' feature. Manual DDL script copying (D) is error-prone, lacks version control, and does not scale in team environments.