Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 541Question →

A cloud engineer is deploying a new Cloud SQL instance that must be accessible exclusively through private IP addresses within an existing Virtual Private Cloud (VPC) network. Which TWO actions must be completed to successfully configure private IP connectivity for this database instance? (Select TWO answers.)

Select all that apply

Show answer & explanation

Answer: Establish a Private Services Access connection by allocating an internal IP range and peering the VPC network with Google Services.; Specify the target VPC network using the --network flag when creating the instance with gcloud CLI.

Answer

To configure private IP connectivity for Cloud SQL, you must establish a Private Services Access connection (VPC network peering) in your VPC and supply the --network flag referencing your VPC network during instance creation.
Deploying a Cloud SQL instance with private IP requires Private Services Access (which establishes VPC network peering between your VPC and Google's service producer network) and supplying the target VPC network via the --network flag during deployment so an internal IP can be assigned.

Step-by-Step Solution

1
Allocate an IP range and configure Private Services Access
Establishes underlying VPC Peering between the customer VPC network and Google's private service producer network.
Cloud SQL instances with private IP reside in a Google-managed VPC that requires peering to communicate with client VPC resources.
2
Deploy the instance with the --network flag
The Cloud SQL instance receives an internal IP address within the peered VPC network.
The --network flag binds the Cloud SQL deployment to the established Private Services Access connection.

Key Concept

Cloud SQL Private IP and Private Services Access Configuration
Question 542Question →

An e-learning company records live interactive training webinars. For the first 14 days after recording, video files are accessed continuously by students and editors. Between day 15 and day 105, access drops significantly, with files retrieved only occasionally (once every 2 to 3 months) for support audits. Beyond 105 days, files must be retained for 3 years to comply with regulatory requirements and are expected to be accessed less than once per year. You need to configure Object Lifecycle Management on the Google Cloud Storage bucket to minimize total operational, storage, and retrieval costs. Which TWO lifecycle rule transitions should you include in the bucket configuration? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Set a rule to transition objects from Standard to Nearline storage 14 days after creation.; Set a rule to transition objects to Archive storage 105 days after creation.

Answer

The correct lifecycle transitions are moving objects to Nearline storage 14 days after creation and moving objects to Archive storage 105 days after creation.
The correct strategy combines Standard storage for active reads during the first 14 days, transitions to Nearline storage at day 14 for occasional reads over the next 3 months, and finally transitions to Archive storage at day 105 for multi-year regulatory retention.

Step-by-Step Solution

1
Analyze access patterns for the initial period (0 to 14 days).
Frequent continuous access requires Standard storage to avoid data retrieval charges.
Standard storage has zero retrieval costs per GB.
2
Analyze access patterns for the intermediate period (15 to 105 days).
Occasional access once every 2 to 3 months matches Nearline storage guidelines (30-day minimum retention, lower storage cost than Standard).
Transitioning to Nearline at day 14 optimizes monthly storage costs while keeping retrieval fees low for occasional reads.
3
Analyze access patterns for the long-term compliance period (beyond 105 days).
Accessing data less than once per year for 3-year compliance matches Archive storage guidelines.
Archive storage delivers the lowest unit storage price for long-term cold data retention.

Key Concept

Selecting Cloud Storage classes based on access frequency, minimum retention periods, and retrieval fees.
Estimated Time:1m 30s
Question 543Question →

A platform engineer is deploying a containerized microservice to Google Cloud Run in the us-central1 region using the container image us-docker.pkg.dev/corp-apps/prod/account-api:v1. The application inside the container is configured to listen strictly on custom TCP port 5000 and does not automatically detect the default PORT environment variable. The requirement dictates that the service must immediately route 100% of live HTTP traffic to this newly deployed revision while enforcing private access by blocking all unauthenticated invocations. Which gcloud command must the engineer execute to achieve this deployment outcome correctly?

Show answer & explanation

Answer: gcloud run deploy account-api --image=us-docker.pkg.dev/corp-apps/prod/account-api:v1 --port=5000 --no-allow-unauthenticated --region=us-central1

Answer

The correct option is the command executing 'gcloud run deploy account-api --image=us-docker.pkg.dev/corp-apps/prod/account-api:v1 --port=5000 --no-allow-unauthenticated --region=us-central1'.
The correct command uses the --port=5000 flag to configure Cloud Run to forward incoming requests to port 5000 inside the container, includes --no-allow-unauthenticated to enforce strict IAM access control, and allows default 100% traffic assignment to the newly deployed revision.

Step-by-Step Solution

1
Identify the container port configuration requirement for Cloud Run.
By default, Cloud Run sends requests to port 8080. To tell Cloud Run to send requests to custom container port 5000, the --port=5000 flag must be set during deployment.
Setting custom environment variables via --set-env-vars does not update the ingress container port mapping unless the app binary actively reads that variable.
2
Verify authentication and ingress access settings.
The --no-allow-unauthenticated flag ensures that IAM authentication is required and public unauthenticated HTTP access is denied.
Using --allow-unauthenticated opens the service to the public internet, violating security requirements.
3
Verify revision traffic assignment behavior.
Standard gcloud run deploy automatically assigns 100% of incoming traffic to the newly created revision.
Using --no-traffic explicitly creates the revision with 0% traffic allocation, requiring a separate traffic splitting operation.

Key Concept

Cloud Run Custom Container Port Binding and CLI Deployment Flags
Question 544Question →

An operations engineer manages a production Google Kubernetes Engine (GKE) Standard cluster hosting a web application microservice and a background batch analytics workload. To optimize compute costs, the team provisions a new dedicated node pool configured with Spot VMs for the batch analytics workload. However, during initial testing, several web application pods are scheduled onto the Spot VM nodes and experience unexpected disruptions when nodes are reclaimed. Which configuration should the engineer implement to ensure the web application pods are never scheduled onto the Spot VM node pool?

Show answer & explanation

Answer: Apply a node taint to the Spot VM node pool and add corresponding tolerations only to the batch analytics workload Deployment manifest.

Answer

Apply a node taint to the Spot VM node pool and configure corresponding tolerations specifically within the batch analytics workload manifest.
In Kubernetes and GKE operational management, Taints and Tolerations are used to ensure workloads are not scheduled onto inappropriate nodes. Tainting a Spot VM node pool repels all pods that do not explicitly contain a matching toleration. By defining tolerations only on the fault-tolerant batch workload, the scheduler prevents the web application pods from ever being placed on Spot VM nodes.

Step-by-Step Solution

1
Identify the workload isolation requirement
Recognize that web application pods must be repelled from Spot VM nodes to prevent unexpected preemption disruptions.
Spot VMs can be reclaimed by GCP at any time, making them unsuitable for non-fault-tolerant web application pods.
2
Analyze Kubernetes scheduling controls for node repelling
Select Taints and Tolerations as the mechanism to allow nodes to repel set of pods.
Node taints ensure that only pods with matching tolerations can be scheduled on the tainted nodes.
3
Implement the taint and toleration strategy
Taint the Spot VM node pool (e.g., cloud.google.com/gke-spot=true:NoSchedule) and add the toleration exclusively to the batch analytics workload.
Web application pods without this toleration will be rejected by the Kubernetes scheduler when placing pods on Spot nodes.

Key Concept

Workload isolation using GKE Node Taints and Pod Tolerations for Spot VM Node Pools
Question 545Question →

A global financial compliance firm is planning a Google Kubernetes Engine (GKE) cluster architecture to host a sensitive risk-analysis workload. The platform must adhere to the following architectural and security requirements:

• The Kubernetes control plane must be private with its public endpoint disabled, allowing cluster administration solely from authorized corporate on-premises IP ranges via Cloud Interconnect.
• Cluster worker nodes must be provisioned with private IP addresses only, preventing direct inbound internet exposure.
• Pods running on worker nodes require outbound internet access to retrieve external regulatory compliance feeds, but nodes must not be assigned public IP addresses.
• Operational overhead for managing cluster node infrastructure and OS maintenance must be minimized without violating security constraints.

Which GKE cluster architecture and networking configuration should the team implement?

Show answer & explanation

Answer: Deploy a private GKE Autopilot cluster with the control plane public endpoint disabled, enable Master Authorized Networks using the on-premises CIDR blocks, and configure Cloud NAT on the VPC subnetwork.

Answer

Deploy a private GKE Autopilot cluster with the control plane public endpoint disabled, enable Master Authorized Networks using the on-premises CIDR blocks, and configure Cloud NAT on the VPC subnetwork.
A private GKE Autopilot cluster offloads node lifecycle management while enforcing private IP address assignment across all worker nodes. Disabling the public control plane endpoint isolates the API server strictly to internal VPC and peered on-premises networks. Specifying Master Authorized Networks ensures only designated corporate IP ranges over Cloud Interconnect can send commands to the cluster API. Finally, deploying Cloud NAT on the VPC subnetwork provides necessary outbound internet connectivity for pods to download regulatory data feeds without assigning public IPs to worker nodes.

Step-by-Step Solution

1
Evaluate cluster operational model requirements for minimizing node management overhead.
GKE Autopilot automates node provisioning, OS patching, and infrastructure scaling, minimizing operational overhead while adhering to security boundaries.
GKE Autopilot fully manages the underlying worker node infrastructure according to Google Cloud best practices.
2
Determine private cluster endpoint and authorization configuration.
Disabling the control plane public endpoint ensures the API server has only a private IP address within the VPC network. Master Authorized Networks restricts access to specified on-premises CIDR ranges.
This isolates administration traffic so it can only traverse private network connections (such as Cloud Interconnect).
3
Select the appropriate networking service for private node egress to the internet.
Cloud NAT provides Managed Network Address Translation for subnets without public IPs.
Nodes and pods remain on private IP addresses while gaining secure outbound internet access to fetch regulatory compliance data feeds.

Key Concept

GKE Private Cluster Networking and Autopilot Architecture
Question 546Question →

You are tasked with deploying a Python-based microservice to Google Cloud Functions (2nd gen) using the gcloud command-line interface. Arrange the deployment workflow steps into the correct chronological order from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence is: first, enable the required APIs; second, prepare local application files; third, execute the gcloud functions deploy command; fourth, test the deployed HTTPS endpoint.
Deploying serverless workloads on Google Cloud follows a standard linear lifecycle: project API enablement precedes local source code creation, followed by deploying via the gcloud CLI, and concluding with endpoint functional testing.

Step-by-Step Solution

1
Enable project service APIs
Cloud Functions API and Cloud Build API are active and ready to accept requests.
Google Cloud requires required service APIs to be active before accepting deployment commands.
2
Develop code and dependency files
Source files main.py and requirements.txt are saved in the project folder.
Cloud Functions requires local source files to package during deployment.
3
Execute deployment command
The code is uploaded, built, and deployed as a 2nd gen Cloud Function.
Executing gcloud functions deploy triggers Cloud Build to compile and host the revision.
4
Verify service functionality
HTTP response confirms function execution.
Post-deployment validation ensures the endpoint works as expected.

Key Concept

Cloud Functions Deployment Workflow
Question 547Question →

Your organization is establishing a deployment pipeline for a stateless containerized web application using Google Cloud Run in the us-central1 region. The application source code is stored locally and needs to be built into a container image, stored in a managed repository, and deployed to Cloud Run with public unauthenticated access enabled. What is the correct sequence of execution steps to deploy this serverless application using the Google Cloud CLI from start to finish?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps begins with enabling the Cloud Run and Artifact Registry APIs, followed by creating the Artifact Registry Docker repository, then submitting the source code to Cloud Build to build and push the container image, and finally deploying the container image from Artifact Registry to Cloud Run using gcloud run deploy with the --allow-unauthenticated flag.
The deployment of a serverless Cloud Run application follows a strict dependency order: API enablement allows resource management, creating the Artifact Registry repository provides the storage destination, compiling source code via Cloud Build pushes the container image to that repository, and finally running gcloud run deploy references the stored image to deploy the running service.

Step-by-Step Solution

1
Enable required Cloud APIs
Cloud Run and Artifact Registry APIs are active and ready to accept API requests.
Google Cloud service APIs must be enabled prior to creating resources or invoking deployment tools that rely on those APIs.
2
Create Artifact Registry Repository
A regional Docker repository is available in us-central1 to store built container images.
Artifact Registry requires an existing target repository of type Docker before images can be stored.
3
Build and Store Container Image
Cloud Build compiles the source code into a container image and tags/pushes it to Artifact Registry.
Cloud Run requires an accessible container image stored in Artifact Registry (or Container Registry) to instantiate service instances.
4
Deploy Service to Cloud Run
The Cloud Run service is deployed, receives a HTTPS endpoint URL, and permits unauthenticated access.
The gcloud run deploy command provisions the service using the fully qualified Artifact Registry image path.

Key Concept

Serverless Container Deployment Workflow with Cloud Run and Artifact Registry
Question 548Question →

A cloud administration team manages a custom-mode Virtual Private Cloud (VPC) network in Google Cloud. An application subnet in `europe-west3` currently uses the primary IPv4 CIDR range 10.30.15.0/2410.30.15.0/24. Due to increased instance deployment, the team needs to expand the capacity of this subnet to a /23/23 netmask length (512512 IP addresses). The adjacent IP block 10.30.16.0/2410.30.16.0/24 is completely unassigned, while the block 10.30.14.0/2410.30.14.0/24 is actively used by a database subnet in the same VPC network. Which strategy should the team implement to resolve the capacity requirement without causing IP allocation errors?

Show answer & explanation

Answer: Provision a new subnet using a non-overlapping block such as 10.30.16.0/2310.30.16.0/23 and migrate the workloads to the new subnet.

Answer

Provision a new subnet using a non-overlapping block such as 10.30.16.0/2310.30.16.0/23 and migrate the workloads to the new subnet.
When expanding a primary subnet IP range in Google Cloud, the new range must encompass the original range and align to a valid binary CIDR boundary corresponding to the new prefix length. For an odd third octet like 1515 in 10.30.15.0/2410.30.15.0/24, expanding to /23/23 forces the lower boundary back to the even number 1414 (10.30.14.0/2310.30.14.0/23). Because 10.30.14.0/2410.30.14.0/24 is already assigned, GCP will reject the expansion to prevent IP overlap. The only viable path is provisioning a separate, non-overlapping subnet (such as 10.30.16.0/2310.30.16.0/23) and migrating resources.

Step-by-Step Solution

1
Determine the required CIDR boundary for expanding a /24/24 subnet to a /23/23 subnet.
A /23/23 block contains 512512 addresses and must start on an even number in the third octet. For 10.30.15.0/2410.30.15.0/24, the enclosing /23/23 block is 10.30.14.0/2310.30.14.0/23 (10.30.14.010.30.14.0 – 10.30.15.25510.30.15.255).
Google Cloud VPC subnet expansion enforces standard binary CIDR alignment boundaries.
2
Evaluate potential IP range collisions within the existing VPC network.
10.30.14.0/2310.30.14.0/23 includes the IP block 10.30.14.0/2410.30.14.0/24, which is already allocated to an active database subnet.
Subnet ranges in the same VPC network cannot overlap under any circumstances.
3
Select the valid mitigation pattern for constrained subnet expansions.
Direct expansion of 10.30.15.0/2410.30.15.0/24 is impossible. Creating a new contiguous block like 10.30.16.0/2310.30.16.0/23 and re-homing workloads avoids all IP conflicts.
Creating a clean, non-overlapping subnet satisfies capacity needs while complying with VPC expansion constraints.

Key Concept

GCP Subnet Expansion Alignment and Overlap Constraints
Question 549Question →

You are managing Compute Engine resources and need to create a custom image from an existing virtual machine's boot disk and use it to deploy a new virtual machine instance. What is the correct sequence of steps to safely perform this operation?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations is: Stop the running source instance -> Create the custom image from the boot disk -> Deploy the new instance using the custom image -> Restart the source instance.
To create a consistent custom image from a Compute Engine boot disk, the source virtual machine should first be stopped. After the VM stops, the image is created from its boot disk. The new VM instance is then provisioned from the created custom image, and finally the original source VM is restarted.

Step-by-Step Solution

1
Stop the source VM instance.
The source instance enters the TERMINATED state, locking disk modifications.
Creating an image from an active disk can cause data corruption or inconsistent snapshot states.
2
Execute `gcloud compute images create`.
A new reusable custom image is created from the source boot disk.
The custom image encapsulates the OS configuration and applications for future deployments.
3
Execute `gcloud compute instances create` with `--image` pointing to the custom image.
A new Compute Engine VM instance is created with identical configuration and disk content.
New VM instances require an image source for provisioning their boot disks.
4
Start the source VM instance using `gcloud compute instances start`.
The original VM resumes normal operation.
Once image creation completes, the original instance can safely resume serving traffic.

Key Concept

Custom Image Creation and VM Provisioning Workflow
Question 550Question →

An Associate Cloud Engineer is tasked with setting up a new environment for the Finance engineering division under an existing Google Cloud Organization. What is the correct sequence of administrative steps to establish the resource container structure, enable billing, and grant access using least privilege?

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, create the child Project inside the Folder, link the Billing Account to the Project, and finally grant the necessary IAM predefined role at the Folder level for inherited permissions.
The correct order follows standard GCP resource hierarchy provisioning: first build the parent container (Folder) under the Organization node, then create the child resource container (Project) inside the Folder, link the Project to a Cloud Billing Account to permit resource deployment, and finally bind predefined IAM roles at the Folder level to automatically grant permissions to child resources via IAM policy inheritance.

Step-by-Step Solution

1
Create the parent Folder under the Organization node.
Establishes the container boundary in the Google Cloud resource hierarchy.
Projects require a parent container (Organization or Folder) to exist first.
2
Provision the Project within the created Folder.
Creates the project resource container under the folder.
Project creation requires defining its parent folder ID during execution.
3
Link the Project to an active Cloud Billing Account.
Enables resource allocation and billing capabilities for the project.
Google Cloud projects cannot run billable services without a linked billing account.
4
Apply predefined IAM roles at the parent Folder level.
Grants access permissions that inherit down to the child project.
Configuring IAM roles at the parent folder ensures consistent permissions through policy inheritance according to the principle of least privilege.

Key Concept

Google Cloud Resource Hierarchy Provisioning and IAM Policy Inheritance
Question 551Question →

A cloud engineer is preparing an automated deployment script to create and configure a Google Cloud Storage bucket for ingesting real-time telemetry data. According to Google Cloud security and operational best practices, infrastructure must be created first, bucket-level configurations and policies applied next, access control granted third, and data ingestion validated last. In what sequence should the engineer execute these operational steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Provision the Cloud Storage bucket with uniform bucket-level access, 2) Apply the lifecycle management rule configuration file to the bucket, 3) Bind the Storage Object Creator IAM role to the ingestion service account, and 4) Perform a test object upload using `gcloud storage cp` to verify configuration.
The deployment sequence follows standard infrastructure-as-code and cloud operational principles: first provision the core storage resource, next apply bucket configurations and governance rules (lifecycle policies), then establish access security by binding least-privilege IAM roles (`roles/storage.objectCreator`), and finally execute an end-to-end write test with object upload.

Step-by-Step Solution

1
Provision the bucket resource using `gcloud storage buckets create`
The Cloud Storage bucket `gs://telemetry-ingest-logs` exists in `us-east1` with uniform bucket-level access enabled.
You cannot set lifecycle rules, bind IAM roles, or upload objects until the underlying Cloud Storage bucket resource is created.
2
Apply lifecycle rules using `gcloud storage buckets update`
The bucket is configured with automated storage class transition rules prior to data ingestion.
Applying bucket governance and lifecycle management rules immediately after bucket creation guarantees compliance before any data is ingested.
3
Grant application access using `gcloud storage buckets add-iam-policy-binding`
The target service account is assigned `roles/storage.objectCreator` on the bucket.
IAM permissions must be explicitly configured on the ready bucket before applications or service accounts attempt data writes.
4
Verify upload capability using `gcloud storage cp`
Object upload succeeds, confirming end-to-end operational readiness.
Data upload is the final verification step to confirm that bucket setup and IAM authorization are functioning correctly.

Key Concept

Cloud Storage Deployment & Operational Sequencing
Question 552Question →

An e-commerce enterprise is planning its compute architecture on Google Compute Engine for two distinct operational workloads:

1. Core Order API: A mission-critical 24/7 web application requiring continuous uptime and predictable CPU/memory resources without unexpected terminations.
2. Nightly Catalog Indexer: A fault-tolerant batch processing job that runs for 2 hours each night, writes incremental checkpoints to Cloud Storage, and can withstand sudden instance preemption.

Which TWO cost-effective provisioning strategies should the cloud engineer implement? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Purchase 1-year or 3-year Committed Use Discounts (CUDs) for the standard Virtual Machines running the Core Order API.; Use Spot Virtual Machines for the Nightly Catalog Indexer batch processing workload.

Answer

The cloud engineer should purchase Committed Use Discounts for the continuous Core Order API service and utilize Spot VMs for the fault-tolerant Nightly Catalog Indexer batch workload.
For continuous 24/7 mission-critical services that require guaranteed availability, standard VM instances backed by Committed Use Discounts (CUDs) supply significant cost reduction without risk of interruption. Conversely, batch workloads that run briefly each night and checkpoint their state are fault-tolerant and uniquely suited for Spot VMs, which deliver maximum discounts for preemptible capacity.

Step-by-Step Solution

1
Evaluate the uptime and interrupt-tolerance requirement for the Core Order API service.
Because the Core Order API is a continuous 24/7 mission-critical service that cannot tolerate abrupt terminations, standard compute instances backed by 1-year or 3-year Committed Use Discounts (CUDs) provide guaranteed availability with optimized pricing.
CUDs offer high discount rates for predictable long-term usage without sacrificing instance reliability.
2
Evaluate the workload characteristics of the Nightly Catalog Indexer job.
Because the indexing job runs for only 2 hours nightly and writes state checkpoints to Cloud Storage, it is fully fault-tolerant and ideal for Spot VMs.
Spot VMs offer steep cost savings for short-lived, interruptible batch processing workloads.

Key Concept

Planning Compute Engine Machine Types and Pricing Models (CUDs vs Spot VMs vs SUDs)
Question 553Question →

A cloud engineer is tasked with using the Google Cloud Pricing Calculator to estimate monthly infrastructure expenses for two upcoming workloads: a fault-tolerant, stateless batch job pipeline that can tolerate sudden instance terminations, and a long-term compliance archive where exported files are stored for several years and accessed less than once a year. Which combination of service configurations in the Pricing Calculator provides the most accurate and cost-effective estimate for these requirements?

Show answer & explanation

Answer: Configure Compute Engine using Spot VMs for the batch processing workload, and select Archive Storage for the compliance file backups.

Answer

Configure Compute Engine using Spot VMs for the batch processing workload, and select Archive Storage for the compliance file backups.
The combination of Spot VMs and Archive Storage represents the correct choice. Spot instances offer deep discounts for stateless, fault-tolerant batch workloads, while Archive Storage minimizes storage costs for data accessed less than once a year.

Step-by-Step Solution

1
Analyze workload fault tolerance and cost optimization model for compute resources.
Stateless, interruption-tolerant batch workloads are best estimated using Spot VMs to achieve maximum pricing discounts.
Spot VMs leverage spare compute capacity at discounted rates and are ideal for workloads that can handle instance preemption.
2
Determine appropriate Cloud Storage class based on access frequency.
Data stored for multi-year compliance and accessed less than once a year maps directly to Archive Storage.
Archive Storage provides the lowest at-rest storage pricing for long-term retention requirements.
3
Select the combined configuration options in the Google Cloud Pricing Calculator.
Combining Spot VMs and Archive Storage provides the most accurate and optimized cost baseline.
This alignment matches GCP architectural best practices for both compute efficiency and storage lifecycle management.

Key Concept

Selecting optimal compute provision models (Spot VMs) and storage tiers (Archive Storage) in the Google Cloud Pricing Calculator based on workload characteristics.
Question 554Question →

An enterprise is architecture-planning a global web application deployed across Compute Engine instance groups in the us-east1 and europe-west3 regions. The application serves dynamic REST API requests along with large static media assets. The design must meet three strict constraints:
1. Terminate client HTTPS connections at the Google Cloud edge and cache static media assets to minimize backend latency and bandwidth usage.
2. Steer public end-user DNS queries for app.example.com to the nearest healthy regional backend pool based on client geographic origin.
3. Automatically divert DNS traffic away from a region if its backend instances fail health checks.

Which combination of Google Cloud networking services and configurations fulfills these requirements while adhering to Google recommended practices?

Show answer & explanation

Answer: Deploy a Global External HTTP(S) Load Balancer backed by instance groups in both regions, enable Cloud CDN on the backend service, and configure a Cloud DNS public zone using a Geolocation routing policy with health checking.

Answer

Deploy a Global External HTTP(S) Load Balancer backed by instance groups in both regions, enable Cloud CDN on the backend service, and configure a Cloud DNS public zone using a Geolocation routing policy with health checking.
The correct answer combines a Global External HTTP(S) Load Balancer with Cloud CDN and Cloud DNS Geolocation routing policies with health checks. The Global External HTTP(S) Load Balancer operates at Layer 7, providing SSL/TLS termination and direct compatibility with Cloud CDN for caching static assets at Google edge locations. Cloud DNS Geolocation routing policies steer public DNS queries to regional load balancer IP addresses according to client geographical proximity, while integrated health checks guarantee automated failover away from unhealthy regions.

Step-by-Step Solution

1
Analyze Layer 7 protocol and edge caching requirements
Identified that HTTP(S) connection termination and Cloud CDN integration mandate a Layer 7 External Load Balancer (Global External HTTP(S) Load Balancer).
Cloud CDN requires Layer 7 HTTP/HTTPS traffic inspection and headers, which Layer 4 Network Load Balancers (passthrough or proxy) cannot provide.
2
Analyze global routing and geographic steering requirements
Selected Cloud DNS Geolocation routing policy for steering client requests based on client source location.
Geolocation routing policy maps DNS client queries to specific IP endpoints corresponding to the nearest geographic region.
3
Analyze health check and automated failover requirements
Attached Cloud Cloud DNS health checking to the Geolocation routing policy.
Associating health checks with Cloud DNS routing policies ensures that if backends in a specific region become unhealthy, DNS queries automatically steer traffic to healthy alternative regional endpoints.

Key Concept

Selecting Layer 7 Load Balancing with Cloud CDN and Cloud DNS Geolocation Routing Policies
Question 555Question →

A software company is architecting a custom high-throughput transaction processing engine deployed on Compute Engine virtual machines. The engine requires ultra-low latency block storage for temporary operational scratch data during execution, but requires durable storage for its primary relational data store with continuous low latency, high random IOPS, availability across VM restarts, and support for automated disk snapshots. Which storage configuration meets these requirements according to Google Cloud best practices?

Show answer & explanation

Answer: Attach a Local SSD array for temporary operational scratch data, and use SSD Persistent Disk (pd-ssd) for the primary relational data store.

Answer

Attaching a Local SSD for temporary scratch space and using SSD Persistent Disk (pd-ssd) for the primary relational data store provides the required low latency, high IOPS, persistence across reboots, and snapshot functionality.
Combining Local SSD for non-persistent scratch workspace with SSD Persistent Disk (pd-ssd) for the persistent database volume balances extreme performance with enterprise durability and backup capabilities. SSD Persistent Disk ensures high IOPS, durability across VM restarts, and point-in-time snapshot features.

Step-by-Step Solution

1
Analyze storage performance and durability requirements for scratch space.
Temporary scratch data requires maximum IOPS and ultra-low latency, which Local SSD provides directly attached to the host server.
Local SSD delivers high throughput and microsecond latency, but loses data on instance termination/stop.
2
Analyze storage durability, snapshot, and IOPS requirements for primary relational data.
SSD Persistent Disk (pd-ssd) offers high performance, persistence across instance restarts, and support for automated snapshot backups.
Persistent disks are network-attached and support snapshot backups and persistent lifecycle independent of VM state.
3
Evaluate and eliminate unsuitable storage types.
Local SSD cannot back primary persistent database files because it lacks snapshot capability and persistence. Cloud Bigtable is NoSQL rather than relational. Standard persistent disks lack performance for databases.
Matching storage types strictly to data lifecycle and workload characteristics ensures architectural reliability and performance.

Key Concept

Selecting GCP Persistent Disk types and managed storage options based on IOPS, latency, durability, and workload characteristics.
Question 556Question →

A cloud engineer is deploying a new Google Cloud Storage bucket named `gs://media-ingest-pipeline-2026` in the `us-central1` region for an automated processing workflow. The project requirements specify configuring security standards (Uniform Bucket-Level Access), applying a lifecycle transition policy to lower long-term storage costs, and uploading initial assets. In what order should the engineer execute the following operational steps to establish the bucket and its initial configuration following Google Cloud best practices?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The operational sequence should begin with bucket creation (`gcloud storage buckets create`), followed by enabling Uniform Bucket-Level Access (`--uniform-bucket-level-access`), then applying the lifecycle rules (`--lifecycle-file`), and lastly uploading the data objects (`gcloud storage cp`).
Google Cloud deployment best practices dictate establishing the infrastructure resource first, applying security access boundaries next (Uniform Bucket-Level Access), binding lifecycle automation rules, and finally ingesting initial objects.

Step-by-Step Solution

1
Provision the bucket
Bucket `gs://media-ingest-pipeline-2026` is created in `us-central1`.
The bucket resource must exist in Google Cloud before any configuration flags or files can be applied.
2
Enforce security controls
Uniform Bucket-Level Access is activated on the bucket.
Security governance requires establishing uniform access controls prior to storing data.
3
Configure lifecycle management
Lifecycle rules from `lifecycle.json` are bound to the bucket.
Setting operational policies before data upload ensures proper automated handling of objects as soon as they land.
4
Ingest objects into the bucket
The file `media_batch_01.tar.gz` is stored in the fully configured bucket.
Object ingestion is the final step after infrastructure and governance rules are in place.

Key Concept

Deploying and Configuring Cloud Storage Buckets and Objects
Question 557Question →

A cloud engineer needs to deploy a web application to an existing Google Kubernetes Engine (GKE) cluster and verify its operational readiness. Arrange the following steps in the correct chronological order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations is: 1) Authenticate and update local kubeconfig credentials using `gcloud container clusters get-credentials`, 2) Submit the deployment manifest using `kubectl apply -f deployment.yaml`, 3) Monitor the deployment rollout status using `kubectl rollout status deployment/web-app`, and 4) Inspect pod details using `kubectl get pods -o wide`.
Deploying a workload to a GKE cluster follows a logical workflow: first, establish cluster authentication and API endpoints locally via `gcloud container clusters get-credentials`; second, create the workload objects by applying the YAML manifest with `kubectl apply`; third, wait for the deployment controller to complete replica creation with `kubectl rollout status`; and fourth, verify active pod IPs and host node assignments with `kubectl get pods -o wide`.

Step-by-Step Solution

1
Fetch cluster credentials using gcloud
The local ~/.kube/config file is populated with the GKE API server endpoint and authentication token.
kubectl requires active credentials and context configuration to issue commands against the GKE control plane.
2
Apply the Kubernetes workload manifest
The Kubernetes API server accepts the specification and triggers pod scheduling across cluster node pools.
Manifest submission tells Kubernetes which container images, replica counts, and configurations to run.
3
Track deployment rollout status
The command monitors pod startup until all requested replicas pass readiness probes.
Verifying rollout status ensures that pod initialization issues, image pull errors, or crash loops are caught.
4
Inspect running pod runtime metadata
A broad overview of running pods, internal IP addresses, and underlying host nodes is rendered.
Final health check and IP address allocation verification occur once pods are confirmed operational.

Key Concept

GKE Workload Deployment Procedure and Verification Sequence
Estimated Time:1m 30s
Question 558Question →

A DevOps engineering team is upgrading an automated infrastructure deployment pipeline to adhere to current Google Cloud CLI best practices. They need to deploy a new Cloud Storage bucket named `gs://compliance-audit-logs-2026` in the `us-central1` region. Security and governance policies mandate that the bucket must enforce Uniform Bucket-Level Access (UBLA), set a default storage class of `COLDLINE` for all newly ingested objects, and enforce an unalterable object retention duration of 365 days. The team mandates using the modern `gcloud storage` CLI component rather than legacy `gsutil` commands. Which `gcloud storage` command correctly provisions this bucket with all specified configurations in a single step?

Show answer & explanation

Answer: gcloud storage buckets create gs://compliance-audit-logs-2026 --location=us-central1 --default-storage-class=COLDLINE --uniform-bucket-level-access --retention-period=365d

Answer

The command `gcloud storage buckets create gs://compliance-audit-logs-2026 --location=us-central1 --default-storage-class=COLDLINE --uniform-bucket-level-access --retention-period=365d` correctly creates the bucket with all required settings using modern `gcloud storage` syntax.
The correct command utilizes valid `gcloud storage buckets create` syntax with exact flags: `--location=us-central1` sets the deployment region, `--default-storage-class=COLDLINE` configures the default storage class for new objects, `--uniform-bucket-level-access` disables legacy per-object ACLs in favor of IAM, and `--retention-period=365d` enforces a 365-day object retention policy.

Step-by-Step Solution

1
Identify the modern Google Cloud CLI command group for bucket deployment
Recognize that `gcloud storage buckets create` is the recommended syntax for bucket provisioning.
`gcloud storage` replaces legacy `gsutil` syntax and uses standard double-dash flag structures.
2
Validate the flags for location and default storage class
Use `--location=us-central1` and `--default-storage-class=COLDLINE`.
In `gcloud storage buckets create`, default object storage class is controlled via `--default-storage-class` rather than `--storage-class` or `-c`.
3
Verify flags for access control and object retention
Specify `--uniform-bucket-level-access` to disable ACLs and `--retention-period=365d` to enforce object retention.
Uniform Bucket-Level Access is enabled using the boolean flag `--uniform-bucket-level-access`, and retention duration is set via `--retention-period`.

Key Concept

Deploying Cloud Storage Buckets using gcloud storage CLI
Question 559Question →

A DevOps team is automating the deployment of a Compute Engine instance named `analytics-worker` in zone `us-central1-a` using the Google Cloud CLI. The VM requires a local file `/opt/scripts/init.sh` to run as a startup script during boot. Additionally, the VM must have custom metadata configured with a key of `environment` set to `production`, attach a custom service account `[email protected]`, and be granted read-only access to Cloud Storage via API access scopes. Which `gcloud compute instances create` command correctly provisions this virtual machine according to all requirements?

Show answer & explanation

Answer: gcloud compute instances create analytics-worker --zone=us-central1-a --metadata-from-file=startup-script=/opt/scripts/init.sh --metadata=environment=production --service-account=sa-analytics@my-project.iam.gserviceaccount.com --scopes=https://www.googleapis.com/auth/devstorage.read_only

Answer

The correct command is the one that uses `--metadata-from-file=startup-script=/opt/scripts/init.sh` alongside `--metadata=environment=production`, `--service-account=sa-analytics@my-project.iam.gserviceaccount.com`, and `--scopes=https://www.googleapis.com/auth/devstorage.read_only`.
The correct command properly distinguishes between string metadata and file-based metadata by employing `--metadata-from-file=startup-script=/opt/scripts/init.sh` and `--metadata=environment=production`. It also correctly specifies a valid OAuth scope URI (`https://www.googleapis.com/auth/devstorage.read_only`) alongside the custom service account email address.

Step-by-Step Solution

1
Identify the proper CLI flag for local script metadata attachment.
Local files supplied as startup scripts must be specified via `--metadata-from-file=startup-script=<path_to_file>` rather than standard string `--metadata`.
The standard `--metadata` flag treats values as explicit string literals, whereas `--metadata-from-file` reads the content of the file specified at the path.
2
Differentiate between OAuth API access scopes and IAM permissions.
The `--scopes` flag requires valid OAuth URLs or shorthand aliases (such as `storage-ro` or `https://www.googleapis.com/auth/devstorage.read_only`).
IAM roles (e.g., `roles/storage.objectViewer`) govern authorization on GCP resources, while legacy API access scopes define the maximum permissions allowed on the instance's service account credentials.
3
Verify service account attachment and availability parameters.
Specify `--service-account` with the full service account email and avoid conflicting provisioning model flags.
Mixing legacy `--preemptible` flags with modern `--provisioning-model=SPOT` flags causes CLI validation errors.

Key Concept

Deploying Compute Engine VMs with startup scripts, custom metadata, custom service accounts, and API scopes via gcloud CLI
Question 560Question →

A cloud engineer must configure access for a finance team member who needs to link newly provisioned Google Cloud projects to the company's central Billing Account and monitor project cost data. The finance team member must not be allowed to modify project infrastructure resources or manage billing account administrators and budgets. Which IAM role assignment strategy adheres to the principle of least privilege?

Show answer & explanation

Answer: Grant the Billing Account User (roles/billing.user) role on the Billing Account, and grant the Project Billing Manager (roles/resourcemanager.projectBillingManager) role on the target projects.

Answer

Grant the Billing Account User role on the Billing Account and the Project Billing Manager role on the target projects.
Linking a Google Cloud project to a Billing Account requires explicit authorization on two separate resources. The principal must hold the Billing Account User (roles/billing.user) role on the central Billing Account resource and the Project Billing Manager (roles/resourcemanager.projectBillingManager) role on the project resource. This combination grants exact rights to link billing and view costs without granting infrastructural administrative rights or full billing account management.

Step-by-Step Solution

1
Identify the required actions
The user needs to link a project to a Billing Account and view project cost data without managing project infrastructure or modifying billing account administration.
Determining exact action boundaries helps select least-privilege predefined roles.
2
Determine Billing Account level permission requirement
The principal needs roles/billing.user on the specific Billing Account object.
Linking a project to a billing account requires permission to use the billing account.
3
Determine Project level permission requirement
The principal needs roles/resourcemanager.projectBillingManager on the target project.
Linking requires project-level authorization to associate billing to that specific project.

Key Concept

Billing Account Project Linking IAM Requirements
PreviousPage 28 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin