Google infrastructure and application modernization decisions
The Cloud Architecture and Service Models domain tests how cloud environments are structured and who is responsible for what. You need the NIST reference architecture roles, the three service models with their management boundaries, the four deployment models, and the enabling technologies of virtualisation and multi-tenancy.
Reference architecture roles
NIST SP 500-292 names five actors: the cloud consumer who uses services; the cloud provider who delivers them; the cloud auditor who independently assesses controls; the cloud broker who aggregates, integrates or arbitrages services from multiple providers; and the cloud carrier who provides network connectivity.
Service models and the responsibility boundary
- IaaS: the provider manages hardware, network and hypervisor; the consumer manages operating systems, middleware, runtime, applications and data.
- PaaS: the provider also manages the OS, runtime and middleware; the consumer manages its application code and its data.
- SaaS: the provider manages the whole stack; the consumer still manages identities, access, configuration and the data it puts in.
Deployment models
Private (single organisation), public (open to the market), community (shared by organisations with common concerns) and hybrid (two or more distinct models bound by technology enabling data and application portability). Private describes exclusive use by one organization, not a requirement for a particular location - a private cloud can be hosted by a third party.
Worked example
A team deploys containerised code and configures environment variables and scaling rules, but never patches an operating system or installs a runtime. Which model? Reasoning: the provider owns the OS, runtime and middleware; the team owns only its application and configuration. Control of scaling rules and environment settings does not make it IaaS, because IaaS would leave OS patching with the team. It is PaaS. If the team also chose and patched the OS, the answer would move to IaaS; if the team only used a finished business application, it would be SaaS.
Traps that cost marks
- Assuming SaaS removes all consumer responsibility: data classification, user access reviews and configuration remain yours.
- Confusing community cloud with hybrid cloud, or assuming private cloud must be on-premises.
- Mixing up the broker (service intermediation) with the carrier (connectivity).
- Choosing a service model by technology rather than by which management tasks the consumer keeps.
Google service choices in the study framework
The public certification guide names Compute Engine for virtual-machine workloads, Google Kubernetes Engine for orchestrated containers, and Cloud Run for managed application execution. It also discusses App Engine and Cloud Functions in its serverless examples. These are service-selection concepts rather than a promise that every name, limit or console screen remains unchanged. Check current documentation before an implementation.
A virtual-machine migration can preserve an existing operating environment but leaves relevant guest-system work with the customer. A managed platform can reduce that work while imposing supported-runtime, packaging or configuration boundaries. Containers improve packaging consistency but do not by themselves remove networking, identity, storage or operational responsibilities. Kubernetes can help coordinate container workloads, but adopting it also introduces a platform and skills decision. A small team should compare that burden with a simpler managed execution option.
An API defines an interface between systems. Exposing an interface creates opportunities for integration and can also create authorization, validation, quota and monitoring requirements. The guide uses Apigee as an API-management example. A private network connection does not itself grant an application permission to use sensitive data. Similarly, a load balancer can distribute requests but cannot automatically repair a database bottleneck or an unsafe stateful design.
The guide also names Anthos in its hybrid and multicloud discussion. Treat that naming as part of the cited study framework and verify current product packaging separately. The useful architectural question is how an organization manages policy, workload placement and operating responsibility across environments. A hybrid label does not establish data portability, resilience or identical behavior. Evaluate dependencies, latency, failure scenarios, cost and exit arrangements with evidence from the intended workload.