Examkin

Tüm alıştırma soruları

262 soru

Tüm türler1,591Çoktan seçmeli816Çoklu seçim491Sayısal12Eşleştirme10Sıralama262
Soru 101Soru →

A cloud engineer needs to expand the primary IPv4 CIDR range of an existing custom-mode Virtual Private Cloud (VPC) subnet in Google Cloud to accommodate new virtual machines without causing service disruption. What is the correct sequence of steps to plan and execute this subnet expansion?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence for expanding a custom-mode VPC primary subnet range is: 1) Verify that adjacent contiguous IP space is free of conflicts, 2) Select a broader prefix length encompassing the original base IP address, 3) Execute `gcloud compute networks subnets expand-ip-range` with the desired prefix length, and 4) Verify the expanded primary range in the subnet resource configuration.
Proper planning and execution of a GCP custom-mode VPC subnet primary range expansion requires checking for non-overlapping contiguous IP space, calculating a valid expanded prefix length, executing `gcloud compute networks subnets expand-ip-range`, and verifying the updated subnet status.

Adım Adım Çözüm

1
Audit current subnet IP allocation and connected networks
Ensures the planned expanded CIDR block does not collide with existing subnets, VPN tunnels, or interconnect routes.
Subnet expansion will fail or cause routing conflicts if the new IP space overlaps with existing network definitions.
2
Determine the new prefix length for expansion
Identifies a smaller prefix number (e.g., /23 instead of /24) that expands capacity while retaining the existing subnet start address.
GCP subnet expansion only permits broadening the netmask without changing the existing starting IP address boundary.
3
Execute the live expansion command
Applies the primary IP range expansion in place without causing VM downtime.
The `gcloud compute networks subnets expand-ip-range` command dynamically grows the subnet CIDR block online.
4
Confirm the updated subnet resource details
Validates that the subnet reflects the expanded primary IP range.
Post-execution verification confirms the subnet has successfully scaled its capacity.

Anahtar Kavram

VPC Subnet Primary Range Expansion Procedure
Soru 102Soru →

You need to manually migrate running microservice workloads from an existing Google Kubernetes Engine (GKE) node pool to a newly created node pool with minimal disruption. Arrange the following operational steps in the correct execution sequence.

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence is: provision the new node pool (gcloud container node-pools create), cordon the original nodes (kubectl cordon), drain the original nodes (kubectl drain), and delete the empty node pool (gcloud container node-pools delete).
Safe workload migration between GKE node pools requires creating the new node pool first so target capacity exists. Next, cordoning the old nodes ensures no new pods land on them. Draining the old nodes then evicts running workloads, allowing Kubernetes to reschedule them onto the new node pool. Finally, deleting the old node pool cleans up unused GCP resources.

Adım Adım Çözüm

1
Create target node pool
A new node pool is created and attached to the cluster.
Target capacity must be active before evicting workloads from the original nodes to avoid unschedulable pod states.
2
Cordon old nodes
The old nodes are marked with SchedulingDisabled status.
Prevents newly incoming pods or restarted pods from being assigned to the nodes undergoing decommission.
3
Drain old nodes
Pods are safely evicted from old nodes and rescheduled onto the new node pool.
kubectl drain triggers a graceful eviction process that respects PodDisruptionBudgets.
4
Delete original node pool
The old node pool and underlying Compute Engine instances are deleted.
Once all workloads are confirmed to be running on the new node pool, the old infrastructure can be safely removed.

Anahtar Kavram

Manual GKE Node Pool Migration and Node Lifecycle Management
Tahmini Süre:1m 30s
Soru 103Soru →

A Cloud Engineer needs to perform maintenance on a Google Kubernetes Engine (GKE) Standard cluster by replacing an existing node pool with a new machine-type node pool, while ensuring zero workload downtime. Arrange the operational CLI steps in the correct sequential order from first to last to complete this node pool migration safely.

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence is: 1) Create the new target node pool using gcloud container node-pools create, 2) Mark nodes in the old pool as unschedulable using kubectl cordon, 3) Gracefully evict running pods from old nodes using kubectl drain --ignore-daemonsets, 4) Verify workload status and node placement using kubectl get pods -o wide, and 5) Decommission the old node pool using gcloud container node-pools delete.
Safe migration requires creating destination capacity first (gcloud container node-pools create), blocking new pod placement on old nodes (kubectl cordon), gracefully evicting existing workloads (kubectl drain), validating that all pods are healthy on the new pool (kubectl get pods -o wide), and finally deleting the deprecated node pool (gcloud container node-pools delete).

Adım Adım Çözüm

1
Provision target compute capacity in GKE.
A new node pool is initialized and joins the cluster.
Destination capacity must be available before evicting pods to prevent capacity shortages or Unschedulable pod states.
2
Cordon the old nodes in the cluster.
Nodes in the legacy node pool are marked as Unschedulable.
Ensures that any new pods or evicted workloads are routed exclusively to the new node pool.
3
Drain the old nodes.
Existing pods are evicted and rescheduled onto the new node pool.
Gracefully shuts down workloads on old hardware and recreates them on the newly provisioned infrastructure.
4
Inspect pod deployment status across nodes.
Pods are confirmed running and healthy on the new nodes.
Verification confirms that application traffic is served correctly before removing old compute resources.
5
Delete the old node pool.
The old node pool is removed from the cluster.
Safely reclaims resources and avoids unnecessary compute billing.

Anahtar Kavram

GKE Zero-Downtime Manual Node Pool Migration Workflow
Soru 104Soru →

You are deploying a Regional Internal HTTP(S) Load Balancer in a Google Cloud Virtual Private Cloud (VPC) network using the gcloud CLI to service internal microservices. Arrange the required deployment steps in the correct dependency sequence from first to last.

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct deployment sequence is: 1) Create a proxy-only subnet in the region, 2) Create the health check and regional backend service (load balancing scheme INTERNAL_MANAGED) with backend instance groups, 3) Create the regional URL map pointing to the backend service, 4) Create the regional target HTTP proxy referencing the URL map, and 5) Create the regional forwarding rule linking the internal IP to the target proxy.
Deploying a Regional Internal Application Load Balancer follows a strict bottom-up object dependency model: lower-layer resources must exist before higher-layer resources can reference them. First, a proxy-only subnet must be established in the region to host Envoy proxies. Next, backend services and health checks are configured. Once backend services are defined, the URL map can be created. The target HTTP proxy is then built targeting the URL map. Finally, the forwarding rule is created as the frontend entry point that links an internal IP address to the target proxy.

Adım Adım Çözüm

1
Reserve network resources for Envoy proxies.
Proxy-only subnet is provisioned in the VPC for the specified region.
Regional Internal Application Load Balancers require a dedicated proxy-only subnet in the region to instantiate Envoy proxies.
2
Configure backend infrastructure.
Regional backend service configured with INTERNAL_MANAGED scheme and associated with health checks and instance groups.
Backend services define how traffic is distributed and health-checked before frontend routing components can reference them.
3
Configure routing configuration.
URL map object created pointing to the backend service.
The URL map relies on the existence of the destination backend service.
4
Configure target proxy.
Target HTTP proxy created referencing the URL map.
Target HTTP proxies require an existing URL map to route traffic received from forwarding rules.
5
Configure frontend entry point.
Forwarding rule established pointing to the target proxy.
The forwarding rule is the final step in the frontend pipeline, connecting incoming network traffic to the target proxy.

Anahtar Kavram

Internal HTTP(S) Load Balancer Deployment Dependencies
Soru 105Soru →

An organization needs to set up a continuous export of detailed Cloud Billing cost data to BigQuery for central financial analytics. Place the implementation steps in the correct chronological order from first step to final step.

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct order of steps is: 1. Create or select a target Google Cloud project and enable the BigQuery API. 2. Create a destination BigQuery dataset in the target project to host the exported billing tables. 3. Ensure the administrator configuring the export is granted the Billing Account Costs Manager role on the Cloud Billing Account. 4. Navigate to the Billing Export page in the Cloud Billing console and enable Detailed Usage Cost export by selecting the target project and dataset.
Establishing BigQuery billing export requires setting up infrastructure prerequisites before linking the billing account. First, create or select the target project and enable the BigQuery API. Second, create the destination BigQuery dataset inside that project. Third, grant the configuring user the Billing Account Costs Manager role on the billing account. Fourth, use the Cloud Billing console to enable Detailed Usage Cost export by selecting the dataset.

Adım Adım Çözüm

1
Initialize target project infrastructure and enable the BigQuery API.
The target GCP project is ready to manage BigQuery resources.
BigQuery datasets cannot be created until the hosting project exists and its BigQuery API service is enabled.
2
Create the destination BigQuery dataset.
A specific dataset container is established.
The Cloud Billing Export configuration menu requires selecting an existing dataset as the export destination.
3
Verify IAM billing account permissions for the administrator.
The administrator holds the Billing Account Costs Manager role on the Cloud Billing Account.
Project-level administrative roles are insufficient to edit Cloud Billing Account export settings.
4
Link the Billing Account to the BigQuery dataset in the Cloud Billing Console.
Automated pipeline for Detailed Usage Cost export is active.
Selecting the project and dataset under Billing Export completes the continuous export workflow.

Anahtar Kavram

Configuring Cloud Billing BigQuery export requires creating the destination project and dataset, securing Billing Account Costs Manager permissions, and defining the export sink in the Cloud Billing console.
Tahmini Süre:1m 30s
Soru 106Soru →

A cloud engineer needs to grant a newly hired developer access to view Cloud Storage objects in a specific project using the gcloud CLI while following Google Cloud security best practices. What is the correct sequence of steps to configure this access?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct workflow follows four sequential steps: first identifying the least-privilege predefined role (`roles/storage.objectViewer`), identifying the target user identity, adding the IAM policy binding via `gcloud projects add-iam-policy-binding`, and verifying the binding using `gcloud projects get-iam-policy`.
The correct sequence begins by planning access: selecting the least-privilege predefined role (`roles/storage.objectViewer`) and establishing the user's principal identifier. Next, the administrator applies the policy change using `gcloud projects add-iam-policy-binding`. Finally, standard operational best practices dictate verifying the applied policy with `gcloud projects get-iam-policy`.

Adım Adım Çözüm

1
Determine the required predefined role
Selected `roles/storage.objectViewer` instead of primitive roles like `roles/viewer` or `roles/editor` to follow least privilege.
Least privilege requires using specific predefined roles tailored to the minimal necessary permissions.
2
Identify the target user's identity
Obtained the user's principal email address formatted as `user:[email protected]`.
IAM bindings require a correctly formatted member descriptor type and identity.
3
Add the IAM policy binding via CLI
Ran `gcloud projects add-iam-policy-binding` with the target member and role.
This modifies the project IAM policy to grant the specified role to the user identity.
4
Validate permission assignment
Executed `gcloud projects get-iam-policy` to view the updated policy object.
Verification confirms that the policy binding was stored correctly without unintended scope changes.

Anahtar Kavram

Managing IAM Roles and Resource Access Permissions via gcloud CLI using least privilege principles
Tahmini Süre:1m 30s
Soru 107Soru →

A firmware distribution engineering team needs to provision a new public Cloud Storage bucket in a dual-region, enforce uniform security permissions, grant anonymous public read access, and attach an object lifecycle policy using the gcloud CLI. What is the correct sequence of steps to configure this storage solution?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence is: First, create the bucket using gcloud storage buckets create; second, enable Uniform Bucket-Level Access; third, bind the roles/storage.objectViewer IAM role to allUsers; fourth, apply the lifecycle configuration file.
The deployment sequence follows logical GCP operational lifecycle order: provisioning the container resource (gcloud storage buckets create), setting security boundaries (enabling Uniform Bucket-Level Access), defining identity access controls (granting roles/storage.objectViewer to allUsers), and finally applying automated lifecycle rules (updating bucket with --lifecycle-file).

Adım Adım Çözüm

1
Provision the initial Cloud Storage bucket resource.
Bucket gs://firmware-dist-2026 is created in the nam4 dual-region location.
Subsequent configuration commands require an existing bucket target.
2
Configure bucket security controls.
Uniform Bucket-Level Access is enabled on the bucket.
Best practice requires enforcing uniform access control before assigning bucket-level IAM roles.
3
Apply IAM access controls.
allUsers identity is assigned roles/storage.objectViewer on the bucket.
Allows public read access to firmware binaries stored inside the bucket.
4
Apply object lifecycle management.
Lifecycle rules defined in policy.json are active on the bucket.
Automates long-term object state transitions once the bucket operational profile is established.

Anahtar Kavram

Sequential provisioning and configuration of Cloud Storage buckets using modern gcloud storage CLI tooling.
Tahmini Süre:2m 0s
Soru 108Soru →

A cloud engineer at a genomics research firm needs to set up a new Cloud Storage bucket in `us-east1` to store raw sequencing data. The deployment must enforce Uniform Bucket-Level Access, apply a 30-day object transition rule to Nearline storage defined in a local JSON file, and ingest the initial dataset. In what operational sequence should the engineer execute these tasks?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct operational sequence is: 1) Provision the bucket using `gcloud storage buckets create` with `--uniform-bucket-level-access`, 2) Create the local `lifecycle.json` policy file, 3) Apply the policy using `gcloud storage buckets update --lifecycle-file=lifecycle.json`, and 4) Upload the data files using `gcloud storage cp`.
The deployment workflow follows a strict dependency order: provision the Cloud Storage bucket with security constraints (Uniform Bucket-Level Access) first, author the local lifecycle policy JSON file second, attach the policy to the existing bucket third, and upload the data files fourth.

Adım Adım Çözüm

1
Provision the Cloud Storage bucket using `gcloud storage buckets create` with `--uniform-bucket-level-access`.
The target bucket `gs://genomics-sequencing-data-2026` is created in `us-east1` with uniform bucket-level access enabled.
A Cloud Storage bucket must exist before any configuration updates or object uploads can take place.
2
Draft the lifecycle rule definition in a local file named `lifecycle.json`.
A JSON configuration file containing the rule to transition objects to Nearline storage after 30 days is available locally.
The Google Cloud CLI requires a local file path to read the lifecycle policy JSON definition.
3
Apply the lifecycle policy to the bucket using `gcloud storage buckets update` with `--lifecycle-file`.
The lifecycle rule is attached and active on the target bucket.
Configuring lifecycle policies prior to data ingest ensures all newly uploaded objects are immediately governed by lifecycle rules.
4
Upload raw sequencing files to the bucket using `gcloud storage cp`.
Sequencing data files are safely transferred into the fully configured Cloud Storage bucket.
Objects should be uploaded only after the bucket parameters and lifecycle rules are active.

Anahtar Kavram

Deploying Cloud Storage buckets using modern gcloud storage CLI commands and configuring object lifecycle management policies.
Soru 109Soru →

A Cloud Engineer needs to provision a new Google Kubernetes Engine (GKE) cluster in zone `us-central1-a` named `web-cluster`, configure local command-line access, and deploy an application defined in a local file named `web-deployment.yaml`. In which sequence should the engineer execute the following commands to successfully deploy and verify the workload?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct operational sequence is: 1) Create the GKE cluster using `gcloud container clusters create`, 2) Generate local authentication credentials with `gcloud container clusters get-credentials`, 3) Deploy the workload manifest using `kubectl apply -f web-deployment.yaml`, and 4) Verify pod status using `kubectl get pods`.
The correct operational order follows the logical deployment lifecycle in GCP: first create the cluster infrastructure (`gcloud container clusters create`), then obtain API cluster credentials and configure local context (`gcloud container clusters get-credentials`), next apply the workload deployment manifest (`kubectl apply -f`), and finally verify that the pods are running correctly (`kubectl get pods`).

Adım Adım Çözüm

1
Provision the GKE cluster control plane and worker nodes.
The GKE cluster `web-cluster` becomes active and accessible in the target Google Cloud zone.
You cannot retrieve credentials or apply Kubernetes manifests without an active running cluster.
2
Execute `gcloud container clusters get-credentials` for the cluster.
The local `~/.kube/config` file is populated with entry endpoints and auth tokens for `web-cluster`.
`kubectl` requires local authentication parameters and cluster endpoints to communicate with the GKE control plane API.
3
Execute `kubectl apply -f web-deployment.yaml`.
Kubernetes API creates the specified Deployment object and starts scheduling Pods.
Manifests can only be applied after `kubectl` has a valid active context pointing to the target cluster.
4
Execute `kubectl get pods` to verify execution.
Returns the status (e.g., Running) of the newly spawned application pods.
Checking resource status confirms whether image pulling, scheduling, and pod startup succeeded.

Anahtar Kavram

GKE Cluster Deployment and Administration Lifecycle
Soru 110Soru →

An administrator observes that a recent container image update to a Google Kubernetes Engine (GKE) deployment named `web-app` introduced application errors. The administrator needs to inspect the revision history, roll back the deployment to the previous working revision, and confirm that the rollback completes successfully. What is the correct chronological sequence of `kubectl` commands to perform this operation?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence of operations is: First, inspect the revision history (`kubectl rollout history deployment/web-app`). Second, execute the rollback to the previous revision (`kubectl rollout undo deployment/web-app`). Third, monitor and verify the rollout status (`kubectl rollout status deployment/web-app`).
When managing GKE workloads, the proper sequence for restoring a failed deployment rollout is: 1) inspect the revision history to identify previous versions (`kubectl rollout history`), 2) revert the deployment to the previous revision (`kubectl rollout undo`), and 3) monitor the progress until completion (`kubectl rollout status`).

Adım Adım Çözüm

1
Run `kubectl rollout history deployment/web-app`
Displays the list of deployment revisions and change causes.
You must inspect the revision history first to verify previous revision numbers before performing a rollback.
2
Run `kubectl rollout undo deployment/web-app`
Initiates a rolling update to revert the deployment spec to the previous revision.
The `rollout undo` command is the standard Kubernetes command to revert a workload deployment to its prior state.
3
Run `kubectl rollout status deployment/web-app`
Streams the status updates until all target replicas are running and ready.
Monitoring the status ensures the rollback completes without hanging or failing due to pod creation issues.

Anahtar Kavram

GKE Deployment Rollback Operations
Soru 111Soru →

What is the correct sequence of operational steps to deploy a custom Virtual Private Cloud (VPC) network, provision a regional subnet, deploy a VM instance into that subnet, and enforce ingress firewall rules targeting the instance?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence begins with creating the custom mode VPC network, followed by defining a regional subnet, deploying the VM instance with a target network tag inside that subnet, and finally creating an ingress firewall rule matching the target tag.
In Google Cloud, resource creation follows a strict logical dependency chain. A custom VPC network must be created first because subnets depend on a parent network. Once the custom network exists, a regional subnet must be created to provide IP address space. A VM instance can then be provisioned within that subnet with appropriate target network tags. Finally, an ingress firewall rule is created to target those tags and permit incoming network traffic.

Adım Adım Çözüm

1
Create the parent custom-mode VPC network.
A VPC network resource is created without any automatic default subnets.
Subnets require a parent VPC network resource to exist first.
2
Create a regional subnet inside the new VPC network.
A subnet IP range is allocated in the specified GCP region.
Compute instances in custom VPC networks require an existing regional subnet for primary network interfaces.
3
Provision a VM instance in the subnet and apply target network tags.
The VM instance starts with an IP address from the subnet and carries the network tag.
Target tags on instances allow fine-grained firewall rule association.
4
Create an ingress firewall rule referencing the target network tag.
Traffic matching allowed ports and protocols reaches the tagged VM instance.
Firewall rules govern network access to instances filtered by target network tags.

Anahtar Kavram

Deployment lifecycle order for custom mode VPC networks, subnets, VM instances, and firewall rules in Google Cloud.
Soru 112Soru →

A Cloud Engineer is tasked with bringing an existing, manually created Compute Engine VM instance named `legacy-app-vm` under Terraform management. The infrastructure state must be maintained in a remote Google Cloud Storage (GCS) backend. In what sequence should the engineer execute the following steps to safely import the VM instance without causing resource recreation or downtime?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct deployment sequence is: 1) Configure the GCS backend and run `terraform init`, 2) Declare a skeleton resource block in HCL, 3) Execute `terraform import` using the GCP resource identifier, 4) Update the HCL resource arguments to match live attributes, and 5) Run `terraform plan` to confirm zero pending changes.
Importing existing GCP infrastructure into Terraform requires initializing the remote backend first, declaring an empty resource block in code to anchor the import command, pulling live state via `terraform import`, updating the HCL code to match the state, and validating zero plan diffs with `terraform plan`.

Adım Adım Çözüm

1
Initialize Remote Backend
State storage is linked to the designated GCS bucket.
Initializing the GCS backend ensures state locking and guarantees that imported resource metadata persists directly to remote state.
2
Declare Skeleton Resource Identifier
Terraform recognizes `google_compute_instance.legacy_vm` as a valid target address.
The `terraform import` CLI command fails if the target resource address is missing from configuration files.
3
Import Existing GCP Resource
Live VM metadata is written to the GCS remote state.
This binds the actual GCP instance object to the Terraform resource address without modifying live infrastructure.
4
Align HCL Code with Live Attributes
HCL definitions match all imported properties such as machine type, disk settings, and network interfaces.
Terraform state holds the imported values, but code files must be manually matched to prevent drift.
5
Validate Parity with `terraform plan`
Terraform reports 'No changes. Your infrastructure matches the configuration.'
Running plan verifies that future execution of `terraform apply` will not attempt to update or recreate the imported instance.

Anahtar Kavram

Terraform Resource Import & GCS State Synchronization
Soru 113Soru →

A cloud engineer needs to deploy a Compute Engine virtual machine instance that automatically executes a bash initialization script stored in a private Cloud Storage bucket upon booting. The VM must adhere to the principle of least privilege using a custom service account. Arrange the required administrative steps in the correct chronological sequence from first to last.

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence of steps is: 1) Create the custom service account, 2) Grant the service account Storage Object Viewer permissions on the script bucket, 3) Upload the initialization script to Cloud Storage, 4) Deploy the VM with gcloud using the service account and startup-script-url metadata flags, and 5) Verify script execution logs via the serial port output.
The correct procedural order ensures identity creation and resource authorization occur before instance provisioning. First, creating the custom service account establishes a dedicated identity. Second, assigning the Storage Object Viewer IAM role on the bucket grants the necessary read permission. Third, staging the script file in Cloud Storage ensures the asset exists. Fourth, invoking gcloud compute instances create attaches the service account with --scopes=cloud-platform and supplies the --metadata=startup-script-url flag. Finally, retrieving serial port output validates that the startup script completed without error.

Adım Adım Çözüm

1
Define workload identity
Custom service account created without default editor privileges.
Following the principle of least privilege requires establishing a specific non-default service account identity first.
2
Configure IAM access control
Service account authorized with Storage Object Viewer on the target bucket.
The startup script fetching mechanism runs under the instance service account identity during boot, requiring read access to Cloud Storage.
3
Stage application artifacts
Initialization script file uploaded to the GCS bucket path.
The file resource must exist at the specified gs:// URI prior to triggering the instance provisioning workflow.
4
Provision the Compute Engine VM
Instance created with custom service account identity and metadata key pointing to GCS URI.
Passing startup-script-url via metadata tells the Compute Engine startup agent to fetch and run the script automatically on boot.
5
Validate deployment
Serial console log stream inspected for successful script execution.
Serial port output records startup script stdout/stderr, providing positive empirical proof of successful initialization.

Anahtar Kavram

Deploying Compute Engine VMs with Custom Service Accounts and Cloud Storage Startup Scripts
Tahmini Süre:2m 0s
Soru 114Soru →

A cloud engineer needs to deploy a custom Virtual Private Cloud (VPC) infrastructure in Google Cloud to host secure internal applications. The requirements specify creating a VPC network without automatic subnet creation, provisioning a regional subnet, launching a Compute Engine VM with a specific network tag in that subnet, and enforcing an ingress firewall rule that allows SSH traffic (TCP port 22) exclusively to instances carrying that network tag. In what order should the engineer execute the following `gcloud` CLI commands to ensure all resource dependencies are satisfied without errors?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct operational sequence begins with provisioning the parent VPC network in custom subnet mode (`gcloud compute networks create --subnet-mode=custom`), followed by creating the regional custom subnet inside that network (`gcloud compute networks subnets create`), then launching the Compute Engine VM instance attached to the subnet with the designated network tag (`gcloud compute instances create --tags`), and finally creating the ingress firewall rule configured with matching target tags on the VPC network (`gcloud compute firewall-rules create --target-tags`).
Resource creation in Google Cloud networking strictly follows a hierarchical dependency structure: Network → Subnet → Compute Instance with Tags → Firewall Rule targeting Tags. Creating the VPC network with `--subnet-mode=custom` establishes the network container. Next, explicit creation of the regional subnet defines the IP address space. The VM instance is then provisioned into that subnet and assigned network tags. Finally, the firewall rule targeting those network tags is created on the network.

Adım Adım Çözüm

1
Create the custom VPC network
The VPC network `enterprise-vpc` is created in custom mode with no default regional subnets.
VPC subnets, compute instances, and firewall rules depend on a pre-existing VPC network resource.
2
Create the regional custom subnet within the VPC network
The subnet `prod-subnet-us-central1` with CIDR `10.10.0.0/24` is created in `us-central1`.
In custom mode VPCs, subnets are not created automatically; instances cannot be provisioned without specifying an existing subnet.
3
Provision the Compute Engine VM instance in the custom subnet with the network tag
The instance `app-vm-1` receives an IP in `10.10.0.0/24` and is labeled with the tag `bastion-ssh-target`.
Target network tags must be present on instance metadata for tag-based firewall filtering to evaluate and route traffic to the intended host.
4
Deploy the ingress firewall rule filtering by target network tag
An ingress rule allowing TCP port 22 is attached to `enterprise-vpc`, targeting only instances tagged `bastion-ssh-target`.
Firewall rules reference the VPC network and filter traffic directed to tagged compute workloads.

Anahtar Kavram

GCP VPC Resource Dependency Hierarchy and Deployment Sequencing
Tahmini Süre:2m 30s
Soru 115Soru →

A Cloud Engineer is initializing a new infrastructure environment on Google Cloud using Terraform. The working directory contains valid `.tf` configuration files. What is the correct chronological sequence of Terraform CLI commands to initialize the working directory, preview proposed infrastructure changes, provision the GCP resources, and finally decommission the resources when no longer needed?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence begins with workspace initialization using `terraform init`, followed by generating an execution preview with `terraform plan`, executing infrastructure creation with `terraform apply`, and ending with resource teardown via `terraform destroy`.
The standard Terraform workflow requires preparing the environment (`init`), validating proposed actions (`plan`), executing provisioning calls (`apply`), and lastly performing cleanup (`destroy`).

Adım Adım Çözüm

1
Initialize working directory
`terraform init` downloads provider plugins and configures state backend.
Terraform requires initialization before it can recognize provider definitions and execute any downstream commands.
2
Generate execution preview
`terraform plan` outputs proposed resource changes.
Planning ensures that unexpected modifications or syntax errors are identified prior to altering live cloud infrastructure.
3
Apply infrastructure updates
`terraform apply` calls GCP APIs to create and update resources.
This step turns the defined configuration code into active Google Cloud infrastructure components.
4
Decommission environment
`terraform destroy` removes all tracked state resources.
Destruction is the final step in the lifecycle, removing resources when they are no longer required.

Anahtar Kavram

Terraform Deployment Lifecycle Command Sequence
Soru 116Soru →

A DevOps engineer needs to deploy an event-driven Python microservice to Cloud Functions (2nd gen) that processes real-time telemetry published to a Cloud Pub/Sub topic in Google Cloud. The deployment must enforce least-privilege security by using a custom service account for function execution and Eventarc event handling. What is the correct sequence of steps to configure, deploy, and verify this serverless application using the gcloud CLI?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence begins by creating the Pub/Sub topic (item 1), creating and granting roles to the custom service account (item 2), deploying the Cloud Function 2nd gen with the appropriate gcloud flags (item 3), binding the Cloud Run Invoker IAM role to the Eventarc trigger (item 4), and finally testing and inspecting execution in Cloud Logging (item 5).
Deploying a 2nd generation Cloud Function with event triggers requires setting up dependent resources first (Pub/Sub topic and IAM execution service account), running the deployment command specifying 2nd gen architecture, ensuring the Eventarc trigger identity has Cloud Run Invoker permissions on the underlying service, and finally testing execution by publishing a message and checking Cloud Logging.

Adım Adım Çözüm

1
Provision the Pub/Sub event source
Cloud Pub/Sub topic is available to receive message streams.
Cloud Functions 2nd gen event triggers depend on pre-existing Pub/Sub topics or Eventarc sources.
2
Configure identity and IAM permissions
A custom service account exists with `roles/eventarc.eventReceiver` granted.
Least-privilege security mandates dedicated execution identities over default compute service accounts.
3
Deploy the 2nd gen function
Cloud Functions provisions the container image on Cloud Run and sets up Eventarc routing.
The `gcloud functions deploy` CLI command compiles and deploys the function infrastructure.
4
Authorize trigger invocation
Eventarc is granted `roles/run.invoker` on the provisioned service.
2nd gen Cloud Functions execute as Cloud Run services; event triggers fail if the invoking service account lacks invoker rights.
5
Validate deployment in Cloud Logging
Event consumption and execution log entries appear in Log Explorer.
Publishing a test message confirms end-to-end functionality from trigger source to serverless application handler.

Anahtar Kavram

Deploying Cloud Functions (2nd gen) with Cloud Pub/Sub triggers and IAM service accounts
Soru 117Soru →

A Cloud Engineer needs to establish automated cost controls by configuring a Cloud Billing budget to publish programmatic threshold notifications to a Cloud Pub/Sub topic. What is the correct sequence of steps to perform this configuration?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence of steps is: 1) Create the Cloud Pub/Sub topic, 2) Grant the Pub/Sub Publisher role to the Cloud Billing service account, 3) Open Budgets & alerts in the Cloud Billing console, 4) Configure the budget scope, target amount, and threshold rules, and 5) Enable programmatic notifications and select the Pub/Sub topic under budget Actions.
Configuring programmatic billing notifications requires establishing the messaging infrastructure before linking it to budget rules. First, the Cloud Pub/Sub topic must be created. Next, the Cloud Billing service account must be granted `roles/pubsub.publisher` access so it has permission to publish messages. Once infrastructure authorization is ready, the engineer opens the Budgets & alerts interface in Cloud Billing, defines the budget limits and threshold rules, and finally connects the budget to the target Pub/Sub topic under Actions.

Adım Adım Çözüm

1
Provision the Pub/Sub notification endpoint.
A Cloud Pub/Sub topic is established in the project.
Creating the Pub/Sub topic first ensures that a valid target resource exists before configuring access policies or budget actions.
2
Authorize the Cloud Billing backend service.
The Cloud Billing service account is assigned the Pub/Sub Publisher role on the newly created topic.
Without explicit publisher permissions on the target topic, Cloud Billing cannot deliver automated notification messages when thresholds are reached.
3
Open billing management tools.
The engineer accesses the Budgets & alerts section within Cloud Billing.
This console location provides the controls required to create and manage billing budget alerting rules.
4
Define budget targets and alert triggers.
Budget scope, spending limit, and percentage thresholds (e.g., 50%, 90%, 100%) are set up.
Establishing threshold rules specifies the exact spending conditions under which notification events will fire.
5
Connect the budget to the programmatic Pub/Sub endpoint.
The budget is linked to the Pub/Sub topic under the Actions configuration panel.
This final binding enables programmatic notification messages to be published to the topic upon threshold breaches.

Anahtar Kavram

Programmatic Cloud Billing budget notifications with Cloud Pub/Sub integration
Soru 118Soru →

A cloud administrator needs to upgrade the machine type of a node pool in a production Google Kubernetes Engine (GKE) Standard cluster to handle increased resource demands without incurring workload downtime. What is the correct sequence of steps to perform this node pool migration safely?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence begins with provisioning the new node pool (`pool-v2`), followed by cordoning nodes in the old pool (`pool-v1`), draining the old pool to migrate pods, and finally deleting the old node pool once migration completes.
In GKE node pool migrations, zero-downtime is achieved by following a structured blue-green workflow. First, provision new capacity (`pool-v2`). Second, cordon the original nodes (`pool-v1`) to prevent new pod assignments. Third, drain the original nodes to gracefully evict running pods so Kubernetes deployment controllers recreate them on `pool-v2`. Fourth, delete `pool-v1` after verifying all pods are running successfully on the new nodes.

Adım Adım Çözüm

1
Execute `gcloud container node-pools create pool-v2 ...` to add target capacity.
A new GKE node pool with the larger machine type is created and joins the cluster.
Destination nodes must exist so that evicted pods have available capacity to be rescheduled onto immediately.
2
Execute `kubectl cordon` targeting nodes in `pool-v1`.
Old nodes are marked as unschedulable (`SchedulingDisabled`).
Cordoning prevents new pods from landing on the legacy nodes while preparing for eviction.
3
Execute `kubectl drain` targeting nodes in `pool-v1`.
Pods on `pool-v1` nodes are gracefully evicted and rescheduled by Kubernetes on `pool-v2`.
Draining triggers orderly pod termination and rescheduling without causing service downtime.
4
Execute `gcloud container node-pools delete pool-v1 ...`.
The legacy node pool and its associated Compute Engine VM instances are deleted.
Deleting empty legacy nodes frees up project resources after verifying workload health on the new pool.

Anahtar Kavram

GKE Blue-Green Node Pool Migration Sequence
Soru 119Soru →

A Kubernetes administrator needs to migrate production workloads from an existing node pool (`pool-v1`) to a newly provisioned node pool (`pool-v2`) in a Google Kubernetes Engine (GKE) Standard cluster without incurring application downtime. Sequence the operational commands in the correct execution order to complete this migration safely.

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct operational sequence is: 1) Provision target node pool `pool-v2` using `gcloud container node-pools create`, 2) Cordon all nodes in `pool-v1` using `kubectl cordon`, 3) Drain nodes in `pool-v1` using `kubectl drain`, and 4) Delete `pool-v1` using `gcloud container node-pools delete`.
To migrate GKE workloads safely without downtime, you must first create target compute capacity (`gcloud container node-pools create`), prevent new pods from landing on old nodes (`kubectl cordon`), gracefully evict existing pods to trigger rescheduling onto new nodes (`kubectl drain`), and finally decommission old infrastructure (`gcloud container node-pools delete`).

Adım Adım Çözüm

1
Provision `pool-v2` using `gcloud container node-pools create`.
A new node pool is created and enters the READY state to accept workloads.
Target compute capacity must exist before evicting workloads from existing nodes to prevent service disruption.
2
Mark nodes in `pool-v1` as unschedulable using `kubectl cordon`.
Existing pods remain running on `pool-v1`, but new pods will not be scheduled onto these nodes.
Cordoning ensures that evicted pods or new replica pods are forced to schedule onto the newly provisioned `pool-v2` nodes.
3
Evict pods from `pool-v1` using `kubectl drain`.
Pods on `pool-v1` nodes are gracefully evicted and rescheduled by Kubernetes onto `pool-v2`.
Draining triggers controlled eviction while respecting PodDisruptionBudgets.
4
Decommission `pool-v1` using `gcloud container node-pools delete`.
The old node pool and underlying Compute Engine instances are deleted.
Once `pool-v1` is empty and workloads are fully running on `pool-v2`, removing the old node pool stops unnecessary resource billing.

Anahtar Kavram

GKE Blue-Green Node Pool Migration Sequence
Soru 120Soru →

Your team needs to deploy a Global External Application Load Balancer using the `gcloud` CLI to serve traffic for a newly created Compute Engine instance group. Arrange the following deployment steps in the correct sequential order from initial backend configuration to final frontend entry point creation.

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct order of deployment steps is: 1) Create a health check and backend service, then add the instance group; 2) Create a URL map referencing the backend service; 3) Create a target HTTP proxy referencing the URL map; 4) Create a global forwarding rule referencing the target HTTP proxy.
Google Cloud Load Balancer resources follow a strict bottom-up dependency model. You must create the backend infrastructure (health check and backend service with instance group backends) first, followed by the URL map which points to the backend service, then the target proxy pointing to the URL map, and finally the forwarding rule which directs external IP traffic to the target proxy.

Adım Adım Çözüm

1
Configure backend service infrastructure and attach instance group
The backend service and health check are ready to accept traffic.
Higher-level HTTP routing objects depend on an existing backend service target.
2
Create URL map to direct request paths to the backend service
URL routing logic is established.
URL maps require a default backend service parameter.
3
Create target HTTP proxy referencing the URL map
Target proxy is configured to route HTTP requests according to URL map rules.
Target proxies require an existing URL map.
4
Create global forwarding rule binding an external IP/port to the target proxy
Frontend IP receives external traffic and forwards it to the target proxy.
Forwarding rules require a target proxy parameter as their destination.

Anahtar Kavram

GCP Load Balancer Component Dependency Architecture
ÖncekiSayfa 6 / 14Sonraki
Tüm alıştırma soruları — Google Cloud Associate Cloud Engineer | Examkin