SY0-701 Threats, Vulnerabilities, and Mitigations Practice Question
Which four of the following are effective mitigations against SQL injection attacks? (Choose four.)
⚠ Common exam trap
The trap here is that all four options are correct, so candidates must recognize that the question expects them to select all four, rather than being misled into thinking one is incorrect due to common misconceptions about input validation being insufficient alone.
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
✓
Using parameterized queries or prepared statements
Parameterized queries and prepared statements are effective because they separate SQL logic from user input, ensuring that input is treated as data rather than executable code. This prevents attackers from injecting malicious SQL commands into query strings, as the database engine compiles the query structure before parameters are bound.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Using parameterized queries or prepared statements
Why this is correct
Parameterized queries, also known as prepared statements, separate SQL logic from user-supplied data by using placeholders. The database engine compiles the query structure once, then binds the user input as pure data values, never as executable code. This ensures that malicious input like `' OR 1=1--` cannot alter the query's syntax, effectively neutralizing the injection vector at the database layer.
- ✓
Implementing input validation and sanitization
Why this is correct
Input validation and sanitization enforce strict rules about what data is acceptable, such as type, length, and character set. Validation rejects malicious patterns before they reach the database, while sanitization escapes or encodes dangerous characters. However, this approach must be applied carefully on the server side with a whitelist strategy, because relying solely on blacklisting known attack patterns is error-prone and often bypassable with encoding tricks.
- ✓
Enforcing least privilege for database accounts
Why this is correct
Enforcing least privilege for database accounts restricts the permissions granted to the application's database connection so it can only perform necessary operations, such as SELECT on specific tables. If an attacker exploits an SQL injection flaw, the compromised account cannot execute powerful commands like `xp_cmdshell`, `DROP TABLE`, or access sensitive schemas. This limits the blast radius of an injection attack, making it a critical defense-in-depth measure even if other controls fail.
- ✓
Disabling error messages that reveal database structure
Why this is correct
Disabling verbose database error messages prevents the application from returning detailed technical information, such as table names, column structures, and SQL syntax fragments, to the end user. Attackers often use these errors to map out the database and refine their injection payloads. By showing generic error pages instead, you eliminate a key information-gathering technique, although this is a reactive measure and should be used alongside more robust protections.
- ✗
Blocking all user input containing the word 'SELECT'
Why it's wrong here
Blocking all user input containing the word 'SELECT' is an ineffective and easily bypassed defense because there are countless other SQL keywords and statements, such as `INSERT`, `UPDATE`, `DELETE`, or `UNION`, that can be exploited. Attackers can also circumvent naive keyword filters using case variations (`SeLeCt`), inline comments (`S/**/ELECT`), or URL encoding. Moreover, legitimate application functionality often requires users to submit text that naturally contains these words, causing false positives and breaking usability.
- ✗
Using client-side JavaScript validation exclusively
Why it's wrong here
Client-side JavaScript validation exclusively is not a security control because it runs in the user's browser and can be trivially disabled, modified, or bypassed by an attacker using tools like a proxy or a crafted HTTP request. It offers no protection against direct server-side injection attempts, as the server must always validate and sanitize input independently. Client-side validation is useful only for improving user experience, not for mitigating SQL injection or any other server-side threat.
Go deeper
Related to this question
Learn chapter
Social Engineering Attacks
Key term
SQL
SQL is a standard programming language used to manage, query, and manipulate relational databases by issuing commands like SELECT, INSERT, UPDATE, and DELETE.
Key term
SQL
SQL is a standardized programming language used to manage and manipulate relational databases, enabling querying, updating, and data retrieval.
About these practice questions
Courseiva writes every SY0-701 question from scratch — 1,013 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SY0-701 practice question is part of Courseiva's free CompTIA 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 SY0-701 exam.