Examkin

All practice questions

1591 questions

All types1,591Multiple choice816Multiple select491Numeric12Matching10Ordering262
Question 1461Question →

A cloud engineer needs to enable Private Google Access on an existing subnetwork named `app-backend-subnet` located in the `us-east4` region. This is required so that Compute Engine instances without external IP addresses residing in this subnet can access Google Cloud APIs and services. Which `gcloud` command should the engineer run to modify the subnetwork settings correctly?

Show answer & explanation

Answer: gcloud compute networks subnets update app-backend-subnet --region=us-east4 --enable-private-ip-google-access

Answer

The command 'gcloud compute networks subnets update app-backend-subnet --region=us-east4 --enable-private-ip-google-access' correctly enables Private Google Access for instances in the specified subnetwork.
Private Google Access allows Compute Engine VMs with internal IP addresses only to reach Google APIs and services. It is enabled on a per-subnet basis using 'gcloud compute networks subnets update <SUBNET_NAME> --region=<REGION> --enable-private-ip-google-access'.

Step-by-Step Solution

1
Identify the target resource and scope for Private Google Access.
Private Google Access is a regional subnetwork property, so the command must target 'gcloud compute networks subnets'.
VPC subnetworks are regional resources in GCP.
2
Select the appropriate gcloud subcommand and flag.
Use 'update' along with the flag '--enable-private-ip-google-access' and specify '--region=us-east4'.
The update subcommand modifies existing subnetwork settings without recreating the resource.

Key Concept

Subnet-level configuration for Private Google Access
Estimated Time:1m 30s
Question 1462Question →

A security analyst is hardening a Cloud Storage bucket named `compliance-audit-logs` that currently permits fine-grained Access Control Lists (ACLs). The analyst needs to restrict access control exclusively to IAM policies across all current and future objects, while granting an internal compliance team view access to the stored logs. Which TWO actions should the security analyst perform to achieve this requirement? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Enable Uniform Bucket-Level Access on the `compliance-audit-logs` bucket.; Grant the `roles/storage.objectViewer` IAM role to the compliance team identity on the `compliance-audit-logs` bucket.

Answer

The security analyst should enable Uniform Bucket-Level Access on the bucket and grant the predefined `roles/storage.objectViewer` IAM role to the compliance team at the bucket level.
To ensure access control is managed exclusively through IAM, Uniform Bucket-Level Access must be enabled on the target Cloud Storage bucket. To grant the required read access to log objects adhering to the principle of least privilege, the predefined role `roles/storage.objectViewer` should be assigned to the compliance team at the bucket level.

Step-by-Step Solution

1
Enforce unified access management by disabling legacy fine-grained ACLs.
Uniform Bucket-Level Access is enabled, ensuring that individual object ACLs are ignored and only IAM policies govern access.
Uniform Bucket-Level Access unifies access management under Cloud IAM, eliminating ACL bypass security risks.
2
Assign the least-privilege predefined IAM role for read operations.
The compliance team receives read access to all objects within the specific bucket without gaining unintended access across the project.
The predefined role `roles/storage.objectViewer` provides the necessary object-read permissions scoped to the target bucket.

Key Concept

Uniform Bucket-Level Access and Predefined Storage IAM Roles
Question 1463Question →

A DevOps engineer is investigating a potential data leak from a sensitive BigQuery dataset hosted in project `corp-analytics-prod`. The engineer runs a `gcloud logging read` command to inspect read operations recorded in Cloud Audit Logs. Although the engineer has been granted the Logs Viewer (`roles/logging.viewer`) role at the project level, the command execution returns no log entries for data read operations, returning only system Admin Activity logs. Which IAM role assignment adheres to the principle of least privilege while enabling the engineer to view these Data Access audit logs?

Show answer & explanation

Answer: Grant the engineer the Private Logs Viewer (`roles/logging.privateLogViewer`) role on project `corp-analytics-prod`.

Answer

Granting the Private Logs Viewer (`roles/logging.privateLogViewer`) role at the project level allows reading Data Access audit log entries while maintaining least privilege.
Data Access audit logs contain sensitive resource access information and are classified as private logs in Google Cloud Logging. The standard Logs Viewer role lacks the `logging.privateLogEntries.list` permission. Granting the Private Logs Viewer role fulfills the requirement using the least privilege principle.

Step-by-Step Solution

1
Identify the type of logs being queried
The engineer is attempting to view read operations on data, which are classified under Data Access Cloud Audit Logs.
Data Access audit logs are treated as private logs because they contain sensitive operation details and access metadata.
2
Analyze why the existing IAM role is insufficient
The standard Logs Viewer (`roles/logging.viewer`) role only permits reading public logs and Admin Activity logs, filtering out Data Access audit logs.
Google Cloud requires explicit private log viewing permissions (`logging.privateLogEntries.list`) to read Data Access audit logs.
3
Select the appropriate role adhering to least privilege
Assigning Private Logs Viewer (`roles/logging.privateLogViewer`) provides the necessary permission (`logging.privateLogEntries.list`) without granting administrative capabilities.
This specifically grants access to read private log entries without granting overprivileged resource management roles.

Key Concept

Cloud Audit Logs Access Control and Private Log Viewing
Estimated Time:2m 0s
Question 1464Question →

A financial firm enforces an Organization Policy at the root Organization node using the list constraint `constraints/sql.restrictPublicIp` to prevent Cloud SQL instances from being created with public IP addresses. A database team requires public IP access temporarily for instances created inside a specific folder named `Partner-Staging`. How should the administrator configure the governance controls on the `Partner-Staging` folder to allow public IP allocation for SQL instances inside that folder without affecting the rest of the organization?

Show answer & explanation

Answer: Set an Organization Policy enforcement override at the `Partner-Staging` folder level for `constraints/sql.restrictPublicIp` to allow public IP configuration.

Answer

Set an Organization Policy enforcement override at the `Partner-Staging` folder level for `constraints/sql.restrictPublicIp` to allow public IP configuration.
Organization Policies evaluate resource state restrictions hierarchically. To grant an exception for resources contained within a specific folder, an Organization Policy rule must be applied directly at that folder node to override or reset the inherited constraint from the root organization.

Step-by-Step Solution

1
Identify the governance mechanism required to permit resource configuration exceptions across a specific resource hierarchy node.
Recognize that Organization Policies enforce constraints on resources regardless of user IAM permissions.
IAM grants permissions to identity principals, whereas Organization Policy constraints enforce boundaries on resources.
2
Evaluate how policy constraints propagate through the GCP resource hierarchy.
Child nodes (folders and projects) inherit parent constraints by default unless explicit policy rules or overrides are applied at the lower node level.
Configuring a policy constraint override at the target folder node selectively alters enforcement for resources contained within that folder.

Key Concept

Organization Policy Hierarchy and Inheritance
Question 1465Question →

A DevOps engineer needs to grant an external automation pipeline short-lived authorization to upload build artifacts to a Google Cloud Storage bucket in project `proj-prod` without using long-lived service account key files. The engineer decides to implement service account impersonation. What is the correct sequence of steps to configure and execute this secure delegation workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order begins with creating the dedicated service account, followed by granting object administration permissions to the service account on the Cloud Storage bucket, then delegating the Service Account Token Creator role on the service account to the calling principal, and finally running the gcloud command with the --impersonate-service-account flag.
The workflow follows logical identity management dependency. First, the service account identity must be created in the project (`[email protected]`). Second, resource permissions (`roles/storage.objectAdmin`) are granted to the service account so it possesses the necessary permissions. Third, impersonation privileges (`roles/iam.serviceAccountTokenCreator`) are granted on the service account resource to the external caller identity. Finally, the external caller executes the gcloud CLI command with `--impersonate-service-account` to generate short-lived tokens dynamically.

Step-by-Step Solution

1
Create the user-managed service account
Establishes a dedicated identity (`[email protected]`) in GCP IAM.
An identity must be instantiated in IAM before role bindings or delegation rules can target it.
2
Bind the target resource access role to the service account
Assigns `roles/storage.objectAdmin` on the destination bucket to the service account.
Defines what operations the service account is authorized to perform when active.
3
Grant Service Account Token Creator permission to the external caller
Binds `roles/iam.serviceAccountTokenCreator` on the service account resource to the principal initiating the workflow.
Allows the external caller identity to mint short-lived OAuth 2.0 access tokens for the target service account.
4
Invoke gcloud command with impersonation flag
The CLI automatically exchanges the caller's credentials for a temporary service account token and executes the storage upload operation.
Verifies end-to-end functionality using short-lived credentials without generating static private keys.

Key Concept

Service Account Creation, Permission Delegation, and Impersonation Sequence
Question 1466Question →

An engineer needs to resize a standalone Compute Engine virtual machine instance named `db-primary` to a larger machine type (`e2-standard-8`) to handle increased workload demand. The instance is currently in the RUNNING state and has a persistent disk attached. Which process must be used to successfully modify the machine type of this VM instance?

Show answer & explanation

Answer: Stop the VM instance, execute `gcloud compute instances set-machine-type db-primary --machine-type=e2-standard-8`, and start the VM instance.

Answer

The correct action is to stop the VM instance, change the machine type using `gcloud compute instances set-machine-type`, and then start the VM instance.
To modify the machine type (vCPU and RAM) of an unmanaged or standalone Compute Engine VM instance, the instance must first be stopped. Once in the TERMINATED state, running `gcloud compute instances set-machine-type` reconfigures the VM attributes. Restarting the instance brings it back online with the requested compute resources.

Step-by-Step Solution

1
Stop the running Virtual Machine
The instance transitions from RUNNING to TERMINATED status.
Compute Engine standalone VM hardware configurations (vCPU/RAM) cannot be altered while the hypervisor is actively executing the host OS.
2
Update the machine type configuration
Execute `gcloud compute instances set-machine-type db-primary --machine-type=e2-standard-8`.
This updates the VM metadata and resource allocation specifications while the instance is stopped.
3
Start the Virtual Machine
The instance boots up with 8 vCPUs and the updated memory profile.
Starting the VM boots the OS on host infrastructure allocated according to the new machine type settings.

Key Concept

Modifying Compute Engine Instance Machine Types
Estimated Time:1m 30s
Question 1467Question →

An organization is deploying Compute Engine VM instances with Customer-Managed Encryption Keys (CMEK) applied to their boot disks in the europe-west3 region. The deployment pipeline uses a dedicated deployment service account with the Cloud KMS Admin role (roles/cloudkms.admin) on the target Key Ring. When creating the instances, the pipeline fails with an authorization error stating that encryption could not be performed. Which action should a cloud engineer take to resolve this failure while maintaining the principle of least privilege?

Show answer & explanation

Answer: Grant the Compute Engine Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) on the specific KMS key.

Answer

Grant the Compute Engine Service Agent the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) on the specific KMS key.
When configuring CMEK for Compute Engine resources, the Google-managed Compute Engine Service Agent executes the cryptographic operations on the disk. The Cloud KMS Admin role grants permissions to manage key resources and policies, but explicitly excludes encryption and decryption capabilities due to separation of duties. To resolve the error, the Compute Engine Service Agent must be granted the Cloud KMS CryptoKey Encrypter/Decrypter role on the specific key.

Step-by-Step Solution

1
Identify the service identity responsible for disk encryption in Compute Engine.
Recognize that GCP services use service agents (such as [email protected]) to access CMEK keys on behalf of users.
The user deployment service account provisions the VM, but the Compute Engine Service Agent performs the underlying cryptographic API calls.
2
Evaluate separation of duties in Cloud KMS IAM roles.
Understand that the Cloud KMS Admin role (roles/cloudkms.admin) only allows managing keys and key rings, not encrypting or decrypting data.
Google Cloud enforces separation of duties between key management and key usage.
3
Assign the least-privilege predefined role to the correct identity.
Grant roles/cloudkms.cryptoKeyEncrypterDecrypter to the Compute Engine Service Agent on the target key.
This enables Compute Engine to access the CMEK key to encrypt and decrypt VM boot disks securely.

Key Concept

Cloud KMS Separation of Duties and Service Agent CMEK Authorization
Question 1468Question →

A Cloud Engineer is managing a custom-mode Virtual Private Cloud (VPC) network. A subnet named `app-subnet-us-east1` in region `us-east1` currently has a primary IP range of `10.1.0.0/24`. Due to rapid application growth, the subnet is running out of available IP addresses. The engineer needs to expand the primary subnet IP range to accommodate at least 500 private IP addresses without disrupting existing running Compute Engine instances or recreating the subnet. Which `gcloud` command should the engineer execute?

Show answer & explanation

Answer: Run `gcloud compute networks subnets expand-ip-range app-subnet-us-east1 --region=us-east1 --prefix-length=23`.

Answer

Run `gcloud compute networks subnets expand-ip-range app-subnet-us-east1 --region=us-east1 --prefix-length=23`.
In Google Cloud Virtual Private Cloud (VPC), primary subnet IP address ranges can be expanded in-place non-disruptively without recreating the subnet or taking VM instances offline. To expand a `/24` range (256 addresses) to fit at least 500 hosts, the prefix length must be reduced to `/23` (512 addresses). The correct command is `gcloud compute networks subnets expand-ip-range [SUBNET_NAME] --region=[REGION] --prefix-length=23`.

Step-by-Step Solution

1
Identify the required IP capacity for the subnet expansion
A /24 subnet provides 256 addresses (251 usable). Expanding to a /23 subnet provides 512 addresses (507 usable after reserved IPs), which satisfies the requirement of at least 500 host addresses.
Decreasing the CIDR prefix length integer (from 24 to 23) doubles the address space of the subnet.
2
Determine the correct gcloud CLI command for expanding subnet IP ranges non-disruptively
The command `gcloud compute networks subnets expand-ip-range` allows expanding the primary IP range of an existing subnet without stopping instances or recreating the network resource.
Google Cloud VPC subnets support in-place expansion of primary IP ranges provided the new netmask encompasses the current range and does not overlap with other subnets.
3
Select the correct flag parameters
The parameter `--prefix-length=23` correctly sets the new broader subnet mask length.
Subnet expansion requires specifying a smaller prefix length value than the current mask length.

Key Concept

Expanding VPC Subnet Primary IP Ranges in Google Cloud
Estimated Time:1m 30s
Question 1469Question →

An Associate Cloud Engineer needs to restore a corrupted secondary data disk attached to a standalone Compute Engine virtual machine named `prod-app-vm`. The engineer has an existing disk snapshot named `data-disk-snap-2026`. What is the correct sequence of steps to safely replace the corrupted disk with a restored disk from the snapshot?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Detach the corrupted persistent disk from the VM, 2) Create a new persistent disk from the specified snapshot, 3) Attach the newly created disk to the VM, and 4) Connect via SSH to mount the new disk inside the guest operating system.
Restoring data from a Compute Engine persistent disk snapshot requires first detaching the broken disk, creating a new persistent disk from the snapshot using the `--source-snapshot` flag, attaching that new persistent disk to the VM instance, and finally mounting the disk partition inside the guest OS via SSH.

Step-by-Step Solution

1
Detach the corrupted persistent disk from `prod-app-vm`
The corrupted disk is safely disconnected from the running virtual machine instance.
Detaching the damaged disk prevents resource conflicts and ensures the device location is cleared for replacement.
2
Provision a new disk using the snapshot source flag
A new GCP persistent disk is created containing the point-in-time snapshot data.
Disk snapshots cannot be attached directly to instances; they must first be restored into a persistent disk resource.
3
Attach the restored persistent disk to `prod-app-vm`
The virtual machine gains access to the restored block storage device.
The compute instance must have the new persistent disk attached at the infrastructure level.
4
SSH into `prod-app-vm` and mount the filesystem device
The file system on the restored disk becomes readable and writable by applications.
GCP infrastructure attachment makes the disk available as a device, but operating system mounting is required for application file access.

Key Concept

Compute Engine Persistent Disk Snapshot Restoration
Question 1470Question →

A cloud engineer is managing an existing External Application Load Balancer in Google Cloud. Monitoring reveals that healthy compute instances in the backend service are frequently marked as unhealthy during brief traffic spikes because the associated HTTP health check named prod-api-hc has an overly strict timeout setting. The engineer needs to modify prod-api-hc to increase the check interval to 15 seconds and the timeout duration to 10 seconds without recreating the resource. Which gcloud command should the engineer execute?

Show answer & explanation

Answer: gcloud compute health-checks update http prod-api-hc --check-interval=15s --timeout=10s

Answer

The command 'gcloud compute health-checks update http prod-api-hc --check-interval=15s --timeout=10s' correctly updates the existing health check parameters in place.
To update an existing HTTP health check in Google Cloud without recreating it, you must use 'gcloud compute health-checks update http [NAME]' along with the desired parameter flags. This modifies the existing health check configuration in place.

Step-by-Step Solution

1
Identify the target resource and CLI command group for Google Cloud load balancing health checks.
Modern health checks for Cloud Load Balancing are managed using the 'gcloud compute health-checks' command family.
Health checks exist as independent Google Cloud networking resources separate from backend services or instance groups.
2
Select the appropriate operation for modifying an existing health check resource.
The 'update' subcommand must be used instead of 'create' to modify parameters without deleting or re-creating the resource.
Attempting to run 'create' on an existing resource name results in a duplicate resource name error.
3
Specify the protocol type and configuration flags.
The protocol 'http' followed by flags '--check-interval=15s' and '--timeout=10s' updates the health check parameters to the desired values.
Parameters such as check interval and timeout are configured directly on the health check entity.

Key Concept

Managing Google Cloud Load Balancing Health Checks via gcloud CLI
Question 1471Question →

A Cloud Engineer is tasked with migrating an enterprise Cloud Storage bucket containing legacy internal archives from fine-grained Access Control Lists (ACLs) to Uniform Bucket-Level Access (UBLA) to comply with organization security policies. Place the administrative steps in the correct sequential order to perform this migration safely without disrupting user access.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with auditing existing object ACL permissions, followed by assigning equivalent predefined IAM roles to affected principals, then enabling Uniform Bucket-Level Access on the bucket, and concluding with verifying object access and log monitoring.
The correct order follows GCP security best practices for migrating from ACLs to Uniform Bucket-Level Access: 1) Identify existing access requirements via an audit, 2) Provision equivalent IAM roles to prevent service disruption, 3) Turn on Uniform Bucket-Level Access on the bucket, and 4) Verify operation and monitor logs.

Step-by-Step Solution

1
Audit current access permissions
Identify all users, groups, and service accounts using per-object ACL access
Before revoking ACL evaluations, you must identify every principal relying on fine-grained object access to prevent unexpected outages.
2
Assign corresponding predefined IAM roles
Principals receive bucket-level or project-level IAM permissions (such as roles/storage.objectViewer)
Uniform Bucket-Level Access relies entirely on IAM policies; granting permissions via IAM prior to enabling UBLA maintains uninterrupted access.
3
Enable Uniform Bucket-Level Access
ACLs are disabled on the bucket and all contained objects
Executing the configuration update enforces uniform security across the entire bucket.
4
Validate and monitor access
Confirmed operational status via access tests and Cloud Audit Logs
Verification confirms that no applications or users experience authorization failures under the new IAM security model.

Key Concept

Uniform Bucket-Level Access (UBLA) migration workflow requires auditing legacy ACL access and granting IAM roles before disabling ACL processing on Cloud Storage buckets.
Question 1472Question →

A cloud administrator needs to establish strict governance controls on a designated 'Production' Folder within the Google Cloud resource hierarchy. The requirements dictate that developers working inside projects under this folder must be prevented from generating long-lived service account JSON keys, and Compute Engine virtual machines must not be assigned public IP addresses. Which TWO configurations should the administrator apply to the 'Production' Folder to meet these security requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Enforce the Boolean constraint constraints/iam.disableServiceAccountKeyCreation on the Production folder.; Configure the List constraint constraints/compute.vmExternalIpAccess to deny all external IP addresses on the Production folder.

Answer

Enforce the Boolean constraint constraints/iam.disableServiceAccountKeyCreation on the Production folder, and configure the List constraint constraints/compute.vmExternalIpAccess to deny all external IP addresses on the Production folder.
Enforcing the Boolean constraint for disabling service account key creation and setting the List constraint to deny external IP access directly at the folder level ensures that all child projects inherit these rules. This satisfies both security requirements without needing project-by-project manual configuration.

Step-by-Step Solution

1
Identify the required Organization Policy constraints for the specified governance requirements.
The constraint for disabling service account JSON key creation is constraints/iam.disableServiceAccountKeyCreation, and the constraint for restricting VM public IP assignment is constraints/compute.vmExternalIpAccess.
Organization Policies are used to set centralized constraints on specific GCP resource configurations across the resource hierarchy.
2
Select the target level in the resource hierarchy for policy enforcement.
Apply both policy constraints at the 'Production' Folder node.
Policies applied at a folder node automatically inherit down to all existing and future child projects within that folder.

Key Concept

Organization Policy Enforcement across Resource Hierarchy Folders
Question 1473Question →

An enterprise security compliance reviewer needs to inspect Cloud Audit Logs for sensitive Compute Engine operations within a Google Cloud project named core-infrastructure-prod. The reviewer currently holds the predefined Logs Viewer (roles/logging.viewer) role at the project level. While they can inspect Admin Activity audit logs, they are unable to view sensitive payload details within Data Access audit logs. Following the principle of least privilege, which action will allow the reviewer to view the Data Access audit logs?

Show answer & explanation

Answer: Grant the reviewer the Private Logs Viewer (roles/logging.privateLogViewer) role at the project level.

Answer

Grant the reviewer the Private Logs Viewer (roles/logging.privateLogViewer) role at the project level.
In Google Cloud Logging, Data Access audit logs contain detailed API calls and sensitive payload data. The standard Logs Viewer (roles/logging.viewer) role allows viewing Admin Activity logs and standard logs, but access to private logs (which include Data Access audit logs) requires the Private Logs Viewer (roles/logging.privateLogViewer) role. Assigning this role follows the principle of least privilege.

Step-by-Step Solution

1
Identify the missing log access level.
The reviewer holds roles/logging.viewer, which grants permission to read standard logs and Admin Activity logs, but not private logs such as Data Access logs with restricted payloads.
Data Access audit logs often contain sensitive data or user information and are classified as private logs in Cloud Logging.
2
Evaluate IAM roles for least-privilege private log access.
The Private Logs Viewer (roles/logging.privateLogViewer) role specifically grants permission to view private logs, including Data Access audit log entries.
Assigning roles/logging.privateLogViewer satisfies the operational requirement without granting unnecessary management or primitive privileges.

Key Concept

Cloud Audit Logs access control requires the Private Logs Viewer role to read Data Access logs containing sensitive metadata.
Question 1474Question →

A security administrator is standardizing access controls on a Cloud Storage bucket named `financial-reports-archive` to align with organizational security guidelines. The bucket currently contains objects with legacy fine-grained Access Control Lists (ACLs), but company policy requires that all access be managed exclusively through Cloud IAM permissions. Which TWO configuration steps must the administrator perform to achieve this requirement following Google Cloud security best practices? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Enable Uniform Bucket-Level Access on the bucket to disable Access Control Lists (ACLs) across all objects.; Assign predefined Cloud IAM roles, such as Storage Object Viewer or Storage Object Admin, to principals at the bucket or project level.

Answer

Enabling Uniform Bucket-Level Access on the target Cloud Storage bucket and granting predefined IAM roles (such as Storage Object Viewer) at the bucket or project level.
To standardize storage access controls to Cloud IAM only, administrators must enable Uniform Bucket-Level Access on the bucket. This action disables per-object ACLs, ensuring all object access is controlled via IAM permissions. Combining this setting with specific predefined roles (such as Storage Object Viewer) ensures least-privilege permissions managed centrally.

Step-by-Step Solution

1
Enable Uniform Bucket-Level Access on the Cloud Storage bucket.
Disables fine-grained object-level Access Control Lists (ACLs) so that access evaluations rely strictly on Cloud IAM policies.
Uniform Bucket-Level Access ensures consistent security governance across all current and future objects in the bucket.
2
Grant appropriate predefined IAM roles to authorized users or service accounts.
Provides required read or admin access to storage objects via Cloud IAM without granting overly broad permissions.
Predefined roles follow the security best practice of least privilege.

Key Concept

Uniform Bucket-Level Access (UBLA) and IAM Access Management
Question 1475Question →

A cloud security engineer needs to configure Cloud Audit Logging to capture object-level read events in Google Cloud Storage for project `prod-data-vault`, stream these logs into a central BigQuery dataset for compliance auditing, and grant access to the security analysis team. Arrange the implementation steps in the correct logical and technical sequence from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is: 1. Enable DATA_READ Data Access audit logs for Google Cloud Storage in IAM & Admin. 2. Create a Cloud Logging sink filtering for storage Data Access audit logs targeted at BigQuery. 3. Grant the sink's generated writer service account the BigQuery Data Editor role on the destination dataset. 4. Grant security analysts the Private Logs Viewer IAM role.
First, DATA_READ logs for Google Cloud Storage must be enabled under IAM & Admin > Audit Logs because Data Access logging is disabled by default for Cloud Storage. Second, a Log Router sink must be created with the appropriate filter targeting the BigQuery dataset. Third, the unique writer service account created alongside the sink must be assigned BigQuery Data Editor permissions on the target dataset to allow writing logs. Fourth, security analysts must be granted the Private Logs Viewer role because standard Logs Viewer cannot access Data Access audit logs.

Step-by-Step Solution

1
Enable Cloud Storage Data Access Audit Logs
Google Cloud Storage starts writing DATA_READ access events to audit logs.
Data Access logs for most services are turned off by default. Enabling them in Audit Logs configuration is required before any downstream routing or analysis can occur.
2
Configure the Log Router Sink
A sink rule is established to catch storage Data Access audit logs and route them to BigQuery.
Creating the sink defines the export destination and log filter parameters.
3
Authorize the Sink Service Account
The sink service account is authorized to write log tables into BigQuery.
Log Router sinks use service accounts for authorization. The writer identity must have write access (`roles/bigquery.dataEditor`) to the target dataset.
4
Grant Analyst Read Access to Private Logs
Security analysts gain access to inspect Data Access log entries.
Because Data Access audit logs contain PII and sensitive data access details, Cloud IAM requires the specific `roles/logging.privateLogViewer` role rather than generic logging roles.

Key Concept

Configuring Cloud Audit Logging export workflows requires four core phases: log activation (Data Access logs are off by default), log sink creation, writer identity IAM authorization, and granular access control (Private Logs Viewer for Data Access logs).
Question 1476Question →

A cloud engineer needs to update an existing custom Virtual Private Cloud (VPC) network configuration in Google Cloud. The environment currently has a subnet `prod-subnet-uscentral1` with the primary IP range `10.1.0.0/24`. Due to rapid growth, the team needs to expand the primary IP address range of this existing subnetwork to `10.1.0.0/22` using the `gcloud` CLI without recreating the subnet or disrupting existing resources. Which of the following conditions and actions are required to successfully perform this subnet expansion? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: The new CIDR prefix length must be smaller than or equal to the existing prefix length (for example, expanding /24 to /22).; Execute `gcloud compute networks subnets expand-ip-range prod-subnet-uscentral1 --region=us-central1 --ip-cidr-range=10.1.0.0/22` to increase the primary range.

Answer

Expanding an existing Google Cloud VPC subnet primary range requires that the new netmask prefix length be smaller than or equal to the current range (such as expanding from /24 to /22), and it is executed using the command `gcloud compute networks subnets expand-ip-range prod-subnet-uscentral1 --region=us-central1 --ip-cidr-range=10.1.0.0/22`.
To expand an existing VPC subnet's primary IP range without recreating it, Google Cloud requires that the new prefix length be smaller (allocating a larger block of IP addresses, such as moving from /24 to /22). The correct CLI tool procedure is invoking `gcloud compute networks subnets expand-ip-range` specifying the subnet name, `--region`, and the expanded `--ip-cidr-range`.

Step-by-Step Solution

1
Verify subnet expansion constraints for Google Cloud VPC.
Identified that expanding a primary CIDR block requires reducing the prefix length (e.g., from /24 to /22) while keeping the same network starting address.
Subnet IP ranges in Google Cloud can only be expanded, never shrunk or moved to an entirely new network range.
2
Identify the correct gcloud CLI command and parameters for subnet expansion.
Determined that `gcloud compute networks subnets expand-ip-range` with `--ip-cidr-range` is the official command.
The standard `subnets update` command is used for modifying properties like Private Google Access or Flow Logs, whereas `expand-ip-range` is specifically dedicated to extending primary CIDR ranges.

Key Concept

VPC Subnet IP Range Expansion via gcloud CLI
Estimated Time:1m 30s
Question 1477Question →

An infrastructure engineer needs to set up an isolated enterprise application environment in Google Cloud using the `gcloud` CLI. The setup requires creating a custom VPC network, provisioning a subnet with Private Google Access enabled, establishing an ingress firewall rule targeting a specific network tag, and launching a Compute Engine instance configured with that network tag.

In what order should the engineer execute these operational steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first create the custom VPC network, next create the subnet with Private Google Access enabled in that network, then create the ingress firewall rule with target tags on the network, and finally deploy the VM instance into the subnet with the matching network tag.
The correct order follows Google Cloud resource dependency requirements: the custom VPC network must be created first as the parent container, followed by creating the subnetwork within that network, establishing firewall rules attached to the network with target tags, and finally deploying the Compute Engine VM into the subnet with the matching target tag.

Step-by-Step Solution

1
Create the custom VPC network
Network `corp-vpc` is created without auto-generated subnets.
VPC networks serve as the top-level container for subnets and firewall rules in Google Cloud.
2
Create the custom subnetwork
Subnet `corp-app-subnet` is created in region `us-east4` with Private Google Access enabled.
Subnets define regional IP address ranges within a parent VPC network.
3
Configure the ingress firewall rule
Firewall rule `allow-corp-https` is created targeting tag `web-frontend`.
Defining network firewall rules before VM instantiation ensures immediate enforcement of access controls upon instance launch.
4
Deploy the VM instance
Instance `web-server-1` is instantiated in `corp-app-subnet` with tag `web-frontend`.
VM instances depend on existing subnetworks and network tags for IP allocation and security rule association.

Key Concept

Deployment dependency order for Google Cloud VPC networks, subnets, firewall rules, and Compute Engine instances.
Question 1478Question →

An enterprise organization is establishing a security baseline for cryptographic operations using Google Cloud KMS across multiple GCP projects. The security team needs to enforce strict separation of duties, adhere to the principle of least privilege, and follow proper key management lifecycle practices. Which TWO of the following configurations or operational steps should the security team implement?

Select all that apply

Show answer & explanation

Answer: Disable or schedule destruction of specific CryptoKey versions during key lifecycle maintenance rather than attempting to delete the parent Key Ring resource.; Grant the Cloud KMS CryptoKey Encrypter/Decrypter role specifically to the relevant service's Google Cloud Service Agent instead of granting broad permissions to service accounts or users.

Answer

The security team should disable or schedule destruction of specific CryptoKey versions (instead of trying to delete key rings) and grant the Cloud KMS CryptoKey Encrypter/Decrypter role to the service agent for the target GCP service.
The correct configurations involve disabling or scheduling destruction of CryptoKey versions (since Key Rings and CryptoKey resources cannot be deleted in Google Cloud KMS) and granting the predefined Cloud KMS CryptoKey Encrypter/Decrypter role to the Google Cloud Service Agent managing the encrypted resource, upholding least privilege and separation of duties.

Step-by-Step Solution

1
Analyze Cloud KMS resource deletion limitations
Identify that Key Rings and CryptoKey resources are permanent in GCP project records and cannot be deleted, but individual CryptoKey versions can be disabled or destroyed.
Cloud KMS retains key ring and key names permanently for tracking and compliance integrity.
2
Evaluate IAM access control for CMEK usage
Determine that service agents require the predefined Cloud KMS CryptoKey Encrypter/Decrypter role to perform cryptographic operations on behalf of GCP resources.
Granting least-privilege predefined roles to service agents ensures separation of duties between key administrators and service consumers.
3
Identify misconceptions in distractors
Reject options proposing key ring deletion, primitive role assignments, or lower-level IAM revocations.
GCP IAM policies inherit additively without explicit denial overrides, primitive roles grant overbroad access, and Cloud KMS key rings cannot be deleted.

Key Concept

Cloud KMS Separation of Duties and Key Lifecycle Management
Question 1479Question →

A DevOps engineer manages an application deployed across a regional Managed Instance Group (MIG) on Compute Engine. The application process occasionally encounters application-level deadlocks where it stops responding to incoming HTTP traffic, even though the underlying virtual machine instance state remains RUNNING. The engineer needs to ensure that unresponsive instances are automatically detected and replaced without manual intervention. What should the engineer do?

Show answer & explanation

Answer: Create an HTTP health check and attach it as an autohealing policy to the Managed Instance Group.

Answer

Create an HTTP health check and attach it as an autohealing policy to the Managed Instance Group.
Attaching an HTTP health check to an autohealing policy on a Managed Instance Group allows Compute Engine to verify that the application layer is actively serving requests. If an instance experiences a deadlock and fails the health check probes, the autohealing policy instructs the group manager to recreate that specific instance.

Step-by-Step Solution

1
Identify the operational requirement
The requirement is to detect application-layer failure (deadlock) when the VM hardware status remains healthy, and automatically replace the failing instance.
Standard compute status checks only verify hypervisor and hardware health, not application responsiveness.
2
Evaluate Google Cloud Compute Engine features for automatic instance lifecycle management
Managed Instance Groups support autohealing policies based on separate application health checks.
An autohealing policy periodically probes the specified endpoint (e.g., HTTP port 80/443). If probes fail sequentially beyond the configured threshold, the MIG signals instance recreate.
3
Select the correct implementation step
Define an HTTP health check probing the application status endpoint, then run `gcloud compute instance-groups managed update` to set the `--health-check` flag.
This directly binds application-level health monitoring to the MIG lifecycle management.

Key Concept

Managed Instance Group (MIG) Autohealing Policies
Question 1480Question →

An administrator notices that virtual machine instances in a private subnet are dropping outbound internet connections during peak traffic hours due to Cloud NAT port exhaustion. A second static regional IP address named `nat-ip-2` has already been allocated in region `us-central1`. The administrator must add `nat-ip-2` to the active Cloud NAT gateway `prod-nat` attached to Cloud Router `prod-router` in region `us-central1` without removing the existing assigned static IP `nat-ip-1`. Which `gcloud` command should the administrator execute?

Show answer & explanation

Answer: gcloud compute routers nats update prod-nat --router=prod-router --region=us-central1 --nat-external-ip-pool=nat-ip-1,nat-ip-2

Answer

Execute `gcloud compute routers nats update prod-nat --router=prod-router --region=us-central1 --nat-external-ip-pool=nat-ip-1,nat-ip-2` to include both static external IPs in the Cloud NAT pool.
Updating a Cloud NAT gateway's manually assigned external IP pool requires invoking `gcloud compute routers nats update` with the `--region` flag and listing all IP addresses intended for the pool in a comma-separated format under `--nat-external-ip-pool`.

Step-by-Step Solution

1
Identify the resource scope and command structure for Cloud NAT management in gcloud.
Cloud NAT configurations are managed under Cloud Routers using `gcloud compute routers nats`.
Cloud NAT is non-zonal regional infrastructure defined within a Cloud Router.
2
Determine how static IP allocation updates operate for Cloud NAT external IP pools.
The `--nat-external-ip-pool` flag expects a complete list of all active IP resources assigned to the gateway.
Passing only new IP addresses overwrites the existing pool rather than appending to it.
3
Select the command that specifies the regional flag along with the full comma-separated list of IP addresses.
The command containing `--region=us-central1` and `--nat-external-ip-pool=nat-ip-1,nat-ip-2` correctly modifies the configuration.
This updates the pool without dropping existing connections or raising scope parameter errors.

Key Concept

Cloud NAT Configuration and IP Pool Management
Estimated Time:1m 30s
PreviousPage 74 / 80Next
All practice questions — Google Cloud Associate Cloud Engineer | Examkin