Database Administrator key topics and quick reference

Updated 17 September 2026 · 2 min read

Database administration rests on a compact set of ideas used constantly: what each family of SQL commands does, how storage protects data, and how design choices turn into performance later. The reference tables on this page hold the facts. The notes below show how they connect in real decisions.

How this guide was made

Written for this site with AI assistance, then checked automatically before publishing. The topic table, sample questions, worked examples and study plan are generated from this site’s question bank: each worked example is recalculated by separate code, and each sample answer says where it came from.

The guide deliberately states no salaries, grades, pass marks or exam dates. Those change, and they could not be checked here, so take them from the advert itself.

This site is independent and is not affiliated with MIFOTRA or any employer.

Where to spend your study time

The suggested emphasis reflects what this position works with day to day. It is a study guide, not a published exam blueprint.

Area	Suggested emphasis	Questions in the bank	Practise
Software development	36%	378	In the full bank
Cybersecurity	18%	541	Security
Hardware and operating systems	18%	961	Hardware & OS
Linux command line	18%	360	In the full bank
Cloud and emerging technology	9%	188	In the full bank

SQL in families

Grouping SQL commands by purpose makes them easier to hold: defining structures, changing data, controlling access and controlling transactions. Questions often name a command and ask which family it belongs to, or describe a task and ask which command performs it. Knowing the families also clarifies permissions, because privileges are granted along the same lines.

Quick reference

SQL command groups

Group	Commands	Purpose
DDL	CREATE, ALTER, DROP, TRUNCATE	Define and change structure
DML	SELECT, INSERT, UPDATE, DELETE	Read and change data
DCL	GRANT, REVOKE	Control access
TCL	COMMIT, ROLLBACK, SAVEPOINT	Control transactions
Joins	INNER, LEFT, RIGHT, FULL OUTER	Combine rows from related tables

RAID levels

Level	Minimum disks	Usable capacity	Survives
RAID 0	2	All disks	No failure
RAID 1	2	One disk	All but one disk
RAID 5	3	n − 1 disks	One disk
RAID 6	4	n − 2 disks	Two disks
RAID 10	4	Half the disks	One disk per mirrored pair

RAID is not a backup. It keeps a system running through a disk failure; it does nothing about deletion, ransomware or a failed controller.

Storage choices are database decisions

A database writes constantly, so the storage underneath it shapes performance as much as any index. Know what each RAID level gives in capacity and what it costs in write performance, and remember that redundancy is not backup: a deleted table is deleted on every mirror instantly.

Design, indexing and recovery connect

A normalised schema reduces duplicated data, which reduces the chance of contradictory rows. Indexes make reads on that schema fast, at a cost to writes. Backups protect all of it, and the recovery model you choose determines what a restore can achieve. A decision in any one of the three shows up in the other two.

Be able to explain in a sentence

The difference between an inner and a left join.
Why an index can make writes slower.
What third normal form removes.
Why RAID is not a backup.
What point-in-time recovery requires.

Common questions

Do I need to memorise SQL syntax exactly?

Know the common statements well enough to write them correctly. Rarer syntax is looked up, and tests usually focus on whether you chose the right approach.

How much storage knowledge is expected?

Enough to size a volume, understand RAID trade-offs and know what your database does to disks. Deep storage engineering belongs to another role.