DP-900 Practice Question: Identify considerations for relational data on Azure

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 (TDE)

  Why this is correct

  Transparent Data Encryption (TDE) in Azure SQL Database automatically encrypts database files, log files, and backups at rest without requiring changes to the application schema or queries. The database engine performs real-time I/O encryption and decryption, but plaintext data remains in memory and is visible to users with proper access. This makes TDE a strong baseline for regulatory compliance, though it protects only against physical theft of storage, not against unauthorized application queries.

• ✗

  Dynamic Data Masking

  Why it's wrong here

  Dynamic Data Masking does not encrypt stored data; instead, it obfuscates sensitive values in query results presented to non-privileged users according to custom masking rules. The underlying data remains in plaintext in the database files, and a user with elevated permissions such as SELECT on the table can read the real values. Therefore, DDM is a usability and access-control feature, not an encryption feature, and offers no protection for data at rest.

• ✓

  Always Encrypted

  Why this is correct

  Always Encrypted is a client-side encryption feature that keeps column-level secret keys outside of the database server, protecting plaintext data both at rest and in transit between the application and the database. The database engine only receives and stores ciphertext for designated columns, so even database administrators and OS administrators cannot view the plaintext values. However, it supports a limited set of operations on encrypted columns, such as equality comparisons, and requires application code and driver changes to use.

• ✗

  Auditing

  Why it's wrong here

  Auditing records database events and actions to a log for tracking and compliance, but it does not alter or encrypt the underlying data storage. Even if auditing is enabled, database files and backups remain in plaintext unless a separate encryption feature such as TDE is configured. Auditing addresses the need for accountability and forensics, not data confidentiality at rest.

• ✗

  Row-Level Security

  Why it's wrong here

  Row-Level Security works by presenting only a subset of rows to users based on a security predicate or filter function tied to session context. It controls what data a user can see or modify, but the hidden rows still exist as plaintext on disk and in backups. RLS is an access-rule mechanism, not an encryption mechanism, and therefore cannot be used as a data-at-rest protection feature.

Go deeper

Related to this question