Analyzing and optimizing technical and business processes practice questions

Answer: A) Load test at projected peak well in advance, tune autoscaling and minimum instances from the results, and file quota increases early

For a known peak, load test at target scale months ahead, tune autoscaling and minimum instances from the results, and secure quota and capacity early, because those requests take time to approve.

• ALoad testing at target load shows whether the system and its dependencies actually scale, and where the bottlenecks are. Minimum instances reduce cold-start delay as traffic ramps up. Quota and capacity requests take time, so they need to be filed well before the event.
• BQuota increases aren't instant, so asking during the spike is too late. Default autoscaling settings that were never tested may also react too slowly to the ramp.
• CThis pays for idle capacity and still doesn't test the system under real load. It can also hit quotas, and it does nothing about bottlenecks in databases or other dependencies.
• DQuota headroom alone doesn't prove the system scales. Without load testing, problems in dependencies, slow scale-out, and cold starts stay hidden until the sale.

Answer: C) Run the workers as Spot VMs in a managed instance group sized up for the job and to zero after

For a short, interruption-tolerant batch job, the lowest-cost design uses Spot VM pricing and runs capacity only during the job. A managed instance group that scales to zero when the job finishes does both.

• AA commitment lowers the hourly rate, but you still pay for capacity 24 hours a day even though it is used for only two. This is far more expensive than paying only for the job's runtime at Spot prices.
• BStopping the VMs outside the job window removes most of the idle cost. However, the job still runs at full on-demand prices, even though it can tolerate interruptions and could run on Spot VMs at a deep discount.
• CThe job checkpoints and resumes, so it can handle Spot preemption. Spot VMs cost up to 91% less than on-demand, and sizing the group to zero after the run means you pay nothing during the 22 idle hours.
• DSpot pricing lowers the hourly rate, but leaving the VMs running still pays for 22 idle hours every day. Long-running Spot VMs can also be preempted at any time, so being always on doesn't guarantee the capacity will be there.

Answer: A) Create a materialized view that precomputes the aggregation and point the dashboard at it so that BigQuery refreshes it incrementally

For a repeated, predictable aggregation over a changing table, a BigQuery materialized view precomputes the result and refreshes it incrementally, which cuts bytes processed. The query result cache does not help when the table receives streaming inserts.

• AMaterialized views store precomputed results and add changes from the base table incrementally in the background. Dashboard queries read the small precomputed result instead of rescanning the raw table, and the data stays current.
• BBigQuery does not cache query results when a referenced table has recently received streaming inserts, or when it has changed since the results were cached. With continuous streaming, the cache will not help.
• COn a table that is not clustered, LIMIT only restricts the rows returned, not the data read. The aggregation still scans the same columns, so bytes billed stay the same.
• DLong-term storage pricing lowers storage cost, not query processing cost. It also cannot apply to a table that receives streaming inserts all the time.

Answer: A) Create a BI Engine reservation and set the dashboard tables as preferred tables

BigQuery BI Engine caches frequently used data in memory and runs queries with a vectorized engine, which speeds up repeated BI dashboard queries without changing the tools. Batch priority, authorized views and ingestion APIs do not speed up interactive queries.

• ACorrect. BI Engine is an in-memory analysis service that caches the most frequently used data and runs queries with vectorized processing. Any tool that uses the BigQuery API can use it without modification, and preferred tables focus the cache on the tables the dashboards need.
• BIncorrect. Batch-priority queries are queued and start when resources are available. This makes dashboard response slower and does not reduce the data scanned.
• CIncorrect. Authorized views control data access. A logical view still reads its underlying tables each time it is queried, so it does not speed up queries or reduce scans.
• DIncorrect. The Storage Write API is for ingesting data. It does not change how dashboard queries read or process data.

Answer: A) Standard Network Service Tier

• AThe Standard Tier routes traffic over the public internet for longer, at lower cost than Premium.
• BPremium uses Google's global network for performance, at higher cost.
• CInterconnect provides private connectivity, not cheaper internet egress for a public site.
• DCloud HSM provides hardware key protection.

Answer: A) Put a routing layer in front of the monolith and move capabilities one at a time into new services until the monolith can be retired

The strangler fig pattern modernizes a monolith step by step: a routing facade sends individual capabilities to new services until the legacy system can be retired. This avoids the risk of a big-bang rewrite. Rehosting or containerizing the whole application doesn't break it into services.

• AThis is the strangler fig pattern. A facade such as a load balancer URL map sends specific routes to new services (for example on Cloud Run or GKE) while everything else still goes to the monolith. Each step is small and reversible, and value keeps shipping.
• BRehosting changes where the application runs but leaves its architecture alone. It's still a single tightly coupled deployable, not independent services.
• CContainerizing the whole application is a replatform. It adds horizontal scaling but doesn't break up the codebase or let parts be deployed independently.
• DA parallel rebuild followed by one cutover is a big-bang rewrite under a different name. It delays value until the end and puts all the risk into a single event.

Answer: A) Use Cloud Trace to break down request latency by span, then Cloud Profiler on the slow service

Cloud Trace shows which downstream call dominates a slow request, and Cloud Profiler finds the expensive code inside that service. Together they locate the cause of intermittent latency.

• ACorrect. Trace spans show how long each downstream call took within a request, which identifies the slow service. Profiler then shows the CPU and heap hotspots in that service's code.
• BIncorrect. Uptime checks measure the endpoint from outside and can't break latency down by downstream call. Error Reporting groups errors, not slow code paths.
• CIncorrect. Flow logs record network flows, not application request spans. Audit logs record who did what, not where the code spends time.
• DIncorrect. CPU charts for each VM don't tie latency to a specific request path, and scaling up without a diagnosis may not fix the cause.

Answer: A) Committed use discounts for the always-on baseline, and Spot VMs for the interruptible batch tier

• ACommitted use discounts give the deepest savings for predictable steady usage over 1–3 years; Spot VMs offer large discounts for workloads that tolerate preemption.
• BOn-demand is the most expensive for steady baseline usage and doesn't leverage the batch tier's interruption tolerance.
• CCommitting to capacity for an interruptible tier wastes the commitment; Spot is the right fit there, and the steady baseline is what should be committed.
• DSpot instances can be preempted at any time — unsuitable for a service that must run continuously.

Answer: A) Create a BigQuery editions reservation with baseline slots and autoscaling up to a configured max reservation size

BigQuery editions reservations combine always-charged baseline slots with autoscaled slots that are billed only while scaled and are capped by the max reservation size. This gives finance a predictable, bounded cost and still handles peaks.

• ACorrect. Baseline slots are always allocated and always charged, which gives a predictable floor. Autoscaling adds slots in increments of 50 during peaks and bills them per second at the edition's capacity rate. The max reservation size caps the spend.
• BIncorrect. Quotas can cap spending, but billing is still per byte scanned under on-demand pricing. Quotas also block queries instead of adding capacity during peaks.
• CIncorrect. Long-term storage pricing lowers storage cost only. Query compute is still billed on demand, so it does not make compute cost predictable or add capacity.
• DIncorrect. BI Engine is an in-memory acceleration layer for certain queries. It does not replace BigQuery's compute pricing model or provide general autoscaling slot capacity.

Answer: A) Use assessment data to compare the TCO and expected business value of each path for this app against the effort and risk of refactoring it

Decide rehost or refactor for each workload during the assessment phase. Weigh TCO and business value against migration effort and risk, rather than relying on a single factor or a program-wide rule.

• AGoogle's assessment phase includes calculating TCO and choosing a migration strategy for each workload. Weighing the value of elastic scaling and faster releases against refactoring effort and risk is how you justify rehosting or refactoring this specific app.
• BCompatibility only shows that a rehost is possible. It doesn't measure business value or long-term cost. Frequent changes and seasonal load could make refactoring worthwhile even though the app runs unchanged.
• CThis decides the outcome before anyone has analyzed it. Refactoring adds effort and risk that must be weighed against its benefits and TCO. It isn't automatically justified by the workload's traits.
• DConsistency is not a reason to ignore differences between workloads. Google's guidance is to choose the migration strategy for each workload during assessment, based on its own requirements, dependencies, and costs.