AZ-500 Secure compute, storage, and databases Practice Question
You need to ensure that all new blobs uploaded to an Azure Storage account are automatically encrypted at rest. What is the simplest way to achieve this?
⚠ Common exam trap
Candidates often confuse Azure Disk Encryption (which encrypts VM disks) with Storage Service Encryption (which encrypts data at rest in Azure Storage), leading them to select option A incorrectly.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Enable Azure Storage Service Encryption (SSE) on the storage account.
Azure Storage Service Encryption (SSE) automatically encrypts data at rest for all storage accounts using 256-bit AES encryption, and it is enabled by default for new storage accounts. This ensures that any new blobs uploaded are encrypted without requiring any application changes or additional configuration, making it the simplest solution.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use Azure Disk Encryption on any VMs writing to storage.
Why it's wrong here
Azure Disk Encryption (ADE) uses BitLocker on Windows or DM-Crypt on Linux to encrypt the OS and data disks attached to virtual machines, not the Azure Storage blobs those VMs may write to via SDK or tools. Blob data lives in the storage service's managed infrastructure, entirely separate from the VM's virtual hard disks. Even if ADE were applied, new blob uploads would still arrive at the storage account unencrypted by ADE, so this action cannot satisfy the requirement.
- ✗
Implement client-side encryption in the application.
Why it's wrong here
Client-side encryption in the application encrypts data before it is transmitted to Azure Storage, typically using the Azure Storage client library with a symmetric or asymmetric key. However, this approach is not automatic: it requires explicit code changes, key management, and application-level handling for every write operation. Since the requirement is that all new blobs are encrypted automatically, relying on client-side encryption forces every client to implement and maintain it, which does not guarantee coverage and is not the storage account's built-in protection.
- ✓
Enable Azure Storage Service Encryption (SSE) on the storage account.
Why this is correct
Azure Storage Service Encryption (SSE), now formally called Azure Storage encryption, is automatically enabled at the storage account level and transparently encrypts all data at rest—including blobs, files, queues, and tables—using AES-256 before it is written to disk. No extra configuration is needed for new blobs because encryption is applied by the platform on every write and decrypted on every read without any code changes. Ensuring that this setting is enabled (or simply confirming it is already on by default) directly guarantees that all new blob uploads are encrypted at rest.
- ✗
Configure a customer-managed key in Azure Key Vault.
Why it's wrong here
Configuring a customer-managed key (CMK) in Azure Key Vault changes how the encryption key for Azure Storage Service Encryption is managed, but it does not itself enable encryption. SSE is already on by default; a CMK only lets you bring your own key (BYOK) for envelope encryption, allowing key rotation, control, and auditing via Key Vault. If SSE were disabled (which is not possible for new accounts in practice), CMK alone would still not encrypt anything—CMK is a key-management overlay, not a separate encryption mechanism, so this option is incorrect as a standalone solution.
Quick reference
Symmetric Encryption Algorithm Comparison
| Algorithm | Key Size | Block Size | Status | Notes |
|---|---|---|---|---|
| AES-128 | 128-bit | 128-bit | Current standard | NIST approved; WPA3, TLS |
| AES-256 | 256-bit | 128-bit | Current standard | Preferred for sensitive / govt data |
| 3DES | 112-bit effective | 64-bit | Deprecated (2023) | Replaced by AES |
| DES | 56-bit | 64-bit | Broken | Cracked in < 24 h; never deploy |
| ChaCha20 | 256-bit | Stream cipher | Current | TLS 1.3, WireGuard |
Go deeper
Related to this question
About these practice questions
This AZ-500 question is part of Courseiva's 617-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-500 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-500 exam.