AZ-204 Develop for Azure storage Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Apply Azure Information Protection labels to the storage account.

  Why it's wrong here

  Azure Information Protection (AIP) is primarily designed for classifying, labeling, and protecting documents and emails, applying encryption and access policies at the file or content level. While it helps manage sensitive data, it does not directly provide encryption for the underlying storage account at rest or manage authentication and authorization for accessing the storage service itself. It operates on the content, not the storage infrastructure.

• ✓

  Enable Azure Storage Service Encryption (SSE) and use Microsoft Entra ID for authentication.

  Why this is correct

  Enabling Azure Storage Service Encryption (SSE) ensures that all data written to Azure Storage is automatically encrypted at rest using Microsoft-managed keys or customer-managed keys via Azure Key Vault. Coupled with Microsoft Entra ID for authentication, this provides robust identity-based access control (RBAC) to the storage account and its contents. This combination offers a secure, scalable, and fully managed solution for protecting sensitive user data.

• ✗

  Implement client-side encryption using the Azure Storage SDK and manage keys via Azure Key Vault.

  Why it's wrong here

  Implementing client-side encryption provides an additional layer of security by encrypting data *before* it leaves the client application, ensuring data is encrypted in transit and at rest from the client's perspective. However, this approach adds significant development complexity and key management overhead for the application developer, as the data is already encrypted at rest by Azure Storage Service Encryption (SSE) by default. It's often overkill unless specific regulatory requirements demand client-side control over encryption.

• ✗

  Use shared access signatures (SAS) with a stored access policy to limit access to the data.

  Why it's wrong here

  Shared Access Signatures (SAS) provide a way to grant limited, time-bound, and granular access to specific Azure Storage resources without sharing the storage account keys. While useful for delegating temporary access to clients or services, SAS tokens do not provide identity-based access control or integrate with Azure's Role-Based Access Control (RBAC) system for managing application permissions. They are a delegation mechanism, not a primary authentication or authorization solution for the application itself.

Go deeper

Related to this question