Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 641Question →

A logistics enterprise is designing a high-throughput fleet tracking platform on Google Cloud to record continuous telemetry and diagnostic metrics from 50,00050,000 active delivery vehicles. The ingest layer requires consistent sub-10 millisecond write latencies, must dynamically scale capacity up to hundreds of terabytes without database schema maintenance or manual sharding, and relies solely on single-row key lookups by vehicle ID and timestamp. Which database architecture should you recommend to meet these requirements with minimal operational overhead?

Show answer & explanation

Answer: Provision Cloud Bigtable instances using SSD storage for high-throughput time-series key-value telemetry data.

Answer

Provision Cloud Bigtable instances using SSD storage for high-throughput time-series key-value telemetry data.
Cloud Bigtable is a fully managed NoSQL wide-column database optimized for high-volume time-series metrics and telemetry data. It offers sub-10 millisecond latency and scales seamlessly to petabytes of key-value data with low operational overhead.

Step-by-Step Solution

1
Analyze access pattern and functional requirements
Workload involves high-volume time-series writes, key-value single-row queries (vehicle ID + timestamp), sub-10 ms latency, scale to 100s of TBs, and no relational joins.
Determines whether relational (Cloud SQL/Spanner) or NoSQL (Cloud Bigtable/Firestore) service fits best.
2
Evaluate GCP managed database options
Cloud Bigtable is engineered for large-scale time-series and key-value workloads requiring ultra-low latency and seamless horizontal scaling.
Cloud Bigtable provides seamless scaling and high throughput for non-relational telemetry data with minimal operational management.
3
Assess storage media and operational constraints
Bigtable with SSD storage provides predictable sub-10 ms performance compared to self-managed VM options on pre-emptible infrastructure or inappropriate storage tiers.
SSD storage clusters in Bigtable ensure optimal read/write IOPS and low latency under continuous stream loading.

Key Concept

Cloud Bigtable is the optimal GCP database choice for high-throughput, low-latency NoSQL time-series data at multi-terabyte scale.
Question 642Question →

Arrange the following administrative procedures in the correct chronological order required to authenticate to a Google Kubernetes Engine (GKE) cluster, confirm active cluster access, submit a new workload manifest, and verify that the pod deployment finishes successfully.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct administrative sequence is: 1. Obtain cluster credentials (`gcloud container clusters get-credentials`), 2. Verify cluster node connectivity (`kubectl get nodes`), 3. Apply the workload manifest (`kubectl apply -f deployment.yaml`), 4. Confirm successful deployment rollout (`kubectl rollout status deployment/web-app`).
The deployment process follows a standard sequence: First, execute `gcloud container clusters get-credentials` to acquire cluster access credentials and set up `kubeconfig`. Second, run `kubectl get nodes` to confirm functional API server access and cluster health. Third, run `kubectl apply -f deployment.yaml` to instruct GKE to create or update the workload resources. Fourth, run `kubectl rollout status deployment/web-app` to observe and verify that all new pods pass readiness probes.

Step-by-Step Solution

1
Generate cluster credentials and update local kubeconfig
The local CLI environment obtains authentication tokens and configures the GKE cluster context.
Commands issued via kubectl will fail unless valid control plane credentials and server endpoints exist in kubeconfig.
2
Test control plane connectivity and node readiness
Returns the list of cluster nodes and their Current status (Ready).
Verifying API server access prevents submitting deployment manifests into an unreachable or broken cluster context.
3
Deploy the application configuration file to the cluster
The Kubernetes API server accepts the deployment specification and triggers pod creation.
Declarative resource creation requires applying the YAML specification file.
4
Observe the progress of the deployment rollout
Monitors pod status until all replicas complete initialization without crash loops or image pull failures.
Executing rollout status provides deterministic verification that the workload update succeeded.

Key Concept

GKE Cluster Authentication and Workload Deployment Lifecycle
Question 643Question →

A compliance team at a financial company requires a new Google Cloud Storage bucket to store daily transaction records in the europe-west1 region. The bucket must enforce Uniform Bucket-Level Access for consistent IAM access management and have object versioning enabled to prevent accidental overwrites. Which command should you execute to deploy the bucket according to Google-recommended best practices?

Show answer & explanation

Answer: gcloud storage buckets create gs://audit-compliance-logs-2026 --location=europe-west1 --uniform-bucket-level-access --enable-object-versioning

Answer

The command using 'gcloud storage buckets create' with both '--uniform-bucket-level-access' and '--enable-object-versioning' flags.
The correct option utilizes the modern 'gcloud storage buckets create' command surface with the '--uniform-bucket-level-access' flag to enforce uniform IAM permissions and '--enable-object-versioning' to maintain object version history, satisfying all security and operational requirements.

Step-by-Step Solution

1
Identify the required CLI tool
Google Cloud recommends using the unified 'gcloud storage' tool over the legacy 'gsutil' tool for bucket management tasks.
gcloud storage offers faster performance and aligns with current GCP best practices.
2
Specify security and versioning requirements
Pass '--uniform-bucket-level-access' to disable per-object ACLs and '--enable-object-versioning' to protect objects against accidental deletion.
These flags fulfill both compliance mandates directly upon bucket creation.

Key Concept

Deploying Cloud Storage Buckets with gcloud storage
Question 644Question →

A database administrator needs to create and configure Cloud SQL instances within a Google Cloud development project. The administrator must be able to perform all administrative tasks on Cloud SQL resources, but must not have permissions to manage other Google Cloud services or edit project IAM policies. Following Google's recommended security best practices of least privilege, which role should be granted to the administrator?

Show answer & explanation

Answer: Cloud SQL Admin (roles/cloudsql.admin)

Answer

Grant the Cloud SQL Admin (roles/cloudsql.admin) predefined role at the project level.
The Cloud SQL Admin (roles/cloudsql.admin) predefined role provides complete administrative access to Cloud SQL instances, databases, and backups without granting access to manage unrelated GCP services or project-level IAM bindings.

Step-by-Step Solution

1
Analyze administrative requirements and resource scope
The user requires full control specifically over Cloud SQL instances without needing permissions on other GCP services.
Selecting an IAM role requires matching necessary permissions directly to specified job duties.
2
Evaluate role options against Google Cloud best practices
The predefined role Cloud SQL Admin (roles/cloudsql.admin) provides full management rights over Cloud SQL while scoped strictly to that service.
Google Cloud best practices dictate using predefined or custom roles instead of broad primitive roles to enforce least privilege.

Key Concept

Granting service-specific predefined roles rather than primitive roles to enforce the principle of least privilege.
Question 645Question →

You are managing a Google Kubernetes Engine (GKE) cluster and need to migrate running workloads from an existing node pool to a newly required machine type with minimal downtime. What is the correct sequence of steps to complete this node pool migration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence for migrating workloads to a new node pool is: 1) Provision the new node pool with gcloud container node-pools create, 2) Mark the old nodes as unschedulable with kubectl cordon, 3) Gracefully evict workloads from old nodes with kubectl drain, and 4) Delete the old node pool with gcloud container node-pools delete.
When performing a manual GKE node pool migration, compute capacity must first be provisioned using 'gcloud container node-pools create'. Once the new nodes are ready, old nodes are marked unschedulable with 'kubectl cordon' to prevent new placements. Executing 'kubectl drain' then evicts Pods, allowing Kubernetes to reschedule them onto the new node pool. Finally, 'gcloud container node-pools delete' removes the empty old node pool safely.

Step-by-Step Solution

1
Provision target compute capacity
New nodes are added to the cluster with the desired specification.
Replacement nodes must exist so evicted Pods have available capacity for rescheduling.
2
Disable scheduling on old nodes
Old nodes are cordoned and marked Unschedulable.
Prevents new Pods from being placed on nodes that are about to be decommissioned.
3
Evict workloads from old nodes
Running Pods are safely evicted and recreated on the newly provisioned node pool.
Draining ensures workloads migrate to active capacity without sudden termination.
4
Decommission old node pool
The old node pool is removed from the GKE cluster.
Cleaning up empty infrastructure prevents unnecessary cloud resource charges.

Key Concept

GKE Node Pool Migration Procedure
Question 646Question →

An online education platform is designing a new Google Kubernetes Engine (GKE) cluster architecture to handle on-demand video encoding tasks. The video encoding workloads are stateless, fault-tolerant, and can tolerate sudden instance preemptions. To reduce operational burden, the engineering leadership has mandated that node management overhead—including node provisioning, security patching, and OS upgrades—must be completely managed by Google Cloud. Which cluster design strategy fulfills all technical requirements while minimizing compute expenses?

Show answer & explanation

Answer: Deploy a GKE Autopilot cluster and configure the video encoding workloads to request Spot Pods using node selectors or tolerations.

Answer

Deploying a GKE Autopilot cluster with workloads configured to request Spot Pods satisfies the requirement of zero node management overhead while achieving maximum cost efficiency for fault-tolerant tasks.
GKE Autopilot shifts node management responsibilities completely to Google Cloud, satisfying the requirement to eliminate node maintenance overhead. By configuring Kubernetes manifests to target Spot Pods (via tolerations and node selectors), the cluster runs stateless video encoding tasks on discounted compute capacity without requiring manually configured Spot VM node pools.

Step-by-Step Solution

1
Analyze the operational constraint regarding node management overhead.
GKE Autopilot fully automates node lifecycle management, patching, and provisioning, removing infrastructure management overhead.
GKE Standard requires manual operational effort to manage node pools and host upgrades.
2
Analyze the cost optimization constraint for stateless, fault-tolerant workloads.
GKE Autopilot supports Spot Pods, which leverage spare compute capacity at a significant discount for fault-tolerant jobs.
Using standard on-demand pod pricing for interrupted video encoding jobs would incur unnecessary expense.

Key Concept

GKE Autopilot Cluster Architecture and Spot Pod Integration
Estimated Time:1m 30s
Question 647Question →

An operations engineer is tasked with configuring a Global External Application Load Balancer using the gcloud CLI to secure incoming HTTPS web traffic destined for Compute Engine managed instance groups. The deployment requires establishing health monitoring, SSL encryption via Google-managed certificates, and frontend traffic routing. Which sequence correctly orders the deployment commands from the backend infrastructure up to the public frontend entry point?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order follows the bottom-up dependency sequence of Google Cloud HTTP(S) Load Balancing: first create the health check, backend service, and attach instance group backends; second, create the URL map pointing to the backend service; third, reserve a static global external IP address and create the Google-managed SSL certificate; fourth, create the target HTTPS proxy linking the URL map and SSL certificate; fifth, establish the global forwarding rule binding the external IP address on port 443 to the target HTTPS proxy.
In Google Cloud Platform, building a Global External Application Load Balancer via gcloud follows a strict dependency chain from backend to frontend. The backend service and health check must exist before a URL map can reference them. Similarly, the URL map and SSL certificate resources must exist before creating the target HTTPS proxy. Finally, the global forwarding rule binds the reserved external IP address and target port to the target HTTPS proxy.

Step-by-Step Solution

1
Define backend resources (Health Check and Backend Service)
Backend service is created with an attached health check and instance group backends registered.
Top-level proxy resources cannot be created without a defined backend service target.
2
Create the URL Map
URL map object routing HTTP(S) traffic to the default backend service is instantiated.
URL maps evaluate incoming request paths and route traffic to configured backend services.
3
Provision IP Address and SSL Certificate frontend dependencies
A global static external IP address and a Google-managed SSL certificate resource are created.
Target HTTPS proxies require an existing SSL certificate object, and forwarding rules require an allocated static IP.
4
Create Target HTTPS Proxy
Target HTTPS proxy binds the URL map and SSL certificate.
The target proxy performs TLS termination using the SSL certificate before consulting the URL map for path routing.
5
Create Global Forwarding Rule
Forwarding rule routes incoming port 443 traffic from the external static IP to the target HTTPS proxy.
The forwarding rule completes the pathway by connecting external network traffic to the GCP load balancing entry point.

Key Concept

Google Cloud Global External Application Load Balancer Architecture & gcloud Dependency Sequence
Estimated Time:3m 0s
Question 648Question →

A multinational retail company generates end-of-day point-of-sale (POS) transaction files that are stored in Google Cloud Storage. Finance teams access these files daily during the first 30 days to complete inventory and sales reconciliation. After 30 days, the files are rarely accessed but must be retained for 5 years for legal compliance. Which storage bucket lifecycle configuration minimizes total storage and retrieval costs while satisfying these access requirements?

Show answer & explanation

Answer: Deploy a bucket with the default storage class set to Standard Storage, and configure an Object Lifecycle Management rule to transition objects to Archive Storage after 30 days.

Answer

Deploy a bucket with the default storage class set to Standard Storage, and configure an Object Lifecycle Management rule to transition objects to Archive Storage after 30 days.
Standard Storage provides zero retrieval fees during the active 30-day period when finance teams access POS files daily. Transitioning objects to Archive Storage after 30 days reduces ongoing monthly storage costs to the lowest tier for the remaining 5-year compliance retention window.

Step-by-Step Solution

1
Analyze access patterns during the initial phase.
Files are accessed daily during the first 30 days, requiring a storage class with zero retrieval fees, such as Standard Storage.
Choosing Nearline, Coldline, or Archive during the active 30-day window would result in substantial data retrieval charges.
2
Analyze long-term retention and access requirements.
After 30 days, data access becomes extremely rare (less than once per year) over a 5-year retention period, making Archive Storage the most cost-effective tier.
Archive Storage offers the lowest per-gigabyte monthly storage cost for long-term archival data.
3
Select the automated management mechanism.
Use Object Lifecycle Management to automatically transition objects from Standard Storage to Archive Storage 30 days after object creation.
Lifecycle rules natively automate class transitions without manual intervention or custom application scripts.

Key Concept

Selecting Cloud Storage classes and automating transitions using Object Lifecycle Management based on access frequency and retrieval costs.
Estimated Time:1m 30s
Question 649Question →

Your organization is establishing a hybrid cloud architecture connecting an on-premises data center to a Google Cloud Virtual Private Cloud (VPC) network via Cloud VPN. On-premises client machines need to resolve private DNS queries for instances hosted in GCP ending with `.internal.example.com`. You need to configure Cloud DNS to allow on-premises systems to resolve these names. Which TWO configuration steps are required to satisfy this requirement?

Select all that apply

Show answer & explanation

Answer: Create an Inbound DNS server policy in Cloud DNS assigned to the target VPC network.; Configure the on-premises DNS servers to forward queries for `.internal.example.com` to the Cloud DNS Inbound forwarder IP addresses.

Answer

To enable on-premises clients to resolve GCP private DNS records over Cloud VPN, you must create an Inbound DNS server policy assigned to the VPC network to allocate inbound forwarder IP addresses, and then configure the on-premises DNS servers to forward domain queries for `.internal.example.com` to those entry-point IP addresses.
Enabling on-premises resolution of GCP private DNS names requires an Inbound DNS server policy attached to the VPC network. This creates entry-point IP addresses inside the VPC subnets. The on-premises DNS server must then be configured with conditional forwarding to target those entry-point IPs for the GCP internal domain name space.

Step-by-Step Solution

1
Configure an Inbound DNS server policy in Cloud DNS for the target VPC.
Cloud DNS reserves entry-point IP addresses in the VPC subnets specifically designed to receive incoming DNS queries from connected hybrid networks.
On-premises systems cannot query GCP Private DNS zones directly without an active inbound forwarding entry point exposed on the VPC.
2
Set up conditional DNS forwarding on the on-premises DNS infrastructure.
Requests for `.internal.example.com` originating from local networks are routed across the VPN tunnel to Cloud DNS.
On-premises systems query local DNS resolvers first; those resolvers need explicit instructions to send specific GCP domain queries to the Cloud DNS inbound entry-point IPs.

Key Concept

Cloud DNS Inbound Forwarding for Hybrid Architecture
Question 650Question →

An enterprise application receives raw encrypted TCP traffic on port 8443 from global clients. The infrastructure team needs to terminate SSL/TLS at the load balancer level and forward unencrypted TCP traffic to a backend Compute Engine Managed Instance Group. The application does not use HTTP or HTTPS protocols. Which Google Cloud load balancing architecture should be deployed to fulfill these requirements?

Show answer & explanation

Answer: Deploy a Global External Proxy Network Load Balancer with a target SSL proxy and an SSL certificate configured on the target proxy.

Answer

Deploy a Global External Proxy Network Load Balancer with a target SSL proxy and an SSL certificate configured on the target proxy.
The Global External Proxy Network Load Balancer using an SSL Proxy is specifically designed to handle global, non-HTTP raw TCP traffic while terminating SSL/TLS connections at the load balancer level before routing cleartext traffic to backend instances.

Step-by-Step Solution

1
Analyze the incoming traffic protocol and global scope
Traffic is raw TCP (non-HTTP/HTTPS) coming from global clients on port 8443.
Layer 7 HTTP(S) Load Balancers require valid HTTP semantics, ruling out Application Load Balancers for custom/raw TCP protocols.
2
Determine the SSL/TLS offloading capability requirement
SSL/TLS offloading is required at the load balancer before sending traffic to backends.
Passthrough Network Load Balancers do not terminate TLS; only Proxy or Application Load Balancers offload TLS.
3
Select the appropriate GCP load balancer archetype
Global External Proxy Network Load Balancer (SSL Proxy).
SSL Proxy handles non-HTTP TCP traffic globally while terminating TLS at the Google edge.

Key Concept

Selecting GCP Load Balancers Based on Protocol, SSL Offloading, and Scope
Estimated Time:2m 0s
Question 651Question →

A cloud administrator receives a newly provisioned workstation and installs `kubectl` to manage an existing regional Google Kubernetes Engine (GKE) cluster named `ecommerce-prod` located in the `us-east4` region. When running `kubectl get pods`, the command fails with an error stating `The connection to the server localhost:8080 was refused`. Which `gcloud` command must the administrator execute to populate the local kubeconfig file with cluster context credentials?

Show answer & explanation

Answer: gcloud container clusters get-credentials ecommerce-prod --region us-east4

Answer

Execute `gcloud container clusters get-credentials ecommerce-prod --region us-east4` to generate the necessary cluster endpoint entries and authentication tokens in the local kubeconfig file.
Running `gcloud container clusters get-credentials` fetches the control plane certificates and generates an entry in the local `~/.kube/config` file. This configures `kubectl` with the correct cluster API server address and credentials required to perform operations against the target GKE cluster.

Step-by-Step Solution

1
Identify the root cause of the `localhost:8080` connection error.
Recognize that `kubectl` defaults to `localhost:8080` when no active GKE cluster context or API server endpoint exists in the local `~/.kube/config` configuration file.
Before executing cluster commands, `kubectl` must know the control plane IP address and present valid IAM/OAuth credentials.
2
Select the correct Google Cloud CLI command to fetch cluster credentials.
Use `gcloud container clusters get-credentials` with the cluster name and region parameters.
This command fetches the cluster's API endpoint and CA certificate, generates an authentication token, and registers the context entry in `~/.kube/config`.

Key Concept

GKE Kubeconfig Authentication & Context Provisioning
Estimated Time:1m 30s
Question 652Question →

You are configuring internal domain name resolution for instances running within a Virtual Private Cloud (VPC) network named `corp-vpc`. You plan to use the Google Cloud CLI (`gcloud`) to create a Cloud DNS managed zone named `corp-zone` for the internal domain `internal.corp.com`. Which combination of flags must you specify in the `gcloud dns managed-zones create` command to restrict resolution of this zone exclusively to `corp-vpc`?

Show answer & explanation

Answer: --visibility=private --networks=corp-vpc

Answer

Specify the flags `--visibility=private` and `--networks=corp-vpc` when running the `gcloud dns managed-zones create` command.
To create a private Cloud DNS zone bound to a specific VPC network using the gcloud CLI, you must set `--visibility=private` and pass the target VPC network name to `--networks=corp-vpc`.

Step-by-Step Solution

1
Identify the requirement for internal-only Cloud DNS name resolution.
Recognize that a private managed zone is required rather than a default public zone.
Private DNS zones restrict name resolution to authorized Virtual Private Cloud (VPC) networks.
2
Determine the correct `gcloud` command parameters for Cloud DNS zone creation.
Use `--visibility=private` to define private scope and `--networks=[VPC_NAME]` to authorize network access.
The `gcloud dns managed-zones create` command expects these specific flag names to establish private network authorization.

Key Concept

Configuring Cloud DNS Private Managed Zones via gcloud CLI
Question 653Question →

Your company hosts a microservices workload on a Google Kubernetes Engine (GKE) cluster. During high traffic spikes, CPU consumption increases significantly across existing pods, resulting in high response latency. The existing cluster nodes have adequate spare CPU and memory resources to handle additional pod workloads. You need to configure automated scaling so that new pod replicas are scheduled when CPU utilization reaches a high threshold. What operational action should you take?

Show answer & explanation

Answer: Configure a Horizontal Pod Autoscaler (HPA) targeting the Deployment using the kubectl autoscale command.

Answer

Configure a Horizontal Pod Autoscaler (HPA) targeting the Deployment using the kubectl autoscale command.
Configuring a Horizontal Pod Autoscaler (HPA) using kubectl autoscale dynamically adjusts the number of pod replicas based on CPU utilization. Because the cluster nodes already possess adequate CPU and memory capacity, adding pod replicas effectively distributes the load without needing to scale node pool infrastructure.

Step-by-Step Solution

1
Identify the bottleneck location
Individual pod instances are experiencing CPU pressure, but the underlying GKE nodes have unallocated capacity.
When nodes have sufficient CPU and memory, additional pod replicas can be scheduled without expanding node count.
2
Select the appropriate GKE autoscaling mechanism
Choose Horizontal Pod Autoscaler (HPA) over Cluster Autoscaler.
HPA scales pod replicas based on workload metrics like CPU, whereas Cluster Autoscaler scales compute node instances.
3
Apply the HPA operational command
Run kubectl autoscale deployment with the targeted CPU utilization threshold.
This creates a HorizontalPodAutoscaler resource to automatically manage pod replica counts.

Key Concept

Managing GKE Workload Autoscaling with Horizontal Pod Autoscaler (HPA)
Estimated Time:1m 30s
Question 654Question →

A Cloud Engineer manages a Google Kubernetes Engine (GKE) Standard cluster that hosts a stateless, fault-tolerant batch processing pipeline. During peak activity, multiple batch processing Pods remain in a Pending state due to insufficient CPU and memory resources on existing nodes. Management requires an automated scaling solution that provisions additional cluster capacity specifically when Pods cannot be scheduled, while minimizing compute infrastructure costs for this resilient workload. Which action should the engineer take?

Show answer & explanation

Answer: Add a dedicated node pool configured with Spot VMs using gcloud container node-pools create with the --spot flag, and enable cluster autoscaling using the --enable-autoscaling flag.

Answer

Create a new node pool configured with Spot VMs using gcloud container node-pools create with the --spot flag, and enable GKE Cluster Autoscaler using the --enable-autoscaling flag.
Creating a dedicated node pool using Spot VMs (--spot) provides maximum cost reduction for stateless and fault-tolerant batch workloads. Enabling GKE Cluster Autoscaler (--enable-autoscaling) ensures that when batch Pods remain in a Pending state due to resource shortages, GKE automatically provisions new Spot nodes to accommodate them.

Step-by-Step Solution

1
Identify the workload resource requirements and cost optimization potential.
Stateless, fault-tolerant batch processing Pods can handle unexpected terminations, making them ideal candidates for discounted GKE Spot VMs.
Spot VMs offer up to 60-91% discounts compared to standard On-Demand Compute Engine pricing.
2
Determine the appropriate Kubernetes/GKE scaling mechanism for unschedulable (Pending) Pods.
GKE Cluster Autoscaler automatically inspects Pods in Pending state due to resource constraints and provisions additional node capacity in designated node pools.
Horizontal Pod Autoscaler (HPA) scales Pod replicas, whereas Cluster Autoscaler scales the underlying Compute Engine node infrastructure.
3
Execute the appropriate gcloud command to create an autoscaling Spot VM node pool.
Run gcloud container node-pools create [POOL_NAME] --cluster=[CLUSTER_NAME] --spot --enable-autoscaling --min-nodes=[MIN] --max-nodes=[MAX].
This command provisions a new Spot VM node pool and enables Cluster Autoscaler to automatically adjust node counts based on unschedulable workload demand.

Key Concept

GKE Cluster Autoscaler vs HPA & Spot VM Node Pools
Estimated Time:2m 0s
Question 655Question →

A cloud engineer needs to deploy a highly available Cloud SQL PostgreSQL instance using Private IP connectivity within a custom Virtual Private Cloud (VPC) network, followed by creating a cross-region read replica using the Google Cloud CLI. Arrange the required infrastructure provisioning and database creation steps in the correct chronological execution order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with reserving an internal IP allocation for VPC peering, establishing the private services access connection to servicenetworking.googleapis.com, creating the regional primary Cloud SQL instance attached to the VPC with public IP disabled, and finally creating the cross-region read replica targeting the primary instance.
Private IP connectivity for Cloud SQL relies on Private Services Access, which is built on VPC Peering between the customer VPC network and Google's internal service network. The workflow requires allocating an internal IP range (`gcloud compute addresses create ... --purpose=VPC_PEERING`), connecting the network to Service Networking (`gcloud services vpc-peerings connect`), provisioning the primary Cloud SQL instance (`gcloud sql instances create ... --no-assign-ip --network=...`), and finally creating any read replicas specifying the primary as the master instance.

Step-by-Step Solution

1
Allocate a private IP range for Private Service Access.
An IP range with purpose VPC_PEERING is reserved in the target VPC network.
Google Cloud service networking requires a pre-allocated IP range to avoid subnet overlap prior to establishing peering.
2
Create the VPC peering connection for Google Managed Services.
The target VPC network is peered with the Service Networking tenant project network.
Cloud SQL Private IP uses Private Services Access, which relies on a underlying Service Networking VPC peering connection.
3
Provision the regional primary Cloud SQL database instance.
A high-availability primary database instance is deployed without a public IP.
The primary database instance must exist and be accessible via the peered network before replicas can be configured.
4
Provision the cross-region read replica.
A read replica is provisioned in the secondary region linked to the primary instance.
Read replicas depend on the primary instance ID specified by the master instance flag during creation.

Key Concept

Provisioning Cloud SQL instances with Private IP requires establishing a Private Services Access (Service Networking VPC Peering) connection before instantiating primary instances or read replicas.
Question 656Question →

Your organization maintains a private Cloud DNS zone hosted in `vpc-shared-services` that resolves internal service domain names. A team deploying a separate workload in `vpc-analytics` needs their Compute Engine instances to resolve these internal DNS names without duplicating DNS records. Which configuration should you implement to enable internal DNS resolution from `vpc-analytics`?

Show answer & explanation

Answer: Create a Cloud DNS Peering zone associated with `vpc-analytics` that specifies `vpc-shared-services` as the target peer network.

Answer

Create a Cloud DNS Peering zone associated with `vpc-analytics` that specifies `vpc-shared-services` as the target peer network.
Cloud DNS Peering allows queries for private DNS zones to be forwarded from one VPC network (the querying network) to another VPC network (the peer network) where the private zone is authorized. Creating a DNS peering zone in `vpc-analytics` targeting `vpc-shared-services` allows `vpc-analytics` to resolve private records without needing direct authorization on the managed zone or duplicating record sets.

Step-by-Step Solution

1
Identify the cross-VPC private DNS resolution requirement.
Determine that `vpc-analytics` needs to query a private DNS zone managed inside `vpc-shared-services`.
Cloud DNS private zones are by default only accessible to the authorized VPC networks explicitly listed in the zone configuration.
2
Select the appropriate GCP Cloud DNS feature for sharing DNS resolution across VPC networks.
Choose Cloud DNS Peering.
Cloud DNS Peering allows a source VPC network to delegate queries for a domain namespace to a peer target VPC network where the zone is configured.
3
Configure the DNS Peering zone settings.
Associate the peering zone with `vpc-analytics` and set `vpc-shared-services` as the peer network.
This establishes a DNS forwarding path so instances in `vpc-analytics` can seamlessly resolve private records without maintaining duplicate records.

Key Concept

Cloud DNS Peering for Cross-VPC Private Zone Resolution
Estimated Time:1m 30s
Question 657Question →

A Cloud Engineer needs to securely configure a workload running on Google Kubernetes Engine (GKE) to access Cloud Storage using Workload Identity instead of downloading service account keys. Arrange the following configuration and deployment steps in the correct chronological order required to grant the GKE workload secure access to Cloud Storage.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological order to configure Workload Identity on GKE is: 1) Create the Google Cloud Service Account (GSA) and assign IAM roles, 2) Create the Kubernetes Service Account (KSA) in the cluster, 3) Bind the KSA to the GSA using the Workload Identity User role, 4) Annotate the KSA with the GSA email address, and 5) Reference the KSA under `spec.serviceAccountName` in the workload deployment manifest before applying it.
The correct sequence starts with provisioning the GCP identity (GSA) and cluster identity (KSA). Next, IAM impersonation trust is established by granting `roles/iam.workloadIdentityUser` to the KSA principal. The KSA is then annotated with the GSA email so the GKE metadata server can handle token exchange. Finally, the workload deployment manifest is configured to use the KSA and applied to the cluster.

Step-by-Step Solution

1
Create the Google Cloud IAM Service Account (GSA) and assign permissions.
GCP identity is provisioned with appropriate Cloud Storage access roles.
Cloud permissions must exist on the GCP side before linking Kubernetes resources.
2
Create the Kubernetes Service Account (KSA) in GKE.
In-cluster identity is created within the specified namespace.
GKE workloads require a KSA identity to participate in Workload Identity mapping.
3
Grant `roles/iam.workloadIdentityUser` on the GSA to the KSA member identity (`serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]`).
IAM policy allows the KSA to impersonate the GSA.
Without this role binding, GCP IAM will reject impersonation requests from GKE.
4
Annotate the KSA using `iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com`.
The GKE metadata server links KSA credential requests to the specified GSA.
The annotation informs the GKE metadata server which GSA identity to issue tokens for.
5
Configure `spec.serviceAccountName` in the Deployment spec and apply it to the cluster.
Pods run under the authenticated KSA identity and gain access to GCP resources.
Pods must explicitly select the configured KSA to inherit Workload Identity authentication.

Key Concept

GKE Workload Identity Configuration Sequence
Question 658Question →

A logistics enterprise is deploying a telemetry ingestion pipeline on Google Cloud. The cloud architecture team needs to provision a dedicated Cloud Storage bucket named `telemetry-logs-prod` in the `us-east4` region. According to corporate policy, the bucket must enforce Uniform Bucket-Level Access upon creation, and an existing lifecycle configuration file named `lifecycle.json` must be applied to automatically transition log objects older than 30 days to Nearline storage. Which TWO `gcloud storage` commands should you run to meet these requirements?

Select all that apply

Show answer & explanation

Answer: gcloud storage buckets create gs://telemetry-logs-prod --location=us-east4 --uniform-bucket-level-access; gcloud storage buckets update gs://telemetry-logs-prod --lifecycle-file=lifecycle.json

Answer

Executing `gcloud storage buckets create gs://telemetry-logs-prod --location=us-east4 --uniform-bucket-level-access` to provision the bucket and `gcloud storage buckets update gs://telemetry-logs-prod --lifecycle-file=lifecycle.json` to attach the object lifecycle policy.
To create a bucket with Uniform Bucket-Level Access in a specific region using current Google Cloud standards, use `gcloud storage buckets create` with `--location` and `--uniform-bucket-level-access`. To apply age-based transition rules from a local JSON file, execute `gcloud storage buckets update` with the `--lifecycle-file` flag.

Step-by-Step Solution

1
Provision the Cloud Storage bucket with Uniform Bucket-Level Access enabled.
Bucket `gs://telemetry-logs-prod` is created in region `us-east4` using `gcloud storage buckets create` with the `--uniform-bucket-level-access` flag.
Google Cloud recommends using the `gcloud storage` CLI over legacy `gsutil` for bucket creation and configuration.
2
Apply the Object Lifecycle Management configuration file.
The bucket configuration is updated with `--lifecycle-file=lifecycle.json` using `gcloud storage buckets update`.
Lifecycle rules transition objects based on age conditions, which requires applying a lifecycle JSON file rather than modifying the bucket's default storage class.

Key Concept

Deploying Cloud Storage buckets and configuring object lifecycle policies using the gcloud storage CLI tool.
Question 659Question →

A digital evidence management platform stores high-definition court proceeding videos in Google Cloud Storage. Attorneys access and stream these video recordings frequently during the active trial phase, which lasts for the first 30 days after ingest. Following the 30-day trial period, the videos are rarely accessed but must be retained for 3 years to comply with legal record preservation requirements. You need to plan a Cloud Storage solution that optimizes overall storage and operational costs while avoiding data retrieval fee penalties during the active trial period. Which TWO configuration choices should you select?

Select all that apply

Show answer & explanation

Answer: Set the default storage class of the bucket to Standard Storage for newly uploaded files.; Configure an Object Lifecycle Management rule to transition objects to Coldline Storage 30 days after creation.

Answer

The optimal strategy is to set the default storage class of the bucket to Standard Storage for initial ingestion and configure an Object Lifecycle Management rule to transition objects to Coldline Storage 30 days after creation.
Selecting Standard Storage as the default bucket class ensures zero retrieval fees during the initial 30 days when attorneys stream and edit files frequently. Transitioning objects to Coldline Storage after 30 days matches the requirement for rare access over a 3-year preservation window, significantly lowering storage costs without incurring unexpected retrieval penalties while active.

Step-by-Step Solution

1
Analyze access patterns for the active phase (Days 1 to 30).
Frequent streaming and editing during the first 30 days require Standard Storage to avoid data retrieval charges.
Coldline, Nearline, and Archive classes charge retrieval fees per GB read, making them inappropriate for active, frequently accessed workloads.
2
Analyze access patterns for the archival phase (After 30 days up to 3 years).
Rare access patterns (less than once per quarter) indicate Coldline Storage as the most cost-effective tier meeting the 90-day minimum storage duration expectation.
Coldline Storage offers significantly lower storage costs per GB per month compared to Standard Storage.
3
Define the Lifecycle Management policy.
Set a condition `age: 30` with action `SetStorageClass: COLDLINE`.
Automating the tier transition ensures data is moved precisely when access patterns change from active to long-term preservation.

Key Concept

Planning Cloud Storage Buckets and Storage Classes based on access frequency, retention timelines, and retrieval cost penalties.
Question 660Question →

Your enterprise organization maintains a central networking project named net-host-proj containing a Google Cloud Virtual Private Cloud network named vpc-shared. A separate application development project named app-dev-proj contains its own VPC network named vpc-app-dev. You are deploying a internal Cloud DNS private zone named app.internal in net-host-proj to host custom A records for internal microservices. Virtual machine instances located in both vpc-shared and vpc-app-dev must be able to resolve domain names in the app.internal zone without exposing DNS queries to the public internet. Which TWO actions must you perform to configure Cloud DNS and VPC networking to satisfy this requirement?

Select all that apply

Show answer & explanation

Answer: Add both vpc-shared and vpc-app-dev to the list of authorized networks when creating or updating the app.internal private DNS zone in net-host-proj.; Create a Cloud DNS peering zone in app-dev-proj for app.internal that targets vpc-shared in net-host-proj as the peer network.

Answer

To allow VMs across different VPC networks and projects to resolve custom names in a Cloud DNS private zone, you can either explicitly authorize both VPC networks (vpc-shared and vpc-app-dev) on the private zone in the central project, or set up a Cloud DNS peering zone in the consumer project (app-dev-proj) that targets the host network (vpc-shared).
The correct options represent the two valid approaches in Google Cloud for cross-VPC Cloud DNS private zone resolution. Option A directly adds multiple authorized VPC networks across projects to the private zone configuration. Option D establishes a Cloud DNS peering zone in the consumer project that delegates queries for the private domain to the network hosting the private zone.

Step-by-Step Solution

1
Identify the multi-VPC private DNS resolution options in Google Cloud.
Cloud DNS supports authorizing multiple VPC networks (even across projects with appropriate permissions) on a single private zone, or configuring Cloud DNS Peering zones.
This allows instances in distinct VPC networks to resolve internal domain names managed within a centralized private DNS zone.
2
Evaluate the authorized networks strategy.
Adding both vpc-shared and vpc-app-dev as authorized networks to the app.internal private zone allows instances in both VPC networks to resolve names directly.
Cloud DNS private zones resolve queries originating from any authorized VPC network specified in the zone configuration.
3
Evaluate the DNS peering strategy.
Creating a Cloud DNS peering zone in app-dev-proj for app.internal that targets vpc-shared in net-host-proj enables vpc-app-dev to delegate DNS queries to vpc-shared.
DNS Peering allows a consumer VPC to resolve private DNS names hosted in another network without directly modifying the primary private zone authorization.

Key Concept

Cloud DNS Private Zone Network Authorization and DNS Peering across VPCs
PreviousPage 33 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin