Repo sync for protected branch

data-explorer/business-continuity-overview.md

@@ -13,7 +13,7 @@ ms.custom:
 
 # Business continuity and disaster recovery overview
 
-Business continuity and disaster recovery in Azure Data Explorer enables your business to continue operating in the face of a disruption. This article discusses availability (intra-region) and disaster recovery. It details native capabilities and architectural considerations for a resilient Azure Data Explorer deployment. It details recovery from human errors, high availability, followed by multiple disaster recovery configurations. These configurations depend on resiliency requirements such as Recovery Point Objective (RPO) and Recovery Time Objective (RTO), needed effort, and cost.
+Business continuity and disaster recovery in Azure Data Explorer enables your business to continue operating in the face of a disruption. This article discusses availability (intra-region) and disaster recovery. It details native capabilities and architectural considerations for a reliable Azure Data Explorer deployment. It details recovery from human errors, high availability, followed by multiple disaster recovery configurations. These configurations depend on recoverability requirements such as Recovery Point Objective (RPO) and Recovery Time Objective (RTO), needed effort, and cost.
 
 ## Mitigate disruptive events
 
@@ -75,7 +75,7 @@ Azure Data Explorer doesn't provide automatic protection against the outage of a
 
 ## Disaster recovery configurations
 
- This section details multiple disaster recovery configurations depending on resiliency requirements (RPO and RTO), needed effort, and cost.
+ This section details multiple disaster recovery configurations depending on recoverability requirements (RPO and RTO), needed effort, and cost.
 
 Recovery time objective (RTO) refers to the time to recover from a disruption. For example, RTO of 2 hours means the application has to be up and running within two hours of a disruption. Recovery point objective (RPO) refers to the interval of time that might pass during a disruption before the quantity of data lost during that period is greater than the allowable threshold. For example, if the RPO is 24 hours, and an application has data beginning from 15 years ago, they're still within the parameters of the agreed-upon RPO.
 
@@ -119,7 +119,7 @@ The Active-Hot configuration is similar to the [Active-Active configuration](#ac
 
 ### On-demand data recovery configuration
 
-This solution offers the least resiliency (highest RPO and RTO), is the lowest in cost and highest in effort. In this configuration, there's no data recovery cluster. Configure continuous export of curated data (unless raw and intermediate data is also required) to a storage account that is configured GRS (Geo Redundant Storage). A data recovery cluster is spun up if there's a disaster recovery scenario. At that time, DDLs, configuration, policies, and processes are applied. Data is ingested from storage with the ingestion property [kustoCreationTime](ingest-data-event-grid-overview.md) to override the ingestion time that defaults to system time.
+This solution offers the least recoverability (highest RPO and RTO), is the lowest in cost and highest in effort. In this configuration, there's no data recovery cluster. Configure continuous export of curated data (unless raw and intermediate data is also required) to a storage account that is configured GRS (Geo Redundant Storage). A data recovery cluster is spun up if there's a disaster recovery scenario. At that time, DDLs, configuration, policies, and processes are applied. Data is ingested from storage with the ingestion property [kustoCreationTime](ingest-data-event-grid-overview.md) to override the ingestion time that defaults to system time.
 
 :::image type="content" source="media/business-continuity-overview/on-demand-data-recovery-cluster.png" alt-text="On-demand data recovery cluster configuration.":::
 
@@ -129,7 +129,7 @@ This solution offers the least resiliency (highest RPO and RTO), is the lowest i
 
 ### Summary of disaster recovery configuration options
 
-| **Configuration** | **Resiliency** | **RPO** | **RTO** | **Effort** | **Cost** |
+| **Configuration** | **Recoverability** | **RPO** | **RTO** | **Effort** | **Cost** |
 | --- | --- | --- | --- | --- | --- |
 | **Active-Active-Active-n** | Highest | 0 hours | 0 hours | Lower | Highest |
 | **Active-Active** | High | 0 hours | 0 hours | Lower | High |

data-explorer/kusto/management/data-export/continuous-data-export.md

@@ -102,12 +102,14 @@ Followed by:
 ```
 
 ::: moniker range="azure-data-explorer"
+
 ## Continuous export from a table with Row Level Security
 
 To create a continuous export job with a query that references a table with [Row Level Security policy](../../management/row-level-security-policy.md), you must:
 
 * Provide a managed identity as part of the continuous export configuration. For more information, see [Use a managed identity to run a continuous export job](continuous-export-with-managed-identity.md).
 * Use [impersonation](../../api/connection-strings/storage-connection-strings.md#impersonation) authentication for the external table to which the data is exported.
+
 ::: moniker-end
 
 ## Continuous export to delta table - Preview
@@ -159,15 +161,25 @@ To define continuous export to a delta table, do the following steps:
 
 **Policies**:
 
+:::moniker range="azure-data-explorer"
+
 * Continuous export can't be enabled on a table with [Row Level Security policy](../../management/row-level-security-policy.md) unless specific conditions are met. For more information, see [Continuous export from a table with Row Level Security](#continuous-export-from-a-table-with-row-level-security).
 * Continuous export can't be configured on a table with [restricted view access policy](../restricted-view-access-policy.md).
 
+::: moniker-end
+:::moniker range="microsoft-fabric"
+
+* Continuous export can't be configured on a table with [restricted view access policy](../restricted-view-access-policy.md).
+
+::: moniker-end
+
 ## Related content
 
 :::moniker range="microsoft-fabric"
 
 * [.create or alter continuous-export](create-alter-continuous.md)
 * [External tables](../../query/schema-entities/external-tables.md)
+
 :::moniker-end
 
 :::moniker range="azure-data-explorer"

data-explorer/kusto/management/row-level-security-policy.md

@@ -38,9 +38,9 @@ For more information, see [management commands for managing the Row Level Securi
 * There's no limit on the number of tables on which Row Level Security policy can be configured.
 * Row Level Security policy cannot be configured on [External Tables](../query/schema-entities/external-tables.md).
 * The RLS policy can't be enabled on a table under the following circumstances:
-  * When it's referenced by an [update policy](update-policy.md) query, while the update policy is not configured with a managed identity.
-  * When it's referenced by a [continuous export](../management/data-export/continuous-data-export.md) that uses an authentication method other than impersonation.
-  * When a [restricted view access policy](restricted-view-access-policy.md) is configured for the table.
+  * The table is referenced by an [update policy](update-policy.md) that doesn’t use a managed identity. A managed identity is required so the engine can securely determine which rows from the referenced tables are allowed to be queried.
+  * The table is referenced by a [continuous export](../management/data-export/continuous-data-export.md) that doesn't uss the `impersonate` authentication method. Impersonation ensures that only users who have access to the target storage account can read the exported (and potentially sensitive) data.
+  * The table has [restricted view access policy](restricted-view-access-policy.md) configured.
 * The RLS query can't reference other tables that have Row Level Security policy enabled.
 * The RLS query can't reference tables located in other databases.
 

data-explorer/kusto/query/join-cross-cluster.md

@@ -3,7 +3,7 @@ title:  Cross-cluster join
 description: Learn how to perform the Cross-cluster join operation to join datasets residing on different clusters.
 ms.reviewer: alexans
 ms.topic: reference
-ms.date: 01/26/2025
+ms.date: 01/26/2026
 monikerRange: "microsoft-fabric || azure-data-explorer"
 ---
 # Cross-cluster join
@@ -32,6 +32,9 @@ The cluster that runs the query fetches the data from the other cluster.
 
 [!INCLUDE [syntax-conventions-note](../includes/syntax-conventions-note.md)]
 
+> [!NOTE]
+> join hints (including hint.remote) are order‑independent and can appear before or after the kind parameter.
+
 ## Parameters
 
 |Name|Type|Required|Description|

data-explorer/kusto/query/jsonpath.md

@@ -50,7 +50,12 @@ Given the following JSON document:
       "User ID": "user123",
       "Username": "kiana_anderson",
       "IP Address": "192.168.1.100"
-    }
+    },
+    "Tags": [
+      "startup",
+      "auth",
+      "performance"
+    ]
   }
 }
 ```
@@ -69,6 +74,7 @@ You can represent each of the fields with JSONPath notation as follows:
 "$.Details.User['User ID']"    // User ID field
 "$.Details.User.Username"      // Username field
 "$.Details.User['IP Address']" // IP Address field
+"$.Tags[0]"                    // First value in the array of the Tags
 ```
 
 ## Related content