AZ-305 Design infrastructure solutions 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.

• ✗

  Azure SQL Database firewall rules, Transparent Data Encryption (TDE), and Always Encrypted

  Why it's wrong here

  IP firewall rules merely restrict the set of source IP addresses that can attempt a connection, and once a client is in the allowed range, the database is still reachable over the public endpoint; TDE encrypts the physical database files at rest, which does nothing to stop a valid query from returning plaintext result sets. Always Encrypted protects specific columns from the database engine itself, but any client that holds the column master key can still decrypt the data and export it. None of these controls create a fully private network path or enforce an automated, credential-free service identity, so the solution leaves the database exposed to a compromised or malicious client.

• ✗

  Azure SQL Database with IP firewall rules, TLS 1.2, and Azure Information Protection

  Why it's wrong here

  TLS 1.2 secures the transport channel between the client and server, and IP firewall rules restrict which source addresses can even establish a connection, but neither prevents an authenticated (or compromised) client from running SELECT queries and copying the returned rows. Azure Information Protection is a classification and labeling service for documents and emails, not an access control mechanism for Azure SQL Database. Together these controls fail to provide the identity-based, private-network isolation needed to prevent data exfiltration, because they still allow an authorized connection to pull data over the public endpoint.

• ✓

  Azure SQL Database with Managed Identity, Azure Private Link, and Transparent Data Encryption (TDE)

  Why this is correct

  Azure Private Link exposes the SQL Database through a private IP address within the customer's virtual network, completely removing the public internet from the data path and sharply reducing the attack surface for exfiltration. Managed Identity allows an Azure resource, such as a function app or virtual machine, to authenticate to SQL Database via Microsoft Entra ID without embedding credentials in code or configuration, ensuring that only the intended service identity can connect. TDE adds defense-in-depth by encrypting data files, backups, and transaction logs at rest. This combination of private network routing plus a non-interactive, least-privilege workload identity directly addresses the requirement to prevent unauthorized data copying.

• ✗

  Azure SQL Database with Microsoft Entra ID authentication, Azure Key Vault, and Azure Storage Service Encryption

  Why it's wrong here

  Microsoft Entra ID authentication is a strong identity boundary and Azure Key Vault can centrally manage keys and secrets, but Azure Storage Service Encryption applies only to Azure Storage, not to SQL Database files, so it is irrelevant to the database's at-rest protection. Key Vault does not enforce which principals can query the database, and Entra ID authentication alone does not block an authorized principal from exporting large result sets to an external location. Without a private network connection such as Private Link (or at least strict IP restrictions), the SQL Database remains publicly reachable, making the combination insufficient for an exfiltration-prevention requirement.

Go deeper

Related to this question