Advising development and operation teams to ensure the successful deployment of the solution

Juniper Ridge Bank runs its account service on GKE with 12 replicas and a Cloud SQL for PostgreSQL database. The next release renames the column cust_name to customer_name. The service is updated with a rolling update, so old and new pods run at the same time for several minutes, and the bank allows no downtime and needs a quick rollback path.

How should you advise the team to deploy this change?

1. AUse an expand and contract approach: add the new column and write to both columns in one release, backfill the data, switch reads to the new column in a later release, and drop the old column only after rollback is no longer neededEach step keeps the schema compatible with both the running and the previous application version, so rolling updates and rollbacks work without downtime.
2. BRename the column in a database migration that runs just before the rolling update startsOld pods still read cust_name during the rollout and fail as soon as the column is renamed, and rollback to the old version would break.
3. CScale the deployment to zero, rename the column, and deploy the new versionScaling to zero causes downtime, which the bank does not allow.
4. DDeploy the new version with a Recreate strategy so that old and new pods never run togetherThe Recreate strategy stops all old pods before starting new ones, which also causes downtime and does not solve rollback compatibility.

Ferncliff Manufacturing wants to move its 3 TB on-premises Oracle database to Cloud SQL for PostgreSQL to remove Oracle license costs. The schema contains stored procedures and triggers that must be converted, and the plant can accept only 30 minutes of downtime for the final cutover. The team wants to use Google Cloud managed tooling as much as possible.

What should you recommend?

1. AExport the Oracle data with Data Pump, copy the files to Cloud Storage, and import them into Cloud SQLData Pump files are an Oracle format that PostgreSQL cannot import, and a one-time export and import cannot meet a 30-minute cutover for 3 TB.
2. BUse Storage Transfer Service to copy the Oracle data files to Cloud SQLStorage Transfer Service moves objects and files into Cloud Storage. It does not convert or load a database.
3. CUse a Database Migration Service conversion workspace to convert the schema and code objects to PostgreSQL, fix the items it flags, and then run a continuous migration job and cut over after replication catches upDatabase Migration Service supports heterogeneous Oracle to PostgreSQL migrations: the conversion workspace translates schema and code, and the continuous job replicates changes so that cutover only needs a short final switch.
4. DRun the Oracle database on a Compute Engine VM and plan the conversion to PostgreSQL laterRehosting Oracle on a VM keeps the license costs the company wants to remove and defers the actual migration.

Kingsbridge Telecom exposes a number lookup API through Apigee to 200 developer apps. A backend on Cloud Run can handle about 500 requests per second, but sudden bursts from a single misbehaving app have caused outages. The business also sells two plans: Basic apps get 10,000 calls per day and Premium apps get 1,000,000 calls per day.

Which two actions should you perform? Each correct answer presents part of the solution.

1. AAdd a SpikeArrest policy to the proxy to smooth traffic bursts to a rate the backend can handleSpikeArrest protects the backend from sudden traffic spikes by limiting the request rate the proxy forwards, which addresses the burst outages.
2. BCreate Basic and Premium API products with different quota settings and apply a Quota policy that reads the limits from the API product of the calling appQuota limits defined on API products and enforced by a Quota policy give each app the daily allowance of its plan, without hardcoding limits in the proxy.
3. CIncrease the Cloud Run maximum instances so that the backend can absorb any burstMore instances may help with some load but costs more, and the backend's downstream limits and the per-plan allowances are still not enforced.
4. DAdd a ResponseCache policy to enforce the daily call limits per planResponse caching reduces backend calls for repeated requests, but it does not count or limit calls per app or plan.
5. EUse a Cloud Armor security policy on the Apigee load balancer to assign daily quotas per developer appCloud Armor rate limiting keys on request attributes such as client IP address or headers. It has no knowledge of Apigee developer apps or their API products, so it cannot enforce per-plan daily quotas.

Fenwick Health's operations team is new to Google Cloud. A Cloud Run service failed after a configuration change, and the on-call engineer is looking at dozens of error log entries in Logs Explorer without knowing which ones matter. The team lead wants the engineer to get help understanding the errors and the likely fix directly in the Google Cloud console, without opening a support case first.

What should you recommend?

1. AExport all logs to BigQuery and write SQL queries to count error typesExporting logs to BigQuery is useful for long-term analysis but is slow to set up during an incident and does not explain what the errors mean.
2. BCreate a log-based alerting policy for each error messageAlerts notify you about future occurrences but do not help interpret the current errors or suggest a fix.
3. CAsk a developer to add debug logging and redeploy the serviceMore logging may help later, but redeploying a broken service during an incident adds risk before the existing evidence has been understood.
4. DUse Gemini Cloud Assist in the console to explain the selected log entries, summarize the likely cause, and suggest troubleshooting stepsGemini Cloud Assist is built into the Google Cloud console and can explain log entries and errors in context and propose next steps, which helps an engineer who is new to the platform.