CDL Cheat Sheet

Scalability is the ability to add or remove capacity to meet demand, while elasticity is doing that scaling automatically and quickly in both directions as load rises and falls. Every elastic system is scalable, but a system can be scalable (you can add capacity) without being elastic (it does not adjust on its own). When a scenario describes capacity following traffic up and back down without anyone placing an order, the answer is elasticity, not just scalability.

Trap Answering 'scalability' when the scenario specifically describes capacity expanding and contracting automatically: that automatic, two-way behavior is elasticity.

Reliability is a system's ability to keep performing its function and to recover when something fails. In the cloud it is achieved by running across independent failure domains so that one fault does not take everything down, which is why workloads are spread across multiple zones. It is a property of the system, distinct from flexibility and agility, which are about the organization.

Flexibility is the freedom to choose, combine, and change technologies, regions, and providers without buying new hardware first. Agility is the business outcome that flexibility enables: teams ship and change products faster because they no longer wait weeks for servers to arrive. A question about launching features in days rather than quarters is describing agility; one about freely swapping technologies is describing flexibility.

Capital expenditure (CapEx) is money spent up front on assets you own and depreciate, such as buying servers sized for peak demand; operating expenditure (OpEx) is money spent on ongoing consumption. In the cloud most resource costs are treated as OpEx: you pay as you consume, with no up-front hardware purchase. This CapEx-to-OpEx shift is the most-tested cost concept, and 'move from CapEx to OpEx' is usually the right answer when a scenario complains about large up-front hardware spend.

Trap Calling pay-as-you-go cloud spending CapEx: owned, up-front, depreciated hardware is CapEx; consumption-based cloud billing is OpEx.

Pay-as-you-go is the baseline cloud pricing model, where you pay only for the resources you actually consume with no commitment and no up-front purchase. It is what makes the OpEx model work and is the right fit when usage is unpredictable or a team cannot commit to a term. Sustained-use and committed-use discounts then reduce the rate on top of this baseline.

A committed-use discount gives a lower price in exchange for committing to a one- or three-year term of usage, so it fits steady, predictable workloads you know will run for years. A sustained-use discount is applied automatically and grows the longer a resource runs within a month, requiring no commitment at all. The exam hinges on this contrast: 'we want a lower rate but cannot commit' points to sustained-use, while 'we will run this steadily for years and want the best rate' points to committed-use.

Trap Treating sustained-use discounts as something you sign up and commit to: they apply automatically with no commitment; only committed-use requires a 1- or 3-year term.

Public cloud runs your workloads on a provider's shared, on-demand infrastructure such as Google Cloud, AWS, or Azure. It maximizes the OpEx model, elasticity, and agility and usually delivers the lowest TCO, with the trade-off of less low-level control over the underlying hardware. It is the default choice when scale, speed, and cost matter more than owning the hardware.

A private cloud dedicates infrastructure to a single organization, often on-premises, and is chosen for data-residency rules, regulatory control, or legacy systems that cannot move. Its trade-off is mostly CapEx and limited elasticity because you still own and size the hardware. When a scenario cites a legal requirement that data stay in-country with no cloud option, private (or hybrid) is the conceptual answer.

Hybrid cloud links a private or on-premises environment with a public cloud so workloads can run across both. It is the answer when part of the estate is constrained (say a regulated database that must stay private) while the rest moves to cloud-native services. The cost is the added network and integration complexity between the two environments.

Multicloud means running on two or more public-cloud providers at once, justified by a concrete need such as avoiding vendor lock-in or using a best-of-breed service only one provider offers. It carries the most integration and skills overhead of any model, so it should be tied to a stated business reason rather than adopted by default. Note the distinction from hybrid: hybrid mixes private/on-prem with public, while multicloud mixes multiple public clouds.

Trap Choosing multicloud 'to be safer' with no stated reason: each extra provider multiplies integration and operational cost, so it must serve a concrete need like lock-in avoidance or a best-of-breed service.

A Google Cloud region is an independent geographic area, and a zone is a deployment area for resources within a region. Each region contains three or more zones, each housed in a separate physical data center, and a zone should be treated as a single failure domain. You choose a region close to your users for lower latency and spread resources across zones so a single-zone failure does not take the workload down.

Trap Treating a zone as a whole region or assuming one zone gives high availability: a zone is a single failure domain, so resilience comes from spreading across multiple zones (or regions).

Multi-region services such as Cloud Storage and Spanner replicate data across more than one region and are designed to keep working after losing a whole region. This is a stronger guarantee than multi-zone, which only protects against a single data-center failure within one region. Reach for a multi-region configuration when the requirement is to survive a full regional outage.

Latency is the time it takes a packet to travel from source to destination, while bandwidth is how much data can move per second. They are independent: a link can have high bandwidth but high latency and still feel slow for interactive use. Placing resources in a region near users primarily reduces latency, which is why proximity matters for responsiveness.

Trap Assuming more bandwidth fixes a latency problem: bandwidth is throughput capacity, latency is delay, so a high-bandwidth but far-away region can still feel slow for interactive traffic.

An IP address is the numeric address that identifies a device on a network, DNS (Domain Name System) translates human-readable names like example.com into IP addresses, and an ISP (Internet Service Provider) is the company that connects you to the internet. The Cloud Digital Leader exam expects you to recognize these foundational terms rather than configure them.

Google operates a global, privately owned fiber-optic network (including subsea cables) that connects its regions, plus a worldwide set of edge points of presence (PoPs) in over 200 locations. Because Google owns this backbone end to end, user traffic enters Google's network close to the user and stays on Google's private fiber for most of its journey rather than crossing the open public internet, which lowers latency, raises throughput, and improves security. The business takeaway is that customers get global, low-latency reach without building any of this network themselves.

Google Cloud's pre-trained APIs let you add AI to an application with a simple API call, requiring no data science team and no custom model training. Match the modality to the API: Vision API for images, Video Intelligence API for video, Speech-to-Text for audio transcription, and the Natural Language API for text analysis such as sentiment.

Trap Pre-trained APIs are for standard tasks out of the box; building a custom model on your own data without coding is AutoML on Vertex AI instead.

BigQuery is serverless: there are no clusters to provision, deploy, or manage, so analysts query large datasets with standard SQL and focus on data instead of infrastructure. Its architecture scales storage and compute independently for flexibility and cost control, supports streaming ingestion for near-real-time querying, and connects to BI tools like Looker, Tableau, and Power BI.

Trap Treating BigQuery as a provisioned warehouse that needs cluster sizing or capacity planning before you can query.

BigQuery ML lets SQL practitioners create and run machine learning models using familiar SQL, with no Python or specialized ML framework needed, democratizing predictive analytics for data analysts. AutoML on Vertex AI builds a custom model from your own training data code-free, automating data prep, model selection, and tuning.

Trap Reaching for custom-trained Vertex AI models and ML engineers when BigQuery ML or AutoML already meets the need.

Cloud Billing reports are the built-in dashboard for understanding spend: they break costs down by project, service, and SKU, show trends over time, and project likely future spend with a cost-trend forecast for budget planning. They also show savings from credits such as committed-use and sustained-use discounts, supporting departmental accountability and chargeback.

Trap Expecting Cloud Billing reports to alert you when spend crosses a threshold, which is the job of Budgets and alerts.

The organization resource sits at the top of the Google Cloud resource hierarchy and gives central visibility and control over every project and resource a company owns. It is created via Google Workspace or Cloud Identity (and is provisioned automatically the first time such an account creates a project). Folders are an optional grouping layer between the organization and projects, so an organization resource is a prerequisite for using folders; IAM policies set on a folder are inherited by the projects inside it.

A fair on-premises-versus-cloud TCO comparison counts all direct and indirect costs, not just hardware and software. Commonly overlooked items include the operational costs of running a data center (power, cooling, maintenance, and support) on the on-prem side, and ongoing, usage-based network egress charges on the cloud side, which replace what used to be a one-time cabling and network-hardware purchase.

Trap Reducing a TCO comparison to hardware and software prices while omitting power, cooling, staffing, and other indirect costs.

IaaS, PaaS, and SaaS are not separate products but three points where the provider takes over the lower layers of a computing stack and leaves the rest to you. The single question behind all three is how much of the stack you want to manage yourself, which is why Google describes them as differing in "the degree of management you're responsible for."

As you move from IaaS toward SaaS you hand off more layers, so you do less operational work and need fewer specialist staff, but you also lose control and customization over the layers the provider now owns. IaaS gives the highest control over infrastructure at the cost of hands-on management; SaaS is the fastest to adopt but offers little to no control.

Trap Assuming a more-managed model like SaaS is strictly better, when the requirement is maximum control or customization of the OS or runtime, which points to IaaS instead.

Infrastructure as a Service delivers on-demand compute, storage, networking, and virtualization, so you no longer run a data center, but you remain responsible for the operating system, runtime, scaling, and all data and apps. It suits teams that need a specific OS or are lift-and-shifting a legacy or specialized application. Google's example is Compute Engine.

Platform as a Service delivers and manages all the hardware and software needed to develop and run applications, so developers deploy their own code while the provider handles server management, patching, and scaling. You still write the code and manage your data and apps. Google's examples are App Engine and Cloud Run.

Software as a Service provides the entire application stack as a ready-to-use, fully managed application, including all updates, bug fixes, and maintenance, usually reached through a web browser with nothing to install. The customer's remaining job is taking care of their own data and user accounts. Google's example is Google Workspace.

Pick the model by the layers the scenario says the customer does not want to manage: needing OS or runtime control, or migrating a legacy app as-is, points to IaaS; wanting to deploy code without managing servers or scaling points to PaaS; needing a ready-to-use app with no infrastructure to manage points to SaaS.

Trap Choosing SaaS when the scenario requires running a specialized or legacy app that needs OS-level control, which only IaaS provides.

Every cloud service model replaces the up-front capital expense (CapEx) of buying and refreshing data-center hardware with an operating expense (OpEx) paid as pay-as-you-go or subscription. This shift applies across IaaS, PaaS, and SaaS alike, so a stem about avoiding large up-front hardware purchases is testing the model category in general, not one specific model.

Total cost of ownership counts the people needed to operate each layer, not only the invoice, so the more layers you hand off the lower the operational staffing cost. A goal of minimizing management effort or specialist headcount trends toward the more managed models (SaaS, then PaaS), because the provider absorbs the patching and operations toil.

Trap Reading "lowest cost" as "cheapest hourly rate" and picking IaaS, when a goal of fewest staff and least operational overhead favors a more managed model.

Because PaaS and SaaS run on provider-specific platforms and applications, moving away later can be hard, which Google lists as a stated disadvantage of both. PaaS can also constrain you with a limited application stack and reduced customization. IaaS keeps more portability at the cost of more hands-on management.

An organization can combine IaaS, PaaS, and SaaS, and mix them with traditional on-premises IT, rather than committing to a single model. A scenario describing different workloads on different models is therefore normal, not a mistake to correct.

The cloud shared responsibility model divides security duties between the provider and the customer, and the split follows the same line as management: wherever the provider stops managing a layer, the customer becomes responsible for securing it. The exact division therefore depends on which service model is in use.

Across every service model the cloud provider always remains responsible for the underlying network and physical infrastructure, including data centers and hardware. This part of the split never shifts, so any answer claiming the customer secures the physical servers or the provider network is wrong.

In every service model the customer always remains responsible for their own data and their access and identity policies, meaning who can sign in and what they can do. Even under SaaS, where Google manages the whole application, your data and access controls stay yours.

Trap Believing the provider secures your data under SaaS because it manages the application; data protection and access control are always the customer's responsibility.

The middle of the stack, the OS, runtime, and middleware, is the part of the security split that moves with the model: it is the customer's responsibility under IaaS but the provider's under SaaS, with PaaS in between. Under IaaS the bulk of security responsibilities are the customer's; under SaaS they reverse to the provider.

Shared fate is Google's posture of taking a more active role in helping customers secure their side of the shared responsibility split, through secure-by-default blueprints, governance tooling, and a Risk Protection Program that connects customers with cyber-insurance partners. It does not remove the customer's responsibilities; it adds provider partnership on top of the existing division.

Trap Treating shared fate as moving all security responsibility to Google; it is a partnership layered on top of shared responsibility, not a replacement for it.

Function as a Service runs small, single-purpose pieces of code in response to events such as a Pub/Sub message or a file landing in Cloud Storage, with zero server or runtime management. Cloud Functions is Google's FaaS: it provisions and scales the infrastructure automatically, scales to zero when idle, and bills only while your code runs, so you pay nothing during quiet periods.

Trap App Engine is PaaS for whole apps; FaaS/Cloud Functions is the answer specifically for single-purpose, event-triggered code.

Container orchestration automatically deploys, scales, and manages containerized applications, which is what makes breaking a monolith into independently deployable microservices practical. Google Kubernetes Engine provides this managed Kubernetes, with Google running the control plane; GKE Autopilot goes further and fully manages the nodes too (provisioning, scaling, maintenance, and security patches) so teams without deep Kubernetes expertise can run containers at scale.

Trap Autopilot mode (not Standard) is the pick when the scenario stresses minimal operational burden and no in-house Kubernetes expertise.

Across the shared responsibility model the customer is responsible for configuring the services they use: enabling high availability and disaster recovery on Cloud SQL, setting VPC firewall rules, and securing application code and container images on services like Cloud Run. Google supplies and secures the underlying capability and infrastructure, but turning it on and configuring it correctly is the customer's job.

Trap "Google provides it" does not mean Google enables it for you: features like Cloud SQL HA or firewall rules stay off until the customer configures them.

Raw data is a cost until analysis turns it into an insight that changes a decision; the value comes from the journey, not the volume. That journey is the data value chain: collect, then store and organize, then process and analyze, then act on the insight. The Cloud Digital Leader lens is to ask where a tool sits on this chain rather than which tool is newest.

Structured data has a fixed schema of rows and columns (transactions in a spreadsheet or a relational database) and is what organizations have always reported on. Unstructured data is everything without a fixed schema: text, images, audio, video, and sensor logs. Semi-structured data sits between them, with attributes that can vary per record, such as JSON event logs.

The volume of unstructured data far exceeds structured data, yet historically most of it went unanalyzed because traditional reporting tools could not read images, audio, or free text. The business opportunity in data transformation is unlocking that untapped majority. This is the bridge to AI and machine learning, which can read unstructured content and extract value from it.

A database is an operational store for live, structured records, built to run an application's many small reads and writes in real time. It answers "what is true right now" for the application, not "what happened over the last year." Pushing large analytical reporting onto it competes with the application's transactions, which is why analysis belongs in a data warehouse instead.

Trap Running heavy analytics or BI reporting directly on the live operational database: it is tuned for small real-time transactions, not large analytical scans.

A data warehouse stores data that has already been cleaned and processed and organized to a defined schema, which makes queries fast and reports trustworthy. It is built for analysis and reporting over structured (and semi-structured) historical data, answering "what happened and why." Reach for it when the business questions are known and analysts need repeatable, reliable reports.

A data lake is a central place to store all data at any scale in its raw form (structured, semi-structured, or unstructured) without defining its purpose first. That makes it the natural home for the unstructured majority and the feedstock for machine learning, answering "what might we discover later." Reach for it when you have lots of raw data and want to keep everything to explore or train models on later.

The deepest difference is when structure is imposed: a warehouse uses schema-on-write, shaping data to a defined schema before saving, while a lake uses schema-on-read, landing data raw and applying structure only at query time. Paying the cleanup cost up front buys query speed and trust but is rigid; deferring it buys cheap, flexible storage of any data at the price of cleanup at query time. "Decide first, query fast" is the warehouse; "store now, decide later" is the lake.

Trap Treating schema-on-read as merely "slower": its real trade is flexibility and low cost for any raw data, paid back as cleanup work when you query.

A data lakehouse is a modern architecture that combines the raw-data storage of a lake with the organized, queryable structure of a warehouse on one platform. For the Cloud Digital Leader exam, recognize the term and that it blends both worlds (cheap raw storage plus fast structured analytics) so you no longer have to choose strictly between siloed lake and warehouse systems.

Cloud Storage serves as the data lake on Google Cloud: object storage that holds any raw data (structured, semi-structured, or unstructured) at any scale without a schema defined first. It is the landing zone when a scenario describes dumping raw events, IoT/sensor streams, images, or files to explore or process later. Analytics and ML tools then read from it when a question finally needs answering.

Value is not limited to data you already hold: leaders create it by analyzing current internal data more deeply, capturing new data such as sensor or app-event streams that was previously discarded, and combining in external third-party data like weather or market feeds to enrich the picture. Each source extends the value chain's collect step; the store-analyze-act steps that follow are unchanged.

Data governance is the set of policies and controls over how data is collected, stored, accessed, used, and retained: who may see what, whether the data is accurate, and how privacy and compliance obligations are met. Its business value is trust: a leader can only bet a decision on an insight if the underlying data is governed for quality and access. Without governance, more data means more risk rather than more value.

Trap Answering a "the data is wrong / who may see this / compliance" problem with a specific storage product: the issue is governance policy over the data, not where it is stored.

Artificial intelligence is the broad field of building systems that reason, learn, and act like humans; machine learning is the subset of AI in which a system learns rules from data rather than having them explicitly programmed. Google defines ML as a subset of AI that learns autonomously by being fed large amounts of data. Hold the nesting straight: AI is the umbrella, ML is an application of AI, and deep learning is a further subset of ML.

In traditional programming a developer hand-codes explicit if-then rules; in machine learning you supply examples and the training process derives the rule itself. That is why ML fits problems whose rules are too varied or too subtle to enumerate by hand, like recognising what is in an image or scoring fraud. If a short, stable set of deterministic rules already solves the problem, plain logic is cheaper and clearer than a model.

Trap Reaching for ML when a handful of fixed business rules would solve the problem reliably: the model adds cost and opacity for no gain.

Business intelligence and data analytics aggregate historical data so a person can read what happened and why: dashboards, reports, and aggregates. ML instead produces a model that generalises to data it has never seen, giving a per-case prediction or classification. The signal to move from BI to ML is a team that already reports on history and now wants to predict or act on each new record.

Trap Treating analytics/BI and ML as interchangeable: one is descriptive and backward-looking, the other predicts unseen cases.

Most business ML maps to a few problem shapes: classification assigns a category (spam-or-not), regression predicts a number (next month's sales), clustering groups similar items with no labels, recommendation suggests the next item, and forecasting projects a time series forward. Naming the shape of the question is the first decision; if it does not reduce to one of these, ML is probably not the right tool.

Trap Calling a 'how many will we sell' question classification: predicting a numeric value is regression, while classification assigns a discrete category.

Supervised learning trains on labelled examples to map inputs to a known output, which is how classification and regression work: you must already have correctly-labelled historical data. Unsupervised learning finds structure in unlabelled data, which is how clustering groups items with no predefined categories. The practical implication: if you have no labels and cannot get them, supervised approaches are off the table.

Trap Assuming clustering needs labelled training data: it is unsupervised and works precisely because no labels exist.

ML earns its place where the volume, size, or kind of data defeats manual analysis. It scales one learned decision rule consistently across millions of cases, far beyond what analysts could review by hand. Reach for ML for high-frequency, repeated decisions like fraud scoring, content moderation, or demand prediction; reach for analytics when a one-off human-read report is the goal.

As the rate of data generation accelerates, ML makes it possible to analyse and find value in volumes of data no person could review. The business value is surfacing patterns and correlations hidden in very large datasets, turning raw scale from a liability into an asset. This is distinct from reporting: BI summarises data a human still reads, whereas ML extracts signal from data at a scale beyond human reading.

Images, audio, video, and free text carry enormous value but do not fit the rows and columns that traditional analytics and BI query. ML extracts meaning from this unstructured data (image recognition, transcription, translation) turning previously untapped data into usable signal. When a scenario describes value locked in documents, photos, or call recordings, that points to ML over a dashboard.

Trap Expecting a BI dashboard to extract insight from images or free text: analytics is built for structured data, so unstructured sources call for ML.

A model learns whatever its training data teaches it, so incomplete, inaccurate, or unrepresentative data produces an unreliable model regardless of the algorithm. Google notes that model accuracy improves with more samples only on the precondition that the training data is high quality. High-quality data is accurate, complete, consistent, and representative of the real population the model will serve, which is why data preparation usually decides whether an ML project succeeds.

Trap Assuming a more powerful algorithm or more compute will rescue a model trained on poor or scarce data: fix the data first, because it caps model quality.

Because the model reflects its training data, data that under-represents a group or encodes a past prejudice teaches the model to reproduce that bias on every prediction. The harm is then applied automatically across many cases, amplifying it. This is why representativeness, not just volume, matters, and why fairness checks on the data and the model are part of responsible ML.

Trap Believing an ML model is automatically objective because it is mathematical: it inherits whatever bias lives in its training data.

Explainable AI is the property that a model's outputs can be interpreted by people: knowing the reason behind a prediction, not just the prediction. It matters for trust, debugging, detecting unfair bias, and meeting regulations that require a decision to be justified. When a scenario stresses transparency, auditability, or having to explain why a decision was made, explainability is the concept being tested.

Responsible AI is the broader practice of building and operating AI that is fair, accountable, safe, and privacy-respecting, and explainability is one pillar within it rather than a synonym. Google frames responsible AI through its published AI Principles, which guide how AI should and should not be developed and used. Keep the relationship straight: fairness, accountability, safety, privacy, and explainability together make up responsible AI.

Trap Equating responsible AI with explainability alone: explainability is just one of several pillars under the responsible-AI umbrella.

Fairness, transparency, privacy, and human oversight are requirements to gather before a model is built, because retrofitting them after a model is in production is far harder. Treating governance as a launch checklist rather than a design input is how bias and opaque decisions ship to users. The exam favours answers that weigh explainability and fairness early in the AI decision.

The cloud provider supplies tools, safety filters, and AI Principles, but the customer remains responsible for testing models and adhering to acceptable-use and prohibited-use policies. Responsible AI is therefore a shared obligation, mirroring the shared-responsibility theme that runs across this exam, not something the platform fully handles on your behalf. Expect scenarios that test who is accountable for safe and compliant model use.

Trap Assuming the cloud provider's built-in safety features make the customer fully responsible-AI compliant: the customer still owns testing and policy adherence.

Google Cloud's compute products line up by degree of abstraction: Compute Engine (VMs, you manage the OS) is the most controllable, then GKE (managed Kubernetes for containers), then Cloud Run (serverless containers), then Cloud Run functions (serverless functions) is the most managed. Moving toward the managed end hands more operational work (patching, scaling, capacity) to Google in exchange for less low-level control. The whole compute decision is just picking the right point on this line for a workload.

Start at the serverless end and step toward control only when a constraint forces it, because the less infrastructure you manage the less undifferentiated work your team carries. In practice that means try Cloud Run first, move to GKE when you genuinely need container orchestration or portability, and drop to Compute Engine VMs only for OS-level control or apps that can't be re-architected.

Trap Reaching for a VM or a Kubernetes cluster by habit when a managed serverless service would run the workload. That leaves your team operating servers Google would otherwise run.

Compute Engine gives virtual machines with operating-system-level control and custom machine types, so pick it when a workload needs a specific OS, custom or specialized hardware, GPUs with full control, or is a monolithic/legacy app like a packaged relational database or ERP. Unlike the serverless options it does not scale to zero: a running VM keeps billing until stopped. It is also the standard landing place for a rehosted (lift-and-shift) app because a VM most resembles the server the app already ran on.

Trap Assuming a serverless service can satisfy a hard OS-level or custom-hardware requirement. Those layers are deliberately hidden by Cloud Run and Cloud Run functions.

Spot VMs are Compute Engine instances sold from Google's spare capacity at a steep discount (up to roughly 90% off on-demand), but Google can reclaim them at any time after a brief, best-effort shutdown notice. They fit fault-tolerant, interruption-tolerant work such as batch processing, rendering, or CI fleets, where a reclaimed instance simply reruns. Spot VMs are the current generation of what Google previously called preemptible VMs.

Trap Putting a steady, always-on production workload on Spot VMs. Reclaimable capacity is wrong for anything that must stay up; use on-demand or committed-use capacity instead.

Google Kubernetes Engine is a managed implementation of Kubernetes, the open-source container-orchestration system Google originally created, where orchestration means scheduling containers, restarting failed ones, and scaling them. Choose GKE when you run many containers needing orchestration, want microservices at scale, or need the same Kubernetes platform across multiple environments for portability. It does not scale to zero: its nodes keep running.

Trap Choosing GKE for a single stateless web service just to run a container. The orchestration and node management is overhead Cloud Run removes for that case.

In GKE Autopilot mode (the recommended default) Google also manages the worker nodes and you pay only for the resources your running workloads request; in Standard mode you manage the node pools yourself when a workload needs that level of control. The split matters at decision level: Autopilot is less operational work, Standard trades that for finer control over the underlying machines.

Trap Assuming Standard mode is the normal way to run GKE. Autopilot is the recommended default and offloads node management to Google.

Cloud Run is a fully managed platform that runs your container without you managing clusters or infrastructure, and it is the default for HTTP services, web apps, and REST/GraphQL/gRPC APIs. Its two defining behaviors are scaling to zero when idle and billing only for the CPU and memory used while serving requests. It can also handle event-driven and asynchronous workloads.

Cloud Run scales to zero: if no requests arrive, even the last instance is removed, so you pay nothing while idle. The flip side is that a request arriving against zero instances incurs a cold start, and a workload needing a persistent always-running background process is a poor fit for scale-to-zero. For those, a VM or a GKE workload that keeps running is the better match.

Trap Putting a workload that must keep a long-lived process always running on a scale-to-zero serverless service. It gets torn down when idle.

Cloud Run functions (formerly named Cloud Functions) runs an individual piece of code in response to an event such as an HTTP request, a file landing in storage, or a published message, the most abstracted compute rung, where you supply only the function body. Reach for it for small event-driven logic, not whole applications, which belong on Cloud Run, GKE, or a VM.

Trap Standing up a VM or a GKE cluster to host a single event-triggered snippet. That is far more infrastructure than the task needs.

A container bundles an application with its libraries and dependencies so it runs the same on a laptop, in a data center, or in any cloud, which is what makes container-based apps portable. This is the deployment unit GKE and Cloud Run both run, and it pairs with microservices: splitting one large application into small, independently deployable services usually shipped as separate containers.

Autoscaling adds compute when load rises and removes it when load falls so you pay for what a workload actually uses instead of provisioning for peak. On Compute Engine this works through a managed instance group (identical VMs from one template) that the autoscaler grows or shrinks on signals like CPU utilization or load-balancing capacity; serverless products autoscale per request, including down to zero. This automatic elasticity is a core reason cloud compute costs less than a fixed on-premises fleet sized for the yearly peak.

A load balancer distributes user traffic across multiple instances of an application so no single instance is overwhelmed, which raises availability and lets the app absorb spikes. It works hand in hand with autoscaling: the load balancer spreads requests across the current instances while autoscaling changes how many instances exist to keep up with that traffic.

Rehosting moves a workload to the cloud with little or no modification, and it is the right path when an app is legacy or specialized, when there is no business case to change it, or when you simply cannot refactor it. The natural target is a Compute Engine VM, because it most resembles the on-premises server the app already ran on, letting the app operate as-is while still gaining cloud elasticity and reliability.

Trap Choosing rehost-to-VM when the business actually wants the app modernized. That is a replatform or refactor decision, not lift and shift.

On-premises you buy hardware for the yearly peak and pay for it even when idle; cloud compute instead scales capacity up and down with demand and bills accordingly, turning a large fixed capital cost into a variable operating cost. That elasticity, delivered by autoscaling and the pay-per-use serverless model, is the central business value of cloud compute the exam expects you to articulate.

The CIA triad names the three goals all security serves: confidentiality (only authorized parties can read data), integrity (data is accurate and untampered), and availability (data and services are reachable when needed). On the exam, classifying an incident by the property it violated is usually the answer: leaked data is confidentiality, altered records are integrity, an outage is availability.

Confidentiality fails when data is disclosed to someone unauthorized: a leaked customer list, a misdirected email, a stolen laptop. It is protected by encryption, access management, and authentication. Keep it distinct from integrity (which is about unauthorized change) so you pick the right CIA property when a scenario describes exposed data.

Trap Calling a silent data alteration a confidentiality breach: changing data without disclosing it is an integrity failure, not confidentiality.

Integrity means data and systems are accurate and have not been altered by anyone unauthorized; the failure mode is tampering, such as a payment amount silently changed or a record deleted. It is protected by checksums, digital signatures, and audit logs that reveal whether something was modified. Read the scenario for whether data was changed (integrity) versus merely seen (confidentiality).

Availability means authorized users can reach the data and services when they need them; the failure mode is denial, whether from a DDoS flood, a hardware failure with no backup, or a ransomware lockout. It is protected by redundancy, backups, and DDoS defense. An attack that knocks a site offline during a sale is an availability incident, even if no data was stolen.

The CIA properties are not mutually exclusive: ransomware that both exfiltrates and encrypts data breaks confidentiality and availability at once. When classifying an incident, read what actually happened to the data rather than assuming exactly one property applies.

Phishing and social engineering (tricking someone into revealing credentials or clicking a malicious link by impersonating a trusted party) are the single most common entry point, because they target human judgment rather than a technical weakness. The leadership consequence is that security awareness and least-privilege access matter as much as technical controls, since buying more perimeter hardware does not address the human vector.

Trap Treating phishing as a purely technical problem solved by firewalls: it exploits human judgment, so awareness training and least privilege are the real mitigations.

The threats the exam expects you to recognize are phishing/social engineering, malware and ransomware (which steal or encrypt data for payment), insider threats (misuse of legitimate access, malicious or accidental), and DDoS (flooding a service so users can't reach it). Each maps back to the CIA triad: ransomware hits confidentiality and availability, DDoS hits availability, an insider can hit any of the three.

A Cloud Digital Leader describes security risk in business terms: financial loss (theft, fraud, ransom, recovery cost), regulatory penalties (fines for violating GDPR, HIPAA, and similar), operational downtime (lost productivity and sales), and reputational damage (eroded customer trust and churn). The reputational and trust damage is frequently the costliest and longest-lasting consequence, often outweighing the immediate financial hit.

Trap Assuming the direct financial loss is always the biggest cost: reputational and customer-trust damage often outlasts and outweighs it.

The shared responsibility model splits security tasks between provider and customer: Google secures the infrastructure (data centers, hardware, the global network) while the customer secures what they run on it (their data, access, and configuration). It does not make security less important: it changes who is responsible for which part. On-premises, by contrast, the organization owns the entire stack and every control.

Trap Reading shared responsibility as outsourcing all security to the provider: the customer is always responsible for their own data, access, and configuration.

Where the shared-responsibility dividing line sits depends on the service model: in IaaS the bulk of security tasks are the customer's, and the provider's share grows through PaaS until, in SaaS, the provider owns most of it and the customer mainly secures their access and the data they choose to store. The customer is responsible for their data and access in every model: only the rest of the line shifts.

Google frames shared fate as an ongoing partnership to improve security: rather than handing the customer a checklist of their responsibilities and stepping back, Google provides secure defaults, vetted blueprints, and guidance so the customer's side of the line is easier to get right. It is the cooperative complement to the shared responsibility model, which only divides the tasks.

Moving to the cloud is not inherently riskier; a hyperscale provider affords controls most organizations cannot and enables many by default. Google encrypts all customer data at rest automatically with AES-256 and no action required, encrypts data in transit, and runs zero trust, whereas on-premises those protections are something the organization must design, fund, and enable itself.

Trap Assuming on-premises is automatically safer because the data is physically in-house: providers turn on encryption and zero trust by default that most on-prem estates lack.

Secure-by-default does not make the cloud automatically safe, because the customer still owns their side of the shared-responsibility line. The majority of real-world cloud security incidents trace to customer misconfiguration (an over-permissive access rule, a publicly exposed storage bucket) rather than a breach of the provider's infrastructure. The cloud raises the security floor, but the customer still has to configure their part correctly.

Zero trust grants access based on continuous verification of identity and context rather than trusting a device just because it sits inside the network perimeter. It is the structural answer to insider and phishing threats, which defeat perimeter-based trust by operating from inside or with stolen credentials. Every access is authenticated and authorized regardless of where it originates.

Trap Believing a trusted internal network removes the need to verify internal traffic: zero trust verifies every access precisely because insiders and stolen credentials bypass the perimeter.

A security control is a safeguard that reduces risk; compliance is demonstrating to an outside party (regulator, auditor, customer) that the required controls are in place and working against a standard. Controls are what you do to be secure; compliance is how you prove it. The two are distinct: a system can have strong controls before it is certified, and certification alone does not guarantee real-world security.

Trap Treating passing an audit as proof the system is actually secure: compliance shows controls exist on paper but is evidence, not a substitute for the controls working.

Security controls fall into three categories the exam may ask you to recognize: technical (or logical) controls enforced by technology such as encryption, access management, and logging; administrative controls that are policy and process such as training and access-review procedures; and physical controls that protect the premises such as badge access and cameras. A complete security posture uses all three, not just technical tools.

Because Google's infrastructure is independently audited and certified against standards like ISO 27001, SOC 2, GDPR, and HIPAA, the customer inherits that coverage for the provider's layer and only has to demonstrate compliance for their own layer. This narrows the scope and cost of an audit compared with proving every certification yourself on-premises: a concrete business benefit of the cloud.

Authentication verifies identity (proving who a user or system is) while authorization determines what that authenticated identity is permitted to do. They run in that order: you authenticate first, then the system authorizes specific actions. Confusing the two is a common error, so anchor on who (authentication) versus what (authorization).

Trap Using authentication and authorization interchangeably: verifying identity is separate from granting permissions, and a valid login still needs authorization for each action.

Least privilege means granting an identity only the access required to do its job and nothing more, which limits the blast radius if an account is compromised or misused. It is a core defense against both insider threats and stolen-credential attacks, since a tightly scoped account can do far less damage than an over-permissive one.

Encryption encodes data so only a party holding the key can read it, protecting confidentiality both at rest (stored data) and in transit (data crossing a network). In Google Cloud both are provided by default, so even a stolen disk or intercepted packet yields unreadable data without the key, which is why encryption is a primary confidentiality control.

Cloud financial governance is the discipline of keeping pay-as-you-go spending predictable and accountable, not just cheaper. It matters because anyone can launch billable resources without a purchase order, so cost can grow unnoticed. Google frames good governance as a repeating loop of visibility (see the spend), control (cap and alert on it), and optimization (remove waste), and the exam rewards answers that improve process and accountability over answers that just buy less.

Total cost of ownership (TCO) is the complete cost of running a workload, including power, cooling, data-center space, staff, and hardware refresh, not only the sticker price of equipment. Cloud typically lowers TCO by folding those hidden on-premises costs into one usage-based bill and removing the over-provisioning needed to cover peak demand. "Reduce TCO" is the right answer when a scenario complains about idle or over-bought hardware.

Google Cloud organizes everything into four levels: an organization at the root (the company), optional folders that group by department or environment, projects that hold workloads, and the resources (VMs, buckets, databases) inside each project. Every resource except the organization has exactly one parent, forming a single tree. This structure is the backbone of governance because both access control and cost reporting roll up along it.

Identity and Access Management (IAM) policies set high in the resource hierarchy are inherited by everything beneath them, so a role granted on a folder applies to every project and resource inside it. This lets you grant access once at the right level instead of repeating it resource by resource, which is how least-privilege is enforced at scale. Set policy as high as is appropriate, and it cascades down automatically.

Trap Assuming a permission granted on one project also covers a sibling project: inheritance flows downward from a shared parent, not sideways between projects.

Because billing rolls up the same organization-folders-projects tree used for access, the resource hierarchy is also how you answer "which team or environment spent what." Designing folders to mirror how the business is organized lets you budget and report spending per department or per environment. The same structure that controls who can do what also attributes the cost of what they do.

Resource quotas cap how much of a resource a project can consume, such as API calls per minute or CPUs in a region. When a request would exceed a quota, the system blocks it and the operation fails, which protects both the shared platform and your own bill from runaway consumption. Quotas are the control to reach for when the goal is to actually prevent excess usage rather than merely be warned about it.

Trap Reaching for a budget when the requirement is to physically stop usage: budgets only notify; a quota is what enforces a hard cap.

A Cloud Billing budget tracks spending against a planned amount and sends notifications as threshold rules are crossed, but setting a budget does not automatically cap or stop usage or billing. It is a smoke detector, not a circuit breaker: it tells people spending is climbing so they can act. To turn an alert into an actual stop, route it to automation (for example via Pub/Sub) that takes action; the budget alone will not.

Trap Assuming a budget will halt spending once exceeded: it only fires notifications; usage and billing continue unless something else acts.

Budget threshold rules define the points at which alerts fire, and a new budget defaults to notifying at 50%, 90%, and 100% of the planned amount. Thresholds can be evaluated against actual cost already accrued or against forecasted cost projected to the end of the billing period. Notifications go to Billing Account Administrators and Users by default and can be widened to other channels.

Quotas and budgets are easy to confuse because both relate to limits, but they act oppositely. A quota is a hard limit that blocks the request and fails the operation when exceeded, so it can prevent spend. A budget is notification-only: it alerts at thresholds but lets usage and billing continue. Match the verb in a question: "prevent/cap usage" points to a quota, "notify/alert when approaching" points to a budget.

Trap Treating quota and budget as interchangeable cost controls: only the quota stops usage; the budget merely sends alerts.

Cloud Billing Reports is the built-in tool for viewing and analyzing Google Cloud cost and cost trends. It breaks spending down by project, service, SKU, location, label, and time period, and shows forecasted alongside actual cost, answering questions like which project cost the most last month. It supplies the visibility half of governance, which budgets and the hierarchy then act on.

Sustained-use discounts lower the rate automatically the longer an eligible resource runs within a billing month, with no commitment and no action required from you. They are the right optimization lever when you run resources often but cannot promise a fixed term. Because they are automatic, the correct answer to "we want a lower rate but cannot commit" is sustained-use (or plain pay-as-you-go), not a contract.

Trap Assuming you must sign up or configure something to get sustained-use discounts: they are applied automatically based on usage.

Committed-use discounts give a reduced price in exchange for committing to a one- or three-year term of usage, and they typically beat sustained-use discounts for spend you can predict. They fit steady, always-on workloads you are confident will keep running. The decision contrast: pick committed-use when usage is predictable and long-running, and sustained-use or pay-as-you-go when it is not.

Trap Choosing committed-use discounts for spiky or short-lived workloads: the multi-year commitment is wasted if the usage does not actually persist.

A Cloud Billing account defines who pays for a set of Google Cloud resources. One billing account can be linked to multiple projects, but each project is linked to exactly one billing account at a time. Organizations may use multiple billing accounts when they must split charges for legal or accounting reasons.

Trap A project links to only ONE billing account at a time, not several

Labels are key-value pairs attached to resources (such as team:engineering or a cost-center identifier). Label information is forwarded to the billing system, letting you categorize and report spend by department, environment, or application without creating separate billing accounts or restructuring the project hierarchy.

Trap Labels enable internal chargeback reporting; you do NOT need a separate billing account per team

Recommender (part of Active Assist) analyzes usage data with machine learning to identify waste such as idle VMs and over-provisioned resources, then generates cost-saving recommendations to stop, delete, or right-size them.

Trap Recommender is the proactive ML cost-optimizer; Billing Reports only show what you already spent