ASSOCIATE-CLOUD-ENGINEER Practice Questions

Creating a Google Cloud service account is an administrative action that modifies the configuration of a project's Identity and Access Management (IAM) resources. According to Google Cloud's audit logging policy, such administrative modifications are captured in Admin Activity audit logs. In the Google Cloud Console's log viewer, Admin Activity logs are categorized under Configuration. To isolate the specific event, you must filter by the resource that was modified, which in this case is the Service Account resource type. This combination provides the most precise filter to find the creation event.

B. Filtering by "Google Project" as the resource type is too broad. This would display all configuration changes for the entire project, making it difficult to locate the specific service account creation event.

C. The "Data Access" category is incorrect. These logs record API calls that read configuration/metadata or read/write user data, not administrative actions like creating a service account.

D. This option is incorrect for two reasons: the "Data Access" category is inappropriate for this administrative action, and filtering by "Google Project" is too broad and inefficient.

1. Google Cloud Documentation - Cloud Audit Logs Overview: This document distinguishes between different types of audit logs. It states

"Admin Activity audit logs contain log entries for API calls or other actions that modify the configuration or metadata of resources." This supports using the "Configuration" (Admin Activity) category.

Source: Google Cloud Documentation > Cloud Audit Logs > Overview > "Types of audit logs".

2. Google Cloud Documentation - IAM Audit Logging: This page details which IAM actions generate which types of logs. The google.iam.admin.v1.IAM.CreateServiceAccount method is explicitly listed as an action that generates an Admin Activity audit log.

Source: Google Cloud Documentation > IAM > Documentation > Guides > "Audit logging" > "Audited operations".

3. Google Cloud Documentation - View logs by using the Logs Explorer: This guide demonstrates how to build queries in the Logs Explorer. It shows the ability to filter by resource.type. The resource type for a service account is iamserviceaccount

which corresponds to the "Service Account" filter in the UI.

Source: Google Cloud Documentation > Cloud Logging > Documentation > "View logs by using the Logs Explorer" > "Build queries".

Google App Engine is designed to support multiple versions of an application simultaneously. The platform's native traffic splitting feature allows you to incrementally roll out changes by directing a specific percentage of traffic to a new version. This is the standard method for performing A/B testing or canary deployments. Deploying the new code as a new version within the same application and then using the Google Cloud Console to configure the traffic split is the most direct and intended approach to achieve the goal.

A. Migrating to Google Kubernetes Engine is a major architectural change and is not the correct procedure for testing a new version of an existing App Engine application.

B. Migrating to Compute Engine is an unnecessary platform change that ignores the built-in versioning and traffic management capabilities of App Engine.

C. Traffic splitting in App Engine is managed between different versions within a single application/service, not between two entirely separate applications. This approach is functionally incorrect.

1. Google Cloud Documentation - App Engine - Splitting Traffic: "App Engine allows you to split incoming traffic for your app between two or more of its versions. Splitting traffic allows you to do A/B testing between your versions and provides control over the pace when rolling out features." This document explicitly describes the process in option D.

Source: Google Cloud Documentation

"Splitting Traffic"

App Engine standard environment for Python 3 docs.

2. Google Cloud Documentation - App Engine - How Requests are Routed: "Within a single project

you can deploy multiple apps as services. [...] Each service can have multiple versions

and you can split traffic between those versions." This clarifies that versions exist within a service/app

making option C incorrect.

Source: Google Cloud Documentation

"How Requests are Routed"

App Engine Concepts.

3. Google Cloud Documentation - Deploying a new service or version: "When you deploy a new version

you can choose to either immediately route traffic to it or deploy it without routing traffic and then later assign traffic to it." This confirms that deploying a new version is the first step

followed by traffic management.

Source: Google Cloud Documentation

"Deploying a new service or version"

App Engine standard environment for Python 3 docs.

The user's goal is to create a new Cloud Billing account and then associate an existing Google Cloud project with it. This is a two-step process. First, a new billing account must be created. Second, the existing project's billing settings must be modified to point to this new account. To modify a project's billing account, the user must have the resourcemanager.projects.setBillingAccount permission on the project, which is included in the Project Billing Manager role. Option B is the only choice that correctly describes both the creation of a new billing account and the subsequent linking to an existing project, while also referencing a necessary permission for the linking step.

A. This option is incorrect because it involves linking the project to an existing billing account, whereas the requirement is to create a new one.

C. This option is incorrect because it involves creating a new project, but the requirement is to use an existing project.

D. This option is incorrect because it uses an existing billing account, not a new one as required by the prompt.

1. Google Cloud Documentation

"Enable

disable

or change billing for a project": This document outlines the permissions required to change a project's billing account. It states

"To change the billing account for a project

you need the Project Billing Manager role... on the project AND the Billing Account User role... on the destination Cloud Billing account." This confirms that the Project Billing Manager role mentioned in option B is essential for the task.

Source: Google Cloud Documentation

Cloud Billing > How-to Guides > Enable

disable

or change billing for a project > "Permissions required to change the billing account of a project".

2. Google Cloud Documentation

"Create

modify

or close your Cloud Billing account": This guide details the process of creating a new billing account

which is the first step in the user's request. It also specifies that the Billing Account Creator role is needed for this action. Option B correctly identifies this as the initial action.

Source: Google Cloud Documentation

Cloud Billing > How-to Guides > Create

modify

or close your Cloud Billing account > "Create a new Cloud Billing account".

3. Google Cloud Documentation

"Overview of Cloud Billing access control": This page provides a comprehensive list of billing-related IAM roles and their associated permissions

confirming that Project Billing Manager contains resourcemanager.projects.setBillingAccount

which is the specific permission needed to link a project to a billing account.

Source: Google Cloud Documentation

Cloud Billing > How-to Guides > Overview of Cloud Billing access control > "Project billing roles".

This solution correctly addresses all requirements for high availability as stated in the scenario. Using an instance template is the standard practice for creating multiple, identical instances. Setting 'Automatic Restart' to 'on' ensures that if a VM crashes due to an underlying hardware or system issue, Compute Engine will attempt to restart it. Setting 'On-host maintenance' to 'Migrate VM instance' enables live migration, where Google Cloud moves the running instance to another host in the same zone before maintenance begins, ensuring the instance remains available and avoiding downtime. Combining these settings in an instance template and applying it to an instance group provides a scalable and highly available configuration.

B. This configuration is the opposite of what is required for high availability. Disabling automatic restart and terminating instances during maintenance would lead to significant downtime.

C. Autohealing is for application-level failures (e.g., a frozen application), not for VM crashes or host maintenance events. The question specifies infrastructure-level availability, which is handled by restart and migration policies.

D. The 'do not retry machine creation' setting applies only to the initial creation of an instance within a group. It does not affect the availability of an already running instance.

1. Setting instance availability policies: The official Google Cloud documentation specifies the two key settings for instance availability.

On host maintenance: "To ensure that your instances continue to run during a host system event

Compute Engine can live migrate your running instances... Your instance continues to run on the new host while the original host is updated."

Automatic restart: "If your instance is set to terminate due to a host error

you can specify that Compute Engine should automatically restart the instance."

Source: Google Cloud Documentation

Compute Engine

"Setting instance availability policies". Section: "Setting the host maintenance policy" and "Setting the automatic restart policy".

2. Instance templates: This document explains the purpose and use of instance templates for creating consistent VM configurations.

"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 or container image

labels

and other instance properties."

Source: Google Cloud Documentation

Compute Engine

"Instance templates". Section: "Overview".

3. Live Migration: This document details the live migration process

which is the mechanism behind the 'Migrate VM instance' setting.

"By default

standard instances are set to live migrate

where Compute Engine automatically migrates your instance away from an infrastructure maintenance event

and your instance remains running during the migration."

Source: Google Cloud Documentation

Compute Engine

"Live migration". Section: "How does live migration work?".

In Google Cloud, a Virtual Private Cloud (VPC) subnet is defined by a primary IPv4 range in CIDR notation. The size of the range is determined by the prefix length (the number after the /). A smaller prefix number indicates a larger IP address range. The largest permissible subnet range in Google Cloud VPC is one with a /8 prefix. The range 10.0.0.0/8 provides 2^(32-8) = 16,777,216 addresses, which is the maximum possible for a single subnet, making it the correct choice for the largest possible range.

A. 0.0.0.0/0 is not a valid range for a subnet. This CIDR block represents all IP addresses and is used in routing tables to define a default route, typically to the internet.

C. 172.16.0.0/12 is a valid subnet range, but it is smaller than a /8 range, providing only 2^(32-12) = 1,048,576 addresses.

D. 192.168.0.0/16 is also a valid subnet range, but it is significantly smaller than a /8 range, providing only 2^(32-16) = 65,536 addresses.

1. Google Cloud Documentation - VPC network overview: "Each subnet is associated with a single region and must have at least one primary IPv4 address range." This document establishes the fundamental relationship between VPCs and subnets.

Source: Google Cloud Documentation

"VPC network overview"

Section: "Networks and subnets".

2. Google Cloud Documentation - Subnets: "The prefix length for a primary IPv4 subnet range cannot be smaller than /8." A smaller prefix length number corresponds to a larger IP address block

confirming that /8 is the largest size allowed.

Source: Google Cloud Documentation

"Subnets"

Section: "Subnet ranges"

Subsection: "Valid ranges".

3. Google Cloud SDK Documentation - gcloud compute networks subnets create: The command-line interface documentation explicitly states the constraints on subnet creation: "The prefix length must be between 8 and 29

inclusive." This confirms that /8 is the minimum valid prefix length

which corresponds to the maximum range size.

Source: Google Cloud SDK Documentation

gcloud compute networks subnets create

Argument: --range.

4. IETF RFC 1918 - Address Allocation for Private Internets: This document defines the private IPv4 address spaces

which include 10.0.0.0/8

172.16.0.0/12

and 192.168.0.0/16. While all are valid private ranges

Google Cloud's implementation limits the maximum subnet size to /8.

Source: IETF RFC 1918

Section 3: "Private Address Space".

The most rapid and effective method to validate a Deployment Manager template without making actual changes to the project is by using the --preview flag. This feature allows you to see exactly which resources Deployment Manager will create, update, or delete. The preview process expands the full configuration, including resolving all dependencies, but does not instantiate any resources. If there are errors in the template, such as unmet dependencies or invalid resource properties, the preview operation will fail, providing immediate feedback. This directly addresses the need to confirm dependencies rapidly before committing.

A. Logging in Python templates is for debugging the template's code logic, not for a rapid, holistic validation of the final resource dependency graph before execution.

B. Monitoring logs in Cloud Logging requires an actual deployment attempt. This is a reactive approach and is not a pre-deployment check for rapid feedback.

C. Executing the template in a separate project is a valid integration testing strategy but is not the most rapid method for feedback, as it involves a full, potentially time-consuming deployment.

1. Google Cloud Documentation

"Previewing a configuration": "Before you commit to a configuration

you can preview it. Previewing a configuration expands the full configuration

including any templates

but does not instantiate any of the actual resources. Deployment Manager returns the expanded configuration so you can review the resources that Deployment Manager would create." This source confirms that --preview is the intended method for non-destructive validation.

Source: Google Cloud

Deployment Manager Documentation

"Previewing a configuration".

2. Google Cloud Documentation

gcloud deployment-manager deployments create: The documentation for the gcloud command explicitly describes the --preview flag: "If specified

the deployment is not created but a preview of the deployment is returned." This highlights its function as a non-executing check.

Source: Google Cloud SDK Documentation

gcloud deployment-manager deployments create.

3. Coursera

Google Cloud

"Managing Deployments Using Google Cloud Deployment Manager": In the module on "Creating and Managing Deployments

" the courseware emphasizes using the preview feature as a best practice before applying changes. It states

"A preview shows you what resources will be created

but doesn't actually create them. This is a great way to test your configuration before you deploy it."

Source: Coursera

Google Cloud Training

"Essential Google Cloud Infrastructure: Core Services"

Week 4

"Managing Deployments Using Google Cloud Deployment Manager".

The requirement is to serve SSL-encrypted TCP traffic to a global user base with minimal latency. The External SSL Proxy Load Balancer is the ideal solution. It is a global service that terminates user SSL/TLS connections at a Google Cloud network point of presence (PoP) closest to the client. This termination at the edge significantly reduces latency, especially for the initial SSL handshake. The load balancer then communicates with the backend instances, typically over an unencrypted channel within Google's network. This design is specifically for non-HTTP(S) SSL traffic, which perfectly matches the "SSL-encrypted TCP" description.

A. HTTPS Load Balancer: This is a global load balancer, but it is designed specifically for HTTP(S) traffic (Layer 7). The question specifies generic "SSL-encrypted TCP," which is not necessarily HTTP.

B. Network Load Balancer: This is a regional, pass-through load balancer (Layer 4). It does not terminate the SSL connection and cannot leverage Google's global network to reduce latency for worldwide clients.

D. Internal TCP/UDP Load Balancer: This load balancer is for internal traffic within a Google Cloud VPC. It cannot be used to serve traffic from external clients on the public internet.

1. Google Cloud Documentation

"Choose a load balancer": The decision tree on this page guides users to the correct load balancer. For "Global" traffic from the "Internet" that is "Non-HTTP(S) traffic

" the recommended solution is the "External SSL Proxy Load Balancer."

Source: Google Cloud Documentation

"Cloud Load Balancing overview"

section "Summary of Google Cloud load balancers".

2. Google Cloud Documentation

"External SSL Proxy Load Balancing overview": "External SSL Proxy Load Balancing is a reverse proxy load balancer that distributes SSL traffic coming from the internet to virtual machine (VM) instances in your Google Cloud VPC network. ... When you want to load balance non-HTTP(S) traffic for a global audience

you should use an SSL Proxy Load Balancer."

Source: Google Cloud Documentation

"External SSL Proxy Load Balancing overview".

3. Google Cloud Documentation

"External SSL Proxy Load Balancing overview"

section "Benefits": "SSL proxy load balancers terminate user TLS sessions at the load balancing layer. ... Terminating TLS sessions at the load balancer enables the load balancer to route connections to backends more efficiently." This termination at the edge is the key to reducing latency.

Source: Google Cloud Documentation

"External SSL Proxy Load Balancing overview"

section "Benefits".

4. Google Cloud Documentation

"External TCP/UDP Network Load Balancing overview": "External TCP/UDP Network Load Balancing is a regional

pass-through load balancer. ... Because the load balancer is a pass-through load balancer

your backends terminate the client TCP connection or UDP packets." This confirms it is regional and does not terminate SSL

making it unsuitable for this scenario.

Source: Google Cloud Documentation

"External TCP/UDP Network Load Balancing overview".

Creating a snapshot schedule is the official, Google-recommended method for automating backups of Compute Engine persistent disks. This managed service directly addresses all the requirements: it can be configured to create snapshots at regular intervals, it includes a retention policy to automatically delete older backups to control costs, and snapshots provide the fastest method for restoring a disk's data. This approach is more robust, manageable, and less error-prone than custom scripting solutions.

A. An instance template is a blueprint for creating new virtual machine instances; it does not back up the data of an existing, running workload.

C. Using a cron job with gcloud is a manual, self-managed solution that lacks the built-in retention policies and reliability of the managed snapshot schedule service.

D. Exporting an image to Cloud Storage is a valid backup method, but restoring from it is a multi-step process (import image, then create disk) which is slower than creating a disk directly from a snapshot.

1. Google Cloud Documentation - Create scheduled snapshots for persistent disk: "To back up your persistent disks

Google Cloud recommends that you set up a snapshot schedule. A snapshot schedule is a resource that defines the frequency of snapshot creation

a retention policy

and a location for the snapshots." This page details the creation and management of schedules

including the retention policy for automatic cleanup.

2. Google Cloud Documentation - About disk snapshots: "Use snapshots to back up data from your persistent disks. ... You can use a snapshot to create a new disk that contains the data from the snapshot." This confirms snapshots are the primary backup mechanism and can be used for quick restoration.

3. Google Cloud Documentation - Best practices for Compute Engine disk snapshots: "Automate your snapshot creation process by using snapshot schedules. This is the best practice for backing up your Compute Engine workloads." This explicitly states that using snapshot schedules is the recommended best practice.

The gcloud command-line tool operates based on a set of configurations that define default properties like project, region, and zone. When you execute a command such as gcloud app deploy without explicitly specifying the --project flag, the tool uses the project ID set in the currently active configuration. The command gcloud config list displays all properties for the active configuration, including the core/project property. By running this command, you can immediately identify which project was targeted by the deployment, thus explaining both why it went to an unintended project and where it was deployed.

A. The app.yaml file defines the application's runtime, scaling, and handler settings, but it does not specify the target Google Cloud project for deployment.

B. The web-application.xml (or web.xml) file is a standard configuration file for Java web applications and does not contain Google Cloud project deployment information.

C. Google Cloud Deployment Manager is an infrastructure-as-code service for provisioning resources, not for deploying application code via the gcloud app deploy command.

1. gcloud config list: "The gcloud config list command displays all the properties for the currently active configuration." This includes the core.project property

which is used by default for commands.

Source: Google Cloud SDK Documentation

gcloud config list

https://cloud.google.com/sdk/gcloud/reference/config/list

2. gcloud app deploy: The documentation for this command shows the optional --project flag. It states

"The Google Cloud project ID to use for this invocation. If omitted

then the current project is assumed." The "current project" is determined by the gcloud configuration.

Source: Google Cloud SDK Documentation

gcloud app deploy

https://cloud.google.com/sdk/gcloud/reference/app/deploy

3. app.yaml Configuration File: The official reference for the app.yaml file for both Standard and Flexible environments lists all valid configuration elements. A project or projectid field is not among them

confirming that the project is not defined within the application's configuration file.

Source: Google Cloud App Engine Documentation

app.yaml reference

https://cloud.google.com/appengine/docs/standard/reference/app-yaml

4. Initializing the gcloud CLI: "When you initialize the gcloud CLI

you run the gcloud init command. The gcloud init command creates a named configuration called default and sets it as the active configuration. The default configuration contains your user account and a default Google Cloud project." This establishes the concept of a default project within a configuration.

Source: Google Cloud SDK Documentation

"Initializing the gcloud CLI"

https://cloud.google.com/sdk/docs/initializing (Section: "Default project

region

and zone")

The most direct, cost-effective, and officially recommended method to send logs from Cloud Logging to BigQuery is by creating a log sink. A sink allows you to define a filter for specific logs (in this case, from Compute Engine instances using resource.type="gceinstance") and route them directly to a supported destination. Choosing BigQuery as the sink destination is a native integration that is optimized for this purpose. This approach avoids the additional cost and complexity of intermediate services like Pub/Sub and Cloud Functions, thereby minimizing both operational overhead and cost, as required by the question.

A. The instance metadata key logs-destination is not a valid or standard configuration parameter for the Cloud Logging agent to specify a BigQuery destination.

B. This solution introduces unnecessary intermediate services (Pub/Sub and Cloud Functions), which add complexity and incur their own costs for message delivery and function execution, violating the "minimize cost" requirement.

D. This describes a complex, daily batch process. It introduces latency (up to 24 hours), is more expensive due to using Cloud Scheduler and Cloud Functions, and is less reliable than a real-time sink.

1. Google Cloud Documentation - Overview of log routing and sinks: "To route logs

you create a sink. A sink includes a destination and a filter that selects the log entries to route... You can route log entries to the following destinations: ... BigQuery dataset". This document establishes the sink as the primary mechanism for routing logs.

Source: Google Cloud Documentation

"Overview of log routing and sinks"

Section: "How sinks work".

2. Google Cloud Documentation - Exporting logs to BigQuery: "To export logs to BigQuery

you create a sink and set BigQuery as the destination... The sink creates a new BigQuery dataset and then creates tables with a schema for the logs." This page details the exact procedure described in option C.

Source: Google Cloud Documentation

"Route logs to supported destinations"

Section: "Route logs to BigQuery".

3. Google Cloud Documentation - Cloud Logging Pricing: "There is no charge for routing logs to a supported destination; however

the destination might have its own ingestion costs." This supports the cost-minimization argument by showing that the routing itself is free

so avoiding extra billable services (like Pub/Sub and Functions) is the most economical approach.

Source: Google Cloud Documentation

"Cloud Logging pricing"

Section: "Log routing".

4. Google Cloud Documentation - Logging agent configuration: The official documentation for configuring the google-fluentd agent does not list a logs-destination metadata key for routing logs

confirming that the method in option A is incorrect. Configuration is managed through agent configuration files

not instance metadata for this purpose.

Source: Google Cloud Documentation

"Logging agent - Advanced configuration".