Google Cloud Professional Cloud Architect: Manage implementation Practice Questions

The correct service name for Cloud Vision API is vision.googleapis.com. The command to list quota for a specific service is gcloud alpha services quota list (or gcloud beta services quota list) and requires both the --service flag and the --consumer=project:PROJECT_ID flag to scope the quota lookup to the project. (A) is incorrect because gcloud services list --available lists all available services, not quota limits for a specific API. (B) is incorrect because gcloud services quota list is not the right subcommand structure — quota commands live under gcloud alpha/beta services quota. (D) uses the wrong service identifier — the correct name is vision.googleapis.com, not cloudvision.googleapis.com.

Cloud Code and Cloud Workstations together represent the modern GCP developer productivity stack for Kubernetes development. Cloud Code (D) integrates directly into VS Code and IntelliJ, provides Skaffold-based build/deploy automation, auto-generates Kubernetes manifests, enables local debugging against minikube/kind or remote GKE clusters, and eliminates the need to manually write Dockerfiles or YAML. Cloud Workstations (E) provide fully managed, cloud-hosted development environments pre-configured with tools (including Cloud Code), ensuring team consistency, eliminating 'works on my machine' issues, and supporting developers who need powerful remote environments. (A) Cloud Build is for CI/CD pipelines — it replaces the inner loop with a cloud build on every commit, which is slow and unsuitable for the rapid iteration of the inner dev loop. (F) Cloud Shell Editor is a browser-based option but is not purpose-built for persistent team development workflows; it lacks the configurability and persistent workspace capabilities of Cloud Workstations. (C) Artifact Registry with Vulnerability Scanning stores and scans images but does not generate Kubernetes manifests. (B) Config Connector is a Kubernetes operator for managing GCP resources via Kubernetes CRDs — it does not generate application manifests from source code.

Anthos Config Management (ACM) is purpose-built for this scenario. It uses a Git repository as the single source of truth and automatically syncs policies (including RBAC, namespace configurations, and security policies via Policy Controller) to all registered clusters — both on-premises and GKE — using the GitOps model. (D) Anthos Service Mesh manages service-to-service communication, traffic management, and observability via Istio; it is not designed to enforce Kubernetes resource policies like RBAC or namespace labels. (A) GKE Hub is the registration and fleet management layer that enables features like ACM and Multi-cluster Ingress, but it does not by itself sync Git-based policies to clusters. (B) Cloud Build could be used to script kubectl applies, but this is an ad-hoc, error-prone approach that does not provide drift detection, automated remediation, or a true GitOps sync loop.

The correct two-step approach for migrating a large on-premises Oracle database to BigQuery without direct connectivity is: (1) Export data to files (CSV/Avro/Parquet) and transfer them to Cloud Storage (using Storage Transfer Service with an on-premises agent, or Transfer Appliance for very large/slow-link scenarios), and (2) Use BigQuery batch load jobs (bq load) to ingest the files from Cloud Storage into BigQuery. This is the standard, well-documented migration pattern. (F) BigQuery Data Transfer Service does not support direct connections to on-premises Oracle databases — it is designed for SaaS sources like Google Ads, Teradata (cloud), Amazon S3, etc. (C) Datastream supports Oracle CDC replication, but it requires network connectivity (VPN or Interconnect) to the on-premises source and is designed for ongoing replication, not a one-time bulk migration of 12 TB. (B) Database Migration Service supports MySQL, PostgreSQL, and SQL Server migrations to Cloud SQL — it does not migrate to BigQuery nor support Oracle as a source. (A) Building a custom Pub/Sub + Dataflow pipeline for a one-time migration is excessive engineering overhead and requires on-premises deployment of Dataflow workers.

Cloud Endpoints with gRPC transcoding (C) deployed on Cloud Run (or as an Extensible Service Proxy) can handle both native gRPC from internal consumers and automatically transcode those same endpoints to RESTful JSON for HTTP/1.1 clients — from a single proxy. This minimizes infrastructure components. Apigee (D) is purpose-built for external API management with full lifecycle management including API keys, OAuth 2.0, developer portals, rate limiting, and analytics for partner and mobile consumers. Together, Endpoints handles the dual-protocol internal/external serving layer while Apigee provides the enterprise API management gateway for external traffic. — An internal GKE Ingress (B) handles internal load balancing but does not provide API management features like API keys or rate limiting, nor does it handle both internal and external traffic in a unified way. — Cloud Armor (A) is a WAF/DDoS protection service applied to external HTTP(S) load balancers; it does not perform rate limiting at the API key or per-consumer level and is not applicable to internal gRPC services directly. — nginx sidecars per pod (E) would work for transcoding but defeats the 'minimize infrastructure components' requirement and creates a maintenance burden across all pods. — Option F adds complexity by using two separate products where Cloud Endpoints alone (with transcoding) can serve both internal and external protocols from a unified proxy.