Cloud DBA Capstone Lab: Deploy, Secure, and Recover a Multi-Tier Cloud Database

Cloud DBA Capstone Lab: Deploy, Secure, and Recover a Multi-Tier Cloud Database

This capstone lab brings together every skill developed throughout the course. You will receive a written scenario, build a complete managed cloud database environment from scratch, survive an unannounced recovery drill, and explain every decision in a run-book and brief oral review. Treat this lab exactly as you would a real work assignment: plan before you click, document as you go, and verify each step before moving to the next.

Reading the Scenario Before You Build

Your first task is to read the scenario carefully and extract its hard requirements before you open any console or CLI. Identify the database platform (PostgreSQL or SQL Server managed service), storage size, recovery time objective (RTO), recovery point objective (RPO), network topology, and access requirements. Write these down in the run-book template's Requirements section immediately. A misconfigured environment that does not meet the scenario's stated RTO and RPO is a failed deployment, regardless of how clean the rest of the build looks.

Map each requirement to a concrete service setting before provisioning. For example, if the scenario states an RPO of one hour, your automated backup schedule must produce restore points no more than one hour apart, and you must verify that point-in-time recovery (PITR) is enabled on your managed instance. If the RTO is two hours, your recovery procedure must be practiced and documented so that the actual restore completes well within that window.

Provisioning the Environment Safely

Work in a dedicated, isolated environment. Never provision resources in a shared production account or a namespace that belongs to another student. Use the cloud account assigned to you for this lab only.

Before touching storage or compute, build the private network first. Create a Virtual Private Cloud (VPC) on AWS or a Virtual Network (VNet) on Azure, then place your managed database instance inside a private subnet with no direct inbound access from the public internet. Use security groups or network security groups to restrict inbound traffic to only the ports and source addresses your scenario requires — database ports should never be open to 0.0.0.0/0 in any graded or professional deployment.

Create IAM roles or Azure managed identities with the minimum permissions needed for the scenario. Follow the principle of least privilege: a monitoring service account should be able to read metrics and logs, not modify database configuration. Assign roles explicitly; do not use root or global administrator credentials for application access.

Enable storage encryption at rest using the platform's default key management service unless your scenario specifies a customer-managed key. Enable encryption in transit (TLS) for all client connections. Both controls are required for DAMA DMBOK2 data protection principles and appear in Microsoft DP-300 exam objectives related to securing Azure SQL environments.

Enable automated backups and confirm that PITR is active. Set the backup retention window to meet or exceed your RPO. Create at least one manual snapshot after your initial deployment so you have a verified baseline restore point before the recovery drill.

Set up a monitoring alert before you consider the build complete. Configure an alert that notifies you (via email or dashboard) if the database instance becomes unreachable or if CPU or storage crosses a defined threshold. This alert is also how you are expected to detect the recovery drill event.

Documenting as You Build

Complete each run-book section immediately after you finish the corresponding step — not at the end. The run-book must contain: network topology diagram or description, instance configuration details (region, tier, storage, version), IAM roles and their assigned permissions, encryption settings, backup schedule and retention period, monitoring alert configuration, and step-by-step recovery procedures. A run-book written after the fact from memory is unreliable and will not reflect the actual configuration accurately.

The Recovery Drill

At an unannounced point during or after your build, the instructor will delete a designated table from your running instance. Your responsibilities are:

1. Detect the loss using your monitoring logs or by querying the database.

2. Identify the latest restore point before the deletion occurred.

3. Execute a point-in-time restore to a new or replaced instance.

4. Verify that the recovered table contains the expected data.

5. Record the exact start time, end time, and total elapsed recovery time in your run-book.

Your actual recovery time must fall within the RTO stated in your scenario. If recovery takes longer than the RTO, document why and what you would change, but be aware that meeting the RTO is a pass/fail requirement for this lab.

Oral Explanation

The oral component is not a quiz — it is a professional debrief. The instructor will ask three questions about specific configuration choices you made. Answer by connecting the setting to the scenario requirement it satisfies. For example, if asked why you chose a particular backup retention period, explain which RPO value it meets and how you verified that PITR was enabled. Reference the DP-300 exam objective checklist and DAMA DMBOK2 sections you used as review guides before submission.

Safety and Professional Responsibility

Cloud resources have real costs. Terminate or deallocate all resources at the end of the lab unless the instructor directs otherwise. Never store real personal data in a lab environment. Do not share credentials, access keys, or account IDs with other students. Report any accidental access to another student's environment to the instructor immediately. These are not just lab rules — they reflect professional and legal obligations you will carry in any DBA role.