This chapter covers the fundamental distinction between managed and unmanaged services on Google Cloud Platform (GCP), a core concept tested in Domain 2 (Infrastructure) of the Google Cloud Digital Leader (GCDL) exam. Understanding this trade-off is critical because roughly 10-15% of exam questions require you to recommend a service based on operational overhead, control, or cost considerations. By the end of this chapter, you will be able to differentiate the two models, identify the appropriate service for common scenarios, and avoid the trap answers that confuse flexibility with responsibility.
Jump to a section
Managed services on GCP are like renting a fully furnished apartment in a managed building. The landlord takes care of all maintenance — plumbing, electrical, painting, security. You just move in, set up your furniture, and live. If the water heater breaks, you call the landlord; they fix or replace it at no extra cost. You don't know the exact brand of the heater or the pipe layout; you just know it works. Unmanaged services are like buying a plot of land and building your own house. You choose the architect, contractor, materials, and you are responsible for every detail: foundation, wiring, roofing, permits. If something breaks, you fix it yourself or hire someone. You have full control — you can customize the house exactly how you want — but you bear all the cost, time, and risk. In the cloud, managed services (like Cloud SQL, Cloud Run, Cloud Functions) abstract away the underlying server, OS, patching, scaling, and high availability. Unmanaged services (like Compute Engine VMs) give you raw compute, storage, and networking, and you must configure everything from the OS up. The exam tests your ability to identify which model fits a given requirement based on control vs. convenience trade-offs.
What Are Managed Services?
Managed services on GCP are fully managed by Google Cloud, meaning Google handles the underlying infrastructure, including server maintenance, OS patching, scaling, backups, and high availability. The customer only configures the service at a high level and uses it. Examples include:
Cloud SQL (managed MySQL, PostgreSQL, SQL Server)
Cloud Spanner (globally distributed managed database)
Cloud Run (managed serverless compute)
Cloud Functions (event-driven serverless)
Cloud Storage (object storage with automatic redundancy)
BigQuery (serverless data warehouse)
What Are Unmanaged Services?
Unmanaged services provide raw infrastructure components that the customer must configure, secure, and maintain. The customer has full control over the OS, software, networking, and security but bears all operational responsibility. Examples include:
Compute Engine (VMs) – you choose the machine type, OS image, boot disk, firewall rules, and must patch the OS yourself
Google Kubernetes Engine (GKE) can be considered a hybrid: managed control plane but unmanaged node pools (unless using Autopilot)
Cloud Storage buckets are managed, but the data inside is customer-managed
Virtual Private Cloud (VPC) networks – you define subnets, routes, firewall rules, and NAT
Key Differences: Control vs. Responsibility
The primary trade-off is control versus operational overhead.
Managed services: Less control over the underlying environment, but zero operational overhead for patching, scaling, backups, and failover. You pay a premium for this convenience, often in the form of higher per-unit costs or licensing fees.
Unmanaged services: Full control over every aspect, but you must handle all maintenance, scaling, security hardening, and disaster recovery. This can be cheaper in raw compute costs but requires skilled staff and time.
How Managed Services Work Internally
Managed services abstract away the infrastructure using a control plane that manages a fleet of compute, storage, and networking resources. For example, Cloud SQL:
You create an instance specifying region, machine type, storage size, and database version.
Google provisions a VM or container running the database engine, but you never see the OS.
Google automatically applies security patches during maintenance windows (configurable).
Backups are taken automatically (default: daily, with 7-day retention).
High availability (HA) is configured by enabling failover replicas in different zones; Google handles replication and failover.
Scaling is manual or automatic (for storage) but limited to predefined machine types.
Key Components and Defaults
Cloud SQL: Default backup retention is 7 days, automated backups daily. Maintenance windows can be set to any day/time. HA uses synchronous replication to a standby in another zone.
Cloud Run: Auto-scales from 0 to N instances based on request concurrency (default 80 concurrent requests per container). Billed only when processing requests (per 100ms). Cold starts occur when scaling from 0.
Compute Engine: Default boot disk is 10 GB of persistent disk (standard). You must configure firewall rules (default deny all ingress). No automatic OS patching – you must use OS Patch Management or custom scripts.
GKE Standard: Control plane is managed (Google handles kube-apiserver, etcd), but you manage node pools (OS patching, scaling). GKE Autopilot manages both control plane and nodes.
Commands and Verification
For managed services, you interact via high-level APIs. For unmanaged, you have direct access to the OS.
Cloud SQL: gcloud sql instances create myinstance --database-version=MYSQL_8_0 --cpu=2 --memory=7680MB --region=us-central1
Compute Engine: gcloud compute instances create myvm --zone=us-central1-a --machine-type=e2-medium --image-family=ubuntu-2204-lts --image-project=ubuntu-os-cloud
To verify managed service status, use gcloud sql instances describe or the Cloud Console. For unmanaged VMs, you typically SSH in and run uname -a, df -h, etc.
Interaction with Related Technologies
Managed and unmanaged services often interact. For example:
A Compute Engine VM (unmanaged) can connect to Cloud SQL (managed) using a private IP via VPC peering.
A Cloud Run service (managed) can invoke a Compute Engine instance via HTTP if the instance has a public IP or is behind a load balancer.
Cloud Storage (managed) can be mounted on Compute Engine using gcsfuse (unmanaged configuration).
The exam expects you to understand these boundaries: managed services reduce operational burden but may have limitations on customization; unmanaged services offer full flexibility but require expertise.
Exam-Relevant Details
SLA differences: Managed services typically have higher SLAs (99.95% to 99.99%) because Google handles redundancy. Unmanaged services like Compute Engine have SLAs of 99.5% for single instances (with premium tier) and 99.99% for regional managed instance groups.
Cost model: Managed services often charge for usage (per query, per hour of instance uptime) and include overhead. Unmanaged services charge for resources allocated (vCPU, memory, disk) regardless of utilization.
Security: Managed services include automatic encryption at rest and in transit by default. Unmanaged services require you to enable encryption (e.g., using CMEK or CSEK) and configure firewall rules.
Compliance: Managed services are often PCI DSS, HIPAA, and SOC compliant out of the box. Unmanaged services require you to harden the OS and applications to meet compliance.
Trap Patterns
Common wrong answers on the exam include:
Choosing an unmanaged service for a scenario that requires low operational overhead (e.g., a startup with no DevOps team).
Selecting a managed service when the requirement specifies full control over the OS or software stack.
Assuming that GKE is fully managed (it is only partially managed unless Autopilot is used).
Confusing Cloud Functions (managed) with Compute Engine (unmanaged) for event-driven processing.
Always ask: Does the customer need to manage the OS? If yes, it's unmanaged. If no, managed is better.
Identify Control vs. Convenience
The first step in deciding between managed and unmanaged is to assess the customer's requirement for control over the underlying infrastructure. If the customer needs to install custom software, configure the OS kernel, or have root access, an unmanaged service like Compute Engine is necessary. If they prefer to avoid patching and scaling tasks, a managed service like Cloud SQL or Cloud Run is appropriate. This step determines the entire architecture direction.
Evaluate Operational Overhead
Next, consider the operational overhead the customer is willing to accept. Managed services offload tasks like backups, patching, and failover to Google, but they come with higher costs and less flexibility. Unmanaged services require dedicated staff to perform these tasks. The exam often presents scenarios where a small team with limited DevOps expertise should choose managed services, while a large enterprise with a dedicated ops team might choose unmanaged for cost savings.
Assess Scaling Requirements
Scaling behavior differs significantly. Managed services like Cloud Run auto-scale from zero to thousands of instances based on demand, with no manual intervention. Unmanaged services like Compute Engine require you to set up managed instance groups and auto-scaling policies manually. If the workload has unpredictable traffic spikes, managed services are typically better. For predictable, steady-state workloads, unmanaged can be more cost-effective.
Check Compliance and Security
Compliance requirements may dictate the choice. Managed services often come with built-in compliance certifications (e.g., HIPAA, PCI DSS) and automatic encryption. Unmanaged services require you to implement and verify compliance controls yourself. If the customer must maintain specific OS-level security configurations (e.g., FIPS 140-2), unmanaged may be required. The exam tests this by presenting a scenario with strict compliance needs.
Analyze Cost Implications
Finally, analyze total cost of ownership. Managed services have higher per-unit costs but lower operational labor costs. Unmanaged services have lower resource costs but require skilled personnel. For short-term or variable workloads, managed services can be cheaper overall. For long-term, predictable workloads, unmanaged may be more economical. The exam expects you to recognize that cost is not just about resource price but includes operational overhead.
Scenario 1: E-commerce Startup with Limited Ops Team
A fast-growing e-commerce startup needs a database for its product catalog and user sessions. They have two developers who know SQL but have no experience managing servers. They choose Cloud SQL (managed MySQL). They create an instance with 2 vCPUs, 8 GB RAM, and 100 GB SSD storage. Google handles automated backups (daily, retained 7 days) and point-in-time recovery. They enable high availability with a failover replica in another zone. The total cost is about $200/month for the instance plus $0.17/GB/month for backups. They never need to patch the database; Google applies security updates during a maintenance window they set to Sunday at 2 AM. The startup grows, and they scale up to 4 vCPUs with no downtime. If they had chosen Compute Engine with a self-managed MySQL, they would need to set up replication, handle backups, and patch the OS quarterly — tasks that would require a DevOps hire costing $100k+/year. The managed service saves them time and risk.
Scenario 2: Financial Services Firm with Strict Compliance
A bank needs to run a proprietary trading application that requires a specific OS kernel version and custom security modules. They also need full disk encryption with customer-managed keys (CMEK). They choose Compute Engine (unmanaged) running Ubuntu 22.04 LTS. They create a custom image with the required kernel and security modules. They attach a persistent disk encrypted with a Cloud KMS key they manage. They configure VPC firewall rules to allow only specific IPs. They set up a managed instance group with auto-scaling based on CPU utilization. They use Cloud Monitoring to track performance and set up alerts. They are responsible for OS patching — they use the OS Patch Management service to automate patching monthly. They also maintain their own backup strategy (snapshots to Cloud Storage). The cost is lower per vCPU compared to a managed service, but the operational burden is high — they have a team of 10 engineers managing the infrastructure. Misconfiguration of firewall rules could expose the application to the internet, so they use VPC Service Controls to mitigate.
Scenario 3: Media Streaming Platform with Variable Load
A video streaming platform experiences huge traffic spikes during live events. They use Cloud Run (managed) to transcode videos and serve APIs. Cloud Run automatically scales from 0 to thousands of containers based on incoming requests. They set max concurrency to 80 per container. During a major event, traffic surges to 50,000 requests per second; Cloud Run scales to 625 containers. They pay only for the compute time used (per 100ms). After the event, traffic drops, and Cloud Run scales down to 0, costing nothing. If they had used Compute Engine, they would need to provision enough VMs to handle peak load, paying for idle capacity. The managed service's auto-scaling and pay-per-use model is ideal for variable workloads. However, they must handle cold starts — the first request to a new container may take a few seconds. They mitigate by setting min instances to 5 to keep some containers warm. The exam tests the understanding that Cloud Run is managed and serverless, while Compute Engine is unmanaged and requires capacity planning.
GCDL Objective 2.2: Differentiate between managed and unmanaged services
The GCDL exam focuses on your ability to recommend the appropriate service model based on business requirements. Key objective codes: 2.2.1 (Identify managed services), 2.2.2 (Identify unmanaged services), 2.2.3 (Compare trade-offs).
Common Wrong Answers and Why
Choosing Compute Engine for a database workload because 'it's cheaper' — Candidates forget that Compute Engine requires manual setup of database software, backups, replication, and patching. The total cost of ownership (TCO) includes operational labor, which often makes managed services cheaper for small teams.
Selecting Cloud SQL when the requirement states 'root access to the database server' — Cloud SQL does not provide OS-level access; you only have database-level access. For root access, you need Compute Engine with a self-managed database.
Assuming GKE is fully managed — GKE Standard has a managed control plane but unmanaged node pools. Only GKE Autopilot is fully managed (both control plane and nodes). The exam may ask: 'Which GKE mode requires you to manage node OS patching?' Answer: Standard.
Confusing Cloud Functions (managed) with Cloud Run (also managed) but thinking one is unmanaged — Both are managed serverless platforms. The difference is in runtime environment (Cloud Functions supports fewer languages, shorter timeout).
Specific Numbers and Terms
Cloud SQL: Default backup retention = 7 days. Maintenance window = any 1-hour window per week. HA failover replica = synchronous replication to another zone.
Cloud Run: Max concurrency default = 80. Request timeout = 60 minutes (max). Min instances = 0 (default). Cold start latency = ~1-2 seconds.
Compute Engine: Default disk = 10 GB standard persistent disk. SLA = 99.5% for single instance (premium tier), 99.99% for regional MIG. Max persistent disk size = 64 TB.
GKE: Standard mode = you manage nodes. Autopilot mode = Google manages nodes. Node auto-upgrade = enabled by default in Autopilot.
Edge Cases
Managed but with some control: Cloud SQL supports databaseFlags to configure some database parameters, but not all. Cloud Run allows setting environment variables and secrets, but not the underlying OS.
Unmanaged with managed features: Compute Engine can use sole-tenant nodes for hardware isolation, but you still manage the OS. Managed instance groups provide auto-scaling and auto-healing, but you manage the instance template and OS.
Hybrid services: Cloud Functions and Cloud Run are fully managed; App Engine is also fully managed but with more restrictions (sandbox).
How to Eliminate Wrong Answers
When you see a question asking for a service recommendation, follow this elimination process:
Does the requirement mention 'full control over the OS' or 'root access'? → Eliminate all managed services (Cloud SQL, Cloud Run, Cloud Functions, App Engine).
Does the requirement mention 'low operational overhead' or 'no need to manage servers'? → Eliminate Compute Engine and GKE Standard.
Does the requirement mention 'auto-scaling from zero'? → Choose Cloud Run or Cloud Functions (managed).
Does the requirement mention 'database with automatic backups and HA'? → Choose Cloud SQL or Cloud Spanner (managed).
Does the requirement mention 'custom kernel or driver'? → Choose Compute Engine (unmanaged).
By applying this logic, you can systematically eliminate trap answers.
Managed services offload operational tasks (patching, backups, scaling) to Google, reducing overhead but limiting control.
Unmanaged services (like Compute Engine) give you full control over the OS and software but require you to manage all maintenance.
Cloud SQL default backup retention is 7 days; Cloud Run default max concurrency is 80 requests per container.
GKE Standard is partially managed (control plane only); GKE Autopilot is fully managed.
The exam tests your ability to recommend based on operational overhead, control needs, and cost trade-offs.
Always consider total cost of ownership (TCO) including labor, not just resource pricing.
Managed services like Cloud Functions and Cloud Run auto-scale from zero, ideal for variable workloads.
These come up on the exam all the time. Here's how to tell them apart.
Managed Services (e.g., Cloud SQL)
Google handles OS patching, backups, and failover automatically.
Higher per-unit cost but lower operational overhead.
Limited control — no OS access, cannot install custom kernel modules.
Auto-scaling is often built-in (e.g., Cloud Run, Cloud Functions).
SLAs are often higher (99.95%+) because Google manages redundancy.
Unmanaged Services (e.g., Compute Engine with self-managed DB)
You handle all OS patching, backups, and failover manually.
Lower per-unit resource cost but requires skilled staff for operations.
Full control — you have root access and can customize the OS.
Scaling requires manual setup of managed instance groups and auto-scaling policies.
SLAs are lower for single instances (99.5%) but can be improved with regional MIGs.
Mistake
Managed services are always more expensive than unmanaged services.
Correct
While per-unit costs are often higher, the total cost of ownership (TCO) includes operational labor. For small teams, managed services can be cheaper when factoring in the cost of a DevOps engineer to manage patching, backups, and scaling.
Mistake
GKE is a fully managed service like Cloud Run.
Correct
GKE Standard has a managed control plane but unmanaged node pools — you must patch and upgrade the nodes. Only GKE Autopilot is fully managed, where Google handles both control plane and nodes.
Mistake
Cloud SQL provides full root access to the database server.
Correct
Cloud SQL provides database-level access (e.g., root MySQL user) but not OS-level access. You cannot SSH into the underlying VM or modify system files.
Mistake
Compute Engine is a managed service because Google manages the hypervisor.
Correct
Compute Engine is an unmanaged service because you are responsible for the OS, applications, and security. Google only manages the hypervisor and physical hardware.
Mistake
Managed services cannot be customized at all.
Correct
Managed services offer configuration options via flags, environment variables, and machine type selection. For example, Cloud SQL allows setting database flags like `max_connections`, and Cloud Run allows setting container concurrency and environment variables. However, you cannot modify the OS or kernel.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Managed services (e.g., Cloud SQL, Cloud Run, Cloud Functions) are fully operated by Google — they handle the underlying infrastructure, including patching, backups, scaling, and high availability. You only configure and use the service. Unmanaged services (e.g., Compute Engine) provide raw compute, storage, and networking resources that you must configure, secure, and maintain yourself. The key trade-off is control vs. convenience. Exam tip: If a question mentions 'low operational overhead' or 'no server management,' choose a managed service. If it mentions 'full control over the OS' or 'custom kernel,' choose an unmanaged service.
GKE is a hybrid. In Standard mode, the control plane (kube-apiserver, etcd) is managed by Google, but the node pools (worker VMs) are unmanaged — you are responsible for OS patching, node upgrades, and scaling. In Autopilot mode, both the control plane and nodes are fully managed by Google. The exam may ask: 'Which GKE mode requires you to manage node OS updates?' The answer is Standard. Always check the mode when GKE appears in a question.
No. Cloud SQL provides database-level access (like the MySQL root user) but no OS-level access. You cannot SSH into the underlying VM or modify system files. If you need OS-level access for custom extensions or kernel modules, you must use Compute Engine with a self-managed database. This is a common trap on the exam.
It depends. Unmanaged services have lower per-unit resource costs (e.g., vCPU/hour) but require you to invest in operational staff and time. Managed services have higher per-unit costs but reduce the need for dedicated ops personnel. For a small team with limited DevOps expertise, managed services are often cheaper in total cost of ownership. For a large enterprise with existing ops teams, unmanaged can be more cost-effective for steady-state workloads. The exam expects you to consider both resource cost and operational overhead.
Cloud SQL (managed MySQL, PostgreSQL, SQL Server), Cloud Spanner (globally distributed managed database), Cloud Run (serverless container platform), Cloud Functions (event-driven serverless), Cloud Storage (object storage with automatic redundancy), BigQuery (serverless data warehouse), and App Engine (PaaS for web applications). These services abstract away the underlying infrastructure entirely.
Compute Engine (VMs), Google Kubernetes Engine (Standard mode — node pools), Cloud Load Balancing (you configure backends and health checks), Cloud NAT (you configure gateway), and Cloud VPN (you configure tunnels). With these, you have control over configuration but must manage the components yourself.
Managed services like Cloud Run and Cloud Functions auto-scale automatically from zero to thousands of instances based on incoming requests, with no configuration needed. Unmanaged services like Compute Engine require you to set up managed instance groups (MIGs) and define auto-scaling policies (e.g., based on CPU utilization or load balancer capacity). The exam tests this: for a variable workload with unpredictable spikes, choose a managed serverless service.
You've just covered Managed Services vs Unmanaged Services on GCP — now see how well it sticks with free GCDL practice questions. Full explanations included, no account needed.
Done with this chapter?