Examkin

All practice questions

262 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 21Question →

An Cloud Engineer needs to set up daily Cloud Billing export to BigQuery for long-term spend analysis. Sequence the following steps in the correct order to successfully configure the export.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by creating the target BigQuery dataset, verifying that necessary IAM roles (Billing Account Administrator and BigQuery Data Editor) are assigned, navigating to Billing export in the Cloud Console, and finally specifying the target project and dataset to enable the export.
To set up Cloud Billing export to BigQuery, a target BigQuery dataset must first exist in a designated project. Next, the engineer must hold appropriate permissions (Billing Account Administrator and BigQuery Data Editor). Then, the engineer navigates to the Billing export section in the GCP Console and selects BigQuery export. Finally, selecting the target project and dataset and saving the configuration enables the export stream.

Step-by-Step Solution

1
Create a BigQuery dataset
A destination location exists to receive billing data.
Cloud Billing export requires a pre-existing dataset in a project.
2
Verify IAM permissions
The engineer has authorization to link billing and BigQuery.
Creating the sink requires Billing Account Administrator on the billing account and BigQuery Data Editor on the target dataset.
3
Navigate to Billing export settings
Access to Cloud Billing configuration options.
Billing export configuration is managed in the Cloud Billing navigation pane.
4
Configure destination dataset and save settings
Cloud Billing export is activated.
Linking the target dataset completes the workflow.

Key Concept

Configuring Cloud Billing Export to BigQuery
Question 22Question →

A cloud engineer needs to enable the Secret Manager API (`secretmanager.googleapis.com`) for a newly created Google Cloud project named `security-vault-prod` using the `gcloud` CLI, ensuring that the target environment is configured before enablement and verified afterward. Place the administrative steps in the correct chronological sequence from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Set the active `gcloud` project context to `security-vault-prod`, 2) Inspect currently enabled APIs to check state, 3) Execute the `gcloud services enable` command for `secretmanager.googleapis.com`, and 4) Verify successful activation by filtering enabled services.
The standard sequence for API management requires initializing the target CLI project context first, checking current state, enabling the service API, and validating activation upon completion.

Step-by-Step Solution

1
Configure gcloud CLI target project context.
The CLI environment is bound to `security-vault-prod` (`gcloud config set project security-vault-prod`).
CLI commands act on the default configured project unless explicitly overridden, avoiding changes to the wrong project.
2
Inspect current API enablement state.
Run `gcloud services list --enabled` to verify active APIs.
Verifying existing configuration avoids redundant operational calls and establishes baseline state.
3
Enable the target API service.
Run `gcloud services enable secretmanager.googleapis.com`.
This enables the service API in Service Usage for the selected project.
4
Verify post-enablement API status.
Run `gcloud services list --enabled --filter="NAME:secretmanager.googleapis.com"` to verify output.
Confirmation validates that the service endpoint is active and ready for resource consumption.

Key Concept

Standard operational workflow for managing and enabling Google Cloud service APIs using the gcloud CLI tool.
Question 23Question →

A site reliability engineering team needs to enforce automated cost controls that disable billing or stop project resources when a project exceeds $10,000 in monthly spending. What is the correct sequence of steps required to configure programmatic budget notifications using Google Cloud services?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first create the Cloud Pub/Sub topic, second deploy the Cloud Function subscribed to that Pub/Sub topic, third create the Cloud Billing budget scoped to the project, and fourth connect the Pub/Sub topic under the budget's programmatic notification settings.
To build an automated budget capping system, the messaging endpoint (Cloud Pub/Sub topic) must be created first. Next, the serverless handler (Cloud Function) is deployed and configured to trigger on messages from that Pub/Sub topic. Then, the Cloud Billing budget is created with the desired spending limits. Finally, the Pub/Sub topic is linked to the budget under the manage notification actions, establishing the workflow where budget threshold events trigger automated code execution.

Step-by-Step Solution

1
Provision Pub/Sub infrastructure
A Cloud Pub/Sub topic exists to capture budget alert events.
Pub/Sub acts as the decoupled messaging bus between Cloud Billing and automated remediation logic.
2
Deploy programmatic consumer service
A Cloud Function with Cloud IAM permissions to manage project billing or stop instances is deployed and listening to the Pub/Sub topic.
The handler code must be active and bound to the topic before alert messages start publishing.
3
Define budget rule in Cloud Billing
A budget rule with specific monetary amounts ($10,000) and threshold percentages is established.
Establishes the financial boundary and triggers that send alert notifications.
4
Attach Pub/Sub notification action to budget
Cloud Billing streams JSON notification payloads to the topic when spending thresholds are breached.
Connects the financial threshold monitoring to the automated programmatic handler.

Key Concept

Cloud Billing Budgets do not automatically cap spending by default; automated enforcement requires linking a Cloud Billing budget to a Cloud Pub/Sub topic, which triggers serverless logic (such as a Cloud Function or Cloud Run service) to cap resources programmatically.
Question 24Question →

A cloud engineer is tasked with onboarding a new telemetry analytics team into an existing Google Cloud Organization. The engineer must establish an isolated resource hierarchy branch, enable resource consumption, and delegate administrative access following Google Cloud recommended practices. Arrange the following administrative steps in the correct operational sequence from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Create the environment folder under the Organization node, 2) Provision the new Cloud Project inside that folder, 3) Link an active Cloud Billing Account to the project, and 4) Grant predefined IAM roles to the engineering team at the project level.
The workflow follows logical GCP dependency requirements: the parent Folder must be provisioned first within the Organization hierarchy; the Project is then created as a child of that Folder; the Billing Account is attached to the Project to allow compute resource allocation; and finally, IAM role bindings are configured on the initialized Project resource to grant appropriate team access.

Step-by-Step Solution

1
Execute `gcloud resource-manager folders create` specifying the Organization ID as the parent.
Establishes the container folder within the organization hierarchy.
Projects require a designated parent node (Organization or Folder) during creation.
2
Execute `gcloud projects create` specifying the newly created folder ID as the `--folder` flag.
Creates the project resource within the folder hierarchy.
The project must exist before billing can be linked or IAM policies attached.
3
Execute `gcloud billing projects link` with the project ID and billing account ID.
Associates the project with an active billing account.
Enables paid service resource provisioning within the newly created project.
4
Execute `gcloud projects add-iam-policy-binding` to assign predefined roles to the team group.
Delegates access permissions to team members.
Applies principle of least privilege access control to the operational project.

Key Concept

Resource Hierarchy Construction and Project Lifecycle Management
Estimated Time:1m 30s
Question 25Question →

Your organization needs to grant an external audit team read-only access to inspect IAM policy bindings across all Google Cloud projects contained within a specific Folder named 'Finance-Workloads'. To strictly enforce the principle of least privilege, you must avoid primitive roles or overly permissive predefined roles by defining a custom IAM role with only the `resourcemanager.projects.getIamPolicy` permission at the folder level and assigning it to the auditors' Google Group via the `gcloud` CLI. In what exact order should you execute the configuration and command-line steps to implement this security control?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations is: first, author the custom IAM role YAML configuration file locally; second, execute the gcloud role creation command targeting the folder scope; third, attach the newly created folder-scoped role to the auditors' Google Group at the folder level; fourth, validate the effective policy inheritance down to all child projects.
The sequence follows Google Cloud IAM best practices: first defining the custom role manifest locally, instantiating the role at the folder scope via gcloud, binding the instantiated role to the group principal at the folder scope to leverage resource hierarchy inheritance, and finally analyzing effective policy inheritance.

Step-by-Step Solution

1
Define the custom role specification file locally
A valid YAML configuration file containing the `resourcemanager.projects.getIamPolicy` permission is generated.
The gcloud CLI requires a structured definition file when creating custom IAM roles containing discrete permission arrays.
2
Create the custom IAM role at the folder hierarchy node
The custom IAM role resource `folders/FOLDER_ID/roles/customIamPolicyAuditor` is created.
Roles must exist at a specific parent scope (Organization or Folder) before they can be referenced in policy bindings.
3
Add an IAM policy binding on the target folder
The auditor group is granted the folder-scoped custom IAM role.
Binding the role at the folder node allows permissions to automatically inherit down to all contained Cloud projects.
4
Analyze and verify inherited policy permissions
Confirmed effective permissions for auditors across all child project resources without over-granting access.
Verification ensures that least-privilege compliance is achieved and that policy inheritance functions as intended.

Key Concept

Custom IAM Role Creation and Folder-Level Resource Hierarchy Inheritance
Estimated Time:2m 30s
Question 26Question →

A cloud administrator needs to request a regional Compute Engine N2 CPU quota increase for project `analytics-prod-942` in the `us-east4` region using the Google Cloud Console. What is the correct sequential order of steps required to locate and submit this quota increase request?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with navigating to IAM & Admin > Quotas & System Limits, filtering for the specific service (Compute Engine API), metric (N2 CPUs), and region (us-east4), selecting the matching quota item and clicking Edit Quotas, entering the target limit with a business justification, and finally submitting the request for evaluation.
To submit a quota increase request in Google Cloud, an administrator must follow a precise sequence: navigate to IAM & Admin > Quotas & System Limits to open the quota management dashboard, apply filter criteria (Service, Metric, Location) to target the specific resource, select the item and click Edit Quotas, specify the required new quota limit along with a business justification, and submit the request for review.

Step-by-Step Solution

1
Open Google Cloud Console navigation and go to IAM & Admin > Quotas & System Limits.
Displays the complete inventory of global and regional service quotas associated with the active project.
Quota management tools are centralized under the IAM & Admin section of the Cloud Console.
2
Filter by Service (Compute Engine API), Metric (N2 CPUs), and Location (us-east4).
Narrows the list specifically to the regional N2 CPU quota line item in us-east4.
Resource quotas are granular by service, metric type, and geographic region.
3
Select the target quota line item and click Edit Quotas.
Opens the quota edit panel on the right side of the screen.
Selecting the item unlocks administrative actions for modifying the limit.
4
Specify the new requested limit and input a business description justification.
Prepares the request parameters for validation.
Google Cloud requires justification details to prevent resource exhaustion and verify valid usage scenarios.
5
Click Submit Request.
Dispatches the quota request ticket to GCP automated systems or support personnel.
Finalizes the submission process so the quota evaluation can proceed.

Key Concept

Google Cloud Console Resource Quota Increase Procedure
Estimated Time:2m 0s
Question 27Question →

A cloud engineer needs to expand the primary IPv4 range of an existing subnet in a Google Cloud custom-mode Virtual Private Cloud (VPC) network without causing downtime to running Virtual Machines. Arrange the operational steps in the correct order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order begins with identifying an available contiguous CIDR block that contains the current subnet range without overlapping existing subnets, followed by executing the subnet IP expansion command via gcloud, and concluding with verification of the updated subnet CIDR block.
The proper sequence for expanding a VPC subnet's IP range requires evaluating netmask boundaries to select a non-overlapping contiguous block first, applying the subnet modification command second, and verifying the updated allocation space last.

Step-by-Step Solution

1
Select a valid expanded CIDR block (such as expanding a /24 to a /23 block).
A target prefix size is defined that fully includes the current IP addresses.
Google Cloud VPC subnets can only be expanded to a larger range that encompasses the existing range without overlapping other subnets in the network.
2
Execute the IP expansion command using `gcloud compute networks subnets expand-ip-range` or the GCP Console.
The subnet primary range is modified in-place online without workload disruption.
Subnet expansion is a zero-downtime operation managed dynamically by the GCP control plane.
3
Inspect the subnet properties using `gcloud compute networks subnets describe` or the GCP Console.
Subnet configuration reflects the new netmask and expanded IP pool.
Validation confirms that the operation completed successfully and additional IP addresses are ready for allocation.

Key Concept

VPC Subnet CIDR Range Expansion Workflow
Question 28Question →

A cloud engineer needs to grant an external auditor access to inspect IAM policies for a specific Google Cloud project using the gcloud command-line interface. What is the correct sequence of command steps to authenticate, set the project context, assign the least-privilege predefined IAM role, and verify the assignment?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with authenticating the session, selecting the target project configuration, applying the least-privilege IAM policy binding with gcloud projects add-iam-policy-binding, and finally inspecting the policy with gcloud projects get-iam-policy to verify access.
The workflow follows standard Google Cloud management practices: first establish user identity ('gcloud auth login'), target the appropriate resource scope ('gcloud config set project'), execute the security policy modification using least-privilege predefined roles ('gcloud projects add-iam-policy-binding'), and finally audit the change ('gcloud projects get-iam-policy').

Step-by-Step Solution

1
Authenticate session credentials.
Obtain user authorization credentials for gcloud.
CLI tools require authentication before attempting resource configuration or IAM policy mutations.
2
Set active project ID context.
Target project set in local CLI profile configuration.
Establishing project context avoids accidentally modifying permissions on the wrong Google Cloud project.
3
Add IAM policy binding with a predefined role.
The role 'roles/iam.securityReviewer' is assigned to 'user:[email protected]'.
Google Cloud best practice requires granting least-privilege predefined roles rather than basic/primitive roles like Owner or Editor.
4
Retrieve project IAM policy.
Returns the updated IAM policy bindings array.
Verifying the IAM policy ensures the binding was persisted successfully without syntax or scope errors.

Key Concept

Managing IAM Roles and Resource Access Permissions via gcloud CLI
Question 29Question →

A cloud engineer needs to set up a BigQuery billing export for detailed cost analysis across an organization. What is the correct sequence of steps to configure this Cloud Billing export?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the BigQuery dataset, granting the Cloud Billing service account the BigQuery Data Editor IAM role on that dataset, navigating to Billing export in the Cloud Billing console, and finally configuring the Detailed usage cost export settings.
Setting up a BigQuery billing export requires preparing the destination environment first. Creating the dataset establishes the target container. Granting the Cloud Billing service account the BigQuery Data Editor role ensures Cloud Billing has permission to create tables and insert billing records. Navigating to the Cloud Billing export console and enabling the Detailed usage cost export with the dataset completes the process.

Step-by-Step Solution

1
Create a BigQuery dataset in the target project.
A destination dataset is created to store billing export tables.
BigQuery requires a dataset to exist before data can be written or targeted by Cloud Billing.
2
Grant the BigQuery Data Editor role on the dataset to the Cloud Billing service account.
The automated Cloud Billing service account receives write authorization.
Without this permission, billing export operations will fail due to lack of write privileges.
3
Navigate to Cloud Billing > Billing export in the GCP Console.
The Cloud Billing export settings interface is displayed.
This is the management location for initiating BigQuery billing data exports.
4
Configure Detailed usage cost export by specifying the project and dataset, then save.
Daily automated billing data export begins streaming to BigQuery.
This links the billing account with the permissioned BigQuery dataset.

Key Concept

BigQuery Billing Export Setup Sequence and Service Account Authorization
Question 30Question →

A cloud engineering team needs to expand the primary IP range of a subnet within an auto-mode Virtual Private Cloud (VPC) network in Google Cloud to accommodate new Compute Engine instances without disrupting existing network traffic. Place the steps required to safely convert the network mode and expand the subnet IP range into the correct sequential order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order begins with verifying that the target expanded CIDR range will not cause IP address overlap, followed by switching the VPC network from auto mode to custom mode using the gcloud compute networks update command. Next, expand the primary subnet range using gcloud compute networks subnets expand-ip-range, and finally verify the updated configuration and deploy workloads into the expanded subnet space.
Expanding a subnet primary IP range in Google Cloud requires IP planning first to avoid collisions, followed by converting an auto-mode VPC to custom mode, executing the gcloud expand-ip-range command, and finally verifying the change before deploying workloads.

Step-by-Step Solution

1
Perform IP range planning and overlap checks.
Ensures the prospective enlarged CIDR block does not collide with connected VPN/Interconnect routes or other VPC subnets.
Expanding a subnet into an already routed or overlapping CIDR range breaks routing and network communication.
2
Switch the VPC network mode from auto to custom.
The VPC network transition completes, enabling custom subnet management capabilities.
Google Cloud auto-mode VPC networks have predefined /20 subnets per region that cannot be manually expanded until switched to custom mode.
3
Expand the primary IP range of the target subnet.
The subnet's netmask is broadened (e.g., from /24 to /23), making more IP addresses available.
Subnet expansion can only increase the primary range (reduce prefix length) and must be contiguous with the current starting IP address.
4
Validate the expanded subnet and provision resources.
New Compute Engine instances are successfully assigned IP addresses from the newly expanded range.
Verifying status ensures the operation finished cleanly before launching new production workloads.

Key Concept

Auto-mode to custom-mode VPC conversion and primary IPv4 subnet expansion
Question 31Question →

A cloud administrator needs to delegate authority to a junior engineer to link an unlinked Google Cloud project to an organization's Cloud Billing Account using least-privilege IAM roles. Arrange the steps in the correct chronological order required to grant permissions and complete the linking process.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by identifying the Project ID and Billing Account ID, granting the Billing Account User role on the billing account, granting the Project Billing Manager role on the project, and executing the gcloud billing projects link command.
Linking a project to a billing account requires permissions on two distinct levels in the GCP resource hierarchy: `roles/billing.user` on the Cloud Billing Account and `roles/resourcemanager.projectBillingManager` on the target Project. The workflow proceeds chronologically from identifying resource parameters to granting necessary IAM roles on both scopes, concluding with the CLI invocation to link the project.

Step-by-Step Solution

1
Identify resource parameters
Obtain target Project ID and Cloud Billing Account ID.
Target identifiers are required parameters for granting scoped IAM roles and running gcloud commands.
2
Configure billing account level IAM
Assign `roles/billing.user` to the user on the Cloud Billing Account.
Linking requires permission to use the billing account without granting administrative access over billing settings.
3
Configure project level IAM
Assign `roles/resourcemanager.projectBillingManager` to the user on the target project.
Linking requires permission on the target project to change its billing configuration under least privilege.
4
Execute project linking
Run `gcloud billing projects link` using the engineer's authenticated session.
The CLI operation succeeds because the identity holds required privileges across both resource boundaries.

Key Concept

Least privilege IAM delegation for project billing link configuration
Question 32Question →

A cloud administrator is establishing governance for a newly acquired business unit in Google Cloud. The administrator needs to set up a dedicated hierarchy branch under the organization node, enforce regional deployment boundaries using organization policy constraints, and place both new and existing workloads into this branch. What is the correct sequence of steps to establish this resource hierarchy and governance structure?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is to first create the parent Folder under the Organization node, apply the Organization Policy constraint at the Folder level, create the new workload Project within the Folder, and finally move the existing standalone Project into the Folder.
In Google Cloud resource hierarchy management, structural nodes (Folders) must be created first under the Organization node. Once the container node exists, governance rules such as Organization Policies should be attached at that Folder level so that policy inheritance takes effect. After policy enforcement is established, new projects can be created directly inside the Folder, and existing standalone projects can be migrated into the Folder to inherit the governance constraints.

Step-by-Step Solution

1
Create the parent container (Folder) directly under the Organization node.
Establishes the structural node in the resource hierarchy where policies and child resources will be anchored.
You cannot apply folder-level policies or assign projects to a folder until the folder container itself exists.
2
Apply the Organization Policy constraint to the newly created Folder.
Establishes security and compliance guardrails that automatically propagate down to all child projects via resource hierarchy inheritance.
Setting policies prior to project creation ensures that newly provisioned or migrated workloads immediately comply with corporate governance.
3
Provision the new project inside the configured parent Folder.
The project is initialized directly within the folder governance scope.
Creating the project in the designated folder ensures it inherits the location restrictions defined at the folder level upon creation.
4
Move the existing project into the parent Folder.
The legacy project changes its location in the resource hierarchy and immediately inherits the folder's policy constraints.
Moving an existing project into a folder is performed after policy configuration so that the project instantly aligns with the target folder's active policy state.

Key Concept

Resource hierarchy inheritance and sequential project governance provisioning in Google Cloud.
Question 33Question →

An enterprise is planning a multi-region Google Cloud deployment that connects to an on-premises data center using Cloud Interconnect. The environment must host Google Kubernetes Engine (GKE) clusters using alias IPs and prevent IP address collisions. Sequence the following steps in the correct order to properly plan and implement the Virtual Private Cloud (VPC) network architecture from initial network assessment to hybrid connectivity configuration.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with auditing existing on-premises IP space, followed by creating a custom-mode VPC network, provisioning custom subnets with non-overlapping primary CIDR ranges, configuring secondary CIDR ranges for GKE alias IPs, and finally setting up Cloud Router BGP advertising to the on-premises network.
Proper VPC network planning for enterprise hybrid environments follows a logical sequence: identifying unallocated IP ranges on-premises first, creating a custom-mode VPC network to maintain full subnet control, establishing regional subnets with primary CIDRs, provisioning secondary ranges for GKE cluster alias IPs, and finally advertising the completed CIDRs across BGP over Cloud Interconnect.

Step-by-Step Solution

1
Audit existing on-premises IP space and identify unallocated ranges.
Establishes clear boundaries for GCP IP assignment, avoiding IP address collisions with existing on-premises networks.
VPC planning must begin by identifying available unallocated space prior to defining cloud ranges.
2
Create a custom-mode VPC network.
Disables automatic creation of subnets in every region, providing total control over subnet CIDR block selection.
Auto-mode VPC networks automatically create subnets using fixed 10.128.0.0/910.128.0.0/9 ranges which often overlap with enterprise networks.
3
Define primary IPv4 CIDR blocks for subnets in selected regions.
Subnets are created with tailored, non-overlapping primary IP ranges.
Subnet primary ranges must exist before secondary ranges can be attached.
4
Configure secondary IPv4 CIDR ranges on the subnets for GKE cluster Pods and Services.
Reserves distinct IP ranges attached to the subnets for container networking.
GKE native VPC clusters rely on secondary IP ranges configured on the subnets for pod and service alias IPs.
5
Configure Cloud Router BGP routes to advertise the VPC subnet ranges to on-premises.
Enables two-way dynamic routing between on-premises and GCP workloads.
Dynamic routing propagation must reflect fully configured subnet primary and secondary ranges.

Key Concept

Planning Enterprise Hybrid VPC Networks and Subnets
Estimated Time:2m 0s
Question 34Question →

A DevOps automation principal needs to grant a service account the minimum necessary IAM roles and execute the appropriate gcloud commands to create a new workload project inside a corporate folder and link it to an existing Cloud Billing Account. Arrange the steps in the correct operational sequence from first to last to complete this task under the principle of least privilege.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with granting `roles/resourcemanager.projectCreator` on the target folder, followed by granting `roles/billing.user` on the Cloud Billing Account, creating the project using `gcloud projects create`, and finally linking the billing account using `gcloud billing projects link`.
Permissions must be configured prior to executing CLI commands. First, folder-level project creation rights (`roles/resourcemanager.projectCreator`) and billing account consumption rights (`roles/billing.user`) are established. Second, the project is created under the folder via `gcloud projects create`. Finally, billing is attached via `gcloud billing projects link`.

Step-by-Step Solution

1
Assign folder creation privileges
Service account gains authorization to create projects within the specific folder.
Google Cloud IAM requires permission propagation at the target hierarchy node before resource provisioning commands can succeed.
2
Assign billing authorization privileges
Service account gains authorization to link projects to the specified billing account.
Least-privilege guidelines mandate granting `roles/billing.user` on the billing account rather than broad primitive roles like Owner or Project Billing Manager.
3
Provision the target project
New project ID is created under the specified folder ID.
The project resource must exist before billing association can take place.
4
Associate billing account to project
Project status is updated to enable paid API services and compute resource provisioning.
Linking requires permissions on both the billing account (`roles/billing.user`) and the target project (inherently held by project creation or project management roles).

Key Concept

Configuring least-privilege IAM roles (`roles/resourcemanager.projectCreator` and `roles/billing.user`) and executing the gcloud tool sequence for project creation and billing link association.
Question 35Question →

An Associate Cloud Engineer needs to configure granular access controls for an automated deployment service account by creating a new project-level custom IAM role and granting it to the service account. Which sequence of steps represents the correct procedure to implement this using the gcloud command-line tool?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational order is: First, define the custom role properties in a local YAML configuration file. Second, create the project-level custom role using `gcloud iam roles create`. Third, verify the created role details with `gcloud iam roles describe`. Fourth, assign the custom role to the target service account using `gcloud projects add-iam-policy-binding`.
Creating and applying a custom IAM role requires a strict workflow: first defining the permission schema in a file, creating the role resource at the desired level of the hierarchy using `gcloud iam roles create`, validating the resource via `gcloud iam roles describe`, and lastly modifying the resource's IAM policy binding to attach the role to the principal via `gcloud projects add-iam-policy-binding`.

Step-by-Step Solution

1
Draft the custom role definition file
A structured YAML file containing metadata and exact permission strings (such as `compute.disks.create`).
Google Cloud best practice requires defining granular permissions in a declarative format prior to resource creation.
2
Create the custom IAM role in the GCP project
The custom IAM role is created under the path `projects/[PROJECT_ID]/roles/[ROLE_NAME]`.
The role must exist in the target project's IAM registry before it can be assigned to principals.
3
Inspect and verify the custom role status
Confirmation that the role launch stage is active and contains the expected permissions.
Verifying role configuration ensures no typos or missing permissions exist before applying the role to production service accounts.
4
Bind the custom role to the service account principal
An updated IAM policy for the project granting the service account access.
Role creation and role assignment are separate IAM operations; the binding step applies the role to the identity.

Key Concept

Custom IAM Role Creation and Policy Binding Lifecycle
Question 36Question →

A cloud engineering team is planning to expand the primary IP address range of an active custom-mode Virtual Private Cloud (VPC) subnet connected to an on-premises data center via Cloud Router using BGP. What is the correct sequence of steps the team must perform to safely plan, execute, and propagate this subnet expansion?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct procedural order begins with auditing contiguous IP space across hybrid networks to prevent IP collisions, validating GCP subnet expansion constraints (prefix length reduction only without shifting base IP), performing the subnet expansion in GCP, and finally updating Cloud Router BGP custom route advertisements to inform on-premises networks.
The sequence follows the required architectural workflow: auditing hybrid IP space first to prevent overlap, verifying GCP netmask expansion rules, modifying the VPC subnet resource, and updating BGP routing advertisements on Cloud Router to complete hybrid connectivity.

Step-by-Step Solution

1
Audit contiguous IP address space across all interconnected environments.
Ensures the expanded block does not overlap with existing subnets, GKE secondary ranges, or on-premises CIDR ranges.
GCP VPC subnets require contiguous unallocated space to expand. Overlapping IP space causes routing failures and IP collisions.
2
Validate the proposed CIDR change against GCP VPC expansion rules.
Confirms the target prefix length is smaller than the current prefix length (e.g., /23/23 expanded to /21/21).
GCP subnets cannot be shrunk, and the network starting address cannot be changed during an expansion.
3
Execute the primary subnet range expansion in GCP.
Modifies the subnet's netmask in the GCP control plane without downtime for existing instances.
Applies the configuration change to the target subnet resource in Google Cloud.
4
Update Cloud Router custom route advertisements.
On-premises BGP routers receive updated prefix announcements covering the newly added IP addresses.
Ensures full bi-directional reachability between on-premises hosts and newly provisioned workloads in the expanded IP range.

Key Concept

Planning and executing non-disruptive primary subnet CIDR expansions in hybrid VPC topologies
Question 37Question →

You need to deploy a containerized application to a newly provisioned Google Kubernetes Engine (GKE) cluster using Google Cloud CLI and `kubectl`. Place the following administrative and deployment steps in the correct chronological sequence from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Set the active GCP project context via gcloud, 2) Fetch GKE cluster authentication credentials into kubeconfig via get-credentials, 3) Submit the application deployment manifest via kubectl apply, and 4) Verify pod execution state using kubectl get pods.
The correct operational workflow requires specifying the active GCP project first, fetching the Kubernetes API credentials for the target cluster into `kubeconfig` second, applying the YAML deployment specification third, and verifying workload execution fourth.

Step-by-Step Solution

1
Select the active Google Cloud project context.
Ensures all subsequent gcloud commands target the correct project resources.
Setting the project context prevents accidentally interacting with resources in a different project.
2
Generate local kubeconfig authentication credentials using `gcloud container clusters get-credentials`.
Populates local API endpoint address and authentication certificates into `~/.kube/config`.
Without fetching cluster credentials, `kubectl` commands cannot authenticate to the GKE control plane.
3
Execute `kubectl apply -f deployment.yaml`.
Submits the Deployment manifest definition to the GKE Kubernetes API server.
The API server creates the Deployment, ReplicaSet, and Pod objects on worker nodes.
4
Execute `kubectl get pods` to inspect pod state.
Returns current pod status (e.g., Running, ContainerCreating, CrashLoopBackOff).
Verification confirms whether the containers pull successfully and start without errors.

Key Concept

GKE Workload Deployment Workflow
Question 38Question →

You need to deploy a containerized web application to an existing Google Kubernetes Engine (GKE) cluster from a freshly provisioned administrator workstation. Arrange the following steps in the correct sequential order from first to last to establish cluster access and deploy the application.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct deployment sequence begins with setting the target GCP project ID, fetching the GKE cluster credentials to populate kubeconfig, applying the Kubernetes manifest file, and finally checking the pod execution status.
To interact with a GKE cluster from a command line environment, the administrator must first configure the active GCP project context and fetch the cluster credentials into the local `kubeconfig` file using `gcloud container clusters get-credentials`. Once authentication context is established, `kubectl apply` creates the workload resources, followed by `kubectl get pods` to verify pod startup.

Step-by-Step Solution

1
Configure the GCP project context
The local `gcloud` CLI environment targets the correct Google Cloud project.
Ensures cluster credentials queries target the project where the GKE cluster resides.
2
Generate kubeconfig authentication entries
Local `kubeconfig` file is updated with cluster endpoints and authentication tokens.
`kubectl` requires valid cluster context and credentials to authenticate calls to the GKE control plane.
3
Apply the Deployment manifest
The GKE control plane schedules and provisions the requested Deployment and Pod objects.
Instantiates the workload resources defined in the configuration file onto cluster worker nodes.
4
Inspect Pod execution status
The current lifecycle state (such as `Running` or `CrashLoopBackOff`) of the workload pods is displayed.
Confirms whether the containerized application started successfully without configuration or image retrieval errors.

Key Concept

GKE Cluster Credential Setup and Workload Deployment Workflow
Question 39Question →

A cloud administrator is creating a custom-mode Virtual Private Cloud (VPC) network in Google Cloud to support a new internal application. The environment must be configured with an explicitly defined regional subnet and basic ingress firewall rules. In what sequence should the administrator perform these VPC configuration tasks?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the custom-mode VPC network container, followed by provisioning a regional subnet with a specific CIDR range inside that network, and finally configuring firewall rules to control traffic to the subnet.
When configuring networking in Google Cloud using custom mode, you must first initialize the parent VPC network shell without auto-subnets. Next, you explicitly define regional subnets with custom primary IP ranges under that network. Finally, you attach firewall rules to the VPC network to manage traffic access.

Step-by-Step Solution

1
Provision the custom VPC network
A VPC network without auto-generated subnets is established
Custom mode prevents Google Cloud from automatically creating subnets in every region, requiring manual definition.
2
Provision the regional subnet
A specific subnet with a defined primary IP range is created within the VPC
A parent VPC network must exist in order to contain and define subnets.
3
Configure network firewall rules
Traffic rules are applied to the VPC network to secure subnet instances
Firewall rules require an existing network context to evaluate and filter inbound or outbound traffic.

Key Concept

Custom-mode VPC Creation Sequence
Question 40Question →

A cloud operations team is setting up a new administrative management host to manage workloads on a newly provisioned Google Kubernetes Engine (GKE) cluster named `billing-cluster` in region `us-east4`. Arrange the following administrative and operational commands in the exact sequence required to authenticate, establish cluster context, verify cluster connectivity, and deploy a manifest named `billing-deployment.yaml`.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with authenticating the gcloud CLI, followed by executing `gcloud container clusters get-credentials` to generate the local kubeconfig context, running `kubectl get nodes` to verify control plane connectivity, executing `kubectl apply -f billing-deployment.yaml` to apply the workload configuration, and concluding with `kubectl get pods` to confirm successful workload execution.
Deploying workloads to GKE from a new environment requires establishing Cloud IAM identity first, generating cluster connection entries in `kubeconfig` via `gcloud container clusters get-credentials`, testing cluster control plane responsiveness via `kubectl get nodes`, declaring resources via `kubectl apply`, and finally verifying pod runtime status with `kubectl get pods`.

Step-by-Step Solution

1
Authenticate identity with Google Cloud APIs
Active credentials are established for gcloud CLI operations
Google Cloud authentication must precede requesting cluster endpoint certificates.
2
Fetch cluster endpoint and credential info via `gcloud container clusters get-credentials`
Local `~/.kube/config` file is populated with cluster context and auth parameters
`kubectl` relies on `kubeconfig` settings populated by `gcloud container clusters get-credentials` to locate and authenticate against the GKE API server.
3
Validate cluster node reachability with `kubectl get nodes`
Confirmation that the GKE control plane responds and cluster nodes report `Ready` state
Testing API connectivity prior to deployment isolates authentication or network issues from manifest configuration errors.
4
Deploy workload manifest using `kubectl apply -f billing-deployment.yaml`
Kubernetes objects defined in the manifest are created or updated on the cluster
`kubectl apply` sends the desired state declaration to the GKE control plane.
5
Monitor container status with `kubectl get pods`
Verification that pods transition from `ContainerCreating` to `Running` state
Post-deployment inspection ensures image pull, scheduling, and health check steps complete successfully.

Key Concept

Sequential lifecycle management for GKE cluster access and workload deployment
PreviousPage 2 / 14Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin