This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
A retailer runs a production catalog on an Azure Cosmos DB for NoSQL account in two specific Azure regions required by a data residency agreement. Several partner integrations authenticate with account keys, and the partners can't change their clients this year. The analytics team wants the catalog available for reporting in Microsoft Fabric. Which approach fits these constraints?
Keep the Azure Cosmos DB account and mirror its database into Fabric.
Migrate the catalog to Cosmos DB in Microsoft Fabric so the operational data and the analytics live in one workspace.
Run the reporting queries against the existing containers and provision extra throughput to absorb the load.
A team enables mirroring with Microsoft Entra ID authentication and assigns the Cosmos DB Built-in Data Contributor role to the identity Fabric connects with. Replication fails with an authorization error. What explains the failure?
Built-in Data Contributor grants write actions, and mirroring rejects an identity that can modify the source data.
Mirroring requires the readAnalytics data action, which neither built-in data role includes, so a custom role definition has to grant it alongside readMetadata.
readAnalytics
readMetadata
Data plane role assignments apply only to containers, so the assignment has to be repeated for every container being mirrored.
An analyst reports that a Power BI report built on a mirrored table looks out of date. The Monitor replication view shows the database and every table as Running, and the Last completed value on the relevant table is from two days ago. What's the most likely explanation to check first?
Replication stalls silently, because a healthy mirror refreshes its tables on a schedule regardless of source activity.
The Fabric capacity was paused, which is why the table stopped refreshing.
The source container might have had no writes for two days, because Last completed advances only when the source changes.
Several hours after mirroring a database with six containers, five tables show Running with the expected row counts and one shows zero rows replicated. What's the appropriate first action?
Stop replication on the mirrored database and start it again.
Deselect the affected container in the mirrored database and then reselect it.
Delete the container in Azure Cosmos DB and recreate it so mirroring detects it as a new container.
A catalog listing report reads a mirrored product table and expands the nested tags array with OPENJSON and CROSS APPLY. Reviewers notice that products the merchandising team knows exist are missing from the report. What change fixes it?
tags
OPENJSON
CROSS APPLY
Declare the element shape in an OPENJSON WITH clause instead of relying on auto schema inference.
WITH
Increase the declared column length to varchar(max) so longer tag values aren't truncated.
varchar(max)
Use OUTER APPLY rather than CROSS APPLY, so products with an empty tags array are kept with null tag columns.
OUTER APPLY
You must answer all questions before checking your work.
Was this page helpful?
Need help with this topic?
Want to try using Ask Learn to clarify or guide you through this topic?