Domain 2 of 4 · Chapter 2 of 3

Implement security for databases

Unlock the complete study guide + 1,040 practice questions across 16 full exams.

Bundled into the existing SC-500 premium course — no separate purchase.

14-day money-back guarantee — no questions asked.

Included in this chapter:

  • Five controls, and none of them implies another
  • Microsoft Entra authentication at server scope
  • Authorization inside the database
  • Which sources may reach the database
  • Transport encryption and certificate validation
  • Encryption at rest with TDE and its protector
  • Keeping values from the people who run the database
  • Auditing Azure SQL Database and SQL Managed Instance
  • Defender for Databases across the data services
  • Exam-pattern recognition

Azure SQL data-protection controls, by the adversary each one stops

Decision criterionTransparent Data EncryptionAlways EncryptedDynamic data maskingLedger
What it protectsData files, log files, and backups at restValues in selected columns, including in memory and in transitOnly the values returned in a query resultEvidence that tracked rows were not altered
Who still sees plaintextThe engine, and anyone permitted to queryOnly clients holding the column master keyPrivileged users, and anyone able to infer valuesEveryone permitted to query; ledger hides nothing
Where the key or rule livesService-managed certificate, or a customer key in Key Vault or Managed HSMColumn master key kept outside the database, reachable by the clientA masking rule stored in the databaseHashes computed by the database, with digests storable outside it
What the client must supportNothing; it is transparent to applicationsA driver with Always Encrypted support plus access to the keyNothingNothing to write; verification is run on demand
Wrong answer it attractsOffered when the requirement is hiding data from administratorsOffered as the platform-wide at-rest baselineOffered as a confidentiality boundaryOffered as an encryption control

Decision tree

Requirement is proof thatstored data was not altered?YesLedgerNoMust the engine and itsoperators never see plaintext?YesAlways EncryptedNoOnly nonprivileged queryresults need obscuring?YesDynamic datamaskingNoTransparent Data Encryptionthe at-rest baselineTDE stays on for every databasethe other three add to it, they never replace it

Cheat sheet

  • An Azure SQL logical server needs a Microsoft Entra administrator before Entra principals can be provisioned
  • Microsoft Entra-only authentication blocks SQL authentication at server scope
  • Azure SQL database authorization still requires database principals for Entra identities
  • Managed identities remove stored credentials from Azure SQL client applications
  • An Azure SQL server identity needs directory read access to resolve Entra principals
  • Row-level security filters table rows by execution context
  • Server-level and database-level SQL firewall rules have different administrative scopes
  • An Azure SQL virtual-network rule selects traffic from a service-endpoint-enabled subnet
  • Creating an Azure SQL private endpoint does not disable its public endpoint
  • Azure SQL Managed Instance networking is not controlled by logical-server firewall rules
  • Production Azure SQL clients must validate the TLS server certificate
  • Transparent Data Encryption protects Azure SQL files and backups at rest
  • A TDE customer-managed protector requires both Key Vault access and a server identity
  • Always Encrypted keeps selected plaintext values outside the database engine
  • Dynamic data masking limits result-set exposure but is not an encryption boundary
  • Azure SQL ledger supplies tamper evidence rather than data confidentiality
  • A logical-server auditing policy covers current and future databases
  • Overlapping server and database auditing can duplicate audit events
  • SQL auditing destinations serve archival, analysis, and streaming needs
  • SQL Managed Instance auditing must target an Azure-supported audit destination
  • Immutable SQL audit storage requires protected appends and aligned retention
  • Defender database protection is enabled by workload-specific plan
  • Subscription-level Defender for Azure SQL extends protection to supported SQL resources in scope
  • SQL vulnerability assessment finds configuration risks rather than runtime attacks
  • Defender for Databases supplements rather than replaces preventive controls
  • The open-source relational plan covers PostgreSQL and MySQL Flexible Server

Unlock with Premium — includes all practice exams and the complete study guide.

References

  1. Azure SQL Database and SQL Managed Instance security overview
  2. Network access controls for Azure SQL Database
  3. Microsoft Entra authentication for Azure SQL
  4. Microsoft Entra-only authentication with Azure SQL
  5. Directory Readers role in Microsoft Entra ID for Azure SQL
  6. Authorize database access to Azure SQL: logins, users, and permissions
  7. Migrate an application to passwordless connections with Azure SQL Database
  8. Row-level security in SQL Server and Azure SQL
  9. Virtual network rules for Azure SQL Database
  10. Azure Private Link for Azure SQL Database
  11. Azure SQL connectivity settings: public network access and minimum TLS version
  12. Connect your application to Azure SQL Managed Instance
  13. Azure SQL connect and query content reference guide
  14. Transparent data encryption for Azure SQL Database and SQL Managed Instance
  15. Customer-managed transparent data encryption with Azure Key Vault
  16. Always Encrypted for Azure SQL Database and SQL Managed Instance
  17. Dynamic data masking in Azure SQL Database
  18. Azure SQL Database ledger overview
  19. Auditing for Azure SQL Database
  20. Immutable storage for Azure Blob Storage: time-based retention and legal holds
  21. Configure auditing for Azure SQL Managed Instance
  22. Overview of Microsoft Defender for SQL
  23. SQL vulnerability assessment in Microsoft Defender for Cloud
  24. Advanced Threat Protection for Azure SQL Database
  25. Overview of Microsoft Defender for open-source relational databases