yoklainterview sim
ProgressHistory

Database Security Access Interview Questions

75 verified Database Security Access interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Security AccessDifficulty 1
What is SQL injection?
  • aThe database rejecting a query because its SQL syntax is invalid
  • bAn attacker overwhelming the database server with too many simultaneous open connections
  • cAn attacker changing a query's meaning by smuggling SQL through unvalidated input✓
  • dA query running slowly because a filtered column has no supporting index
Explanation:SQL injection happens when untrusted input is concatenated into a SQL string, so the input can change the statement's structure (add conditions, run extra statements) instead of being treated as a value. Option (b) describes a denial-of-service / connection flood and (d) a performance issue — neither alters query logic.
Security AccessDifficulty 2
An application runs a query with a placeholder and binds the value separately:
-- SQL text (sent and parsed once):
SELECT * FROM users WHERE email = ?;
-- value supplied separately, as data:
bind(1, '[email protected]')

Why does binding the value as a parameter instead of concatenating it into the SQL text prevent SQL injection?
  • aThe database automatically encrypts each bound parameter before storing or comparing it
  • bThe statement is parsed with the placeholder, so the value can only be used as data, not as SQL✓
  • cBound parameter values are capped at a fixed length, which blocks long injection payloads
  • dThe database carefully scans each parameter and automatically rejects any value that contains SQL keywords
Explanation:With a parameterized (prepared) statement the SQL text — including the placeholder — is parsed and planned first; the supplied value is then bound purely as data and is never re-parsed as SQL, so it cannot add conditions or statements. Encryption (a) and keyword-blocking (d) are not how it works — a legitimate value may contain the word 'OR' or a quote and must still be accepted as data. Length capping (c) is unrelated.
Security AccessDifficulty 3
A login check builds its query by concatenating the form input:
SELECT * FROM users WHERE username = '<input>' AND password = '<input>';

An attacker submits ' OR '1'='1' -- as the username. What is the likely result?
  • aThe query fails with a syntax error, so the login attempt is safely rejected
  • bOnly a user literally named ' OR '1'='1' matches, so the query returns no rows
  • cThe database refuses the request automatically because the input contains a single quote
  • dThe WHERE turns always-true and -- comments out the password check, bypassing login✓
Explanation:The injected ' closes the username string, OR '1'='1' makes the condition always true, and -- comments out the rest (the password check). The query returns rows — often the first/admin user — and authentication is bypassed. Databases do not reject quotes by themselves (c); once injected the input is valid SQL, so there is no syntax error (a).
Security AccessDifficulty 1
According to the principle of least privilege, what privileges should a production application's database account have?
  • aOnly the specific privileges its normal operations require, and nothing beyond that✓
  • bFull superuser rights, so that a missing permission can never break a request
  • cEvery privilege on every table, restricted only to normal business hours
  • dExactly the same privileges as the developers who built the application
Explanation:Least privilege means granting only the permissions a component needs to do its job, limiting the damage if it is compromised or has a bug. A superuser app account (b) turns any SQL injection or logic flaw into full database control. Time-based (c) or developer-matching (d) grants are not what least privilege means.
Security AccessDifficulty 1
What does GRANT SELECT ON orders TO reporting; do?
  • aIt transfers ownership of the orders table to the reporting role
  • bIt allows the reporting role to read rows from orders, but not to change them✓
  • cIt grants the reporting role both full read and full write access to the entire orders table
  • dIt copies the orders table's rows into a new table owned by reporting
Explanation:SELECT is the read privilege; GRANT SELECT lets the grantee query the table but gives no INSERT/UPDATE/DELETE (so not (c)). It does not change ownership (a) or copy data (d) — ownership and DDL are separate from data-access privileges.
Security AccessDifficulty 2
An account currently has SELECT and INSERT on payments. After running:
REVOKE INSERT ON payments FROM app_user;

what can app_user still do on payments?
  • aNothing, because REVOKE strips every privilege the account had on the table
  • bBoth SELECT and INSERT, since a REVOKE only applies after the server restarts
  • cOnly SELECT — INSERT is removed while the previously granted SELECT stays✓
  • dOnly INSERT, because REVOKE always keeps the most recently granted privilege
Explanation:REVOKE removes exactly the named privilege (INSERT); the untouched SELECT grant remains, so the account can still read but no longer insert. REVOKE takes effect immediately (no restart, so (b) is wrong) and only affects the privileges you list (so (a) and (d) are wrong).

By specialization

MongoDB 450MySQL 450PostgreSQL 450Redis 450

By seniority

Database JuniorDatabase MidDatabase Senior

Other fields

BackendFrontendFullstackDevOps / CloudAI EngineerMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 2475-question Database bank.

Start interview