All practice questions

1591 questions

All types1,591 Multiple choice816 Multiple select491 Numeric12 Matching10 Ordering262

A cloud engineer is configuring customer-managed encryption keys (CMEK) in Google Cloud KMS for a sensitive Cloud Storage bucket residing in the us-central1 region. The organization requires strict separation of duties: security administrators must manage keys and IAM policies without being able to encrypt or decrypt data, whereas the Cloud Storage service account requires permissions solely to perform cryptographic encryption and decryption operations. Additionally, an operator asks to permanently delete an outdated Cloud KMS Key Ring to clean up resources. Which configuration correctly satisfies these requirements while adhering to Google Cloud KMS operational capabilities?

Grant security administrators the Cloud KMS Admin role, assign the Cloud KMS CryptoKey Encrypter/Decrypter role to the service account on the key, and explain that Key Rings cannot be deleted once created in Cloud KMS.

Grant security administrators the Cloud KMS Admin role, assign the Cloud KMS CryptoKey Encrypter/Decrypter role to the service account, and run a gcloud command to immediately delete the outdated Key Ring and its keys.

Grant security administrators the primitive Editor role for full Cloud KMS management capability, and assign the Cloud KMS CryptoKey Encrypter/Decrypter role to the Cloud Storage service account.

Assign the Cloud KMS CryptoKey Encrypter/Decrypter role at the Organization level to ensure all service accounts inherit key access, and assign the Owner role to security administrators to oversee key management.

Show answer & explanation

Answer: Grant security administrators the Cloud KMS Admin role, assign the Cloud KMS CryptoKey Encrypter/Decrypter role to the service account on the key, and explain that Key Rings cannot be deleted once created in Cloud KMS.

Answer

Assign the Cloud KMS Admin role to security administrators, grant the Cloud KMS CryptoKey Encrypter/Decrypter role to the service account, and explain that Key Rings cannot be deleted once created in Cloud KMS.

Separation of duties in Cloud KMS is enforced by combining predefined roles. The Cloud KMS Admin role permits management of keys and IAM policies without granting encrypt/decrypt data access. The Cloud KMS CryptoKey Encrypter/Decrypter role allows workload service accounts to perform cryptographic operations on data. Additionally, Google Cloud KMS enforces immutability for Key Rings and CryptoKeys—they cannot be deleted once created.

Step-by-Step Solution

Evaluate separation of duties for IAM roles

Cloud KMS Admin (`roles/cloudkms.admin`) allows managing key rings, keys, and IAM policies, but explicitly lacks permissions to encrypt or decrypt data (`cloudkms.cryptoKeyVersions.useToEncrypt`/`useToDecrypt`), ensuring administrative duties are isolated from data access.

Security policy requires administrators to manage keys without being capable of viewing or decrypting payload data.

Assign cryptographic permissions to the workload service account

The Cloud KMS CryptoKey Encrypter/Decrypter role (`roles/cloudkms.cryptoKeyEncrypterDecrypter`) gives the Cloud Storage service account necessary rights to use the key for CMEK operations without granting administrative access.

Service accounts integrating with CMEK require explicit permission to perform cryptographic operations.

Analyze key ring lifecycle operations and limitations

Cloud KMS resources, specifically Key Rings and CryptoKeys, are permanent entities once created to prevent data loss and ensure audit trail integrity; they cannot be deleted.

Google Cloud KMS design mandates that key names and key ring resource paths remain permanent in GCP project history.

Key Concept

Cloud KMS Separation of Duties and Key Lifecycle Governance

Question 22Question →

A cloud security engineer is tasking a DevOps team with deploying an automated monitoring agent on a new Google Compute Engine VM instance. The deployment must strictly adhere to Google Cloud security best practices of least privilege and secure service account management. Arrange the following administrative gcloud CLI and IAM setup steps in the correct operational sequence required to create, configure, delegate access for, and attach the custom service account.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: First, create the custom service account using `gcloud iam service-accounts create`. Second, assign the predefined role (`roles/monitoring.metricWriter`) to the service account at the project level using `gcloud projects add-iam-policy-binding`. Third, grant the provisioning user the `roles/iam.serviceAccountUser` role directly on the service account via `gcloud iam service-accounts add-iam-policy-binding`. Fourth, create the Compute Engine VM instance specifying `--service-account` with the service account email via `gcloud compute instances create`.

Provisioning a secure Compute Engine workload requires establishing the service account identity first (`gcloud iam service-accounts create`). Next, granting least-privilege predefined permissions to the service account (`gcloud projects add-iam-policy-binding`) establishes what the workload can do. Then, authorizing the deploying user to use the service account (`roles/iam.serviceAccountUser` via `gcloud iam service-accounts add-iam-policy-binding`) allows resource attachment. Finally, initiating VM creation with `--service-account` attaches the identity to the instance.

Step-by-Step Solution

Create the Service Account identity

A non-human service account identity `ops-monitor-sa@PROJECT_ID.iam.gserviceaccount.com` is provisioned.

IAM roles cannot be assigned to an identity that does not yet exist in Google Cloud IAM.

Assign predefined IAM role to the Service Account

The service account gains authorization to write monitoring metrics to Google Cloud Monitoring.

Granting least-privilege predefined roles directly to the workload service account ensures strict access control before deployment.

Grant Service Account User permission to the deploying entity

The DevOps engineer receives authorization to attach the service account to compute resources.

Compute Engine instance creation requires the user executing the command to have `iam.serviceAccounts.actAs` permission, provided by `roles/iam.serviceAccountUser` on the targeted service account.

Attach the Service Account during instance creation

The VM instance is created with the dedicated service account attached, avoiding static service account key exports.

Attaching the service account allows applications running on the instance to access Google Cloud APIs securely through the internal metadata server.

Key Concept

Creating and attaching custom service accounts to Compute Engine instances following least-privilege IAM configuration and ServiceAccountUser role delegation.

Estimated Time:2m 0s

Question 23Question →

A cloud administrator manages resource constraints across an enterprise Google Cloud hierarchy. An Organization Policy using the Boolean constraint constraints/compute.vmCanIpForward is set to Enforced at the Analytics folder level to prevent virtual machines from enabling IP forwarding. A specific workload inside this folder, located in the Network-Appliance project, requires a virtual machine to act as a router with IP forwarding enabled. How should the administrator configure the environment to allow IP forwarding specifically for the Network-Appliance project while maintaining the constraint for all other projects in the folder?

Override the inherited policy by configuring the constraints/compute.vmCanIpForward constraint to Enforced: Off specifically at the Network-Appliance project level.

Grant the Compute Admin (roles/compute.admin) IAM role to the service account in the Network-Appliance project so it can bypass the folder Organization Policy.

Assign the primitive Owner role on the Network-Appliance project to override inherited folder constraints.

Create an IAM Deny policy at the Analytics folder level blocking compute.instances.create and add an IAM policy binding exception for the Network-Appliance project.

Show answer & explanation

Answer: Override the inherited policy by configuring the constraints/compute.vmCanIpForward constraint to Enforced: Off specifically at the Network-Appliance project level.

Answer

Override the inherited policy by setting the constraints/compute.vmCanIpForward Organization Policy constraint to Enforced: Off explicitly at the Network-Appliance project level.

Google Cloud Organization Policies evaluate constraints hierarchically. When a parent folder enforces a Boolean constraint such as disabling IP forwarding, all descendant projects inherit that restriction. To create an exception for a single project, an administrator configures an explicit Organization Policy on that project with the Boolean constraint enforcement set to Off (unenforced), which overrides the inherited policy for that project only.

Step-by-Step Solution

Analyze how Organization Policies inherit down the Google Cloud resource hierarchy.

Policies applied at a parent node (Folder) automatically apply to all child nodes (Projects) unless an explicit policy override is configured at the child level.

Hierarchical inheritance ensures consistent guardrails across sub-resources.

Determine the mechanism required to disable a Boolean Organization Policy constraint for a specific sub-resource.

Setting the Boolean constraint enforcement status to Off (false) on the specific target project overrides the inherited Enforced status from the parent folder.

Explicit child node settings take precedence over inherited parent node policies.

Key Concept

Organization Policy Boolean Constraint Inheritance and Explicit Overrides

Estimated Time:1m 30s

Question 24Question →

A software team deployed an application to Compute Engine that processes images uploaded to a Cloud Storage bucket named `media-processing-prod`. The security team recently enabled Uniform Bucket-Level Access on the bucket to meet organizational compliance requirements. Following this change, the application throws an error whenever it attempts to grant fine-grained permissions using object Access Control Lists (ACLs). According to Google Cloud security best practices, which action should the cloud administrator take to resolve the application errors and properly manage access?

Disable Uniform Bucket-Level Access on the bucket and grant per-object ACL access to the application service account.

Update the application logic to rely on IAM permissions and assign the predefined role Storage Object Viewer or Storage Object Admin to the service account at the bucket level.

Grant the primitive Viewer role (roles/viewer) to the application service account at the Google Cloud project level to enable object-level ACL modifications.

Remove bucket-level IAM roles and configure custom IAM denial rules at the individual object path level.

Show answer & explanation

Answer: Update the application logic to rely on IAM permissions and assign the predefined role Storage Object Viewer or Storage Object Admin to the service account at the bucket level.

Answer

Update the application logic to rely on IAM permissions and assign the predefined role Storage Object Viewer or Storage Object Admin to the service account at the bucket level.

Enabling Uniform Bucket-Level Access (UBLA) centralizes access control under Google Cloud IAM and turns off fine-grained Access Control Lists (ACLs) for all objects in the bucket. To grant access properly, applications must rely on bucket-level or project-level IAM bindings using predefined Cloud Storage roles (e.g., Storage Object Viewer or Storage Object User).

Step-by-Step Solution

Identify the cause of the failure

Uniform Bucket-Level Access (UBLA) disables fine-grained object Access Control Lists (ACLs), causing operations that attempt to set or modify object ACLs to fail.

UBLA unifies access control exclusively under Identity and Access Management (IAM).

Remediate application permissions strategy

Refactor application code to stop making ACL modification API calls.

ACL manipulation calls are invalid when UBLA is enforced on the target Cloud Storage bucket.

Apply principle of least privilege using IAM predefined roles

Grant the service account the required predefined role, such as Storage Object Viewer (`roles/storage.objectViewer`), at the bucket level.

Bucket-level IAM role assignment provides consistent access management without relying on deprecated object-level ACLs.

Key Concept

Configuring Storage Access Controls and Uniform Bucket-Level Access

Question 25Question →

An enterprise software team manages multiple environment folders under their Google Cloud organization. In the Staging folder, service account JSON key creation is currently permitted to support legacy integration tests. However, for a newly created high-security project named finance-vault-prod residing inside the Staging folder, security compliance mandates that service account key creation must be blocked completely. Which action should a Cloud Engineer take to enforce this security restriction on finance-vault-prod without modifying the policy settings for other projects in the Staging folder?

Apply the Organization Policy boolean constraint constraints/iam.disableServiceAccountKeyCreation with enforcement set to Enforce directly at the finance-vault-prod project level.

Remove the serviceaccountadmin role at the Staging folder level to prevent users from creating service account keys across all nested projects.

Enable the constraints/iam.disableServiceAccountKeyCreation constraint at the Staging folder level and expect child projects to automatically ignore it unless explicitly re-enabled.

Grant the primitive Viewer role to all project users on finance-vault-prod to restrict service account key generation capabilities.

Show answer & explanation

Answer: Apply the Organization Policy boolean constraint constraints/iam.disableServiceAccountKeyCreation with enforcement set to Enforce directly at the finance-vault-prod project level.

Answer

Apply the Organization Policy boolean constraint constraints/iam.disableServiceAccountKeyCreation with enforcement set to Enforce directly at the finance-vault-prod project level.

In the Google Cloud resource hierarchy, Organization Policies are inherited from top to bottom (Organization → Folder → Project). Applying a constraint directly at the project level allows an administrator to set a specific enforcement rule that applies exclusively to that project, overriding any looser policy settings inherited from its parent folder.

Step-by-Step Solution

Analyze the resource hierarchy and inheritance model

Organization policies applied at lower nodes in the resource hierarchy (such as a specific project) override or narrow policies inherited from parent folders or organization nodes.

Targeted project-level policy application allows specific security controls without impacting sibling projects under the same parent folder.

Select the appropriate constraint type and target node

Configuring constraints/iam.disableServiceAccountKeyCreation to Enforce on the finance-vault-prod project blocks key creation specifically for that project.

This directly fulfills the security requirement while preserving the folder-level configuration for legacy workloads in sibling projects.

Key Concept

Organization Policy inheritance and node-level constraint overrides

Question 26Question →

A cloud security engineer receives an alert that a specific key version of a CryptoKey in Cloud KMS may have been exposed. The security policy dictates that no new data should be encrypted using this compromised key version, but existing backup files encrypted with prior key versions must remain decryptable by authorized service accounts. Additionally, to clean up the project resources, the engineer attempts to remove the parent KeyRing that holds the CryptoKey. Which action correctly fulfills the security requirement while reflecting Cloud KMS resource capabilities?

Disable the compromised CryptoKey version, and acknowledge that Cloud KMS KeyRings and CryptoKeys cannot be deleted once created.

Execute a deletion command on the parent KeyRing resource to permanently remove all associated CryptoKeys and key versions from the GCP project.

Assign the Project Owner primitive role to the service account so it can execute an immediate force-delete on the CryptoKey object.

Revoke the Cloud KMS CryptoKey Encrypter/Decrypter role at the KeyRing level, assuming it overrides the inherited access granted at the Project level.

Show answer & explanation

Answer: Disable the compromised CryptoKey version, and acknowledge that Cloud KMS KeyRings and CryptoKeys cannot be deleted once created.

Answer

Disable the compromised CryptoKey version, and acknowledge that Cloud KMS KeyRings and CryptoKeys cannot be deleted once created.

Disabling a specific CryptoKey version stops it from being used for cryptographic operations. Furthermore, Cloud KMS enforces strict immutability for catalog structure: KeyRings and CryptoKeys cannot be deleted once created.

Step-by-Step Solution

Analyze key lifecycle options in Cloud KMS

Disabling a specific CryptoKeyVersion prevents any future cryptographic operations (encryption/decryption) using that specific version, which addresses the security compromise requirement.

Cloud KMS allows managing individual key versions independently through state transitions (Enabled, Disabled, Scheduled for destruction, Destroyed).

Evaluate resource deletion capabilities in Cloud KMS

Recognize that KeyRings and CryptoKeys are immutable resources in terms of deletion; they cannot be deleted from a GCP project.

Google Cloud KMS intentionally prevents the deletion of KeyRings and CryptoKeys to preserve audit logs, prevent key loss disasters, and ensure cryptographic history remain traceable.

Evaluate IAM policy inheritance

Confirm that IAM roles granted at parent levels (e.g., Project) are inherited downwards and cannot be restricted by child-level revocations.

IAM permissions are purely additive; child resources inherit all access granted at higher levels in the GCP resource hierarchy.

Key Concept

Cloud KMS Key Lifecycle and Resource Immutability

Question 27Question →

An organization is deploying a multi-region workload in a custom-mode Virtual Private Cloud (VPC) network named `analytics-vpc`. Compute Engine virtual machines without external public IP addresses are located in `us-east4` (tagged `db-backend`) and `europe-west1` (tagged `app-frontend`). The security policy requires that `db-backend` instances accept incoming TCP traffic on port 5432 exclusively from `app-frontend` instances. Additionally, all virtual machines must be able to reach Google Cloud service endpoints without being assigned public IP addresses. Which TWO configuration steps are required to implement this architecture? (Select TWO.)

Select all that apply

Enable Private Google Access on the subnets containing the virtual machines.

Assign the IAM primitive role `roles/owner` to the service accounts attached to the instances to automatically grant cross-subnet network access.

Create an ingress firewall rule specifying target tag `db-backend`, source tag `app-frontend`, protocol TCP, and port 5432 with an allow action.

Create an egress firewall rule with a priority number of 10000 to override default implicit deny rules, assuming higher priority numbers take precedence in evaluation.

Show answer & explanation

Answer: Enable Private Google Access on the subnets containing the virtual machines.; Create an ingress firewall rule specifying target tag `db-backend`, source tag `app-frontend`, protocol TCP, and port 5432 with an allow action.

Answer

The two required configuration steps are enabling Private Google Access on the subnets and creating an ingress firewall rule targeting 'db-backend' with source tag 'app-frontend' for TCP port 5432.

Enabling Private Google Access on subnets allows VM instances with only private internal IP addresses to reach Google Cloud APIs and services. Creating an ingress firewall rule with target tag 'db-backend' and source tag 'app-frontend' for TCP port 5432 correctly restricts traffic between the front-end and database instances according to security requirements.

Step-by-Step Solution

Enable Private Google Access at the subnet level

Virtual machine instances without external IP addresses can reach Google APIs and services using internal routes.

By default, instances without external IPs cannot reach public Google service endpoints unless Private Google Access is enabled on their subnet.

Configure an ingress VPC firewall rule using network tags

Only instances tagged with 'app-frontend' are permitted to send TCP traffic on port 5432 to instances tagged with 'db-backend'.

GCP firewall rules evaluate ingress traffic based on target and source tags, ensuring least-privilege network isolation.

Key Concept

VPC Subnet Private Google Access & Firewall Network Tag Rules

Question 28Question →

A cloud administrator needs to configure access for an external automated pipeline running on a self-hosted server so that it can read log files stored in a Cloud Storage bucket named `analytics-logs`. To comply with company security policies, the administrator must set up a dedicated user-managed service account using short-lived credentials via service account impersonation rather than using long-lived exported JSON keys.

Which of the following steps must the administrator take to implement this configuration securely? (Select TWO.)

Select all that apply

Create a user-managed service account within the project housing the Cloud Storage bucket.

Grant the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) on the service account to the external pipeline's authenticated identity.

Generate a downloadable service account JSON key file and upload it to the external self-hosted server environment.

Assign the primitive Editor role (`roles/editor`) to the service account at the project level.

Enable Google Cloud APIs locally on the self-hosted server operating system using system environment flags.

Show answer & explanation

Answer: Create a user-managed service account within the project housing the Cloud Storage bucket.; Grant the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) on the service account to the external pipeline's authenticated identity.

Answer

The administrator must create a user-managed service account in the GCP project hosting the storage bucket, and grant the Service Account Token Creator role on that service account to the external workload's identity.

To grant access via impersonation without static keys, an administrator creates a dedicated user-managed service account in the GCP project and grants the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) on that service account to the calling identity. This allows the calling identity to mint short-lived security tokens dynamically.

Step-by-Step Solution

Provision a user-managed service account in the GCP project where the resources reside.

Establishes a dedicated GCP identity specifically for the external workload.

Dedicated service accounts allow precise role bindings and auditing for specific applications.

Assign the Service Account Token Creator role on the service account to the external identity.

Enables short-lived token generation via IAM service account impersonation.

Short-lived tokens eliminate the security risks associated with static long-lived key exports.

Key Concept

Creating User-Managed Service Accounts & Service Account Impersonation

Estimated Time:1m 30s

Question 29Question →

An organization requires a centralized observability strategy across multiple Google Cloud projects. The compliance team mandates aggregating all Cloud Audit Logs from every project into a single Cloud Storage bucket for long-term retention. Additionally, the operations team needs to collect guest operating system memory utilization telemetry from a fleet of Compute Engine instances and trigger alerts if memory usage exceeds threshold limits. Which TWO steps should the cloud engineer implement to satisfy these operational requirements? (Select TWO.)

Select all that apply

Create an aggregated Log Router sink at the organization level with an inclusion filter for audit logs, designating the centralized Cloud Storage bucket as the sink destination.

Install the Google Cloud Ops Agent on all Compute Engine instances and configure a Cloud Monitoring alerting policy based on the agent's memory utilization metric.

Install the legacy Stackdriver Monitoring agent on the Compute Engine virtual machines to capture guest OS memory metrics.

Create individual Log Router sinks in each project and grant the Primitive Owner role to the sink writer service account on the destination Cloud Storage bucket.

Show answer & explanation

Answer: Create an aggregated Log Router sink at the organization level with an inclusion filter for audit logs, designating the centralized Cloud Storage bucket as the sink destination.; Install the Google Cloud Ops Agent on all Compute Engine instances and configure a Cloud Monitoring alerting policy based on the agent's memory utilization metric.

Answer

To meet both compliance and telemetry requirements, the engineer must create an aggregated Log Router sink at the organization level targeting the centralized Cloud Storage bucket, and install the Google Cloud Ops Agent on Compute Engine instances to collect memory metrics for alerting policies.

The solution requires two distinct actions: organization-level log routing and guest OS metric collection. An aggregated Log Router sink configured at the organization node automatically captures audit logs from all underlying projects into a single Cloud Storage bucket. Meanwhile, guest OS memory usage is not visible to the hypervisor by default, so installing the Google Cloud Ops Agent on the virtual machines is required to send memory metrics to Cloud Monitoring for alerting.

Step-by-Step Solution

Configure centralized audit log aggregation

An aggregated Log Router sink at the organization scope captures audit logs from all current and future projects and routes them to Cloud Storage.

Organization-level aggregated sinks remove the maintenance overhead of configuring individual sinks per project.

Deploy telemetry agent for OS-level metrics

The Ops Agent collects system metrics such as RAM utilization from inside the virtual machine operating system.

Hypervisor-level telemetry cannot inspect guest memory usage without an in-guest agent.

Set up alerting policies in Cloud Monitoring

Alerting policies monitor the Ops Agent memory utilization metric and trigger notifications when the specified threshold is exceeded.

Cloud Monitoring alerting policies actively notify operations teams when telemetry metrics cross predefined operational boundaries.

Key Concept

Centralized Log Router Sinks and Ops Agent Telemetry Collection

Question 30Question →

An enterprise organization is migrating a legacy batch processing and simulation application to Google Cloud Compute Engine. The application operates continuously 24/7 as a steady-state workload and requires a non-standard resource ratio of 1 vCPU to 8 GB of RAM to prevent paying for unneeded compute processing power. Furthermore, the application performs synchronous state writes to attached disks and cannot tolerate abrupt or ungraceful instance terminations. The infrastructure team must minimize total cost of ownership over a 3-year horizon while ensuring full operational stability and exact resource fit. Which compute planning strategy best meets these requirements?

Provision N2 custom machine types configured with a 1 vCPU to 8 GB RAM ratio, and purchase 3-year resource-based Committed Use Discounts (CUDs) for the baseline vCPU and memory capacity.

Provision Spot VMs configured with N2 custom machine types with 1 vCPU to 8 GB RAM to leverage up to 90% cost savings compared to standard compute pricing.

Migrate the workload to a Google Kubernetes Engine (GKE) Autopilot cluster and configure custom node pools with high-memory machine configurations under 3-year Committed Use Discounts.

Deploy the application onto Cloud Run as a long-running service with custom CPU and memory limits, applying Sustained Use Discounts to optimize 24/7 execution costs.

Show answer & explanation

Answer: Provision N2 custom machine types configured with a 1 vCPU to 8 GB RAM ratio, and purchase 3-year resource-based Committed Use Discounts (CUDs) for the baseline vCPU and memory capacity.

Answer

Provision N2 custom machine types configured with a 1 vCPU to 8 GB RAM ratio, and purchase 3-year resource-based Committed Use Discounts (CUDs) for the baseline vCPU and memory capacity.

The correct strategy leverages N2 custom machine types to precisely fit the required 1 vCPU to 8 GB RAM ratio without over-provisioning unused vCPUs. Pairing this configuration with 3-year resource-based Committed Use Discounts (CUDs) yields the lowest cost for a steady-state 24/7 workload while guaranteeing VM availability and persistent disk statefulness.

Step-by-Step Solution

Analyze workload resource ratio requirements.

Standard predefined machine types offer specific vCPU-to-RAM ratios (e.g., standard is 1:4, highmem is 1:8). Custom machine types (such as N2 custom) permit precise specification of vCPU and RAM allocations to eliminate wasted compute costs.

Matching exact resource needs requires custom machine configuration when standard ratios do not fit.

Evaluate fault tolerance and availability needs.

The application is stateful and cannot sustain ungraceful terminations, which disqualifies Spot/Preemptible VMs despite their deep discounts.

Spot instances offer no availability SLA and can be reclaimed with a 30-second notification.

Determine optimal pricing model for 24/7 steady-state long-term execution.

For a 24/7 baseline workload running continuously over a 3-year horizon, purchasing resource-based Committed Use Discounts (CUDs) provides the highest guaranteed discount rate.

CUDs commit to a specific vCPU and memory footprint over 1 or 3 years in exchange for significant cost reductions without operational risk.

Key Concept

Compute Engine Resource Planning and Machine Type Customization

Estimated Time:2m 0s

Question 31Question →

A financial analytics firm is planning the compute deployment on Google Compute Engine for two distinct workloads:

1. Workload 1: A stateless Monte Carlo risk simulation engine that runs overnight batch jobs. The application is highly fault-tolerant and saves state checkpoints every 5 minutes.
2. Workload 2: A core customer backend service operating continuous 24/7 traffic with precise memory demands requiring 8 vCPUs and 52 GB of RAM to prevent memory spilling.

Which TWO machine type selection and provisioning strategies should the Cloud Engineer implement to optimize cost and performance for these workloads? (Select TWO answers.)

Select all that apply

Provision Workload 1 using Spot Virtual Machines (Spot VMs) to obtain deep discounts for fault-tolerant, interruptible batch processing.

Configure Workload 2 on an N2 custom machine type with 8 vCPUs and 52 GB RAM, and purchase a 1-year or 3-year Committed Use Discount (CUD) for predictable resource usage.

Provision Workload 2 on Spot VMs within an auto-healing Managed Instance Group (MIG) to maximize cost savings while relying on auto-healing for 24/7 availability.

Rely solely on automatic Sustained Use Discounts (SUDs) instead of Committed Use Discounts (CUDs) for Workload 2 to obtain the maximum possible financial discount for continuous execution.

Show answer & explanation

Answer: Provision Workload 1 using Spot Virtual Machines (Spot VMs) to obtain deep discounts for fault-tolerant, interruptible batch processing.; Configure Workload 2 on an N2 custom machine type with 8 vCPUs and 52 GB RAM, and purchase a 1-year or 3-year Committed Use Discount (CUD) for predictable resource usage.

Answer

The Cloud Engineer should provision Workload 1 using Spot VMs for cost-effective batch execution, and deploy Workload 2 on a custom N2 machine type (8 vCPUs, 52 GB RAM) backed by Committed Use Discounts (CUDs).

Stateless, checkpointed batch jobs are perfectly suited for Spot VMs because they can tolerate interruptions in exchange for massive price reductions. Meanwhile, 24/7 production workloads with precise CPU-to-memory needs benefit from custom machine types to avoid over-provisioning, paired with Committed Use Discounts to secure the maximum possible savings on predictable baseline usage.

Step-by-Step Solution

Analyze the requirements for Workload 1

Workload 1 is stateless, checkpointed, and runs batch operations overnight. These characteristics make it ideal for Spot VMs, which offer deep discounts in exchange for preemptibility.

Fault-tolerant batch jobs do not require continuous SLA guarantees and can resume work after preemptions.

Analyze the requirements for Workload 2

Workload 2 requires custom resource sizing (8 vCPUs, 52 GB RAM) and continuous 24/7 operation.

Standard machine types (such as n2-standard-8 with 32 GB RAM or n2-highmem-8 with 64 GB RAM) would either lack sufficient RAM or waste paid capacity. Custom machine types fit the exact workload requirements.

Determine the optimal pricing model for continuous baseline usage

Purchasing a 1-year or 3-year Committed Use Discount (CUD) provides significantly higher cost reductions than relying on automatic Sustained Use Discounts.

CUDs commit to resource usage for 1 or 3 years in exchange for maximum predictable pricing reductions on baseline compute.

Key Concept

Compute Engine Machine Type Selection and Pricing Model Optimization

Question 32Question →

An organization is designing a high-throughput video processing service on Compute Engine. The processing application is stateless, fault-tolerant, and designed to auto-resume from checkpoints if interrupted. Benchmark testing indicates that each processing worker node performs optimally when allocated exactly $14\text{ vCPUs}$ and $28\text{ GB}$ of RAM. Standard predefined machine types with $14\text{ vCPUs}$ are unavailable, and larger predefined instances would result in significant unused vCPU and memory capacity. Which TWO architectural and provisioning strategies should the cloud engineering team select to optimize cost and resource utilization? (Select TWO.)

Select all that apply

Configure Custom Machine Types specifying

14\text{ vCPUs}

and

28\text{ GB}

of RAM for the Compute Engine instance templates.

Deploy the worker instances using Spot VMs within a Managed Instance Group (MIG).

Purchase 3-year Committed Use Discounts (CUDs) and apply them directly to the Spot VM instance reservations.

Migrate the processing workers to Cloud Functions to automatically handle multi-core parallel processing without virtual machine management.

Show answer & explanation

Answer: Configure Custom Machine Types specifying $14\text{ vCPUs}$ and $28\text{ GB}$ of RAM for the Compute Engine instance templates.; Deploy the worker instances using Spot VMs within a Managed Instance Group (MIG).

Answer

The team should configure Custom Machine Types with

14\text{ vCPUs}

and

28\text{ GB}

of RAM, and deploy the instances using Spot VMs inside a Managed Instance Group.

The correct strategy involves two steps: First, configuring Custom Machine Types allows provisioning exact custom core counts (

14\text{ vCPUs}

) and memory allocations (

28\text{ GB}

), eliminating the waste of upgrading to a

16\text{-vCPU}

predefined instance. Second, since the workload is stateless and checkpointed, deploying on Spot VMs within a Managed Instance Group yields maximum cost savings while preserving operational resiliency.

Step-by-Step Solution

Analyze resource ratio requirements

The target requirement is

14\text{ vCPUs}

and

28\text{ GB}

of RAM (

2\text{ GB}

per vCPU). Predefined types jump from 8 to 16 vCPUs. Creating a Custom Machine Type avoids paying for unneeded vCPUs and memory.

Custom Machine Types allow customized vCPU and memory combinations in increments allowed by the machine family.

Evaluate workload fault tolerance for cost optimization

Because the video processing workload is stateless, checkpointed, and fault-tolerant, it can handle VM preemptions without data loss.

Spot VMs provide significant cost reductions (60-91%) for fault-tolerant batch workloads.

Key Concept

Compute Engine Custom Machine Types and Spot VM Suitability

Question 33Question →

A financial analytics firm is designing a cost-effective Google Cloud compute environment for two distinct workloads:

1. A nightly batch calculation task that is fully fault-tolerant, can resume from checkpoints if interrupted, requires specific custom OS kernel modules, and runs for 6 hours.
2. An event-driven microservice that receives unpredictable HTTP webhooks throughout the day and requires scaling down to zero instances during idle periods with minimal management overhead.

Which TWO compute configurations should the engineering team select to satisfy these operational and architectural requirements?

Select all that apply

Deploy Compute Engine Spot VM instances configured with a custom VM image for the nightly batch calculation task.

Deploy Cloud Run to host the event-driven microservice receiving unpredictable HTTP webhooks.

Deploy GKE Autopilot clusters to run the nightly batch calculation task with custom kernel modules.

Deploy Cloud Functions (1st gen) to execute the 6-hour nightly batch calculation task.

Provision standard On-Demand Compute Engine instances attached to a 3-year Committed Use Discount for the nightly batch workload.

Show answer & explanation

Answer: Deploy Compute Engine Spot VM instances configured with a custom VM image for the nightly batch calculation task.; Deploy Cloud Run to host the event-driven microservice receiving unpredictable HTTP webhooks.

Answer

Select Compute Engine Spot VMs with custom images for the fault-tolerant batch task requiring custom kernel modules, and select Cloud Run for the HTTP webhook microservice that needs automatic scale-to-zero capabilities.

Compute Engine Spot VMs offer up to 90% cost reduction for fault-tolerant jobs while permitting full OS kernel customization. Cloud Run provides zero-management HTTP container execution with automatic scale-to-zero capabilities.

Step-by-Step Solution

Analyze the workload requirements for the nightly batch calculation.

The task runs for 6 hours, is fault-tolerant/checkpointable, and requires custom OS kernel modules.

Fault-tolerant batch processing aligns with Spot VMs for maximum cost savings, and OS kernel customization requires Compute Engine Virtual Machines where full OS access is permitted.

Analyze the requirements for the event-driven microservice.

The service handles unpredictable HTTP webhooks, requires scaling down to zero when idle, and demands low operational overhead.

Cloud Run natively supports containerized HTTP requests, scales down to zero automatically during idle windows, and abstracts server management.

Evaluate why alternative compute options fail the specified constraints.

GKE Autopilot restricts OS kernel customization; Cloud Functions cannot run 6-hour jobs due to timeout limits; 3-year Committed Use Discounts incur unnecessary continuous costs for intermittent 6-hour daily jobs.

Architectural trade-offs dictate selecting service boundaries matched strictly to statefulness, execution duration, and OS customization level.

Key Concept

Selecting GCP compute services based on OS access requirements, workload fault tolerance, execution time limits, and autoscaling characteristics.

Estimated Time:2m 30s

Question 34Question →

An enterprise telemetry team is designing a serverless architecture on Google Cloud to handle two distinct workload components:

1. An HTTP webhook ingestion endpoint that receives high-concurrency bursty web traffic and depends on a custom compiled C++ shared library binary.
2. An event-driven data transformation pipeline that processes incoming files uploaded to Cloud Storage, where individual file transformation runs take up to 25 minutes to complete.

You need to recommend a serverless compute architecture that minimizes operational overhead while satisfying all technical limits and runtime dependencies. Which TWO architectural decisions should you recommend? (Select TWO answers.)

Select all that apply

Deploy the HTTP webhook ingestion service to Cloud Run using a custom container image configured to handle multiple concurrent requests per instance.

Deploy the 25-minute data transformation workload to Cloud Run triggered asynchronously by Cloud Storage object creation events via Eventarc.

Deploy the HTTP webhook ingestion service to Cloud Functions (2nd gen) using standard zip source code deployment with embedded C++ binary wrappers.

Deploy the 25-minute data transformation workload directly as a Cloud Storage-triggered Cloud Functions (2nd gen) function with its timeout configured to 30 minutes.

Show answer & explanation

Answer: Deploy the HTTP webhook ingestion service to Cloud Run using a custom container image configured to handle multiple concurrent requests per instance.; Deploy the 25-minute data transformation workload to Cloud Run triggered asynchronously by Cloud Storage object creation events via Eventarc.

Answer

The correct architecture uses Cloud Run with a custom container image for the HTTP webhook service to support multi-concurrency and native C++ binary dependencies, and uses Cloud Run triggered via Eventarc for the 25-minute Cloud Storage data transformation pipeline to exceed the 9-minute event-driven function limit.

The design correctly pairs Cloud Run with both requirements: first, Cloud Run accepts custom container images containing custom compiled binary dependencies (like C++) while allowing request concurrency per instance; second, Cloud Run supports request/task timeouts up to 60 minutes when invoked asynchronously via Eventarc for Cloud Storage events, bypassing the 9-minute event timeout restriction of Cloud Functions.

Step-by-Step Solution

Analyze requirement 1 (HTTP webhook with C++ binary dependency and high concurrency)

Cloud Run allows packaging any runtime environment or binary inside a Docker container image and supports up to 1000 concurrent requests per container instance, making it ideal for high-throughput HTTP endpoints with custom system dependencies.

Cloud Functions zip deployments only support standard high-level language runtimes and do not support low-level custom compiled binaries or full OS environment customization.

Analyze requirement 2 (25-minute file processing triggered by Cloud Storage)

Event-driven Cloud Functions (both 1st and 2nd gen) have a hard maximum timeout limit of 9 minutes (540 seconds) for event triggers. Workloads exceeding 9 minutes triggered by Cloud Storage events must run on Cloud Run services or Cloud Run jobs via Eventarc, which support HTTP/event timeouts up to 60 minutes.

Attempting to configure a 30-minute timeout on an event-driven Cloud Function violates GCP platform quota boundaries.

Key Concept

Selecting Cloud Run vs Cloud Functions based on custom binary dependencies, concurrency capabilities, and event-driven timeout boundaries.

Estimated Time:3m 0s

Question 35Question →

An enterprise organization is setting up a centralized governance model in Google Cloud. A financial operations specialist needs to create new GCP projects within a specific organizational folder and associate those newly created projects with the company's master Cloud Billing account. The security policy mandates strict adherence to the principle of least privilege, preventing the user from managing billing account permissions, modifying organization policies, or gaining administrative control over existing projects. Which TWO Identity and Access Management (IAM) roles must be granted to the specialist to enable these actions? Select 2 options.

Select all that apply

Billing Account User (roles/billing.user) on the target Cloud Billing account

Project Creator (roles/resourcemanager.projectCreator) on the target organizational Folder

Billing Account Administrator (roles/billing.admin) on the target Cloud Billing account

Project Billing Manager (roles/billing.projectManager) on the target Cloud Billing account

Owner (roles/owner) on the target organizational Folder

Show answer & explanation

Answer: Billing Account User (roles/billing.user) on the target Cloud Billing account; Project Creator (roles/resourcemanager.projectCreator) on the target organizational Folder

Answer

To allow creating projects and linking them to a billing account under least-privilege access, grant the Billing Account User role on the Cloud Billing account and the Project Creator role on the parent Folder.

Linking a project to a Cloud Billing account requires two sets of rights: project-level permissions (granted automatically upon project creation to the creator) and billing account-level permissions. The Billing Account User role on the billing account grants permission to attach projects to that billing account, while the Project Creator role on the folder provides the ability to create projects within that folder scope.

Step-by-Step Solution

Identify the project creation requirement.

Creating new projects within a specific resource hierarchy container requires the Project Creator role (roles/resourcemanager.projectCreator) bound at the target Folder or Organization level.

This predefined role grants resourcemanager.projects.create permission without exposing broader folder management capabilities.

Identify the billing association requirement.

Linking a GCP project to a billing account requires permissions on both the billing account and the project.

The user automatically becomes Project Owner of newly created projects, giving them project-level billing permissions. To associate the project with the master billing account, they must explicitly hold the Billing Account User role (roles/billing.user) on that billing account.

Verify least-privilege constraints.

Combining Billing Account User on the billing account and Project Creator on the folder fulfills all operational requirements while preventing unauthorized administration.

Broader roles like Billing Account Administrator or primitive Owner roles violate strict security requirements.

Key Concept

Dual IAM Permission Requirement for Project Billing Account Association

Question 36Question →

A cloud administrator is configuring a new organizational folder structure for an enterprise application suite. The central deployment team requires authorization to create new Google Cloud projects inside the 'Payments-Production' folder and link those projects to the organization's central billing account. Furthermore, the organization enforces a constraint at the organization root node restricting external IP addresses on Compute Engine instances.

Which of the following statements regarding GCP resource hierarchy management, IAM permissions, and policy enforcement are correct? (Select TWO.)

Select all that apply

The deployment team requires the Project Creator role on the target folder and the Billing Account User role on the central billing account to successfully create and link projects.

Organization policies inherited from parent nodes enforce restrictive constraints that cannot be bypassed or overridden by granting IAM roles at lower resource hierarchy levels.

Granting the Project Creator role on the parent folder automatically delegates billing linking permissions for any billing account linked to that folder.

Assigning the primitive Owner role to developers at the project level allows them to disable organization policies inherited from parent folders.

To enable project creation and billing linking under least privilege, the deployment team should be granted the primitive Editor role at the Organization root level.

Show answer & explanation

Answer: The deployment team requires the Project Creator role on the target folder and the Billing Account User role on the central billing account to successfully create and link projects.; Organization policies inherited from parent nodes enforce restrictive constraints that cannot be bypassed or overridden by granting IAM roles at lower resource hierarchy levels.

Answer

The correct statements are that project creation and billing linking require permissions on both the parent container (Project Creator role on the folder) and the billing account (Billing Account User role on the billing account), and that organization policies inherited from parent nodes cannot be overridden by granting lower-level IAM roles.

Project creation within a folder container requires the Project Creator role on that folder, and attaching a project to a billing account requires the Billing Account User role on the billing account. In addition, Organization Policy constraints enforced at upper hierarchy levels define absolute configuration limits that IAM role assignments cannot override.

Step-by-Step Solution

Analyze project creation and billing linkage administrative requirements across resource hierarchy levels.

Creating projects inside a specific folder requires project creation permissions scoped to that container, while associating projects with billing requires access permissions on the target billing account resource.

Google Cloud separates IAM permissions for resource hierarchy containers from permissions governing billing account usage.

Evaluate the interaction between IAM permission assignments and Organization Policy inheritance.

Organization Policy constraints set at parent hierarchy nodes (such as the Organization root) establish programmatic guardrails that apply regardless of IAM role grants at project or resource levels.

IAM determines who can perform actions on resources, whereas Organization Policies determine what configurations are allowed across the resource hierarchy.

Apply the principle of least privilege to role selection.

Assigning fine-grained predefined roles (Project Creator on folder, Billing Account User on billing account) fulfills operational needs without granting unnecessary organization-wide broad access.

Primitive roles (Owner, Editor) at the organization level grant excessive access and violate operational security guidelines.

Key Concept

Managing Google Cloud projects, billing account linkage permissions, least privilege roles, and organization policy inheritance rules across the resource hierarchy.

Question 37Question →

A telemetry engineering team is setting up a dedicated workload project named `data-analytics-prod`. The developers need to enable the Cloud Monitoring API (`monitoring.googleapis.com`) and Cloud Logging API (`logging.googleapis.com`) for their services. Additionally, load testing is expected to exceed the default API rate limits during peak operations, requiring quota management. Security policy strictly mandates applying the principle of least privilege without granting broad resource ownership or billing management rights. Which TWO configuration steps should the team take to meet these access control and quota requirements following Google Cloud best practices? (Select TWO answers.)

Select all that apply

Grant the developer team the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin) on the data-analytics-prod project.

Enable the required Cloud APIs inside the central shared infrastructure host project so that child workload projects automatically inherit enabled status.

Submit a quota increase request for the affected API metrics through the IAM & Admin Quotas interface within the data-analytics-prod project.

Grant the developer team the Owner role (roles/owner) at the Organization level to allow developers to bypass default API rate limits without quota requests.

Show answer & explanation

Answer: Grant the developer team the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin) on the data-analytics-prod project.; Submit a quota increase request for the affected API metrics through the IAM & Admin Quotas interface within the data-analytics-prod project.

Answer

The team should grant the Service Usage Admin role on the target project to allow API enablement under least privilege, and submit a quota increase request via the IAM & Admin Quotas interface within the project when default limits are insufficient.

To satisfy least privilege while allowing API enablement, the Service Usage Admin role should be assigned on the target project because it grants permissions to view and enable APIs without granting full control over project assets. In addition, when traffic demands exceed standard API thresholds, a formal quota increase request must be submitted within the target project's Quotas section.

Step-by-Step Solution

Identify the minimum required IAM role for API enablement

Determined that Service Usage Admin (roles/serviceusage.serviceUsageAdmin) grants serviceusage.services.enable permissions on the project.

Primitive roles like Owner or Editor grant excessive broad permissions across all project resources.

Determine the proper location for API enablement and quota requests

APIs and quotas are scoped at the specific project level (data-analytics-prod).

Enabling APIs in parent or host projects does not enable them for workload projects, nor does it raise workload project quotas.

Formulate the correct workflow for capacity bottlenecks

Submit a formal quota increase request in the Cloud Console under IAM & Admin > Quotas for the target project.

API quotas are enforced by Google Cloud and cannot be bypassed merely by increasing administrative IAM privileges.

Key Concept

API enablement using Service Usage Admin and project-level quota increase request workflows

Estimated Time:2m 0s

Question 38Question →

An online gaming company is planning its Google Cloud Compute Engine architecture for two distinct operational workloads: a continuous, low-latency in-memory leaderboard service that runs 24/7 and cannot tolerate sudden terminations, and an overnight batch analytics pipeline that parses telemetry log files, runs for 6 hours, is stateless, and can resume from checkpoints if interrupted. You need to design a compute provisioning strategy that optimizes cost while satisfying the reliability requirements for both workloads. Which TWO compute configuration strategies should you implement?

Select all that apply

Provision the continuous, low-latency leaderboard service using standard Compute Engine instances backed by Committed Use Discounts (CUDs).

Provision the overnight batch analytics pipeline using Spot VMs in a Managed Instance Group (MIG).

Provision the continuous, low-latency leaderboard service using Spot VMs to maximize hourly baseline cost savings.

Combine Sustained Use Discounts (SUDs) with Spot VM instances for the batch processing pipeline to accumulate additional automated pricing reductions.

Show answer & explanation

Answer: Provision the continuous, low-latency leaderboard service using standard Compute Engine instances backed by Committed Use Discounts (CUDs).; Provision the overnight batch analytics pipeline using Spot VMs in a Managed Instance Group (MIG).

Answer

The optimal strategy requires provisioning the 24/7 baseline leaderboard service using standard Compute Engine virtual machines backed by Committed Use Discounts (CUDs), while provisioning the fault-tolerant overnight batch processing pipeline on Spot VMs within a Managed Instance Group (MIG).

For continuous baseline workloads running 24/7, Committed Use Discounts (CUDs) provide guaranteed resource reservation and substantial cost savings without risking preemption. For stateless, fault-tolerant batch jobs that can withstand sudden interruptions, Spot VMs offer the maximum possible pricing discount on Compute Engine.

Step-by-Step Solution

Analyze the operational requirements of the continuous leaderboard workload

Identified as a continuous, 24/7, non-fault-tolerant service requiring high availability.

Workloads with predictable 24/7 uptime requirements qualify for Committed Use Discounts (CUDs) to maximize savings without risking unexpected instance preemption.

Analyze the operational requirements of the overnight batch processing pipeline

Identified as a stateless, fault-tolerant batch workload that runs intermittently and can resume from checkpoints.

Fault-tolerant, stateless batch processing jobs are ideal candidates for Spot VMs, which offer up to 60-91% discounts off standard instance pricing.

Evaluate GCP pricing discount rules and constraints

Confirmed that Spot VMs do not receive Sustained Use Discounts (SUDs) or Committed Use Discounts (CUDs).

Understanding discount exclusivity prevents miscalculating cost savings when planning Compute Engine resource commitments.

Key Concept

Compute Engine Machine Type Selection and Cost Optimization Strategies

Question 39Question →

A logistics platform is evaluating Google Cloud compute options for two application services with distinct operational and cost constraints:

1. Workload X: A stateless, containerized REST API that experiences unpredictable traffic spikes and extended idle periods. It requires automatic scaling down to zero instances to eliminate ongoing infrastructure expenses.
2. Workload Y: A 4-hour batch processing job that analyzes historical GPS telemetry. The job is fault-tolerant, regularly checkpoints its state, and must execute at the lowest possible per-hour compute cost.

Which deployment strategy best meets the requirements for both workloads while minimizing operational overhead and cost?

Deploy Workload X on Cloud Run, and deploy Workload Y on Compute Engine Spot VMs.

Deploy Workload X on Cloud Run, and deploy Workload Y on Cloud Functions.

Deploy Workload X on Compute Engine Spot VMs, and deploy Workload Y on GKE Autopilot.

Deploy Workload X on GKE Standard, and deploy Workload Y on Cloud Run.

Show answer & explanation

Answer: Deploy Workload X on Cloud Run, and deploy Workload Y on Compute Engine Spot VMs.

Answer

Deploy Workload X on Cloud Run, and deploy Workload Y on Compute Engine Spot VMs.

The combination of Cloud Run for the stateless REST API and Compute Engine Spot VMs for the batch job perfectly matches all operational constraints. Cloud Run scales seamlessly to zero during idle periods to eliminate cost, while Spot VMs provide the lowest per-hour compute rates for a long-running, fault-tolerant batch application.

Step-by-Step Solution

Analyze Workload X requirements.

Workload X is a stateless containerized REST API with variable traffic requiring zero-cost scaling during idle periods.

Cloud Run is a fully managed serverless container platform that automatically scales instances based on incoming traffic down to 0 when no requests are received.

Analyze Workload Y requirements.

Workload Y is a long-running (4-hour), batch job that is fault-tolerant and requires maximum cost reduction.

Compute Engine Spot VMs offer unused capacity at deep discounts (up to 90% off standard pricing). Because Workload Y checkpoints state and tolerates preemptions, Spot VMs provide the optimal balance of execution length support and cost efficiency.

Evaluate combined architecture options against constraints.

Cloud Run for Workload X and Compute Engine Spot VMs for Workload Y meets all functional, timing, and pricing criteria.

Alternative options violate serverless execution timeout limits (Cloud Functions/Cloud Run for 4-hour jobs) or introduce unnecessary idle infrastructure costs and availability risks (GKE Standard or Spot VMs for live API traffic).

Key Concept

Selecting GCP compute resources based on workload statefulness, execution duration, scaling characteristics, and fault tolerance.

Estimated Time:2m 0s

Question 40Question →

A financial transaction processing company is planning a new Google Kubernetes Engine (GKE) cluster architecture to host two workloads with contrasting technical requirements. The first workload is a stateful transaction logging engine that requires custom host-level Linux kernel parameters (`sysctl`) tuned on the underlying nodes. The second workload is a large-scale, fault-tolerant batch processing job that can tolerate sudden instance terminations. The DevOps team wants to minimize node compute costs for the batch processing job while ensuring the transaction logging engine runs on nodes with the required kernel modifications. Which cluster architecture design should you recommend?

Provision a GKE Standard cluster containing a dedicated node pool configured with custom sysctl settings for the transaction logging workload, and a separate node pool using Spot VMs for the batch processing workload.

Provision a GKE Autopilot cluster, deploying the transaction logging workload with a privileged DaemonSet to set host kernel parameters, and deploying the batch processing workload as Spot Pods.

Provision a GKE Autopilot cluster utilizing Spot Pods for both the stateful transaction logging workload and the batch processing workload to minimize compute cost and node management overhead.

Provision a GKE Standard cluster with a single node pool comprised of Spot VMs, applying custom sysctl parameters across all nodes to support both workloads within one pool.

Show answer & explanation

Answer: Provision a GKE Standard cluster containing a dedicated node pool configured with custom sysctl settings for the transaction logging workload, and a separate node pool using Spot VMs for the batch processing workload.

Answer

The correct recommendation is to use a GKE Standard cluster configured with multiple node pools. GKE Standard provides full access to node configurations, allowing sysctl kernel parameter customization for the stateful transaction logging workload. Adding a secondary node pool using Spot VMs allows the fault-tolerant batch processing workload to run at significantly reduced costs without risking the stability of the transaction logger.

Step-by-Step Solution

Analyze host OS kernel modification requirements

GKE Standard is required because GKE Autopilot locks down host node operating system configurations and prevents custom node kernel (sysctl) parameter tuning.

Autopilot manages node provisioning and security baseline automatically, restricting low-level host kernel customization.

Evaluate fault tolerance and cost requirements for batch processing

Batch processing is fault-tolerant and stateless, making it ideal for Spot VMs to significantly reduce compute costs.

Spot VMs provide deep discounts in exchange for being preemptible, which suits batch jobs that can resume or restart easily.

Evaluate availability requirements for the stateful transaction logging engine

The stateful logging engine requires standard (on-demand) node pools to prevent sudden node preemptions.

Stateful workloads can suffer data loss or service disruption if placed on preemptible Spot VM instances.

Combine workload requirements into an optimal cluster architecture

A single GKE Standard cluster with multiple heterogeneous node pools (one custom sysctl pool and one Spot VM pool) meets all requirements.

Separate node pools isolate host configurations and pricing models while allowing single-cluster administrative management.

Key Concept

GKE Cluster Planning: Autopilot vs Standard Operational Boundaries & Heterogeneous Node Pool Architecture

PreviousPage 2 / 80Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept