[AuthorizationPermissionMismatch]: This request is not authorized to perform this operation using this permission.

Based on the information provided, this does not appear to be a straightforward RBAC assignment issue, because:

• The iceDQ connection validates successfully.
• The issue is intermittent rather than consistently reproducible.
• Restarting the icedq-connection pod restores functionality.
• Preview Data and rule execution work again immediately after the restart.

That said, the AuthorizationPermissionMismatch error indicates that Azure Storage authenticated the request but rejected the specific operation because the effective permissions available to that request were insufficient. [cloudwebschool.com], [learn.microsoft.com]

Areas worth investigating

1. Credential or token refresh issues within iceDQ

Given that a pod restart resolves the problem, one possibility is that the connector is holding stale credentials or is not refreshing Azure AD access tokens correctly.

Things to look for in the pod logs before the restart:

• Token acquisition failures
• Token refresh failures
• Credential cache errors
• HTTP 401 or 403 responses from Azure Storage

The timing of failures versus successful requests may help determine whether credential refresh is involved.

2. Role assignment conditions

One detail that stands out in the screenshot is that the service principal appears to have a Role Assignment Condition applied.

Even if connection validation succeeds, Preview Data may perform additional operations such as:

• Blob enumeration
• Container enumeration
• Metadata retrieval
• Tag access
• Temporary write operations

If one of those operations falls outside the permissions allowed by the condition, Azure Storage can return AuthorizationPermissionMismatch for that specific request.

3. Different operations requiring different permissions:

Connection testing often performs only basic validation, whereas Preview Data may execute additional storage APIs.

Confirm which operation is failing by correlating the RequestId: 833b49b4-201e-0010-3251-3c835f000000

Check:

• Storage Account diagnostic logs
• Azure Monitor
• Log Analytics

This should reveal the exact Blob Storage action that received the 403 response.

4. Multiple pod or cached-session scenarios:

If the deployment is scaled, different pod instances may be using different cached credentials or sessions.

This could explain why:

• Some requests succeed
• Some requests fail
• Restarting the pod immediately restores access

Pls verify:

1. Review the icedq-connection pod logs immediately before restarting it.
2. Trace the failing Storage RequestId in diagnostic logs.
3. Determine the exact Blob Storage API being called during Preview Data.
4. Review the role assignment condition and verify that all Preview Data operations are permitted.
5. Confirm that the identity has the appropriate data-plane role for the operations being performed, such as:
   • Storage Blob Data Reader for read-only access.
   • Storage Blob Data Contributor if any write activity occurs.

Based on the symptoms, I would not conclude that permissions are missing outright. The stronger indicators are:

• Intermittent occurrence
• Successful connection tests
• Consistent recovery after restarting the icedq-connection pod

Those patterns suggest either a credential/token lifecycle issue within iceDQ or a storage operation that is being blocked by the role assignment condition for certain requests. Correlating the failing RequestId with Azure Storage diagnostics should help identify the exact operation that is triggering the AuthorizationPermissionMismatch response.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.