The defense described—keeping user inputs separate from the SQL statement and binding them as fixed values before execution—is the defining characteristic of parameterized queries (prepared statements). This is one of the most effective and widely recommended countermeasures against SQL injection because it prevents attacker input from being interpreted as SQL code.

In a vulnerable application, developers often build SQL statements by concatenating strings, such as " SELECT ... WHERE user= ' " + input + " ' " . In that pattern, malicious payloads can alter the query structure (adding conditions, UNIONs, comments, or stacked queries). With prepared statements, the SQL engine receives the query structure first (the template), and then receives the parameter values separately. The database treats the parameters strictly as data, not executable SQL. As a result, even if an attacker submits quotes, keywords, or operators, those characters remain part of the parameter value and cannot change the query’s logic.

The scenario specifically says inputs are “bound as fixed values,” which is direct language associated with parameter binding. That makes option D the best answer.

Why the other options are less accurate:

User input validation (A) is helpful but can be bypassed and is not as robust as parameterization; also the described mechanism is not validation but binding separation.

Restrict database access (B) is a defense-in-depth measure (least privilege) that reduces impact, but it does not inherently stop injection from occurring.

Encoding the single quote (C) is a legacy/insufficient approach; encoding or escaping can be error-prone and DBMS-specific, and it does not match the description of parameters being bound separately.

Therefore, the application is using D. Use parameterized queries or prepared statements.