GCP Cloud Digital Leader Practice Test

Elastic resource scaling-often called elasticity-allows Google Cloud workloads to grow when demand increases and shrink back when demand falls. Because the company no longer pays for permanently provisioned peak-capacity hardware, idle capacity costs are avoided, improving total cost of ownership. The other options may improve performance or resiliency but do not directly address paying for unused compute resources.

Cloud Run is a fully managed container platform. You hand Google Cloud a container image, and Cloud Run provides an HTTPS URL, handles all infrastructure tasks, and automatically scales each revision from zero to as many instances as needed. Google Kubernetes Engine and managed instance groups require infrastructure or cluster administration and do not scale individual containers to zero. App Engine flexible environment supports containers but keeps at least one instance running, so it cannot scale to zero.

Cloud Bigtable is designed for very large, high-throughput workloads such as IoT and time-series streams. Its distributed architecture supports millions of writes per second and provides single-digit millisecond latency for point reads and writes, while automatically scaling to petabytes of data. BigQuery is excellent for analytical queries but is optimized for batch ingestion rather than low-latency operational lookups. Cloud SQL offers familiar relational capabilities but cannot scale horizontally to the required write rate. Firestore is a serverless NoSQL document store suited to mobile back-ends, yet it cannot match Bigtable's sustained throughput at a global scale.

Cloud agility is the capacity to quickly provision resources, develop, test, and deploy applications, so teams can shorten release cycles and respond to feedback faster. Elasticity focuses on automatic scaling to match variable demand, which helps handle traffic spikes but does not directly accelerate release frequency. Global reach relates to serving users from multiple geographic regions, and sustainability concerns environmental impact; neither of these capabilities specifically drives faster software iteration.

Google Cloud Armor integrates directly with external HTTP(S) load balancers to provide Google-scale protection against both network-layer (L3/4) and application-layer (L7) DDoS attacks. It lets administrators create security policies that can block or rate-limit abusive IP addresses and leverages the same global edge infrastructure Google uses for its own services.

VPC firewall rules offer only basic allow-or-deny filtering and do not include advanced DDoS detection. Cloud NAT provides outbound address translation and does not mitigate unsolicited inbound attacks. Cloud Storage is an object storage service; while it benefits from Google's default infrastructure protections, it is not a dedicated DDoS mitigation service for web applications. Therefore, enabling Cloud Armor is the appropriate choice.

A rehost, or "lift-and-shift," migration copies the existing virtual machine image to Compute Engine with little or no modification. For highly specialized legacy software where source code changes are impractical, rehosting provides the fastest path to the cloud, avoids the cost and risk of refactoring, and lets the business retire on-premises hardware while immediately gaining Google Cloud's elastic resources. Replatforming, refactoring, or fully re-imagining the application would delay migration and require code access, so they do not meet the stated constraints.

With a PaaS such as Google App Engine, Google manages the underlying infrastructure, operating system, runtime, and network. The customer remains responsible for what runs on top of the platform-such as their application code, the data it stores, and who can access that data. Therefore, configuring Identity and Access Management (IAM) policies to control access to the application and its data is the customer's duty. Google, not the customer, handles operating-system patching, physical server maintenance, and backbone network routing.

Public cloud offers on-demand self-service and rapid scalability (elasticity). Teams can spin up resources instantly to test new ideas and automatically scale them up or down with use, paying only for actual consumption. The other options describe traditional CapEx approaches, limited regional deployment, or proprietary lock-in, none of which deliver the same agility or cost flexibility.

Public cloud platforms let organizations add or remove compute capacity within minutes, paying only for what they actually use. This elasticity means the startup can seamlessly scale out during high-traffic campaigns and scale back when demand drops, avoiding the cost and inflexibility of buying peak-sized on-premises hardware. The other options either describe traditional practices (fixed capacity or manual provisioning) or a governance concern (data residency) that does not address the need to match resources to short-lived demand spikes.

Because the team wants to supply and control its own application code but does not want to provision or maintain the underlying servers, operating systems, or runtime stack, a Platform as a Service (PaaS) offering is the best fit. PaaS solutions let customers deploy custom applications to a managed platform that handles infrastructure, patching, and scaling. Infrastructure as a Service would still require the team to manage virtual machines and operating systems, and Software as a Service would provide a finished application they could not customize at the code level. Colocation hosting is an on-premises alternative that leaves all hardware and software management to the customer.

Cloud platforms let customers add or remove compute, storage, and networking resources within minutes. This elasticity (or scalable, on-demand provisioning) means the retailer can automatically scale up to handle the 10× traffic spike during each flash sale and scale back when demand subsides. Because resources are metered and billed only while in use, the company avoids the capital expense of purchasing and maintaining servers that would remain under-utilized most of the time. Global distribution, dedicated hardware, or advanced machine learning services offer other advantages, but they do not simultaneously address the dual needs of rapid capacity expansion and pay-per-use cost efficiency as directly as elastic scalability does.

Google's private global backbone network carries customer traffic on Google-owned fiber between edge points of presence and Google Cloud regions. By keeping traffic on this high-capacity, software-defined network for most of its journey, the platform can deliver content with lower latency and fewer hops without building its own worldwide infrastructure. Sustained use discounts reduce VM cost but do not address latency. Regional replication keeps data inside one geography, not across continents. Customer-managed encryption keys improve security compliance but have no effect on performance or global reach.

Cloud Spanner is Google Cloud's horizontally scalable, strongly consistent relational database. It automatically shards data across nodes and even multiple regions, giving near-unlimited capacity while preserving ACID semantics. Cloud SQL for PostgreSQL is fully managed but limited to vertical scaling on a single region. BigQuery is an analytics warehouse, not an OLTP database, and Firestore is a document-oriented NoSQL store, so neither meets the requirement for a relational system with strong consistency across regions.

Relational databases are designed for highly structured data that follows a fixed schema. They use Structured Query Language (SQL) to define and manipulate data, support relationships between multiple tables, and can enforce constraints such as primary and foreign keys for referential integrity. Non-relational key-value stores and NoSQL document databases do not require fixed schemas and generally lack robust join capabilities, while object storage is optimized for unstructured binary objects and does not support table structures or SQL queries. Therefore, a relational database is the most appropriate choice for the described HR application.

Cloud-native development focuses on building and running applications that fully exploit cloud characteristics such as on-demand scalability, managed infrastructure, microservices, containers, and automated delivery pipelines. While digital transformation is the broader business change enabled by technology, open source refers to licensing that makes source code publicly available, and a private cloud is an environment run solely for one organization-none of which specifically captures the redesign strategy described.

In the Infrastructure as a Service (IaaS) model, the provider delivers the fundamental computing resources-such as physical servers, networking, storage, and the virtualization layer-while the customer retains control of the operating system, middleware, runtime, and applications. By contrast, Platform as a Service (PaaS) abstracts away the operating system and runtime so customers focus mainly on code and data, and Software as a Service (SaaS) delivers complete applications managed entirely by the provider. Function as a Service (often referred to as serverless) abstracts even more, automatically handling provisioning and scaling of runtime resources for event-driven code. Therefore, the described responsibility split aligns with IaaS, not PaaS, SaaS, or FaaS.

AutoML Vision lets organizations upload their own labeled images and automatically trains an image-classification model without requiring deep ML knowledge or complex infrastructure management. This matches the retailer's need to recognize custom, domain-specific attributes while keeping effort and expertise requirements low. The pre-trained Cloud Vision API cannot be taught new, specialized labels; it only returns generic categories. Building a fully custom model on Vertex AI with TensorFlow offers maximum flexibility but demands significant ML expertise and operational overhead. BigQuery ML focuses on structured data and does not train image-recognition models, so it is unsuitable for this scenario.

In the Platform as a Service (PaaS) model, Google Cloud provisions and maintains the underlying infrastructure, including virtual machines, networking, storage, operating-system updates, and the language runtime or middleware. Developers simply deploy their application code and manage their own data. With Infrastructure as a Service, the customer would still need to maintain the guest OS and runtime components, which the team wants to avoid. Software as a Service removes even application-level control, offering a complete ready-made application-more than the team requires. A colocation or on-premises environment would leave all infrastructure and platform maintenance entirely with the customer. Therefore, PaaS aligns most closely with the stated responsibilities and desired level of control.

Elasticity refers to the cloud's ability to automatically add or release resources so that capacity closely tracks real-time demand. This prevents overprovisioning for peak periods and under-utilizing hardware during quiet times, reducing wasted spend and improving total cost of ownership. Scalability focuses on growing capacity (not necessarily shrinking it automatically), reliability concerns availability of services, and shifting from CapEx to OpEx describes a financial model rather than an on-demand technical capability.

Public cloud platforms provide elasticity-the capability to scale resources up or down automatically in response to actual workload demand. Because resources expand during peak periods and contract when demand falls, the company no longer needs to predict peak usage far in advance or maintain idle hardware during normal periods. High availability, lower capital expenditure, and full physical-stack control are important considerations, but they do not by themselves solve the specific issue of over- or under-provisioning for variable traffic.