Database Provisioning and Cloning
What the exam tests
This domain tests profile selection, project scoping, snapshot-based cloning, and post-provision behavior.
Core rules
- Provisioning combines compute, network, software, and database parameter profiles. Incompatible engine versions fail early.
- Projects scope users, networks, clusters, and quotas. A user can provision only where project permissions allow.
- A clone is created from a Time Machine snapshot, not from an unmanaged source VM. The source must be registered and protected.
- Clones are storage-efficient thin copies. They still need compute and network resources.
- Post-provision scripts and parameter profiles change the clone without altering the source.
- Naming and tagging should identify owner, source, and purpose.
Worked example
A MySQL production database has a Time Machine with a snapshot from 02:00. A developer clones it to the dev project at 09:00. NDB creates a clone from the 02:00 snapshot, applies the dev compute profile, attaches the dev VLAN, and runs a masking script. The clone does not contain changes after 02:00. If the developer needs current data, use clone refresh after a newer snapshot exists.
Traps
Do not promise point-in-time data from a plain clone; that requires PITR. Do not choose a compute profile too small for the clone and then blame NDB. Do not assume a clone is independent of snapshot retention; deleting the parent snapshot chain can break clone operations. Do not use a production network profile for a test clone.