Courseiva

AZ-500 Secure compute, storage, and databases Practice Question

You need to protect Azure SQL Database from SQL injection attacks. Which TWO measures should you implement? (Choose TWO.)

⚠ Common exam trap

It's easy for candidates to confuse data-at-rest encryption (TDE or Always Encrypted) with input validation or application-layer defenses, mistakenly thinking encryption alone can prevent SQL injection attacks.

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

✓

Deploy Azure Web Application Firewall (WAF) in front of the application.

Option B is correct because Azure Web Application Firewall (WAF), typically via Application Gateway or Front Door, inspects HTTP/HTTPS traffic and applies OWASP Core Rule Set rules that detect and block common SQL injection payloads before they reach the application or database. Option E is correct because parameterized queries (prepared statements) cause the database engine to treat user input strictly as data rather than executable SQL, which is the fundamental application-level defense against SQL injection. Option A is not correct here because Always Encrypted protects data confidentiality at rest and in memory by encrypting sensitive columns, but it does not detect or prevent SQL injection. Option C is not correct because Transparent Data Encryption (TDE) only encrypts data and log files at rest and has no bearing on injection attacks. Option D is not correct because SQL Server auditing records activity for compliance and forensic review after the fact; it is a detective control, not a preventive measure against SQL injection.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Use Always Encrypted for sensitive columns.

    Why it's wrong here

    Always Encrypted shields column data so that even database administrators with elevated permissions cannot view plaintext values because encryption keys are held by the client application. However, it does not inspect or alter the SQL statements sent to Azure SQL Database; an attacker can still inject malicious SQL through a vulnerable query string. This feature addresses confidentiality of sensitive data during legitimate operations, not the semantic integrity of the SQL command itself.

  • ✓

    Deploy Azure Web Application Firewall (WAF) in front of the application.

    Why this is correct

    Azure Web Application Firewall, when attached to Application Gateway or Front Door, evaluates incoming HTTP requests against managed rule sets that specifically detect SQL injection patterns, allowing you to block malicious payloads at the network edge before they reach your application. It filters on query strings, request bodies, and header parameters using signature analysis and can scale to absorb attack traffic. This is a strong compensating control, but it operates outside the database engine and may require false-positive tuning.

  • ✗

    Enable Transparent Data Encryption (TDE).

    Why it's wrong here

    Transparent Data Encryption performs real-time I/O encryption and decryption of the database, backup, and transaction log files, protecting physical copies of data from being read if they are stolen. It has no bearing on the processing of incoming queries, because the server simply decrypts data pages when needed for legitimate workloads. Injection attacks are an application-level security flaw involving how query text is constructed, not how data is stored at rest.

  • ✗

    Enable SQL Server auditing.

    Why it's wrong here

    SQL Server auditing tracks and records server and database events, such as successful and failed login attempts, data modifications, and query executions, by writing audit logs to a configured destination. It provides a forensic trail that can help you determine when or how an injection occurred, but auditing is passive and cannot block the malicious statement from executing. The attacker's injected payload would still run and potentially damage or exfiltrate data before any alert is reviewed.

  • ✓

    Use parameterized queries in application code.

    Why this is correct

    Parameterized queries separate the SQL logic from the data by passing user-supplied values as bound parameters, which means the database engine treats them as literals rather than executable syntax. For example, SqlCommand parameters or stored procedure parameters ensure that an input like '; DROP TABLE Users;--' is interpreted as string data, not as additional command text. This directly eliminates the syntax confusion that enables classic SQL injection and is the most reliable mitigation at the application layer.

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 →

How Courseiva writes practice questions · Editorial policy

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.