Databricks workspace inside a locked (ReadOnly) managed application never finalizes — is this supported?

We are an ISV packaging an Azure Databricks workspace as a Service Catalog managed application with lockLevel: ReadOnly. The workspace never reaches provisioningState: Succeeded: every Azure resource is created successfully — including Databricks' own managed resource group, the DBFS storage account, dbmanagedidentity, unity-catalog-access-connector, the subnet networkIntentPolicies, and Databricks' own system deny assignment — but the workspace stays at Accepted until ARM abandons the operation after ~2 hours ("The resource provision operation did not complete within the allowed timeout period") and the application lands Failed.

No AuthorizationFailed or denied operation appears in the activity log at resource-group or subscription scope at any point — the failure is completely silent from the customer side. The only logged caller is the Appliance Resource Provider polling the workspace.

The identical template succeeds in ~5 minutes when deployed directly, or via the same managed application with lockLevel: None. It reproduces with both a bare premium workspace and a fully VNet-injected private-link workspace (API 2024-05-01).

We have exhaustively tested the definition-side configuration surface — every variant hangs at the identical point:

• authorizations carve-out of the AzureDatabricks first-party SP (appId 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d) — verified present in the deny assignment's excludePrincipals.
• authorizations carve-out of the Databricks Resource Provider first-party SP (appId d9327919-6775-4843-9037-3fb0fb0473cb) — the identity we observe creating Databricks' own deny assignment during finalization.
• lockingPolicy.allowedActions = Microsoft.Databricks/*, Microsoft.Network/*, Microsoft.Storage/*, Microsoft.ManagedIdentity/*, Microsoft.Resources/*, Microsoft.OperationalInsights/* — verified as notActions on the live deny assignment, i.e. allowed for every principal.
• All of the above combined in one definition.
• lockingPolicy.allowedActions: ['*'] is rejected by the platform (InvalidAllowedCustomerAction: Action verb invalid: '*').

The hung and successful runs have identical resource inventories in both the managed RG and Databricks' second managed RG — the only difference is the workspace's final Accepted → Succeeded state flip, which never happens under the deny assignment.

Questions:

1. Is deploying Microsoft.Databricks/workspaces inside a locked managed application a supported scenario? If not, can this limitation be documented (Managed Applications + Azure Databricks docs currently say nothing)?
2. What operation/identity is being blocked during workspace finalization? Nothing is visible from the customer side, which makes this undiagnosable.
3. If it is supportable, what authorizations / lockingPolicy configuration makes it work?
4. Could the failure be made fast and actionable instead of a silent multi-hour hang?
5. Does the Marketplace publisher-managed variant behave any differently from Service Catalog here?

We are an ISV packaging an Azure Databricks workspace as a Service Catalog managed application with lockLevel: ReadOnly. The workspace never reaches provisioningState: Succeeded: every Azure resource is created successfully — including Databricks' own managed resource group, the DBFS storage account, dbmanagedidentity, unity-catalog-access-connector, the subnet networkIntentPolicies, and Databricks' own system deny assignment — but the workspace stays at Accepted until ARM abandons the operation after ~2 hours ("The resource provision operation did not complete within the allowed timeout period") and the application lands Failed.

No AuthorizationFailed or denied operation appears in the activity log at resource-group or subscription scope at any point — the failure is completely silent from the customer side. The only logged caller is the Appliance Resource Provider polling the workspace.

The identical template succeeds in ~5 minutes when deployed directly, or via the same managed application with lockLevel: None. It reproduces with both a bare premium workspace and a fully VNet-injected private-link workspace (API 2024-05-01).

We have exhaustively tested the definition-side configuration surface — every variant hangs at the identical point:

1. authorizations carve-out of the AzureDatabricks first-party SP (appId 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d) — verified present in the deny assignment's excludePrincipals.
2. authorizations carve-out of the Databricks Resource Provider first-party SP (appId d9327919-6775-4843-9037-3fb0fb0473cb) — the identity we observe creating Databricks' own deny assignment during finalization.
3. lockingPolicy.allowedActions = Microsoft.Databricks/*, Microsoft.Network/*, Microsoft.Storage/*, Microsoft.ManagedIdentity/*, Microsoft.Resources/*, Microsoft.OperationalInsights/* — verified as notActions on the live deny assignment, i.e. allowed for every principal.
4. All of the above combined in one definition.
5. lockingPolicy.allowedActions: ['*'] is rejected by the platform (InvalidAllowedCustomerAction: Action verb invalid: '*').

The hung and successful runs have identical resource inventories in both the managed RG and Databricks' second managed RG — the only difference is the workspace's final Accepted → Succeeded state flip, which never happens under the deny assignment.

Questions:

1. Is deploying Microsoft.Databricks/workspaces inside a locked managed application a supported scenario? If not, can this limitation be documented (Managed Applications + Azure Databricks docs currently say nothing)?
2. What operation/identity is being blocked during workspace finalization? Nothing is visible from the customer side, which makes this undiagnosable.
3. If it is supportable, what authorizations / lockingPolicy configuration makes it work?
4. Could the failure be made fast and actionable instead of a silent multi-hour hang?
5. Does the Marketplace publisher-managed variant behave any differently from Service Catalog here?