Hi @Chris Middleton
Before you assign an Azure RBAC role to a security principal, determine the scope of access that the security principal should have. Best practices dictate that it's always best to grant only the narrowest possible scope. Azure RBAC roles defined at a broader scope are inherited by the resources beneath them.
You can scope access to Azure table resources at the following levels, beginning with the narrowest scope:
An individual table. ** At this scope, a role assignment applies to the specified table.
**The storage account. At this scope, a role assignment applies to all tables in the account.
The resource groups. ** At this scope, a role assignment applies to all of the tables in all of the storage accounts in the resource group.
**The subscription. At this scope, a role assignment applies to all of the tables in all of the storage accounts in all of the resource groups in the subscription.
A management group. At this scope, a role assignment applies to all of the tables in all of the storage accounts in all of the resource groups in all of the subscriptions in the management group.
For more information about scope for Azure RBAC role assignments, see Understand Scope for Azure RBAC.
You can't do it in the portal, but you should be able to do it with PowerShell or CLI - Assign an Azure role for access to table data (preview) - Azure Storage | Microsoft Learn
Regards,
Oury
it is quite easy to test: create new storage account with test tables (table1 and table2) and try to connect to it (e.g. from PowerShell) via connection string. After that switch to AAD, grant permissions for table2 only and check will the same PowerShell still work with both tables.