Envisioning future solution improvements

Yarrowfield Market runs an online grocery business in the United States on Google Cloud. Over the next three years the company expects to open a business-to-business wholesale channel and to enter two European countries with data residency rules, but the timing and order are not decided. The CTO wants the architecture to absorb these changes without a redesign.

Which two design decisions best prepare the architecture for these changes? Each correct answer presents part of the solution.

1. AExpose core capabilities such as catalog, pricing, and ordering as versioned APIs so that a new wholesale channel can reuse themWell-defined, versioned APIs let new channels reuse existing business capabilities instead of duplicating them, which keeps the platform adaptable.
2. BWrite infrastructure as parameterized Terraform modules and organize projects in folders per jurisdiction, so that a new country gets its own region and location policy by configurationRegion-parameterized modules and per-jurisdiction folders with organization policies let the company add a compliant European deployment quickly when the decision is made.
3. CHardcode us-central1 in all deployment templates to keep them simpleHardcoded regions make expansion into Europe a rewrite of every template, which is the redesign the CTO wants to avoid.
4. DBuy three-year committed use discounts now for the capacity the expansion might needCommitting to capacity for plans whose timing is unknown risks paying for unused resources, possibly in the wrong regions.
5. EPut retail, wholesale, and all countries in one shared database schema in one regionOne schema in one region cannot meet European data residency rules and couples the channels tightly, making each change riskier.

Holloway Council is building a new resident services portal and has adopted a cloud-first policy for all new systems. The project team asks the architect what this policy means for the default design choices of the portal, which has normal web application requirements and no unusual operating system or licensing needs.

Which default approach should you recommend?

1. AStart with managed and serverless services such as Cloud Run, Cloud SQL, and Cloud Storage, and use VMs only when a specific requirement calls for themCloud-first design defaults to managed services that provide scaling, patching, and availability, and keeps lower-level infrastructure for cases with a real need.
2. BDesign the portal for on-premises servers first and move it to Google Cloud laterDesigning for on-premises first is the opposite of a cloud-first policy and leads to a later lift-and-shift rather than a design that uses cloud capabilities.
3. CRun every component on Compute Engine VMs so that the design matches the data centerCopying data center patterns onto VMs keeps the patching and capacity work that managed services remove, which does not use the cloud's strengths.
4. DBuild the portal on GKE Standard so that it can move to any providerPortability can be a valid goal, but making a self-managed Kubernetes cluster the default for a normal web portal adds operational load without a stated requirement.

Penhallow Data runs 300 stateless Go microservices on N1 VMs in GKE Standard node pools that were set up five years ago. Compute is now its largest cost. The services have no architecture-specific dependencies, and the team builds container images in Cloud Build. The CTO wants to take advantage of newer Google Cloud infrastructure to improve price-performance without rewriting the services.

What should you recommend as the first step?

1. APurchase three-year committed use discounts for the existing N1 capacityCommitments lower the price of the old machine series but lock the company into it for three years, which works against adopting newer, more efficient hardware.
2. BMove all services to memory-optimized M3 machine typesM3 machines are designed for large in-memory databases, and stateless Go services do not need their memory ratio, so cost would rise.
3. CAdd GPUs to every node pool to speed up the servicesGeneral-purpose web services do not benefit from GPUs, which would add cost without improving performance.
4. DBuild multi-architecture container images and benchmark the services on a node pool of C4A machines powered by Google Axion Arm processorsGo compiles easily for Arm, multi-architecture images let the same deployment run on x86 and Arm nodes, and benchmarking C4A shows the actual price-performance gain before a wider rollout.