ACE Exam Questions and Answers

Create a new instance template with the startup script, then update the MIG to use the new template via a rolling update.

The correct approach is to create a new instance template that includes the desired startup script in its metadata, then update the MIG to reference this new template using a rolling update. Since instance templates are immutable, creating a new template is mandatory. A rolling update (e.g., gcloud compute instance-groups managed rolling-action start-update) recreates the managed instances incrementally with the new template, ensuring the startup script executes during their boot. This method preserves availability and aligns with the MIG's declarative management model.

The service is hitting the maximum number of concurrent requests per container instance (default 80) and needs more instances.

A 503 from Cloud Run specifically signals that a request arrived but no container instance was available to accept it within the timeout window. Each instance can process only a fixed number of concurrent requests—the default concurrency is 80—so when all existing instances are saturated and the autoscaler cannot add new instances quickly enough (or the 'max instances' setting has been reached), the server returns Service Unavailable. The fix is to raise the max instances limit, lower the concurrency setting, or enable additional CPU to reduce per-instance bottleneck.

roles/pubsub.subscriber

The Pub/Sub Subscriber role (roles/pubsub.subscriber) is the correct, least-privileged role for a Cloud Functions trigger. It includes the permissions needed to pull messages (pubsub.subscriptions.consume) and acknowledge them after processing (pubsub.subscriptions.acknowledge), which is exactly what the function's runtime service account must do to read and complete each message from its subscription.

Cloud SQL (MySQL)

Cloud SQL for MySQL is a fully managed relational database service that provides the exact MySQL engine required by the application. It supports regional high availability through synchronous replication across two zones, automated backups, and point-in-time recovery, meeting both performance and durability needs without operational overhead. Its compatibility with standard MySQL drivers and protocols makes it the ideal choice for a regional MySQL workload.

Cloud Storage

Cloud Storage is an object storage service where static assets like images, JavaScript, and CSS files can be stored and served publicly via unauthenticated read access or a CDN. It integrates with Cloud CDN and offers high availability by default, with the ability to configure a regional bucket policy to keep data in a specific region. This makes it the appropriate service for hosting publicly accessible static content for the application.

Enable OS Login and assign IAM roles to users.

Enabling OS Login at the project or instance level, then assigning IAM roles such as roles/compute.osLogin or roles/compute.osAdminLogin to users, is the recommended pattern for SSH access. OS Login links the Linux account on the instance to the user's Google identity, automatically provisions a temporary SSH key when the user runs gcloud compute ssh, and allows instant revocation simply by removing the IAM policy binding.

Install the metrics-server in the cluster.

The metrics-server aggregates CPU and memory usage from kubelets via the Summary API and exposes them through the metrics.k8s.io API. The HorizontalPodAutoscaler (HPA) controller repeatedly queries that API to obtain current resource utilization; if no metrics-server is installed, the metrics API is unavailable and the HPA reports 'unable to retrieve metrics' and does not scale. It is the lightweight, cluster-local component that provides the raw numbers the HPA needs, whereas GCP's monitoring service is not directly consulted by the HPA.

Create a HorizontalPodAutoscaler resource (e.g., via kubectl autoscale).

Creating a HorizontalPodAutoscaler resource is the declaration of your scaling policy: it specifies the target workload (e.g., a Deployment), the target CPU utilization percentage, and the min/max replica count. The HPA controller periodically computes the desired replica count using the formula ceil(currentReplicas * (currentMetric / targetMetric)) and updates the Deployment's scale subresource accordingly. Without this resource, GKE has no scaling rules to apply even if metrics-server and resource requests are present.

Create a Deployment with resource requests for CPU.

The HPA calculates utilization as the ratio of measured CPU usage to the sum of the CPU requests across the pods in the Deployment. If pods do not declare a CPU request, the HPA controller cannot compute a utilization percentage and marks the metric as 'unknown', leaving the autoscaler permanently inactive. Specifying requests for CPU (and optionally memory) is therefore a hard dependency for CPU-based autoscaling, as it establishes the denominator for the target utilization calculation.

gcloud init

gcloud init is the intended bootstrap command for a new user because it performs the entire initial setup in one interactive flow: authenticating your Google account via the browser, then prompting you to choose or create a default project and set a default compute region/zone. It writes the resulting credentials and configuration properties into the active gcloud configuration file, leaving your environment ready for immediate use. This one-command workflow is exactly why it's the recommended starting point on a fresh workstation.

gcloud projects create PROJECT_ID

gcloud projects create PROJECT_ID is the correct command because it sends a create request to the Cloud Resource Manager API, which provisions a new project with the specified ID. This command requires the resourcemanager.projects.create permission and the PROJECT_ID must be globally unique across all Google Cloud projects. Once created, the project can be used for development and managed via gcloud.

Organization

The organization node is the root of the GCP resource hierarchy, and it is the correct place to attach an organization-wide policy. Any IAM role binding or organization policy constraint set at this level is inherited by every folder, project, and resource in the hierarchy, thereby ensuring the policy is enforced across all projects while also applying automatically to any future projects created under the organization.

gcloud services enable compute.googleapis.com

'gcloud services enable compute.googleapis.com' is the correct command to enable the Compute Engine API for the active project. The 'gcloud services' command group interacts with the Service Usage API to manage service availability. This command uses the fully qualified service name 'compute.googleapis.com', which is required for successful enablement. You can also specify a project with the '--project' flag if the API should be enabled for a different project than the current one.

Run 'gcloud config configurations create prod' then 'gcloud config set project prod-project'

The correct method is to first run gcloud config configurations create prod, which generates a new empty named configuration and automatically activates it. With the prod configuration active, gcloud config set project prod-project then sets the project property for that configuration, providing a clean, isolated environment for managing the prod project.

Create folders for dev, staging, and prod under the organization, then place projects in each folder

Folders in the Google Cloud resource hierarchy allow you to organize projects under the organization node, and you can apply IAM policies and organization policies at the folder level, which are inherited by all projects within. This gives you a natural separation between dev, staging, and prod while enabling consistent controls, e.g., different approval workflows or network configurations. Placing projects in environment-specific folders is the standard best practice for multi-environment governance.

Cloud Run

Cloud Run runs stateless containers in a fully managed environment that scales from zero to the number of concurrent requests and bills only for the CPU, memory, and requests consumed during a request. There is no infrastructure to provision, no idle capacity to pay for, and the platform enforces a request deadline, making it ideal for an HTTP-driven legacy application with unpredictable traffic. Its per-request billing and automatic scaling mean you pay nothing when the service is not being called.

Archive

Archive is correct because it is the only Google Cloud storage class specifically designed for data accessed less than once a year, offering the lowest storage cost. It is ideal for long-term retention, regulatory archives, or disaster recovery backups, with the trade-off of higher retrieval fees and a 365-day minimum storage duration before deletion or class change.

Cloud Run

Cloud Run is a managed serverless container platform that executes your container image on demand, automatically scaling instances from zero to thousands based on incoming HTTP traffic and billing only for resources used during request processing. It is purpose-built for stateless HTTP workloads and supports common features like health checks, environment variables, secrets, and gRPC, all without requiring you to provision or manage any servers. For a containerized web application, this directly satisfies the requirement with minimal operational effort and can scale to zero when idle.

HA VPN

HA VPN uses two external IP addresses and two tunnels to the same on-premises peer, and when paired with two on-premises VPN gateways, it achieves a 99.99% SLA. It relies on BGP to automatically fail over if one tunnel or gateway becomes unavailable, providing true high availability and making it the correct choice here.

Place web servers in a subnet with public IPs, and database servers in a separate subnet with Cloud NAT and no public IP

This is the recommended design because web servers get public IPs (or are behind an external load balancer) to accept inbound user connections, while database servers remain in a separate private subnet with no public IP, preventing direct internet access. Cloud NAT on the database subnet allows outbound internet requests for updates or external APIs without exposing the database to inbound traffic. Separate subnets also enable granular VPC firewall rules and routing policies between tiers, reducing the blast radius if the web tier is compromised.

Firestore

Firestore is a fully managed NoSQL document database that stores data in documents organized into collections. It provides built-in real-time synchronization through client-side listeners, automatically pushing updates to subscribed apps whenever data changes, making it ideal for live, collaborative applications. It also includes offline support and strong consistency, which are key differentiators for real-time use cases.

Cloud Monitoring

Cloud Monitoring includes native uptime checks that actively send HTTPS GET requests to the external endpoint from multiple global locations, verifying that the service is reachable and that expected HTTP status codes are returned. You can set response-time thresholds and alerting policies on these checks to trigger notifications when the endpoint fails or becomes slow. This makes it the correct service for monitoring endpoint availability rather than merely analyzing its internal behavior.

Stop the instance, then use gcloud compute instances set-machine-type, then start the instance.

Stopping the instance transitions it to the TERMINATED state, which releases the underlying host resources while preserving the boot disk, metadata, and attachment of persistent disks. The `gcloud compute instances set-machine-type` command can then change the vCPU and memory allocation, and after that you start the instance. This is the correct workflow because Compute Engine rejects machine type changes on running instances.

kubectl set image deployment/my-app my-app=my-app:v2 followed by kubectl rollout status deployment/my-app

kubectl set image deployment/my-app my-app=my-app:v2 imperatively updates the container image of the specified container in the Deployment, which immediately triggers a new ReplicaSet and rolling update. kubectl rollout status deployment/my-app then blocks and reports the status of that rollout until it completes, satisfying the requirement to update and monitor progress in one straightforward command sequence.

A log sink with BigQuery as the destination

A log sink with BigQuery as the destination is the correct method: Cloud Logging's log router matches your chosen log entries and delivers them to a BigQuery dataset, where each daily collection becomes a table. You configure the destination by providing a dataset name, and the sink automatically handles batching and streaming writes. This is the officially supported, commonly used way to export logs to BigQuery for analytics.

gcloud run services update-traffic --to-revisions v1=90,v2=10

This is the correct command for splitting traffic between already deployed revisions: `gcloud run services update-traffic` with `--to-revisions` takes a comma-separated list of `revision=percentage` pairs (v1=90,v2=10) and applies the routing immediately. The specified revisions must exist and the percentages must total 100. It does not create a new revision, so it is the appropriate operation after v1 and v2 have both been deployed.

Use bq cp (copy) command.

bq cp performs a server-side metadata copy, duplicating the schema and all rows without streaming data through the client, so billions of rows transfer in seconds and avoid the cost and time of a query-based rewrite.

Use gcloud compute instances create with the --service-account flag pointing to the custom service account.

When creating an instance, you must specify the service account with `gcloud compute instances create --service-account <SA_EMAIL>`, which attaches that identity to the instance for its entire lifetime. Once attached, the instance metadata server returns OAuth credentials for that service account, so all API calls from the instance are made as that identity. This is the correct way to ensure the instance uses a custom, least-privileged service account, provided the account has been granted the necessary IAM roles.

gcloud projects get-iam-policy PROJECT_ID --format json

This is the correct read-only command for retrieving a project's IAM policy. It outputs the complete policy document, including bindings, version, etag, and audit configs, and '--format json' formats that document as JSON for easy parsing. It is the standard tool for viewing current IAM state and is the basis for making offline changes with set-iam-policy.

Attach the service account to the instance using the --service-account flag when creating the instance.

Attaching the service account via the --service-account flag at instance creation is the correct approach because it binds the identity to the VM and makes credentials available through the metadata server. Code running on the instance can fetch OAuth 2.0 tokens from the metadata endpoint (http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token) and act on behalf of the service account. This avoids managing key files and ensures that IAM permissions are automatically applied to the instance.

Secret Manager

Secret Manager is the dedicated Google Cloud service for storing, managing, and accessing secrets such as API keys, passwords, and certificates. It provides built-in secret versioning with immutable payloads, IAM-based access control at the secret-version level, automatic replication for high availability, and full audit logging via Cloud Audit Logs. This makes it the managed and scalable solution that directly matches the requirement.

No additional configuration is required.

Private Google Access is a subnet-level setting that already routes traffic from VM instances with only internal IP addresses to Google APIs and services over Google's internal network. When this is enabled on the subnet, DNS resolution for googleapis.com automatically maps to Google's internal IP ranges, so the existing VPC routing handles API calls without any extra networking components. Therefore, no additional configuration is required.

Data Access audit logs

Data Access audit logs are the correct Cloud Audit Logs category for recording data-plane read/write operations, including Cloud Storage object GETs, BigQuery query reads, and Pub/Sub message publishes/pulls. They are typically disabled by default for most services and must be explicitly enabled for each service in the Audit Logs configuration, after which they deliver the who/what/when trail needed to audit data access across the organization.