AZ-900 Describe Azure architecture and services 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.

• ✓

  Transparent Data Encryption with customer-managed keys

  Why this is correct

  Transparent Data Encryption (TDE) with customer-managed keys is the correct approach because TDE performs real-time I/O encryption and decryption of the data and log files at the storage layer, protecting the entire database at rest. By placing the TDE protector (a key used to encrypt the database encryption key) in Azure Key Vault, you retain full control over key material, and you can rotate the key online without taking the database offline or re-encrypting data—maintaining high availability while meeting compliance requirements.

• ✗

  Always Encrypted

  Why it's wrong here

  Incorrect. Always Encrypted encrypts sensitive data on the client side and never exposes plaintext to the database engine, but it is not for at-rest encryption of the entire database and does not support TDE key rotation.

  When this WOULD be correct

  A question asking for a feature that ensures sensitive data (e.g., credit card numbers) is encrypted throughout its lifecycle (in transit and at rest) and remains encrypted even from database administrators, with client-side key management.

• ✗

  Dynamic Data Masking

  Why it's wrong here

  Dynamic Data Masking (DDM) is not encryption at rest; it is a data-exposure control that applies masking rules to query results so that non-privileged users see obfuscated values, such as partial credit card numbers, while the underlying data remains stored in plaintext. DDM operates at the presentation layer during query execution and does not protect the physical files on disk, nor does it involve key management or cryptographic transformations—so it cannot satisfy a requirement to encrypt data at rest in Azure SQL Database.

  When this WOULD be correct

  A company wants to limit exposure of sensitive data by showing only partial values (e.g., masking credit card numbers) to non-privileged users in Azure SQL Database query results, without changing the underlying data.

• ✗

  Row-level security

  Why it's wrong here

  Row-Level Security (RLS) is an authorization mechanism that filters which rows a user can read or modify based on the output of a predicate function and the user's context (e.g., session properties or group membership). While RLS helps enforce data isolation at the query level, it does not encrypt data at rest; the data is still stored as plaintext, and RLS has no key management or ciphering capability—therefore it is not an at-rest encryption solution.

  When this WOULD be correct

  A company needs to restrict access to specific rows in a table based on user role or identity, such that a sales manager can only see their region's sales data. RLS would be the correct feature to implement this row-level access control.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-900 exam frequently reuses these exact scenarios with slightly different constraints.

Analysis generated from the official AZ-900blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”