Task 5.1: Advising development and operation teams to ensure the successful deployment of the solution.

• AAPI Gateway with an OpenAPI specification for each backend service

  Incorrect

  API Gateway gives a managed REST front door, but not the developer portal and API product model for self-service partner onboarding.

• BApigee API proxies published as API products in a developer portal

  Correct

  Apigee adds security, quotas and analytics to API proxies, and its developer portal lets providers discover the APIs, read the docs and register their apps themselves.

• CShared SFTP drops and a documentation wiki for each new provider

  Incorrect

  This repeats the legacy file-based integration and gives providers no self-service registration, API keys, quotas or usage analytics.

• DPub/Sub topics that each provider publishes to with a service account

  Incorrect

  Pub/Sub is messaging; creating accounts per provider is manual and offers no documented API catalog.

Partner onboarding at speed is an API management problem: publish the APIs as products, let partners self-register through a portal, and govern each partner's use with keys, quotas and analytics.

• ADatabase Migration Service continuous jobs into Cloud SQL

  Incorrect

  Database Migration Service moves databases into Cloud SQL or AlloyDB; it does not feed BigQuery for analytics.

• BBigQuery Data Transfer Service loads of nightly export files

  Incorrect

  Nightly batch loads are not near real time, and exports put load on the source.

• CDatastream change data capture from Oracle into BigQuery

  Correct

  Datastream is a serverless CDC service that reads the database's change log and replicates changes into BigQuery with minimal latency.

• DStorage Transfer Service jobs that copy database files hourly

  Incorrect

  Copying database files moves storage blobs, not queryable, consistent table data.

Data migration and management tooling should match the target: change data capture into BigQuery is Datastream's job, without custom code or heavy source queries.

• AA Cloud Build trigger per environment that rebuilds the image from the source branch

  Incorrect

  Rebuilding for each environment produces different artifacts, which is the problem to remove.

• BCloud Deploy pipelines with a target per environment and an approval for production

  Correct

  A Cloud Deploy release is promoted through the targets in the pipeline's sequence, and a target can require approval before the rollout proceeds.

• CShared kubeconfig files kept in Secret Manager so that every team uses the same access

  Incorrect

  Shared credentials standardize access, not what gets deployed or who approves it.

• DA separate Artifact Registry repository per environment that each team pushes to

  Incorrect

  Separate repositories with independent pushes still let each environment receive a different build.

Application deployment advice: build once, promote the same release through environments and gate production with an approval. Cloud Deploy manages that progression for GKE, Cloud Run and other targets.

• AApigee hybrid, with the runtime plane on the bank's own Kubernetes

  Correct

  Apigee hybrid hosts the management plane in Google Cloud and runs the runtime plane on supported Kubernetes platforms that the customer manages, including on-premises.

• BApigee in Google Cloud, reaching on-premises backends over Interconnect

  Incorrect

  The API runtime would still process traffic in Google Cloud, which the regulator does not allow.

• CAPI Gateway in Google Cloud with backends reached over Cloud VPN

  Incorrect

  API Gateway hosts the APIs it serves in Google Cloud, so the traffic would not be processed in the bank's data center.

• DAn internal Application Load Balancer with hybrid network endpoint groups

  Incorrect

  This load-balances traffic to on-premises endpoints but provides no API management.

API management best practice includes choosing the deployment model that fits regulatory constraints. Apigee hybrid splits a cloud-hosted management plane from a customer-run runtime.

• ATrust autoscaling, because managed services scale up without any practical limits

  Incorrect

  Autoscaling has limits and warm-up times that only testing reveals.

• BExtend the unit test suite so that every function has full coverage

  Incorrect

  Unit tests check code correctness, not behavior under ten times the load.

• CLoad test a production-like environment at the expected peak and watch Monitoring

  Correct

  Load and stress tests that simulate realistic traffic show whether the system and its scaling meet the peak, and where the bottlenecks are.

• DRun a load test against production at the start of the holiday sale

  Incorrect

  Testing during the event finds problems when it is too late to fix them.

Testing frameworks include load testing. The operational readiness principle calls for performance and load testing so that applications can handle peak loads before they happen.

• AIngress on the backend set to internal traffic from the VPC network

  Incorrect

  Ingress limits the network paths to the service, so any internal caller still gets through; it does not identify the storefront.

• BAn API key that the storefront sends and the backend's code checks

  Incorrect

  This is the custom authentication code the team wants to avoid, and a shared key does not prove which service is calling.

• CRequired authentication on the backend, with Invoker for the caller

  Correct

  The storefront's service account gets the Cloud Run Invoker role on the backend and sends a Google-signed ID token, so IAM rejects other callers.

• DA Cloud Armor rule that allows the storefront's outgoing addresses

  Incorrect

  Cloud Armor filters traffic at a load balancer by attributes such as source IP; an address does not prove the caller's service identity.

For service-to-service calls on Cloud Run, Google recommends IAM with a per-service service account: grant the calling service the Invoker role on the receiving service and have it present an ID token. Network ingress settings can add a layer, but they do not identify the caller.

• AMigrate to Virtual Machines to rehost the Oracle server onto Compute Engine VMs

  Incorrect

  Rehosting keeps Oracle and its licenses, which the company wants to remove.

• BManaged Service for Apache Spark jobs that copy the tables over JDBC

  Incorrect

  Spark jobs can move rows, but they convert neither the schema nor the stored procedures, and the team would write and run the jobs itself.

• CCSV exports of the Oracle tables imported into Cloud SQL for PostgreSQL

  Incorrect

  CSV files carry data only; the schema and stored procedures would still need converting by hand.

• DDatabase Migration Service for Oracle to AlloyDB, with its conversion tools

  Correct

  Database Migration Service converts Oracle schema and code objects to PostgreSQL syntax, with Gemini-assisted conversion, and then migrates the data.

Heterogeneous migrations need schema and code conversion as well as data movement. Database Migration Service provides both for Oracle to PostgreSQL targets.