AZ-500 Secure compute, storage, and databases Practice Question
You are designing a security solution for Azure Cosmos DB that stores Personally Identifiable Information (PII). You need to encrypt data at rest and in transit. You also need to implement row-level security to restrict access based on user role. What should you configure?
⚠ Common exam trap
Many exam-takers confuse Cosmos DB with SQL-based services and incorrectly assume features like Always Encrypted or Dynamic Data Masking apply, when in reality Cosmos DB relies on automatic encryption and application-layer row-level security.
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
✓
Encryption at rest is automatically enabled; enforce TLS for transit; implement row-level security via application code.
Azure Cosmos DB automatically encrypts data at rest using AES-256 encryption, and data in transit is secured by enforcing TLS (Transport Layer Security). Row-level security is not natively supported in Cosmos DB; instead, it must be implemented at the application layer by filtering queries based on user roles, typically using a partition key or a custom property in the document.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable Azure Disk Encryption on the Cosmos DB account.
Why it's wrong here
Azure Disk Encryption (ADE) is a capability for IaaS virtual machines, using BitLocker or DM-Crypt to encrypt OS and data disks at the host level. Azure Cosmos DB is a fully managed PaaS service where the underlying infrastructure, including storage, is abstracted away from the tenant and already protected by storage encryption. You cannot enable or configure ADE on a Cosmos DB account — there are no VMs or disks to encrypt; attempting to apply this indicates a misunderstanding of the shared responsibility model and the service boundaries of PaaS.
- ✗
Enable Always Encrypted and configure column encryption.
Why it's wrong here
Always Encrypted is a feature of SQL Server and Azure SQL Database that encrypts sensitive columns at the client-side, allowing the database engine to process encrypted data without exposing plaintext keys to the server. Azure Cosmos DB is a multi-model NoSQL database with a schema-agnostic document model, so column-level encryption as defined in the relational SQL world does not exist. Furthermore, Always Encrypted does not provide row-level security — it only protects data at rest and during query execution, so it cannot address the requirement to restrict sensitive rows.
- ✗
Use Dynamic Data Masking to restrict sensitive data.
Why it's wrong here
Dynamic Data Masking (DDM) is a SQL Server and Azure SQL Database feature that obfuscates sensitive columns in query results to non-privileged users, but it does not encrypt data and is purely a presentation-layer control. Azure Cosmos DB does not support DDM — it lacks a relational schema and a catalog of columns that such masking could apply to. Even if DDM were available, it would not prevent a user from reading the underlying data through the SDK or direct API, so it falls short of the row-level security needed for this scenario.
- ✓
Encryption at rest is automatically enabled; enforce TLS for transit; implement row-level security via application code.
Why this is correct
Azure Cosmos DB automatically encrypts all data at rest using Azure-managed keys, and this encryption cannot be disabled; transit security is enforced by requiring TLS for all client connections to the account. Row-level security is not natively provided by Cosmos DB, so you must implement it in the application layer — typically by filtering queries based on the authenticated user's token claims or by using partition keys to isolate tenant data. This aligns with the shared responsibility model: Cosmos DB secures the physical and network layers, while the application enforces fine-grained authorization over individual document access.
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
One of 617 original AZ-500 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.