Google Cloud Digital Leader common mistakes
Google Cloud Digital Leader · Understand the traps and how to avoid them.
Selecting an answer that ignores reversibility and exit planning in adoption questions, for example agreeing to a migration with no data-export format, no notice period and no deletion verification, and calling that 'vendor lock-in avoidance' because the workload is containerised.
Candidates focus on the migration-in phase and on technical portability, while exam items test the contractual and operational exit conditions that determine real portability.
What to do instead
For any adoption or sourcing scenario, check four exit levers: data export format and cost, contractual notice and transition assistance, deletion certification, and skills to run the workload elsewhere. Containerisation helps only the runtime layer; proprietary managed services and egress pricing are where lock-in actually lives.
Ignoring the shared responsibility model when answering security questions, so the candidate says the provider is responsible for data classification, access management or customer application vulnerabilities, or conversely claims the customer must patch the hypervisor.
The model shifts with the service model, and candidates apply one fixed split (often the IaaS split) to PaaS and SaaS scenarios where the boundary has moved upward.
What to do instead
For each scenario, first name the service model, then place the boundary. In all models the customer retains responsibility for data, identity and access decisions, and client-side configuration; the provider covers the physical layer and, increasingly with PaaS and SaaS, the runtime and application stack. Answer from the boundary, not from a memorised slogan.
Confusing identity and access concepts in cloud security items, such as choosing 'authentication' when the question is about what a principal may do, or treating federation and single sign-on as the same control.
IAM vocabulary is dense (authentication vs authorisation, roles vs policies, federation vs SSO vs provisioning) and candidates rely on everyday usage where 'access' covers everything.
What to do instead
Fix the definitions: authentication proves identity, authorisation decides permitted actions, federation trusts an external identity provider, SSO is a user experience built on federation or a shared session, provisioning creates accounts. Read the question for the verb ('prove', 'permit', 'trust', 'create') and match it.
Treating compliance and data-location questions as purely technical, e.g. answering that encrypting data removes the need to consider where it is stored, or assuming a provider's certification automatically makes the customer compliant.
Candidates conflate security controls with legal obligations, and provider compliance pages are written to encourage that reading; the exam tests the distinction between the provider's certification scope and the customer's accountability.
What to do instead
Inspect provider assurance scope, actual duties of each party and relevant technical controls. Outsourcing does not by itself remove the customer’s own obligations. Encryption, key administration, data location, replicas and actual jurisdiction need separate analysis.
Confusing cost-management concepts, such as treating reserved capacity as automatically cheaper in every case, ignoring egress and storage-request charges when comparing options, or assuming that shutting down a virtual machine stops all billing.
Candidates reason from the headline compute price and from on-premises intuition where powering off a server ends its cost, while cloud billing includes attached storage, public IPs, licences and data transfer.
What to do instead
Build a total-cost checklist for every cost question: compute, storage (including snapshots and replicas), data transfer in/out, requests/operations, licences, and support plan. Remember that stopped instances usually still incur storage and reserved IP charges, and that reservations only pay off when utilisation is predictable and high.
Answering availability and continuity items with the wrong mechanism, e.g. offering backups as the answer for a service that must survive a zone failure, or claiming a multi-zone deployment protects against accidental deletion by an administrator.
Backup, replication, high availability and disaster recovery are taught together and candidates do not map each to the failure it addresses (component failure, zone loss, region loss, data corruption or human error).
What to do instead
Learn the mapping: multi-zone/multi-AZ handles infrastructure failure within a region; multi-region handles regional loss; replication keeps a live copy but propagates deletions; backup with versioning and immutability handles corruption and human error. Match the stated failure in the scenario to the mechanism before reading the options.
Interpreting duplicate rows from a join as genuine revenue growth.
The transformation changes the number of matches without creating additional business events.
What to do instead
Check business keys and effective-date conditions, compare distinct event counts and reconcile totals before explaining an apparent trend.
Treating one accuracy percentage as proof that a model is suitable for every decision.
Class imbalance, different error costs and uneven subgroup performance can be hidden by one aggregate measure.
What to do instead
Specify the evaluation population and compare relevant precision, recall, error types, subgroup results and operational outcomes before drawing a limited conclusion.
Confusing the three service models by what the provider 'does' rather than by where the management boundary sits, so a question about who patches the guest OS in IaaS gets answered 'the provider' or a question about a managed runtime is labelled IaaS.
Marketing descriptions blur the layers ('fully managed platform', 'serverless containers'), and candidates reason from product names instead of from the responsibility split across application, data, runtime, middleware, OS, virtualisation, servers, storage and network.
What to do instead
Draw the layer stack once from memory and mark the boundary for IaaS (provider: virtualisation, hardware, network; customer: OS upward), PaaS (provider adds OS, runtime, middleware; customer: application and data) and SaaS (provider manages everything; customer manages users and data). Apply the stack to every scenario question before choosing.
Mixing up the four deployment models, for example calling a community cloud 'public' because it is shared, or calling a provider-hosted single-tenant environment 'private' when it is a dedicated public-cloud offering.
The distinction hinges on who the resource pool serves and who controls it, not on physical location or tenancy wording, and exam distractors exploit exactly that ambiguity.
What to do instead
Identify exclusive use, the relevant resource pool, service boundary and actual deployment arrangement. Third-party hosting does not by itself disqualify a private cloud; a dedicated host offering alone also does not establish all private-cloud characteristics.