You have an Azure subscription that contains a storage account named storage1 and two web apps named app1 and app2.
Both apps will write data to storage1.
You need to ensure that each app can read only the data that it has written.
What should you do?
To ensure that each app can read only the data that it has written, you should provide each app with a unique Base64-encoded AES-256 encryption key and configure the app to send the key with each request. By using unique encryption keys for each app, you can create secure boundaries around the data, ensuring that only the app that wrote the data can decrypt and read it. This approach enables fine-grained control over data access within the same storage account.
I think the answer is D. Can make use of "Encryption Scopes". https://docs.microsoft.com/en-us/azure/storage/blobs/encryption-scope-overview
The question can be seen as having two complementary answers. Answer C (provide each application with a managed identity and configure storage1 to use Azure AD authentication) is the essential part of the solution to ensure that each application can securely authenticate itself and access data. However, answer D (giving each application an encryption key) is also an important part of the solution because encryption helps ensure that only the application that wrote the data can read it. Therefore, both answers C and D are complementary and together form a comprehensive solution to meet the requirements of the question. Microsoft's official answer seems to focus more on the managed identity part (answer C), but the community also highlights the importance of encryption (answer D), which is valid for ensuring data security.
D is the answer. https://learn.microsoft.com/en-us/azure/storage/blobs/encryption-scope-overview Encryption scopes enable you to manage encryption with a key that is scoped to a container or an individual blob. You can use encryption scopes to create secure boundaries between data that resides in the same storage account but belongs to different customers.
I think C. System Assigned identities are mutable. User-assigned can be used persistently to assign File permissions. D is about the storage encryption itself, not RBAC for storage access.
ANS - A a system manage id can be associated with one resource. so app 1 with a system managed id, will be allowed access to the storage with an RBAC role. similarly app 2 will have another sys managed id and has access to storage with RBAC. each sys managed id are two different service principals. so each app writes to storage using the sys id, can read only that. Where as a user assigned managed id can be associated with multiple resources.
Why many people here voted D? Encrypt the data never used for to control the access right. C makes more sense as we can use RBAC (with user's MI) to grant the required access.
This is not control plane, it's data plane. Inside the same storage, on the same blob container, 2 apps write, but each app can only read the content it has written itself.
Answer: D Explanation: https://docs.microsoft.com/en-us/azure/storage/blobs/encryption-scope-overview "Encryption scopess enable you to manage encryption with a key that is scoped to a container or an individual blob. You can use encryption scopes to create secure boundaries between data that resides in the same storage account but belongs to different customers."
Encryption scopes enable you to manage encryption with a key that is scoped to a container or an individual blob. You can use encryption scopes to create secure boundaries between data that resides in the same storage account but belongs to different customers.
Letter B. Option B is the correct approach to ensure that each app can read only the data it has written to the storage account. By providing each app with a separate Storage account key and configuring the app to send the key with each request, you're essentially implementing per-app authentication and authorization for accessing the storage account.
D. Provide each app with a unique Base64-encoded AES-256 encryption key and configure the app to send the key with each request.
I think user and system assigned managed identities can be used question more likely asking about encryption scopes which is possible with option D, technically A and C also work and they are same and both can be used in this scope but question does not say will both application use same blob to write data or not , if it will use same blob then with system assigned and user assigned managed identities will be useless because let’s say both app1 and app2 write data into blob1 which is inside storage1 , if we use managed identity then when will grant access to identity it will automatically have access both data which is inside this is not going to work . In this scenario and even separate blob scenario we can use encryption scope which will allow apps read data that it is written by specific app.
Answer is D.. below is the explanation Clients making requests against Azure Blob storage can provide an AES-256 encryption key to encrypt that blob on a write operation. Subsequent requests to read or write to the blob must include the same key. Including the encryption key on the request provides granular control over encryption settings for Blob storage operations. Customer-provided keys can be stored in Azure Key Vault or in another key store. https://learn.microsoft.com/en-us/azure/storage/blobs/encryption-customer-provided-keys
based on the question, both apps can reach same StorageAccount with may full permissions (read-write). Let them only read data they written is giving them Base64-encoded AES-256 encryption key. So, App1 can't read App2's created files without correct Base64-encoded AES-256 encryption key. I also asked this to copilot and AI corrected itself after my feedback :) "You are correct! I apologize for the oversight. The option to provide each app with a unique Base64-encoded AES-256 encryption key indeed aligns with the goal of ensuring that each app can read only the data it has written to storage1. By using unique encryption keys, you can achieve fine-grained control over data access, allowing each app to access only its own data within the storage account. Thank you for pointing that out! "
The correct answer is C. Provide each app with a user-managed identity and configure storage1 to use Azure AD User account authentication. Azure Active Directory (Azure AD) authentication is a mechanism of connecting to Azure Storage by using identities defined in Azure AD. It allows you to use a user-managed identity for your apps, which provides a managed identity for Azure resources. By assigning a managed identity to your apps, you can authenticate to any service that supports Azure AD authentication without having any credentials in your code.
D) You can set permissions against the containers within the storage accts that would suffice the request by only allowing, lets say, app 1 to read/write against SA1 but that is not what the question is technically asking. If we chose to go that route I would say System Assigned MI because nothing is being shared. Still, for this question I would say encryption keys because it servers two purposes. Encryption at Rest and it ensures only the app with the key that encrypted the data can decrypt the data.
Maybe it's an error and in the exam with can choose both ? C and D ? Like an UMI (C) to connect to the storage account and then the key (D) to setup client side encryption: https://www.lytzen.name/2022/04/06/blob-storage-client-side-encryption.html
Can i suggest this? B, It involves providing each app with a separate Storage account key and configuring the app to send the key with each request. This ensures that each app can only access the data it has written to the storage account. We are talking about restricting to the APPs, not to restrict to users or other objects at the account level, it is only at the APP level.