Every database, no matter where it runs, needs ongoing care: operating system and engine patches, index and storage maintenance, backups, restore testing, performance tuning, capacity planning, and security configuration. What changes between a locally hosted deployment and a cloud-managed service is not whether this work happens, but who does it. In a self-managed environment your organization owns nearly all of it and must staff accordingly; with a managed service such as AWS RDS, Azure SQL Database, or Google Cloud SQL, the provider absorbs much of the infrastructure-level work while you remain accountable for schema design, query performance, access control, and your own data.
This topic matters because administrative burden is one of the most under-estimated cost and risk factors in a hosting decision. A team may choose the cloud expecting "no maintenance" and then discover that backup retention, patch windows, encryption keys, and user privileges are still theirs to manage. The shared responsibility model is the framework that makes those boundaries explicit, and understanding it is essential before you can defend a hosting recommendation in a real scenario.
As you watch, keep a two-column list: tasks the provider performs versus tasks the customer retains, and note how that line shifts as you move from IaaS toward PaaS and SaaS. Pay attention to the distinction between a backup and a recovery plan, and to what monitoring and expertise each model demands from your staff.
Revisit this video a second time with a database focus, mapping its general model onto specific tasks such as engine patching, minor version upgrades, failover configuration, user privileges, and data classification. Use it to build the responsibility matrix you will need for the module assessment.
A second pass turns a conceptual framework into a usable classification tool, which is the skill the shared responsibility outcome asks you to demonstrate.
An IBM Technology explainer that separates two concepts students often merge: taking backups versus planning for disaster recovery. Expect discussion of recovery objectives, what a disaster recovery plan includes beyond stored copies of data, and how the two practices complement each other.
Backup and recovery responsibilities are a core subtopic, and this video makes clear that provider-managed snapshots do not by themselves constitute a recovery strategy, which is exactly the nuance needed when comparing deployment models.
This IBM Technology video surveys cloud architecture and the standard delivery models, including IaaS, PaaS, and SaaS, along with related deployment concepts. It should clarify what the provider supplies at each layer of the stack.
The service model determines where the maintenance line falls, so this video supplies the structural background that makes self-managed versus provider-managed maintenance comparisons meaningful, and it reinforces the infrastructure distinctions used throughout the module.
Together these videos build from infrastructure concepts to concrete administrative duties. The cloud architecture overview supports distinguishing deployment models by their defining characteristics and clarifies where scalability and management responsibilities sit at each service layer (MO1, MO3). The backup versus disaster recovery discussion supplies the availability and risk considerations needed to weigh maintenance trade-offs and recommend a hosting strategy, and it surfaces hidden operational costs such as staffing, tooling, and recovery testing that feed total cost of ownership reasoning (MO2, MO4). The shared responsibility material gives you the explicit framework for sorting tasks between provider and customer in a managed database service (MO5).
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.