You are building a pipeline to process time-series dat a. Which Google Cloud Platform services should you put in boxes 1,2,3, and 4? https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Real_Google_Associate-Cloud-Engineer/page_14_img_1.jpg

Cloud Pub/Sub, Cloud Dataflow, Cloud Bigtable, BigQuery

Cloud Pub/Sub, Cloud Dataflow, Cloud Datastore, BigQuery

Firebase Messages, Cloud Pub/Sub, Cloud Spanner, BigQuery

Cloud Pub/Sub, Cloud Storage, BigQuery, Cloud Bigtable

Cloud Pub/Sub, Cloud Dataflow, Cloud Bigtable, BigQuery

Free Associate-Cloud-Engineer Practice Test Questions and Answers (2026)

Last Update Check September 2, 2026

Q: 1

You have a number of compute instances belonging to an unmanaged instances group. You need to SSH to one of the Compute Engine instances to run an ad hoc script. You’ve already authenticated gcloud, however, you don’t have an SSH key deployed yet. In the fewest steps possible, what’s the easiest way to SSH to the instance?

Options

24 comments in the community discussion

Anita N. 1

C or B, but B is what Google expects since gcloud compute ssh does everything if no key yet.

Sofia C. 1

Correct Answer:

Explanation

The gcloud compute ssh command is a wrapper around the standard ssh command that automates the entire connection process. When executed, it checks for the existence of SSH keys. If no keys are found, it automatically generates a new key pair (~/.ssh/googlecomputeengine), adds the public key to the project or instance metadata, and then initiates the SSH connection to the specified instance. This single command handles authentication, key generation, key distribution, and connection, making it the most efficient method with the fewest steps, as required by the question.

Why Incorrect

A. This method will fail. The standard ssh command requires a pre-existing private key on the local machine and a corresponding public key on the target instance, which the scenario states is not deployed.

C. This is an unnecessary step. While it would work, the gcloud compute ssh command will automatically generate the key pair for you if one doesn't exist, making the manual ssh-keygen step redundant.

D. This is the most complex and manual process. It involves multiple commands and manual key management, which is the exact opposite of the "easiest way" and "fewest steps" requirement.

References

1. Google Cloud Documentation

gcloud compute ssh: "If you do not have a public SSH key

gcloud compute ssh generates one for you. When you generate a new key

gcloud compute ssh adds the key to your project or instance metadata and connects you to the VM." This confirms that the command handles key generation automatically.

Source: Google Cloud SDK Documentation

gcloud compute ssh

Command Description section.

2. Google Cloud Documentation

Connect to Linux VMs: "The gcloud command-line tool provides the simplest way to connect to your instances... When you connect to a Linux instance by using the gcloud command-line tool

Compute Engine creates an ephemeral SSH key for you and sets a username."

Source: Google Cloud Documentation > Compute Engine > User guides > Connect to Linux VMs > Connect using Google Cloud tools.

3. Google Cloud Documentation

Managing SSH keys in metadata: "When you use gcloud compute ssh to connect to an instance

gcloud can automatically create and add an SSH key to the project for you."

Source: Google Cloud Documentation > Compute Engine > User guides > Access control > Managing SSH keys in metadata > How SSH keys work on Compute Engine instances.

Q: 2

You are the project owner of a GCP project and want to delegate control to colleagues to manage buckets and files in Cloud Storage. You want to follow Google-recommended practices. Which IAM roles should you grant your colleagues?

Options

23 comments in the community discussion

Emma 1

Chloe I. 1

B imo, A is too broad and C doesn't handle bucket-level permissions.

Correct Answer:

Explanation

The Storage Admin (roles/storage.admin) role provides full control over Cloud Storage resources. This includes all necessary permissions to manage both buckets (e.g., create, delete, list, set IAM policies) and the objects (files) within them. Using this predefined role adheres to the Google-recommended practice of applying the principle of least privilege. It grants the required permissions scoped specifically to the Cloud Storage service, unlike the overly broad Project Editor basic role. This role is the most suitable for colleagues who need comprehensive control over buckets and files without granting them permissions for other services in the project.

Why Incorrect

A. Project Editor: This is a basic role that grants broad permissions across most Google Cloud services, violating the principle of least privilege.

C. Storage Object Admin: This role grants permissions to manage objects (files) but lacks the necessary permissions to create, delete, or configure buckets.

D. Storage Object Creator: This role is highly restrictive, only allowing users to create objects. It does not permit managing objects or buckets.

References

1. Google Cloud Documentation

"Cloud Storage IAM roles": The table in this document explicitly states that the roles/storage.admin role provides "Full control of Cloud Storage resources

" which encompasses both buckets and objects. In contrast

roles/storage.objectAdmin is described as having "Full control of Cloud Storage objects

" which does not include bucket management.

Source: Google Cloud

Cloud Storage Documentation

"IAM roles for Cloud Storage".

2. Google Cloud Documentation

"Understanding roles": This guide explains the different types of roles. It recommends using predefined roles over basic roles (like Editor) to grant only the necessary permissions. "Whenever possible

we recommend that you grant predefined roles instead of basic roles. Predefined roles provide finer-grained access control and help you follow the principle of least privilege."

Source: Google Cloud

IAM Documentation

"Understanding roles"

Section: "Role types".

3. Google Cloud Documentation

"Using IAM permissions": This document reinforces the best practice of using the most limited predefined role that meets requirements. "Follow the principle of least privilege... When choosing a predefined role

pick one that contains the minimum set of permissions that your user needs."

Source: Google Cloud

IAM Documentation

"Granting

changing

and revoking access to resources"

Section: "Best practices".

Q: 3

You want to configure an SSH connection to a single Compute Engine instance for users in the dev1 group. This instance is the only resource in this particular Google Cloud Platform project that the dev1 users should be able to connect to. What should you do?

Options

16 comments in the community discussion

Morgan G. 1

A , that's the pattern shown in the official documentation and practice tests, especially for scoped SSH via IAM.

Parker C. 1

D, not A

Correct Answer:

Explanation

The most secure, scalable, and manageable method to grant SSH access to a specific group of users for a single instance is by using OS Login. OS Login links a user's Google identity with their VM's POSIX account and manages access through IAM roles.

By setting the instance metadata enable-oslogin=true, you activate this feature for that specific instance. Granting the roles/compute.osLogin IAM role to the dev1 group provides the necessary permissions for its members to establish an SSH connection to any instance with OS Login enabled, without granting them broader administrative privileges. This combination precisely meets the requirement of providing scoped access to the specified group.

Why Incorrect

B. This option is incomplete. While it correctly enables OS Login, it fails to grant the necessary IAM role (compute.osLogin) to the dev1 group, so the users would have no permission to connect.

C. This method is insecure and unscalable. It requires manually generating, distributing, and managing individual SSH keys for each user, which is prone to error and becomes a significant administrative burden as the group changes.

D. Sharing a single private SSH key among multiple users is a severe security anti-pattern. It eliminates individual accountability and makes key revocation and rotation extremely difficult if the key is compromised.

References

1. Google Cloud Documentation - About OS Login: "OS Login lets you use Compute Engine IAM roles to grant and revoke SSH access to your Linux instances... OS Login is the recommended way to manage many users across multiple instances or projects." This document also specifies that you enable OS Login by setting the enable-oslogin metadata value to TRUE.

Source: Google Cloud Documentation

"About OS Login".

2. Google Cloud Documentation - Set up OS Login: "After you enable OS Login on one or more instances in your project

you need to grant the necessary IAM roles to users." It lists roles/compute.osLogin as the role required to connect to instances.

Source: Google Cloud Documentation

"Set up OS Login"

Step 2: Grant necessary IAM roles.

3. Google Cloud Documentation - Compute Engine predefined IAM roles: The compute.osLogin role is described as providing "permissions to log in to Compute Engine instances using OS Login. This role does not grant administrator access." This confirms it as the appropriate least-privilege role.

Source: Google Cloud Documentation

"Compute Engine IAM roles"

Predefined roles table.

4. Google Cloud Documentation - Managing SSH keys in metadata: This document describes the manual method of managing keys and contrasts it with OS Login. It explains that blocking project-wide keys is a way to restrict access

but it still relies on manually adding instance-level keys

which is less manageable than OS Login.

Source: Google Cloud Documentation

"Managing SSH keys in metadata"

section "Instance-level public SSH keys".

Q: 4

You have a Dockerfile that you need to deploy on Kubernetes Engine. What should you do?

Options

16 comments in the community discussion

AjayQ 1

Had something like this in a mock and went with B. I thought since App Engine also uses Dockerfiles, gcloud app deploy should work for Kubernetes Engine too. But now that I think about it, maybe that's only for App Engine deployments. Anyone else tripped up by the similar commands?

Nora P. 1

Option C

Correct Answer:

Explanation

The standard and correct workflow for deploying a containerized application to Google Kubernetes Engine (GKE) begins with the Dockerfile. First, a container image must be built from the Dockerfile using a tool like Docker. This image must then be stored in a container registry that the GKE cluster can access; Google Container Registry (GCR) or Artifact Registry are the standard, integrated choices on Google Cloud. Next, a Kubernetes Deployment manifest (a YAML file) is created. This file declaratively defines the desired state, specifying the container image location (from the registry), the number of replicas, and other configurations. Finally, the kubectl command-line tool is used to apply this manifest to the GKE cluster, which then pulls the image and creates the Pods.

Why Incorrect

A. kubectl app deploy . is not a valid or standard kubectl command for deploying applications. The correct command to apply a configuration file is kubectl apply -f .

B. gcloud app deploy . is the command used to deploy applications to Google App Engine, which is a different service (Platform-as-a-Service) from Google Kubernetes Engine.

D. Google Cloud Storage is an object storage service, not a container registry. GKE nodes cannot pull container images directly from a Cloud Storage bucket; they require a registry that implements the Docker Registry API.

References

1. Google Cloud Documentation

"Deploying a containerized web application": This official tutorial outlines the exact steps described in the correct answer. It details building a container image

pushing it to Artifact Registry (Google's recommended container registry)

and then deploying it to a GKE cluster using a manifest file (deployment.yaml) and kubectl apply. (See steps 3

and 6 in the guide).

2. Google Cloud Documentation

"Container Registry overview": "Container Registry is a private container image registry that runs on Google Cloud... You can access Container Registry through HTTPS endpoints

from gcloud

or from Docker." This confirms that a registry

not object storage

is the correct location for images.

3. Google Cloud SDK Documentation

gcloud app deploy: The official documentation for this command states

"This command is used to deploy the source code and configuration of your application to the App Engine server." This explicitly links the command to App Engine

not GKE.

4. Kubernetes Documentation

"Deployments": "A Deployment provides declarative updates for Pods... You describe a desired state in a Deployment

and the Deployment Controller changes the actual state to the desired state at a controlled rate." This supports the use of a declarative YAML file as the standard practice.

Q: 5

You have an object in a Cloud Storage bucket that you want to share with an external company. The object contains sensitive dat a. You want access to the content to be removed after four hours. The external company does not have a Google account to which you can grant specific user-based access privileges. You want to use the most secure method that requires the fewest steps. What should you do?

Options

27 comments in the community discussion

Sam E. 6

Option A works best since a signed URL allows secure, temporary access without needing a Google account and auto-expires after 4 hours. The other options either make data public or add unnecessary steps. I think A is the most direct and secure here, but open to other views if missed something.

LeoB 6

Option A is the way to go. Creating a signed URL with a 4-hour expiration is secure and quick, and no Google account needed for access. I saw similar scenarios in official practice sets. If you want to double-check, the GCP official documentation covers signed URLs pretty well. Pretty sure A matches best here.

Correct Answer:

Explanation

A signed URL provides a secure, time-limited method for granting read or write access to a specific Cloud Storage object. It uses a cryptographic signature embedded in the URL, which authenticates the request without requiring the user to have a Google account. By setting a four-hour expiration, access is automatically revoked after the specified period. This approach directly addresses all requirements: it's secure for sensitive data, time-limited, works for users without Google accounts, and is the most direct method, requiring only a single step to generate the URL.

Why Incorrect

B. Making an object public is highly insecure for sensitive data, as anyone on the internet could potentially access it during the four-hour window.

C. Configuring a bucket as a static website also makes objects publicly accessible, which is not secure for sensitive content. This method is also more complex than generating a signed URL.

D. This method is inefficient, requiring multiple steps (create bucket, copy object, delete bucket). It also fails to specify the access mechanism, which would still need to be either public (insecure) or a signed URL (making option A superior).

References

1. Google Cloud Documentation - Signed URLs: "A signed URL is a URL that provides limited permission and time to make a request... Anyone who knows the signed URL can access the resource until the URL expires

regardless of whether they have a Google Cloud account." This document explicitly describes the use case of providing temporary access to users without Google accounts.

Source: Google Cloud Documentation

"Cloud Storage > How-to Guides > Using signed URLs".

2. Google Cloud Documentation - Overview of Access Control: This document outlines various access control methods. It implicitly discourages using public access for sensitive data by describing its function: "The allUsers identifier is a special identifier that represents any user who is on the internet." This highlights the insecurity of options B and C.

Source: Google Cloud Documentation

"Cloud Storage > Key Concepts > Overview of access control".

3. Google Cloud Documentation - Object Lifecycle Management: "Object Lifecycle Management lets you apply rules to a bucket that automatically take an action on the objects in the bucket when they meet the criteria you specify." The purpose is automated object state management (e.g.

deletion

changing storage class)

not for granting temporary

secure access to external users.

Source: Google Cloud Documentation

"Cloud Storage > How-to Guides > Using Object Lifecycle Management".

Q: 6

You create a Deployment with 2 replicas in a Google Kubernetes Engine cluster that has a single preemptible node pool. After a few minutes, you use kubectl to examine the status of your Pod and observe that one of them is still in Pending status:

Google Associate Cloud Engineer question

What is the most likely cause?

Options

26 comments in the community discussion

Taylor L. 1

Its B, unless they specifically mention preemption just happened. Resource shortage hits first in these cases with a single node pool.

Parker 1

B , unless the question clearly called out a recent preemption event. In most cases, with just one node and two pods, resource constraints hit first and cause Pending. If cluster had autoscaling or multiple nodes, then maybe D. Others agree?

Correct Answer:

Explanation

The Pending status for a Pod indicates that the Kubernetes scheduler has accepted the Pod but cannot yet place it onto a node. The most common reason for this is insufficient cluster resources (CPU or memory). In this scenario, the first replica of the Deployment was successfully scheduled and is Running, consuming resources on a node. The second replica, with identical resource requests, cannot be scheduled because the remaining available resources in the cluster are not sufficient to meet its needs. The Pod will remain Pending until resources are freed up or a new node is added to the cluster, for example, by the cluster autoscaler.

Why Incorrect

A: This is incorrect because one replica is already Running. As both Pods have identical resource requests, if one can fit on a node, the other's request is not inherently too large.

C: Incorrect image pull permissions would cause an ImagePullBackOff or ErrImagePull status after the Pod is scheduled to a node, not prevent it from being scheduled (i.e., leave it Pending).

D: While a node preemption could lead to this state, the direct cause of the Pending status is the lack of schedulable resources, which is more accurately described by option B.

References

1. Kubernetes Documentation

Pod Lifecycle

Pod Phase: The Pending phase is defined as: "The Pod has been accepted by the Kubernetes cluster

but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to be scheduled..." This confirms that scheduling issues are a primary cause of the Pending state. (Source: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)

2. Google Cloud Documentation

GKE

Cluster autoscaler: "Cluster autoscaler automatically resizes the number of nodes in a given node pool

based on the demands of your workloads. ... it adds nodes when there are Pods that failed to schedule in the node pool due to insufficient resources." This directly links the Pending state (failed to schedule) with resource insufficiency. (Source: https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-autoscaler

"How cluster autoscaler works" section).

3. Kubernetes Documentation

Kubernetes Scheduler: The scheduler's role is to assign Pods to nodes. "If no node is suitable

the pod remains unscheduled until the scheduler is able to place it." The primary filtering step in finding a suitable node is checking if a node has enough available resources to meet the Pod's specific resource requests. (Source: https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/

"The kube-scheduler" section).

Q: 7

You are building a pipeline to process time-series dat a. Which Google Cloud Platform services should you put in boxes 1,2,3, and 4?

Options

27 comments in the community discussion

Skyler M. 9

D. Saw a similar question in recent exam reports, matches the best for real-time time-series processing using GCP services.

HelpfulConsultant6357 2

I don’t think it’s D. C looks better since Cloud Storage comes right after Pub/Sub, which would handle raw event storage before anything else happens. That makes sense if you want to keep all incoming data, even before processing. Not totally sure but that’s how I’d see it.

Correct Answer:

Explanation

This architecture represents a classic streaming data pipeline on Google Cloud, particularly for time-series or IoT data.

1. Ingest (Cloud Pub/Sub): Cloud Pub/Sub is a fully managed, real-time messaging service designed to ingest high-throughput event streams from many sources, such as IoT devices.

2. Process (Cloud Dataflow): Cloud Dataflow is a unified stream and batch data processing service. It is ideal for executing pipelines that transform, enrich, and aggregate incoming data in real-time.

3. Serve (Cloud Bigtable): Cloud Bigtable is a NoSQL, wide-column database optimized for high-throughput reads and writes with very low latency. This makes it the perfect choice for serving time-series data to real-time dashboards and applications.

4. Analyze (BigQuery): BigQuery is a serverless, highly scalable data warehouse built for business intelligence and ad-hoc analysis. It allows for complex SQL queries over massive datasets.

Why Incorrect

A: Cloud Datastore is a document database designed for transactional web and mobile application backends, not for the high-throughput analytical workloads typical of time-series data.

B: Firebase Messages is for sending notifications to client applications, not a general-purpose data ingestion service. Cloud Spanner is a relational database, which is less suited for this specific time-series use case than Bigtable.

C: Cloud Storage is an object storage service, not a data processing engine. This option also incorrectly swaps the roles of BigQuery (for analysis) and Bigtable (for low-latency serving).

References

1. Google Cloud Documentation

"IoT overview": This document presents a reference architecture for IoT data that explicitly shows the flow: Cloud Pub/Sub (for ingestion) -> Cloud Dataflow (for processing) -> Cloud Bigtable (for processing and serving) and BigQuery (for data analysis). See the "Reference architecture" diagram.

2. Google Cloud Documentation

"Cloud Bigtable - Overview": Under the section "What it's good for

" the documentation lists "Time series data" as a primary use case

stating

"Cloud Bigtable is a great choice for storing and querying large amounts of time-series data."

3. Google Cloud Documentation

"Dataflow - Common use cases": This page describes using Dataflow for "Streaming analytics" and "IoT

" often in conjunction with Pub/Sub for ingestion and BigQuery or Bigtable for storage and analysis.

4. Google Cloud Documentation

"What is BigQuery?": The official documentation defines BigQuery as a "fully managed enterprise data warehouse that helps you manage and analyze your data

" which directly corresponds to the "Ad-hoc analysis" function in the diagram.

Q: 8

You have an application that uses Cloud Spanner as a backend database. The application has a very predictable traffic pattern. You want to automatically scale up or down the number of Spanner nodes depending on traffic. What should you do?

Options

18 comments in the community discussion

Quinn A. 6

D. not A. Manual cron or SRE alerting is a trap since only D gives actual autoscaling. Seen this approach in other exam reports.

Hannah O. 1

D is correct, not A. Using a cron job (A) looks tempting since the traffic is predictable, but it's not real autoscaling. Only D builds a closed loop with alerts and Cloud Function so everything runs hands-off. Think I've seen this logic in other practice sets, but open to pushback if anyone's seen auto-scaling handled

Correct Answer:

Explanation

This solution describes a standard, event-driven, and fully automated pattern for scaling Google Cloud resources that do not have a native autoscaling feature. A Cloud Monitoring (formerly Stackdriver) alerting policy can monitor the Cloud Spanner instance's CPU utilization. When the utilization crosses a predefined threshold (either high or low), the policy triggers a notification to a webhook. A Cloud Function is configured with an HTTP trigger to listen on this webhook's endpoint. Upon receiving the alert, the function executes code that uses the Cloud Spanner API to resize the instance by adding or removing nodes, thus achieving automatic scaling.

Why Incorrect

A. A cron job is a scheduled, time-based trigger. While it can automate scaling for predictable patterns, it is less responsive to real-time metric fluctuations compared to an event-driven alerting policy.

B. This option relies on manual intervention by an on-call SRE to scale the instance. This fails to meet the requirement for an automatic scaling solution.

C. Involving Google Cloud Support for routine operational tasks like scaling is not a standard or appropriate procedure. This process is manual and not the intended use of the support service.

References

1. Google Cloud Blog - Tutorial: Autoscaling Cloud Spanner: This official tutorial explicitly details the recommended architecture for autoscaling Cloud Spanner. It states

"In this architecture

Cloud Monitoring periodically checks the CPU utilization of your Spanner instance. When the CPU utilization crosses a threshold

Monitoring sends a notification to a webhook. The notification triggers a Cloud Function that adds or removes a node from your Spanner instance." This directly validates option D.

Source: Google Cloud Blog

"Autoscaling Cloud Spanner".

2. Cloud Monitoring Documentation - Notification options: The official documentation lists webhooks as a notification channel. It explains

"You can use webhooks to send a notification to other services... When you create a webhook notification channel

you provide a URL to which Monitoring sends a POST request when a notification is triggered." This confirms the trigger mechanism.

Source: Google Cloud Documentation

Cloud Monitoring

"Notification options"

Section: "Webhooks".

3. Cloud Spanner Documentation - Monitoring with Cloud Monitoring: The documentation highlights high-priority CPU utilization as a key metric for monitoring Spanner performance and determining when to scale. It recommends keeping CPU utilization below 65% for multi-region instances and 75% for regional instances to ensure optimal performance. This validates using CPU metrics as the basis for scaling decisions.

Source: Google Cloud Documentation

Cloud Spanner

"Monitoring with Cloud Monitoring"

Section: "Alerting".

4. Cloud Functions Documentation - HTTP Triggers: This documentation explains how to create functions that can be invoked via HTTP requests

which is precisely how a webhook integration works. "HTTP functions can be invoked from standard HTTP requests. These functions must send a response."

Source: Google Cloud Documentation

Cloud Functions

"Develop"

"HTTP Triggers".

Q: 9

You are using Deployment Manager to create a Google Kubernetes Engine cluster. Using the same Deployment Manager deployment, you also want to create a DaemonSet in the kube-system namespace of the cluster. You want a solution that uses the fewest possible services. What should you do?

Options

24 comments in the community discussion

Drew H. 1

B or C? Type Provider in A looks like a trap because it could count as another service. Not totally sure though.

Kevin 1

Its C, since spinning up a Compute Engine instance and running kubectl seems simpler to me.

Correct Answer:

Explanation

Google Cloud Deployment Manager can be extended to manage resources from third-party APIs by adding them as "Type Providers". The Kubernetes API is a RESTful API with an OpenAPI specification, making it a perfect candidate for a Type Provider. By creating the GKE cluster first, you can extract its API endpoint and credentials within the same deployment. You then use these outputs to dynamically configure a new Type Provider for that specific cluster's API. Finally, you use this new type to declaratively create the DaemonSet, all within a single Deployment Manager execution without needing extra services like Compute Engine.

Why Incorrect

B: Runtime Configurator is a service for storing and managing dynamic configuration data. It does not have the capability to apply configurations or create resources within a GKE cluster.

C: This approach requires an additional Compute Engine instance solely to run a kubectl command. This is inefficient and violates the principle of using the fewest possible services.

D: The Google Kubernetes Engine resource definition in Deployment Manager does not have a feature to interpret metadata entries as Kubernetes manifests to be applied to the cluster.

References

1. Google Cloud Documentation - Adding a Type Provider: This document explains how to extend Deployment Manager to work with third-party APIs. It states

"You can expand the types of Google Cloud resources that Deployment Manager can create by adding API-specific type providers... A type provider exposes all of the resources of a third-party API to Deployment Manager as base types that you can use in your configurations." The Kubernetes API is such a third-party API in this context.

Source: Google Cloud Documentation

"Adding a Type Provider"

Section: "Before you begin".

2. Google Cloud Documentation - Calling a Third-Party API: This guide provides a conceptual overview and explicitly mentions that the API must have an OpenAPI (formerly Swagger) specification

which the Kubernetes API does.

Source: Google Cloud Documentation

"Calling a Third-Party API"

Section: "About integrating with third-party APIs".

3. Google Cloud Community Tutorials - Automating GKE cluster and application deployment with Deployment Manager: This tutorial provides a step-by-step example of the exact process described in the correct answer. It shows creating a GKE cluster

then using its endpoint to create a Type Provider

and finally using that provider to deploy a Kubernetes application.

Source: Google Cloud Community Tutorials

"Automating GKE cluster and application deployment with Deployment Manager"

Sections: "Creating the Deployment Manager configuration" and "Creating the Kubernetes type provider".

Q: 10

You are running a data warehouse on BigQuery. A partner company is offering a recommendation engine based on the data in your data warehouse. The partner company is also running their application on Google Cloud. They manage the resources in their own project, but they need access to the BigQuery dataset in your project. You want to provide the partner company with access to the dataset What should you do?

Options

18 comments in the community discussion

Luke M. 1

Its D, since you want the partner to control their own service account. Granting their service account access is least privilege. A is tempting but not correct here.

Kevin C. 1

Why not just have the partner own their service account and you grant it access? That way you don't have to manage their credentials, and permissions stay tidy. Feels like that's standard on GCP for cross-project access. Or am I missing a reason to do it differently?

Correct Answer:

Explanation

This scenario describes a standard cross-project resource sharing pattern on Google Cloud. The most secure and manageable approach is for the entity requiring access (the partner) to create and manage their own identity. The partner creates a service account in their project, which they control. They then provide the service account's unique email address to you. As the owner of the BigQuery dataset, you grant the necessary IAM role (e.g., BigQuery Data Viewer) to that specific service account on your dataset. This adheres to the principle of least privilege and proper separation of concerns, where each party manages their own resources and identities.

Why Incorrect

A. Creating the service account in your project requires you to manage its lifecycle and securely share its credentials (keys) with the partner, which is a security risk and an anti-pattern.

B. This is illogical. The service account needs access to the BigQuery dataset in your project, not to resources in the partner's project.

C. The partner granting their service account access to their own project does not confer any permissions to access resources, like your dataset, in a different project.

References

1. Google Cloud Documentation

BigQuery

"Control access to datasets": In the section "Grant access to a dataset

" the procedure describes adding a "principal" to the dataset's IAM policy. A principal can be a "service account

" and its email address format ([email protected]) inherently allows for granting access to a service account from a different project. This document outlines the exact procedure described in the correct answer.

2. Google Cloud Documentation

IAM

"Overview of IAM": This document explains the core IAM concepts. It defines a "principal" as an identity that can be granted access to a resource. It states

"A principal can be a Google Account... a service account

a Google group

or a Google Workspace... that needs access to a Google Cloud resource." This confirms that a service account from the partner's project is a valid principal to which you can grant access.

3. Google Cloud Documentation

IAM

"Service accounts overview": This page clarifies that "Service accounts are principals in IAM policies" and are "identified by their email address

which is unique to the account." This supports the method of the partner providing their unique service account email for you to add to your dataset's IAM policy.

Q: 11

You want to verify the IAM users and roles assigned within a GCP project named my-project. What should you do?

Options

2 comments in the community discussion

Kevin U.

C vs D? I'm actually going with D since the Roles section in the Console shows all the roles, and you can review their status there. It might not directly list users, but it gives a good overview of roles assigned across the project. Someone chime in if I'm missing a nuance here.

ThoughtfulLearner9413

C or D depends on what exactly you mean by "verify users and roles". If you just want to see what custom roles exist, D works, but if the question means checking which users have which roles assigned (memberships), that's C. Are we talking about checking assignments or just listing available roles?

Correct Answer:

Explanation

The IAM & Admin page in the Google Cloud Console provides a comprehensive view of the Identity and Access Management (IAM) policy for a specific resource, such as a project. This page lists all principals (members like users, groups, and service accounts) and the specific roles granted to them for that project. This directly allows an administrator to verify who has what level of access, fulfilling the question's requirement to check assigned users and roles. The gcloud projects get-iam-policy [PROJECTID] command provides the same information via the command line.

Why Incorrect

A. gcloud iam roles list only lists the available IAM roles in a project or organization; it does not show which members are assigned to those roles.

B. gcloud iam service-accounts list only lists the service accounts within a project. It does not show other member types (like users or groups) or their role assignments.

D. The "Roles" section in the GCP Console lists available roles and their associated permissions, similar to option A. It does not display the bindings of these roles to members.

---

References

1. Google Cloud Documentation - View access to a project

folder

or organization: "You can get a list of principals who have access to a project... using the Google Cloud console... In the Google Cloud console

go to the IAM page... The IAM page displays all of the principals who have IAM roles on your project

and what roles they are granted."

Source: Google Cloud Documentation

"IAM > Documentation > How-to guides > Granting

changing

and revoking access > View access to a project

folder

or organization".

2. Google Cloud SDK Documentation - gcloud projects get-iam-policy: This command is the CLI equivalent for viewing the full policy. "This command prints the IAM policy for a project... The output includes an etag field identifying the version of the policy." The policy itself contains the bindings between members and roles.

Source: Google Cloud SDK Documentation

gcloud projects get-iam-policy.

3. Google Cloud SDK Documentation - gcloud iam roles list: "List the IAM roles for a project or organization." This command's description confirms it only lists the roles themselves

not their assignments.

Source: Google Cloud SDK Documentation

gcloud iam roles list.

Q: 12

You have a development project with appropriate IAM roles defined. You are creating a production project and want to have the same IAM roles on the new project, using the fewest possible steps. What should you do?

Options

12 comments in the community discussion

FriendlyLearner6144 5

Makes sense to go with A here

AaronI 1

A imo

Correct Answer:

Explanation

The gcloud iam roles copy command is specifically designed to duplicate a custom role from a source project or organization to a destination project or organization. Using this command-line tool is the most efficient method ("fewest possible steps") to replicate one or more roles, as it can be executed in a single line per role and easily scripted for bulk operations. This approach is significantly faster and less prone to human error than manually recreating roles through the Google Cloud Console.

Why Incorrect

B. Copying the role to the destination organization makes it available to all projects. This is a broader scope than requested and may not be desirable from a security or management perspective.

C. The ‘create role from role’ functionality in the console is a multi-step, manual process for each role, which is less efficient than a single gcloud command, especially if multiple roles are involved.

D. Manually creating a role and selecting permissions is the most inefficient and error-prone method, directly contradicting the requirement for the "fewest possible steps."

---

References

1. Google Cloud SDK Documentation

gcloud iam roles copy:

The official documentation for the command explicitly states its purpose: "is used to copy an IAM role." The examples demonstrate copying a role from a source project to a destination project using the --source-project and --dest-project flags. This directly supports option A as the purpose-built tool for the task.

Source: Google Cloud. (n.d.). gcloud iam roles copy. Google Cloud SDK documentation. Retrieved from https://cloud.google.com/sdk/gcloud/reference/iam/roles/copy

2. Google Cloud IAM Documentation

"Creating and managing custom roles":

Under the section "Copying an existing role

" the documentation provides the exact gcloud iam roles copy command as the method for this task. It highlights this as a primary way to replicate roles

reinforcing its status as the correct and most direct procedure.

Source: Google Cloud. (n.d.). Create and manage custom roles. IAM documentation. Retrieved from https://cloud.google.com/iam/docs/creating-custom-roles#copying-an-existing-role

3. Google Cloud IAM Documentation

"Custom roles overview":

This document explains the scope of custom roles

which can be created at either the project or organization level. This context clarifies why specifying the destination project (Option A) is more precise and appropriate for the user's request than specifying the organization (Option B).

Source: Google Cloud. (n.d.). Overview of IAM custom roles. IAM documentation. Retrieved from https://cloud.google.com/iam/docs/understanding-custom-roles#customroleavailability

Q: 13

You created a Google Cloud Platform project with an App Engine application inside the project. You initially configured the application to be served from the us-central region. Now you want the application to be served from the asia-northeast1 region. What should you do?

Options

3 comments in the community discussion

Morgan

C/D? Both mention setting asia-northeast1, but leaning C since you can add another app. Not totally sure.

SharpAuditor4058

Just to clarify, is the requirement specifically to move the existing app and its data, or just to deploy the same code in asia-northeast1? If actual migration is needed, that could impact whether D is still the best solution or if additional steps would be required.

Correct Answer:

Explanation

The location of a Google App Engine application is a permanent setting chosen during its initial creation within a Google Cloud project. This location cannot be changed after the application is created. Furthermore, a single Google Cloud project can contain only one App Engine application. Therefore, to deploy the application in a new region (asia-northeast1), you must create an entirely new Google Cloud project. Within this new project, you can then create a new App Engine application and specify asia-northeast1 as its serving location during the setup process.

Why Incorrect

A. The project's default region setting primarily affects services like Compute Engine and does not alter the immutable location of an existing App Engine application.

B. The region of an App Engine application is an immutable property. It is set once at creation and cannot be modified later.

C. A Google Cloud project is limited to a single App Engine application. It is not possible to create a second one within the same project.

References

1. Google Cloud Documentation

App Engine Locations: "When you create an app

you must choose a location... The location you choose for your app is permanent and cannot be changed." This document also states

"Each Google Cloud project can contain only one App Engine app."

Source: Google Cloud

App Engine Locations

"Choosing a location" and "Location and your project" sections. https://cloud.google.com/appengine/docs/locations

2. Google Cloud SDK Documentation

gcloud app create: The official command-line tool documentation for creating an App Engine application explicitly states for the --region flag: "The region to create the App Engine application in. You can't change the region after you set it."

Source: Google Cloud SDK

gcloud app create

Command description. https://cloud.google.com/sdk/gcloud/reference/app/create

Q: 14

You want to add a new auditor to a Google Cloud Platform project. The auditor should be allowed to read, but not modify, all project items. How should you configure the auditor's permissions?

Options

8 comments in the community discussion

Sara 6

Option C is correct since the built-in IAM Viewer role already has broad read-only permissions at the project level. A custom role (A or B) is unnecessary here and D would be too limited. Anyone disagree?

Noah Z. 1

Had something like this in a mock before and chose A. I thought custom roles were better for security since you can specifically control what permissions are granted, even if just view-only. Might be overthinking it but custom seems safer to me than default roles. Anyone else prefer option A?

Correct Answer:

Explanation

The most appropriate and secure method to grant read-only access to all resources within a Google Cloud project is by using the predefined Identity and Access Management (IAM) Viewer role (roles/viewer). This basic role provides broad, read-only permissions across all project services and resources, which aligns perfectly with the requirements for an auditor who needs to inspect but not alter the project's state. Using a predefined role is a best practice as it is managed by Google and ensures that the permissions are correctly and consistently applied for the intended purpose without the overhead of creating and maintaining a custom role.

Why Incorrect

A. Creating a custom role is unnecessary when a predefined role perfectly fits the requirement. It adds management overhead and potential for misconfiguration.

B. A custom role with "view-only service permissions" is ambiguous and likely insufficient, as the requirement is for all project items, not just specific services.

D. There is no single, built-in "service Viewer" role. Predefined viewer roles are specific to services (e.g., Compute Viewer), which would not grant the required project-wide access.

References

1. Google Cloud Documentation

IAM

Basic roles: "The Viewer role (roles/viewer) provides permissions for read-only actions that don't modify state

such as viewing (but not modifying) existing resources or data." This directly supports the use of the Viewer role for an auditor. (See section: "Basic roles"

subsection: "Viewer").

2. Google Cloud Documentation

IAM

Understanding roles: "Basic roles include the Owner

Editor

and Viewer roles. You can use these roles to grant principals broad access to all Google Cloud resources... When possible

we recommend that you grant predefined roles instead of basic roles." However

for project-wide read access

the basic Viewer role is the intended and most direct solution. (See section: "Role types").

3. Google Cloud Documentation

IAM

Creating and managing custom roles: "IAM also offers custom roles. These roles let you grant a fine-grained set of permissions that you define... Create a custom role only if the predefined roles don't meet your needs." This confirms that predefined roles should be used first

making option C superior to A. (See section: "Before you begin").

Q: 15

You have a Google Cloud Platform account with access to both production and development projects. You need to create an automated process to list all compute instances in development and production projects on a daily basis. What should you do?

Options

5 comments in the community discussion

FocusedLead9011

I’m not sure C is correct here. gsutil doesn’t manage compute, so B is out. D seems manual, and C just says “go to Cloud Shell” but doesn’t specify listing by project or automation. I think A is better since you can script switching projects with gcloud configs, but maybe I’m missing something?

MayaD

This looks like one from my exam last year in some practice sets, picked C there. Seemed like exporting from Cloud Shell to Storage daily would work.

Correct Answer:

Explanation

The most effective method for automating command-line operations across multiple Google Cloud projects is by using gcloud configurations. Each configuration stores a set of properties, including the project ID and account. By creating one configuration for the 'development' project and another for 'production', a script can programmatically switch between them using gcloud config configurations activate. For each active configuration, the gcloud compute instances list command is used to retrieve the instance data for that specific project. This entire workflow is scriptable, allowing it to be automated for daily execution via a cron job or Cloud Scheduler.

Why Incorrect

B. gsutil is the command-line tool for Cloud Storage, not Compute Engine. The command gsutil compute instances list is invalid and does not exist.

C. This option describes a manual daily action ("Go to Cloud Shell"), which fails to meet the core requirement of creating an "automated process".

D. This option describes a manual daily action ("Go to GCP Console"), which directly contradicts the requirement for an "automated process".

References

1. gcloud config configurations: The official documentation explains how to create and manage named sets of properties. "A configuration is a named set of gcloud CLI properties. These properties are key-value pairs that govern the behavior of the gcloud CLI."

Source: Google Cloud SDK Documentation

gcloud config configurations. (https://cloud.google.com/sdk/gcloud/reference/config/configurations)

2. gcloud compute instances list: This command is the correct tool for listing Compute Engine instances. The documentation states its purpose is to "List Google Compute Engine instances." It can be targeted at a specific project

which is controlled by the active gcloud configuration.

Source: Google Cloud SDK Documentation

gcloud compute instances list. (https://cloud.google.com/sdk/gcloud/reference/compute/instances/list)

3. gsutil Tool: The documentation clarifies that gsutil is for interacting with Cloud Storage. "gsutil is a Python application that lets you access Cloud Storage from the command line." It does not manage Compute Engine resources.

Source: Google Cloud Documentation

Cloud Storage

"gsutil tool". (https://cloud.google.com/storage/docs/gsutil)

Q: 16

You deployed an LDAP server on Compute Engine that is reachable via TLS through port 636 using UDP. You want to make sure it is reachable by clients over that port. What should you do?

Options

4 comments in the community discussion

CarefulAnalyst6066 1

Pretty sure it's C. You need to allow ingress not egress for the clients to reach the server, and a firewall rule tied to a network tag is the way to go. Anyone else seen this setup in GCP docs?

Olivia I. 1

D imo, seen similar question in the official practice tests.

Correct Answer:

Explanation

To make a service on a Compute Engine instance accessible from outside the VPC network, you must create an ingress firewall rule. The standard and most effective method is to apply a network tag to the VM instance. This tag acts as an identifier. You then create a VPC firewall rule that allows ingress traffic, specifies the protocol (UDP) and port (636), and targets all instances with that specific network tag. This approach correctly configures the network security to permit the required client connections to the LDAP server.

Why Incorrect

A. Adding a network tag by itself does not create any network permissions. A tag is merely a label that must be referenced by a firewall rule to have any effect.

B. Routes are used to define paths for traffic to reach destinations, not to permit or deny connections. Firewall rules control access based on protocol and port.

D. An egress rule controls outbound traffic from the VM instance. To allow clients to connect to the server, an ingress (inbound) rule is required.

References

1. Google Cloud Documentation - VPC firewall rules overview: Under the "Components of a firewall rule" section

it states that a rule's target can be specified using "Target tags

" which applies the rule to instances with a matching network tag. The "Direction of traffic" component must be set to ingress for incoming connections.

Source: Google Cloud

"VPC firewall rules overview"

cloud.google.com/vpc/docs/firewalls#components.

2. Google Cloud Documentation - Using VPC firewall rules: This page provides examples of creating firewall rules. The common pattern shown is to define a rule with a direction (INGRESS)

a target (using targetTags)

a source filter

and a protocol/port specification. This directly aligns with the procedure described in the correct answer.

Source: Google Cloud

"Using VPC firewall rules"

cloud.google.com/vpc/docs/using-firewalls#creatingfirewallrules.

3. Google Cloud Documentation - Network tags overview: "Tags are useful for applying firewall rules... You make a firewall rule applicable to specific instances by using target tags." This reference clarifies that the primary purpose of tags in this context is to be used as targets for firewall rules

invalidating the option that suggests using a tag alone is sufficient.

Source: Google Cloud

"Configure network tags"

cloud.google.com/vpc/docs/add-remove-network-tags.

Q: 17

You have one project called proj-sa where you manage all your service accounts. You want to be able to use a service account from this project to take snapshots of VMs running in another project called proj-vm. What should you do?

Options

8 comments in the community discussion

Logan D. 2

C imo, I saw a similar question on my last practice and it matched.

Neha I. 1

Its C since IAM roles are what you need for cross-project resource access. Granting Compute Storage Admin to the service account in proj-vm gives it snapshot permissions. The other options mess with keys or scopes but don't solve the permission problem. Pretty sure that's right, correct me if I missed something.

Correct Answer:

Explanation

This scenario requires granting a principal (the service account from proj-sa) permissions to act on resources (VM disks) in a different project (proj-vm). The standard Google Cloud method for cross-project authorization is to grant the principal an Identity and Access Management (IAM) role on the project containing the resources. The Compute Storage Admin (roles/compute.storageAdmin) role contains the necessary permissions, such as compute.disks.createSnapshot, to manage storage resources like persistent disks and snapshots. By granting this role to the service account on the proj-vm project, you authorize it to perform the required actions.

Why Incorrect

A. Storing private keys in custom metadata is a significant security risk and does not grant the necessary cross-project permissions (authorization) for the service account to act on resources in another project.

B. Service account private keys are used for authenticating to Google Cloud APIs, not for user SSH access. SSH keys are a completely different authentication mechanism for interactive logins.

D. API scopes are a legacy authorization method that defines the maximum permissions for a service account attached to a VM. The primary and more granular method is IAM. This option fails to address the core requirement of granting the service account permissions in the target project (proj-vm).

References

1. Google Cloud Documentation

"Granting roles to service accounts": In the section "Granting a role to a service account for a project and resources within the project

" the documentation states

"To allow a service account to access resources in a different project

you can grant a role to the service account on the other project." This directly supports the cross-project IAM binding described in the correct answer.

2. Google Cloud Documentation

"IAM basic and predefined roles reference"

Compute Engine roles: The documentation for the Compute Storage Admin role (roles/compute.storageAdmin) confirms that it provides "Full control of Compute Engine storage resources

" which includes permissions for creating snapshots (compute.disks.createSnapshot).

3. Google Cloud Documentation

"Service accounts overview": This document clarifies that a service account is a principal

or an identity

which can be granted IAM roles to access resources. This reinforces the concept of treating the service account from proj-sa as an identity that needs permissions in proj-vm.

4. Google Cloud Documentation

"Access control for Compute Engine resources": This page contrasts IAM and API Scopes

stating

"In general

we recommend using IAM to manage access to Compute Engine resources instead of access scopes." This explains why relying on API scopes (Option D) is not the recommended or correct primary approach.

Q: 18

You have a single binary application that you want to run on Google Cloud Platform. You decided to automatically scale the application based on underlying infrastructure CPU usage. Your organizational policies require you to use virtual machines directly. You need to ensure that the application scaling is operationally efficient and completed as quickly as possible. What should you do?

Options

3 comments in the community discussion

Ivy 2

Option B but only if you actually set the autoscaling policy to target CPU usage, not just rely on the default. C wouldn't work for dynamic CPU changes and A fails org policy since it's not VMs directly. Anyone run into edge cases with B if app has stateful needs?

Sara

B makes sense since managed instance groups let you autoscale VM instances based on CPU metrics natively. This fits the org policy about using VMs directly, and it's faster and less manual than custom scripts or third-party tools. Pretty sure it's B but open to feedback if anyone's seen issues with this setup.

Correct Answer:

Explanation

The most operationally efficient and rapid method to meet the requirements is to use a Managed Instance Group (MIG) based on an instance template. An instance template defines the configuration of the virtual machines, ensuring consistency. The MIG uses this template to manage a group of identical VMs. By configuring the MIG's autoscaler with a policy based on average CPU utilization, Google Cloud's managed service will automatically add or remove VMs to maintain the desired performance level. This native solution directly addresses the need to use VMs, scale on CPU, and do so efficiently without custom tooling.

Why Incorrect

A. Google Kubernetes Engine is a container orchestration service. It scales container pods, not virtual machines directly as required by the policy.

C. This option describes schedule-based autoscaling, which scales based on time, not on the required real-time CPU usage metric.

D. Building and maintaining a custom scaling solution with third-party tools is significantly less operationally efficient and more complex than using the native, fully managed autoscaler.

References

1. Google Cloud Documentation

"Autoscaling groups of instances": "Autoscaling helps your applications gracefully handle increases in traffic and reduces costs when the need for resources is lower. You define the autoscaling policy

and the autoscaler performs automatic scaling based on the measured load." The document further specifies CPU utilization as a primary scaling metric. (Source: Google Cloud

Compute Engine Documentation

"Autoscaling groups of instances").

2. Google Cloud Documentation

"Scaling based on CPU utilization": "You can configure the autoscaler to scale a managed instance group (MIG) based on the average CPU utilization of the instances in the group... The autoscaler adds or removes virtual machine (VM) instances from the MIG to maintain the target CPU level." This directly supports option B. (Source: Google Cloud

Compute Engine Documentation

"Autoscaling policies"

Section: "Scaling based on CPU utilization").

3. Google Cloud Documentation

"Instance templates": "An instance template is a resource that you can use to create VM instances and managed instance groups (MIGs). Instance templates define the machine type

boot disk image...

and other instance properties." This confirms that an instance template is the correct prerequisite for a MIG. (Source: Google Cloud

Compute Engine Documentation

"Instance templates").

4. Google Cloud Documentation

"Google Kubernetes Engine (GKE) overview": "GKE is a managed

production-ready environment for deploying containerized applications." This highlights that GKE's primary abstraction is the container

not the underlying VM

making option A incorrect for the stated requirement. (Source: Google Cloud

GKE Documentation

"Concepts"

Section: "Overview").

Q: 19

Your organization has strict requirements to control access to Google Cloud projects. You need to enable your Site Reliability Engineers (SREs) to approve requests from the Google Cloud support team when an SRE opens a support case. You want to follow Google-recommended practices. What should you do?

Options

6 comments in the community discussion

Owen

Its D, official guide and exam blueprint both stress groups over single users for this.

Adam I.

D imo. Google always recommends assigning IAM roles to groups rather than individual users, easier to manage and audit. The roles/accessapproval.approver is exactly what lets SREs approve support access requests, so putting them in a group and assigning that role matches best practice. Pretty sure that's t

Correct Answer:

Explanation

To allow SREs to approve access requests from Google support, they must be granted the accessapproval.requests.approve permission. This permission is included in the predefined IAM role roles/accessapproval.approver. Google's recommended best practice for managing permissions is to assign roles to groups rather than individual users. This approach simplifies administration, as membership changes are managed within the group without altering IAM policies. Therefore, the correct procedure is to add the SREs to a Google Group and then grant the roles/accessapproval.approver role to that group.

Why Incorrect

A. The roles/iam.roleAdmin role is for managing custom IAM roles, not for approving support access requests. It also violates the best practice of using groups.

B. While this assigns the correct role, it grants it to individual users directly, which contradicts the Google-recommended practice of using groups for scalable and manageable permissions.

C. This option correctly uses a group, but it assigns the roles/iam.roleAdmin role, which does not grant the necessary permissions to approve Access Approval requests.

References

1. Google Cloud Documentation

"Access Approval IAM roles": This document explicitly lists the roles/accessapproval.approver role and its associated permission

accessapproval.requests.approve

which is required to "Approve a request for access."

Source: Google Cloud > Documentation > Access Approval > Control access with IAM > Access Approval IAM roles.

2. Google Cloud Documentation

"Policy recommendations": This guide on best practices for IAM states

"Use Google Groups to manage principals... Using groups is a convenient way to manage access for a collection of users. You can grant and change access controls for a whole group at once

instead of granting or changing access controls for individual users one by one."

Source: Google Cloud > Documentation > Identity and Access Management > Best practices for using IAM > Policy recommendations > Use Google Groups to manage principals.

3. Google Cloud Documentation

"Overview of Access Approval": This document describes the purpose of the service: "Access Approval ensures that whenever a Google employee wants to access your user content for support and other services

they must get your explicit approval." This confirms that Access Approval is the correct service for the described scenario.

Source: Google Cloud > Documentation > Access Approval > Overview.

Q: 20

You recently deployed a new version of an application to App Engine and then discovered a bug in the release. You need to immediately revert to the prior version of the application. What should you do?

Options

3 comments in the community discussion

Ajay F.

Maybe C, since you can just point all traffic to the previous stable version instantly from the Versions page. The other options don’t really match any real-world App Engine flow. Not 100% sure but this lines up with what I’ve seen in practice.

ReeseU

C is correct. On App Engine, you can route all traffic back to the good version from the Versions page-no redeploy needed. Saw a similar question in practice, pretty sure this is fastest. Disagree?

Correct Answer:

Explanation

Google App Engine retains previously deployed versions of an application. The standard and immediate method for rolling back a faulty deployment is to use the built-in traffic splitting feature. By navigating to the 'Versions' page for the specific App Engine service, you can re-route 100% of the user traffic from the new, buggy version to a previously known stable version. This action is instantaneous and effectively reverts the application to its prior state without requiring a new deployment, thus minimizing downtime and impact on users.

Why Incorrect

A. gcloud app restore is not a valid gcloud command for App Engine. The correct command-line tool for managing traffic is gcloud app services set-traffic.

B. There is no single "Revert" button at the application level in the Google Cloud Console. Reverting is a function of traffic management between different versions.

D. This approach is incorrect and inefficient. App Engine automatically keeps prior versions, so redeploying is unnecessary. Furthermore, traffic is split between versions of a service, not between separate applications.

References

1. Google Cloud Documentation

"Splitting Traffic": "If you need to roll back a version

you can easily do so by migrating traffic to one or more other versions." This page details the process of using the Google Cloud Console to select a version and allocate 100% of traffic to it

which is the procedure described in the correct answer. (See section: "Migrating traffic to a single version").

2. Google Cloud Documentation

"Managing Versions": "When you deploy changes to your app

a new version is created and traffic is routed to it. You can

however

choose to not route traffic to the new version automatically... If you discover a bug in a new version

you can quickly roll back to a previous version by routing traffic to it." This confirms that previous versions are retained and that traffic routing is the intended rollback mechanism.

3. Google Cloud SDK Documentation

gcloud app services set-traffic: This command-line reference demonstrates the programmatic way to manage traffic splits. The documentation states its purpose is to "[s]et the traffic splitting configuration for a service." This reinforces that traffic management is the core concept for version control

and it implicitly shows that a command like gcloud app restore does not exist for this purpose.

Question 1 of 20

Premium Access Includes

More Google Practice Tests