You have a semantic model that pulls data from an Azure SQL database and is synced via Fabric deployment pipelines to Development, Test, and Production workspaces. You need to reduce the size of the query requests sent to the Azure SQL database when full semantic model refreshes occur in Development or Test. What should you do for the deployment pipeline?

You have a semantic model that pulls data from an Azure SQL database and is synced via Fabric deployment pipelines to Development, Test, and Production workspaces. You need to reduce the size of the query requests sent to the Azure SQL database when full semantic model refreshes occur in Development or Test. What should you do for the deployment pipeline?

• A. Increase batch size
• B. Add a deployment parameter rule to filter the data
• C. Disable caching
• D. Use a smaller dataset

Answer: (B)

The idea being tested is using deployment parameters to limit the amount of data loaded during a refresh. By adding a deployment parameter rule that filters the data specifically for Development and Test workspaces, the semantic model will pull only a subset of the Azure SQL data during full refreshes. This directly reduces the size of the query requests sent to the database because the queries now include a filter (such as a date range, a subset of customers, or other criteria) tailored to those environments. It keeps Production unchanged while ensuring Dev/Test get faster refreshes with smaller payloads. Increasing batch size would raise the amount of data moved per request, not reduce it. Disabling caching affects performance and whether results are stored for reuse, but not the actual data size of the query. Using a smaller dataset without a deployment parameter approach is less precise and harder to enforce consistently across environments. Implementing a deployment parameter rule provides a clean, maintainable way to constrain data specifically for non-production refreshes.

The idea being tested is using deployment parameters to limit the amount of data loaded during a refresh. By adding a deployment parameter rule that filters the data specifically for Development and Test workspaces, the semantic model will pull only a subset of the Azure SQL data during full refreshes. This directly reduces the size of the query requests sent to the database because the queries now include a filter (such as a date range, a subset of customers, or other criteria) tailored to those environments. It keeps Production unchanged while ensuring Dev/Test get faster refreshes with smaller payloads.

Increasing batch size would raise the amount of data moved per request, not reduce it. Disabling caching affects performance and whether results are stored for reuse, but not the actual data size of the query. Using a smaller dataset without a deployment parameter approach is less precise and harder to enforce consistently across environments. Implementing a deployment parameter rule provides a clean, maintainable way to constrain data specifically for non-production refreshes.