Planning and Configuring a Cloud Solution practice questions

Answer: A) Create a custom mode VPC network and add subnets only in us-east1 and europe-west1, using ranges that don't overlap 10.130.0.0/16

Use a custom mode VPC network when you need to choose the regions and IP ranges, for example to avoid overlapping an on-premises range. Auto mode networks, including the default network, create a subnet in every region with predefined ranges from 10.128.0.0/9.

• ACorrect. Google Cloud creates no subnets in a custom mode network. You decide which regions get subnets and which IP ranges they use, so the team can create just the two subnets with ranges that don't overlap the on-premises network.
• BIncorrect. Auto mode creates a subnet in every region using predefined ranges inside 10.128.0.0/9. That block contains 10.130.0.0/16, so overlap is possible. Auto mode also doesn't let the team choose the regions or the ranges.
• CIncorrect. The default network is an auto mode network. It has a subnet in every region, and the predefined ranges come from 10.128.0.0/9 instead of the team's IP plan.
• DIncorrect. Converting an auto mode network to custom mode keeps every existing subnet with the same names and IP ranges. The unneeded subnets and the predefined 10.128.0.0/9 ranges would still be there.

Answer: A) Each VPC can create its own endpoint that uses one internal IP from its own subnet, without an allocated range or VPC peering

Private services access connects to Cloud SQL through VPC Network Peering and needs an allocated IP range. With Private Service Connect, each VPC instead creates an endpoint that uses one internal IP from its own subnet. This saves IP space and makes it easier for several VPCs to reach the same instance.

• ACorrect. A Private Service Connect endpoint is an internal IP address that you choose from your VPC, connected through a forwarding rule to the Cloud SQL instance's service attachment. Each VPC can have its own endpoint. No allocated IP range or VPC Network Peering is needed, which saves IP space and makes multi-VPC access easier.
• BIncorrect. Allocated ranges (minimum /24, recommended /16) belong to private services access, not Private Service Connect. VPC Network Peering also isn't transitive.
• CIncorrect. Private Service Connect doesn't use or change the private services access peering. That peering stays non-transitive and only exchanges routes between the two directly peered networks.
• DIncorrect. Private Service Connect is a private connectivity option. Clients connect to an internal IP address on an endpoint in their own VPC, not to a public IP.

Answer: A) Reserve a static external IP address (or promote the current one) and assign it to the VM's network interface

An ephemeral external IP is released when a VM stops, so a stable address that internet clients can reach needs a reserved static external IP. Internal IPs and Cloud NAT don't give inbound internet access.

• ACorrect. A static external IP address stays reserved in the project and assigned to the VM when the VM is stopped and started. An ephemeral address is released when the VM stops, and you can promote it to static to keep it.
• BIncorrect. Deletion protection only stops the VM from being deleted. Compute Engine still releases an ephemeral external IP when the VM is stopped and gives it a new one when it starts.
• CIncorrect. A static internal IP is fixed, but it can only be reached from inside the VPC network or connected networks. Partner systems on the internet can't connect to it directly.
• DIncorrect. Cloud NAT gives a fixed IP address only for connections the VM opens to the internet. It doesn't accept unsolicited inbound connections, so partners can't use the NAT IP to reach the VM.

Answer: A) Migrate to Containers

Migrate to Containers modernizes VM-based workloads by extracting them into container images and artifacts that run on GKE or Cloud Run, without rewriting the application. The other migration services move VMs, databases, or data, not applications into containers.

• ACorrect. Migrate to Containers extracts applications from VMs (Compute Engine or VMware) and produces container images and deployment artifacts for GKE or Cloud Run without a manual rewrite. You generate and review a migration plan, and you can adjust it before deploying.
• BIncorrect. Migrate to Virtual Machines lifts and shifts VMs into Compute Engine as VMs. It does not turn the workload into container images for GKE.
• CIncorrect. Database Migration Service moves databases such as MySQL, PostgreSQL, or SQL Server into Cloud SQL or AlloyDB. It does not containerize application servers running on VMs.
• DIncorrect. Storage Transfer Service copies object and file data into Cloud Storage. It does not analyze VMs or generate container images and Kubernetes artifacts.

Answer: A) The app needs specific OS packages or custom build steps that buildpacks' automatic language detection does not handle

Buildpacks automatically build images for standard apps in supported languages. A custom Dockerfile is worth maintaining when the app needs OS packages or build steps that buildpacks don't handle.

• ACorrect. Buildpacks detect supported languages and build on a Google-managed base image. If the app needs system libraries or build steps that buildpacks don't support, a Dockerfile gives the team full control over the image. Source deploy will use the Dockerfile if it is in the source directory.
• BIncorrect. Source deploy works without a Dockerfile. When none is present, it uses Google Cloud's buildpacks to build the image automatically.
• CIncorrect. A standard app in a supported language is the case buildpacks handle well. Here buildpacks are the faster, lower-maintenance choice.
• DIncorrect. Source deploy stores built images in Artifact Registry either way, creating a cloud-run-source-deploy repository if needed. Storage location is not a reason to choose a Dockerfile.

Answer: A) A Private Service Connect endpoint that targets the partner's service attachment

Private Service Connect endpoints let a consumer reach a producer's published service through an internal IP in the consumer's own VPC, without VPC Network Peering and with access limited to that one service.

• ACorrect. A Private Service Connect endpoint is an internal IP address in the consumer VPC, created as a forwarding rule that points to the producer's service attachment. Traffic goes one way to the published service only, and the producer and consumer networks are not peered.
• BIncorrect. Peering joins the two networks and exchanges subnet routes, so clients could reach more than the single service. It also breaks the requirement that the networks not be peered.
• CIncorrect. Private services access connects the producer network to your VPC through VPC Network Peering, which the requirements rule out. Private Service Connect provides similar private access without peering.
• DIncorrect. Private Google Access lets VMs without external IP addresses reach Google APIs and services. It doesn't give private access to a third-party partner's published service.

Answer: A) A regional Persistent Disk, replicated synchronously across two zones in the region

A resource's scope decides which failures it survives. Zonal disks are lost with their zone, while a regional Persistent Disk replicates synchronously across two zones and can fail over to a VM in the other zone.

• ACorrect. A regional Persistent Disk keeps synchronous replicas in two zones of the same region. If the primary zone fails, the disk can be force-attached to a VM in the second zone, so the data stays available without loss.
• BIncorrect. Changing the size or type of the disk doesn't change its scope. It is still a zonal resource and becomes unavailable if us-central1-a fails.
• CIncorrect. A zonal Persistent Disk can only be attached to instances in its own zone. A VM in a different zone can't attach it, in any mode.
• DIncorrect. A Local SSD is physically attached to the host of one VM, so it is zonal and its data doesn't persist on its own. It gives no protection against a zone outage.

Answer: A) Enable Requester Pays on the bucket so that each read must name a billing project that is charged for that access

Requester Pays requires readers to supply a billing project, which then pays the network, operation and retrieval charges for their access. The bucket owner keeps paying for storage. Public access, Autoclass and signed URLs do not change which project is billed for access.

• ACorrect. With Requester Pays enabled, anyone accessing the data must include a project ID with the request. That project is billed for network usage, operation charges and retrieval fees. Storage charges still go to the bucket owner's project.
• BIncorrect. This makes the objects publicly readable, but the bucket owner's project still pays all access and network charges. Public access does nothing to move costs to readers.
• CIncorrect. Autoclass optimizes storage class based on how often objects are accessed. That changes how much the owner pays, not who pays. Access and network charges still go to the bucket's project.
• DIncorrect. Signed URLs control who can access objects and for how long. Requests made through them are still billed to the bucket owner's project.

Answer: A) E2 machine series from the general-purpose machine family

For balanced, everyday workloads where low cost matters most, start with E2, the cost-optimized general-purpose series with the lowest on-demand pricing. Compute-, memory- and accelerator-optimized families are for specialized needs.

• AE2 is the cost-optimized series in the general-purpose family. It is built for everyday workloads such as web servers and has the lowest on-demand pricing of the general-purpose machine types.
• BMemory-optimized machines are for workloads that need very large amounts of memory per vCPU, such as large in-memory databases like SAP HANA. They cost far more than this balanced web workload needs.
• CCompute-optimized machines target compute-heavy work such as HPC or gaming, where high per-core performance matters. They are not the cheapest choice for a moderate, balanced workload.
• DAccelerator-optimized machines come with GPUs for ML training, inference and HPC. The workload has no special hardware needs, so they would add a lot of unnecessary cost.

Answer: A) Run backends in regions near both player groups, behind a global load balancer that sends each player to the closest region with healthy backends

For latency-sensitive apps, deploy in multiple regions close to where users are, and use global load balancing to route users to the nearest healthy region. That keeps latency low and protects against a regional outage.

• ACorrect. Google recommends deploying latency-sensitive apps such as real-time games in multiple regions close to users. Cloud Load Balancing can send users to the closest region with available capacity, and the second region keeps the game running if one region fails.
• BIncorrect. Spreading across zones protects against a zone failure, not a whole-region outage. Premium Tier improves network delivery, but European players are still served from a distant region.
• CIncorrect. A midpoint region is far from both groups, which raises latency for everyone. A single region also offers no protection against a regional outage.
• DIncorrect. Two regions give redundancy, but choosing regions only by price ignores how close they are to players. For a real-time game that sensitive to delay, user latency should drive region choice.