Configuring access and security

271 questions

Question 1Question

An enterprise security team requires that Compute Engine virtual machines in the 'Data-Processing' folder be prevented from enabling IP forwarding (acting as routers or network gateways), except for one specialized project named 'gw-prod-100' located inside that folder. A cloud engineer must implement this guardrail using the Google Cloud resource hierarchy while granting the explicit exception. Which configuration should the engineer apply?

Show answer & explanation

Answer: Enforce the `constraints/compute.vmCanActAsIpForwarder` Organization Policy constraint on the 'Data-Processing' folder, and set the policy constraint to false (enforcement off) at the 'gw-prod-100' project level.

Answer

Enforce the `constraints/compute.vmCanActAsIpForwarder` Organization Policy constraint on the 'Data-Processing' folder, and set the policy constraint enforcement to false at the 'gw-prod-100' project level.
Organization Policy constraints set at a folder level automatically inherit down to all child projects. To grant an exception to a specific project within that folder, the constraint must be explicitly set to false (off) at the project level, which overrides the inherited folder policy.

Step-by-Step Solution

1
Identify the proper Google Cloud mechanism for enforcing infrastructure configuration rules across resource hierarchy nodes.
Organization Policy constraints (such as `constraints/compute.vmCanActAsIpForwarder`) must be used instead of IAM roles.
Organization Policies govern what configurations resources can have, whereas IAM governs identity permissions.
2
Determine the resource hierarchy inheritance behavior for the folder and child project.
Enforcing the constraint at the 'Data-Processing' folder level applies the restriction to all projects in that folder by default.
Organization policies inherit downwards from parent nodes to child nodes.
3
Configure the exception for the target project.
Override the inherited policy at the 'gw-prod-100' project level by setting enforcement to false.
Setting a specific policy setting at a child node overrides inherited parent rules for that specific child node.

Key Concept

Organization Policy Hierarchy and Constraint Inheritance Overrides
Question 2Question

A security mandate for a Google Cloud project named `analytics-prod` prohibits developers from generating or downloading long-lived JSON service account keys. A cloud engineer using the identity `[email protected]` needs temporary authorization to mint short-lived OAuth 2.0 access tokens for an existing service account named `[email protected]`. Which command should an administrator run to grant the engineer the necessary permission directly on the service account using the principle of least privilege?

Show answer & explanation

Answer: gcloud iam service-accounts add-iam-policy-binding [email protected] --member="user:[email protected]" --role="roles/iam.serviceAccountTokenCreator"

Answer

Execute the `gcloud iam service-accounts add-iam-policy-binding` command targeting the specific service account and assigning the `roles/iam.serviceAccountTokenCreator` role to the user.
To allow a developer to generate short-lived access tokens for a service account without key creation, the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) should be bound directly to the target service account resource using `gcloud iam service-accounts add-iam-policy-binding`.

Step-by-Step Solution

1
Identify the security requirement and identity mechanism.
The scenario requires short-lived credential generation without creating static JSON keys.
Security best practices discourage long-lived service account key downloads in favor of IAM impersonation and token generation.
2
Select the appropriate IAM role for token creation.
The `roles/iam.serviceAccountTokenCreator` role allows generating short-lived access tokens.
This specific predefined role grants permissions to sign tokens and impersonate the target service account.
3
Determine the binding target resource.
Bind the policy directly to `[email protected]`.
Applying the role binding to the specific service account resource enforces the principle of least privilege instead of project-wide access.

Key Concept

Managing Service Account Impersonation and Token Creation via IAM Policy Bindings
Estimated Time:1m 30s
Question 3Question

An enterprise Google Cloud environment enforces the boolean Organization Policy constraint `constraints/compute.disableGlobalSerialPortAccess` (Enforced: True) at the root Organization node. A DevOps engineer who holds the primitive `roles/owner` IAM role on a child project within a subfolder attempts to enable interactive serial console access on a Compute Engine instance in that project using the Google Cloud CLI. Which statement correctly describes the outcome of this operational request and the underlying policy enforcement mechanism?

Show answer & explanation

Answer: The operational request will fail because Organization Policies establish programmatically enforced guardrails across the resource hierarchy that cannot be overridden by IAM permissions; enabling access requires an explicit policy override or exception configured by an Organization Policy Administrator at the folder or project level.

Answer

The operational request will fail because Organization Policies establish programmatically enforced guardrails across the resource hierarchy that cannot be overridden by IAM permissions; enabling access requires an explicit policy override or exception configured by an Organization Policy Administrator at the folder or project level.
Google Cloud Organization Policies set constraints on specific Google Cloud service resources to configure guardrails across an entire organization. These constraints evaluate independently of IAM roles and permissions. Even users with primitive Owner (`roles/owner`) privileges cannot perform operations that violate active Organization Policy constraints. To allow the operation, an authorized user with the `roles/resourcemanager.organizationPolicyAdmin` role must explicitly alter or override the policy constraint at the appropriate folder or project level in the resource hierarchy.

Step-by-Step Solution

1
Analyze the relationship between IAM permissions and Organization Policies.
IAM determines identity access authorization ('who can do what'), while Organization Policies define resource configuration restrictions ('what can be done to resources').
Understanding the separation of concerns between IAM and Organization Policies is essential.
2
Evaluate the effect of resource hierarchy inheritance for Organization Policy constraints.
The boolean constraint `constraints/compute.disableGlobalSerialPortAccess` set at the root Organization node is inherited down to folders and projects unless explicitly overridden by an authorized role.
Organization Policies follow the Google Cloud resource hierarchy inheritance model.
3
Determine if primitive Project Owner (`roles/owner`) privileges can bypass Organization Policy enforcement.
IAM roles, including primitive Owner/Editor roles, cannot bypass enforced Organization Policy constraints.
Organization Policies sit above IAM in restricting allowed resource configurations.

Key Concept

Organization Policies vs IAM Roles & Hierarchy Inheritance
Question 4Question

An organization is establishing strict compliance guardrails for service account administration in Google Cloud. A dedicated security team created a custom service account named `[email protected]` in project `proj-backend`. Developers in the project need to attach this service account to newly deployed Cloud Run services. However, security policy strictly forbids developers from modifying service account permissions, creating key files, or managing other service accounts in the project. Which IAM role configuration meets these security requirements while applying the principle of least privilege?

Show answer & explanation

Answer: Grant the developers the Service Account User role (roles/iam.serviceAccountUser) bound directly on the sa-app-deployer service account resource.

Answer

Grant the developers the Service Account User role (roles/iam.serviceAccountUser) bound directly on the specific service account resource.
To allow a user or group to attach a service account to a GCP compute resource without granting permission to manage service accounts, you must grant the Service Account User role (roles/iam.serviceAccountUser) on that specific service account resource. Binding the role on the individual service account rather than at the project level enforces strict least-privilege control.

Step-by-Step Solution

1
Identify the minimal permission required for workload attachment
The permission required to attach a service account to a compute resource (like Cloud Run or Compute Engine) is iam.serviceAccounts.actAs, which is provided by the Service Account User role (roles/iam.serviceAccountUser).
Developers only need to attach the service account to compute workloads, not manage IAM or service account metadata.
2
Determine the optimal resource scope for IAM binding
Binding roles/iam.serviceAccountUser on the specific service account resource ([email protected]) restricts the actAs permission strictly to that identity.
Granting the role at the project level would allow developers to attach any service account in the project, violating least privilege.
3
Verify compliance with security guardrails
Resource-level binding prevents developers from creating service account keys, modifying IAM policies, or managing other identities in the project.
This guarantees full alignment with security mandates prohibiting identity management rights.

Key Concept

Fine-grained IAM Delegation for Service Accounts
Estimated Time:2m 0s
Question 5Question

An enterprise security policy requires that an external automated CI/CD pipeline operating outside of Google Cloud deploy infrastructure into a project named `prod-app-services`. To eliminate security risks associated with long-lived credentials, a cloud administrator creates a dedicated deployment service account named `[email protected]` and configures Workload Identity Federation. Which IAM role configuration should the administrator apply to grant the external workload permission to act as the service account while following Google Cloud security best practices?

Show answer & explanation

Answer: Grant the external workload identity principal the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) directly on the deployer-sa service account resource.

Answer

Grant the external workload identity principal the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) directly on the deployer-sa service account resource.
Granting the Service Account Token Creator role directly on the specific target service account allows the external workload identity to mint short-lived tokens for that exact account via Workload Identity Federation. This satisfies security requirements by maintaining a keyless authentication architecture while enforcing least privilege resource scoping.

Step-by-Step Solution

1
Identify authentication and authorization security requirements
Workload Identity Federation allows external workloads to exchange external tokens for GCP short-lived tokens via service account impersonation.
Eliminating static, long-lived JSON keys is a core Google Cloud security best practice.
2
Determine the required IAM role for generating short-lived credentials
The Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) permits a principal to mint OAuth 2.0 access tokens and ID tokens by impersonating the target service account.
Service Account User allows attaching accounts to resources, whereas Token Creator allows direct token generation/impersonation.
3
Apply resource-level scoping following the principle of least privilege
Bind the role directly on the specific service account resource (deployer-sa) rather than at the project or organization level.
Restricting the role binding to the targeted service account prevents the pipeline from impersonating other service accounts in the project.

Key Concept

Service Account Impersonation & Workload Identity Least Privilege
Question 6Question

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

Show answer & explanation

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

Answer

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

Step-by-Step Solution

1
Evaluate separation of duties for IAM roles
Cloud KMS Admin (`roles/cloudkms.admin`) allows managing key rings, keys, and IAM policies, but explicitly lacks permissions to encrypt or decrypt data (`cloudkms.cryptoKeyVersions.useToEncrypt`/`useToDecrypt`), ensuring administrative duties are isolated from data access.
Security policy requires administrators to manage keys without being capable of viewing or decrypting payload data.
2
Assign cryptographic permissions to the workload service account
The Cloud KMS CryptoKey Encrypter/Decrypter role (`roles/cloudkms.cryptoKeyEncrypterDecrypter`) gives the Cloud Storage service account necessary rights to use the key for CMEK operations without granting administrative access.
Service accounts integrating with CMEK require explicit permission to perform cryptographic operations.
3
Analyze key ring lifecycle operations and limitations
Cloud KMS resources, specifically Key Rings and CryptoKeys, are permanent entities once created to prevent data loss and ensure audit trail integrity; they cannot be deleted.
Google Cloud KMS design mandates that key names and key ring resource paths remain permanent in GCP project history.

Key Concept

Cloud KMS Separation of Duties and Key Lifecycle Governance
Question 7Question

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: First, create the custom service account using `gcloud iam service-accounts create`. Second, assign the predefined role (`roles/monitoring.metricWriter`) to the service account at the project level using `gcloud projects add-iam-policy-binding`. Third, grant the provisioning user the `roles/iam.serviceAccountUser` role directly on the service account via `gcloud iam service-accounts add-iam-policy-binding`. Fourth, create the Compute Engine VM instance specifying `--service-account` with the service account email via `gcloud compute instances create`.
Provisioning a secure Compute Engine workload requires establishing the service account identity first (`gcloud iam service-accounts create`). Next, granting least-privilege predefined permissions to the service account (`gcloud projects add-iam-policy-binding`) establishes what the workload can do. Then, authorizing the deploying user to use the service account (`roles/iam.serviceAccountUser` via `gcloud iam service-accounts add-iam-policy-binding`) allows resource attachment. Finally, initiating VM creation with `--service-account` attaches the identity to the instance.

Step-by-Step Solution

1
Create the Service Account identity
A non-human service account identity `ops-monitor-sa@PROJECT_ID.iam.gserviceaccount.com` is provisioned.
IAM roles cannot be assigned to an identity that does not yet exist in Google Cloud IAM.
2
Assign predefined IAM role to the Service Account
The service account gains authorization to write monitoring metrics to Google Cloud Monitoring.
Granting least-privilege predefined roles directly to the workload service account ensures strict access control before deployment.
3
Grant Service Account User permission to the deploying entity
The DevOps engineer receives authorization to attach the service account to compute resources.
Compute Engine instance creation requires the user executing the command to have `iam.serviceAccounts.actAs` permission, provided by `roles/iam.serviceAccountUser` on the targeted service account.
4
Attach the Service Account during instance creation
The VM instance is created with the dedicated service account attached, avoiding static service account key exports.
Attaching the service account allows applications running on the instance to access Google Cloud APIs securely through the internal metadata server.

Key Concept

Creating and attaching custom service accounts to Compute Engine instances following least-privilege IAM configuration and ServiceAccountUser role delegation.
Estimated Time:2m 0s
Question 8Question

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

Show answer & explanation

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

Answer

Override the inherited policy by setting the constraints/compute.vmCanIpForward Organization Policy constraint to Enforced: Off explicitly at the Network-Appliance project level.
Google Cloud Organization Policies evaluate constraints hierarchically. When a parent folder enforces a Boolean constraint such as disabling IP forwarding, all descendant projects inherit that restriction. To create an exception for a single project, an administrator configures an explicit Organization Policy on that project with the Boolean constraint enforcement set to Off (unenforced), which overrides the inherited policy for that project only.

Step-by-Step Solution

1
Analyze how Organization Policies inherit down the Google Cloud resource hierarchy.
Policies applied at a parent node (Folder) automatically apply to all child nodes (Projects) unless an explicit policy override is configured at the child level.
Hierarchical inheritance ensures consistent guardrails across sub-resources.
2
Determine the mechanism required to disable a Boolean Organization Policy constraint for a specific sub-resource.
Setting the Boolean constraint enforcement status to Off (false) on the specific target project overrides the inherited Enforced status from the parent folder.
Explicit child node settings take precedence over inherited parent node policies.

Key Concept

Organization Policy Boolean Constraint Inheritance and Explicit Overrides
Estimated Time:1m 30s
Question 9Question

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

Show answer & explanation

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

Answer

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

Step-by-Step Solution

1
Identify the cause of the failure
Uniform Bucket-Level Access (UBLA) disables fine-grained object Access Control Lists (ACLs), causing operations that attempt to set or modify object ACLs to fail.
UBLA unifies access control exclusively under Identity and Access Management (IAM).
2
Remediate application permissions strategy
Refactor application code to stop making ACL modification API calls.
ACL manipulation calls are invalid when UBLA is enforced on the target Cloud Storage bucket.
3
Apply principle of least privilege using IAM predefined roles
Grant the service account the required predefined role, such as Storage Object Viewer (`roles/storage.objectViewer`), at the bucket level.
Bucket-level IAM role assignment provides consistent access management without relying on deprecated object-level ACLs.

Key Concept

Configuring Storage Access Controls and Uniform Bucket-Level Access
Question 10Question

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

Show answer & explanation

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

Answer

Apply the Organization Policy boolean constraint constraints/iam.disableServiceAccountKeyCreation with enforcement set to Enforce directly at the finance-vault-prod project level.
In the Google Cloud resource hierarchy, Organization Policies are inherited from top to bottom (Organization → Folder → Project). Applying a constraint directly at the project level allows an administrator to set a specific enforcement rule that applies exclusively to that project, overriding any looser policy settings inherited from its parent folder.

Step-by-Step Solution

1
Analyze the resource hierarchy and inheritance model
Organization policies applied at lower nodes in the resource hierarchy (such as a specific project) override or narrow policies inherited from parent folders or organization nodes.
Targeted project-level policy application allows specific security controls without impacting sibling projects under the same parent folder.
2
Select the appropriate constraint type and target node
Configuring constraints/iam.disableServiceAccountKeyCreation to Enforce on the finance-vault-prod project blocks key creation specifically for that project.
This directly fulfills the security requirement while preserving the folder-level configuration for legacy workloads in sibling projects.

Key Concept

Organization Policy inheritance and node-level constraint overrides
Question 11Question

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

Show answer & explanation

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

Answer

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

Step-by-Step Solution

1
Analyze key lifecycle options in Cloud KMS
Disabling a specific CryptoKeyVersion prevents any future cryptographic operations (encryption/decryption) using that specific version, which addresses the security compromise requirement.
Cloud KMS allows managing individual key versions independently through state transitions (Enabled, Disabled, Scheduled for destruction, Destroyed).
2
Evaluate resource deletion capabilities in Cloud KMS
Recognize that KeyRings and CryptoKeys are immutable resources in terms of deletion; they cannot be deleted from a GCP project.
Google Cloud KMS intentionally prevents the deletion of KeyRings and CryptoKeys to preserve audit logs, prevent key loss disasters, and ensure cryptographic history remain traceable.
3
Evaluate IAM policy inheritance
Confirm that IAM roles granted at parent levels (e.g., Project) are inherited downwards and cannot be restricted by child-level revocations.
IAM permissions are purely additive; child resources inherit all access granted at higher levels in the GCP resource hierarchy.

Key Concept

Cloud KMS Key Lifecycle and Resource Immutability
Question 12Question

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

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

Select all that apply

Show answer & explanation

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

Answer

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

Step-by-Step Solution

1
Provision a user-managed service account in the GCP project where the resources reside.
Establishes a dedicated GCP identity specifically for the external workload.
Dedicated service accounts allow precise role bindings and auditing for specific applications.
2
Assign the Service Account Token Creator role on the service account to the external identity.
Enables short-lived token generation via IAM service account impersonation.
Short-lived tokens eliminate the security risks associated with static long-lived key exports.

Key Concept

Creating User-Managed Service Accounts & Service Account Impersonation
Estimated Time:1m 30s
Question 13Question

A security audit highlights that a Compute Engine virtual machine running an automated nightly report generator is using the default Compute Engine service account with the primitive Editor role. To comply with security mandates and the principle of least privilege, you need to reconfigure the workload to use a dedicated user-managed service account that only has access to read Cloud Storage objects and write BigQuery datasets in the project. Which sequence of steps should you take?

Show answer & explanation

Answer: Create a user-managed service account, grant it the roles/storage.objectViewer and roles/bigquery.dataEditor roles at the project level, stop the VM instance, attach the new service account to the VM, and restart the instance.

Answer

Create a dedicated user-managed service account, grant it the predefined roles roles/storage.objectViewer and roles/bigquery.dataEditor at the project level, stop the VM instance, attach the custom service account to the VM, and restart the instance.
The solution follows Google Cloud security best practices by replacing the default service account with a custom user-managed service account, granting minimal predefined roles (roles/storage.objectViewer and roles/bigquery.dataEditor), and attaching the service account directly to the Compute Engine instance so the application uses automatic metadata credentials rather than exported long-lived JSON key files.

Step-by-Step Solution

1
Create a dedicated user-managed service account
A new service account identity is established specifically for the reporting workload.
Default service accounts should not be used for production workloads as they often default to overly permissive broad roles.
2
Bind predefined IAM roles to the service account at the project level
The service account gains roles/storage.objectViewer and roles/bigquery.dataEditor permissions.
Predefined roles satisfy the principle of least privilege by providing only the required Cloud Storage read and BigQuery dataset write capabilities.
3
Attach the user-managed service account to the VM instance without generating exportable keys
The VM automatically acquires credentials from the instance metadata service.
Attaching the service account directly eliminates the storage and management risks associated with long-lived JSON service account keys.

Key Concept

User-managed service accounts best practices and VM attachment
Question 14Question

A cloud architect is configuring governance controls for a company's Google Cloud environment containing an Organization node, a 'Staging' folder, and multiple child projects. The security team needs to establish clear boundaries for resource configurations and access controls across the resource hierarchy. Which of the following statements correctly describe the behavior of Google Cloud Organization Policies and resource hierarchy constraints? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Organization Policy constraints configured at the 'Staging' folder level automatically evaluate and apply to all child projects inside that folder unless explicitly overridden at a lower level.; Organization Policies define configuration guardrails on resources regardless of who performs the action, whereas IAM roles determine which principals have permissions to perform operations.

Answer

The correct statements are that Organization Policy constraints set on a folder level automatically apply to all child projects unless explicitly overridden at a lower level, and that Organization Policies restrict resource configurations while IAM roles manage identity-based access permissions.
Organization Policy constraints set at a folder level automatically inherit down to child projects unless explicitly overridden at a lower node. Furthermore, Organization Policies establish guardrails on resources regardless of the user performing the action, whereas IAM roles manage identity-based permissions.

Step-by-Step Solution

1
Analyze how Organization Policies propagate through the GCP resource hierarchy.
Policies configured at higher levels (Organization or Folder) pass down to lower levels (Projects and resources) through hierarchical inheritance unless an explicit override is set.
Hierarchical inheritance is a fundamental design property of Google Cloud Organization Policies.
2
Differentiate between the roles of IAM and Organization Policies.
Organization Policies enforce guardrails on resource configurations (e.g., restricting public IPs or allowed VM locations), while IAM grants identities specific permissions to perform operations.
Understanding this distinction prevents mixing governance guardrails with access control configurations.
3
Evaluate the incorrect choices regarding role permissions and policy grants.
Primitive IAM Owner roles cannot bypass Organization Policy enforcement, and Organization Policies cannot be used to assign identity-level read permissions.
IAM permissions and Organization Policies operate independently; IAM roles do not override enforced organizational guardrails.

Key Concept

Organization Policy Hierarchical Inheritance and IAM Decoupling
Estimated Time:1m 30s
Question 15Question

A cloud administrator is performing a resource cleanup in a Google Cloud project and identifies a Cloud KMS Key Ring containing unused CryptoKeys. The administrator attempts to permanently remove the Key Ring to clean up project resources, but discovers that the Google Cloud Console does not offer a delete action for Key Rings. Why does Google Cloud prevent the deletion of Cloud KMS Key Rings, and what is the recommended procedure to restrict further use of the cryptographic keys?

Show answer & explanation

Answer: Key Rings and CryptoKeys are immutable resources to preserve resource names and audit trails; the administrator should disable or destroy the individual CryptoKey versions to prevent usage.

Answer

Cloud KMS Key Rings and CryptoKeys are immutable resources designed to maintain audit integrity and unique resource identifiers. To prevent unauthorized or unintended usage of keys inside an unneeded Key Ring, administrators should disable or schedule destruction for all active key versions.
In Google Cloud KMS, Key Rings and CryptoKeys are immutable resources. They cannot be deleted once created in order to guarantee that resource names are never reused and audit records remain reliable over time. To prevent any further cryptographic operations, administrators must disable the key versions or schedule them for destruction.

Step-by-Step Solution

1
Identify Cloud KMS resource lifecycle constraints.
Recognize that Cloud KMS Key Rings and CryptoKeys cannot be deleted once created.
Immutability preserves resource naming conventions and cryptographic audit logs across GCP.
2
Determine the proper method to revoke cryptographic functionality.
Disable active CryptoKey versions or schedule key versions for destruction.
Disabling or destroying key versions prevents decryption and encryption operations without violating resource immutability.

Key Concept

Immutability of Cloud KMS Key Rings and CryptoKey management lifecycle
Question 16Question

An organization enforces a strict security directive prohibiting the creation and export of static service account JSON keys. A automated pipeline executing under a source service account `[email protected]` in Project-A must deploy compute resources into Project-B by impersonating a target service account `[email protected]`. Which two IAM configuration actions must be performed to enable this secure impersonation workflow following Google Cloud security best practices? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Grant the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) to [email protected] on the [email protected] service account resource.; Grant the target service account [email protected] the necessary compute deployment permissions within Project-B.

Answer

Granting the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) to the source service account on the target service account resource, and granting the target service account the necessary resource deployment permissions within Project-B.
To establish keyless cross-project impersonation, the calling service account must be given the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator) directly on the target service account resource. Additionally, the target service account must be assigned specific predefined IAM roles in the destination project so it can perform the intended deployment tasks upon being impersonated.

Step-by-Step Solution

1
Configure impersonation permissions on the target service account.
The source service account `[email protected]` is granted `roles/iam.serviceAccountTokenCreator` binding on `[email protected]`.
This permission allows the source service account to generate short-lived credentials for the target identity without needing private keys.
2
Configure deployment authorization in the destination project.
The target service account `[email protected]` receives predefined compute deployment roles in Project-B.
Operations executed via impersonation inherit the IAM permissions of the target service account inside the destination environment.

Key Concept

Service Account Impersonation requires granting the Service Account Token Creator role to the caller on the target service account resource.
Question 17Question

A data analyst must execute a scheduled Python script from an on-premises workstation to pull analytics data from BigQuery using a dedicated service account named `[email protected]`. Organization security policies explicitly prohibit generating or downloading long-lived service account JSON key files to local machines. The analyst has already authenticated their personal user identity using `gcloud auth login`. Which configuration best satisfies this security requirement while adhering to the principle of least privilege?

Show answer & explanation

Answer: Grant the data analyst's user account the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) on the target service account.

Answer

Grant the data analyst's user account the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) on the target service account.
Granting the Service Account Token Creator role (`roles/iam.serviceAccountTokenCreator`) directly on the target service account enables the user to generate short-lived credentials via `gcloud` or Google API client libraries. This completely removes the need for long-lived JSON service account keys while adhering to the principle of least privilege.

Step-by-Step Solution

1
Identify the security requirement regarding authentication without key files.
Long-lived service account JSON keys cannot be created or downloaded to local workstations.
Security policies require keyless authentication using identity impersonation.
2
Determine the minimum IAM role required for identity impersonation.
The user requires `roles/iam.serviceAccountTokenCreator` granted on the specific service account resource.
This role allows the user to mint short-lived credentials (OIDC/OAuth2 tokens) for the service account.
3
Apply the principle of least privilege.
Grant the role strictly on the target service account rather than broadly at the project or organization level.
Restricting the IAM binding to the target service account resource prevents unauthorized impersonation of other service accounts.

Key Concept

Service Account Impersonation via Service Account Token Creator Role
Estimated Time:1m 30s
Question 18Question

An enterprise organization manages a Google Cloud resource hierarchy containing an Organization root node, a folder named `Production`, and a child project named `Payment-Service` inside `Production`. The security team wants to enforce strict network perimeter controls and ensure proper administrative access delegation across the environment. Which of the following statements correctly describe the behavior and management of Organization Policies in this resource hierarchy? (Select TWO answers.)

Select all that apply

Show answer & explanation

Answer: Enforcing an Organization Policy constraint at the `Production` folder level automatically applies the restriction to `Payment-Service` through resource hierarchy inheritance.; Assigning the Organization Policy Admin role (`roles/orgpolicy.policyAdmin`) gives an administrator the authority to configure constraints, but does not inherently grant data access or resource management permissions on Compute Engine instances.

Answer

The correct statements are that Organization Policy constraints enforced at a parent folder level automatically inherit down to child projects, and that the Organization Policy Admin role (`roles/orgpolicy.policyAdmin`) grants permission to manage constraints without conferring permissions to access underlying project resources.
Organization Policies inherit down the Google Cloud resource hierarchy, meaning policies enforced at a parent folder level automatically apply to all contained projects. Furthermore, Google Cloud maintains a strict separation of duties: the `roles/orgpolicy.policyAdmin` role allows administrators to manage policy constraints across the resource hierarchy without giving them access to project-level resource data or management operations.

Step-by-Step Solution

1
Analyze Organization Policy resource hierarchy inheritance behavior.
Constraints defined at higher levels of the hierarchy (such as Folders or the Organization root) pass down to child nodes (such as Projects) automatically.
Google Cloud Organization Policies adhere to hierarchical inheritance unless an explicit restore or override policy is applied at a child node.
2
Evaluate the distinction between Organization Policies and IAM permissions.
Organization Policies set guardrails on resource behaviors (what can be done to resources), whereas IAM roles define identity permissions (who can perform actions).
Enforcing an Organization Policy restriction does not alter IAM policy bindings, nor can IAM roles like `roles/owner` grant immunity from enforced Organization Policies.
3
Examine the scope of the `roles/orgpolicy.policyAdmin` role.
The Organization Policy Admin role provides administrative capabilities over organization policy constraints only, maintaining least privilege separation from workload administration.
Google Cloud enforces separation of duties between compliance policy governance and underlying infrastructure/data management.

Key Concept

Organization Policy inheritance and separation of governance controls from IAM access permissions across the resource hierarchy
Question 19Question

Your team needs to grant a newly hired developer access to manage Compute Engine virtual machine instances (create, start, stop, and delete) within a specific Google Cloud project. The developer must not be granted permissions to modify project firewall rules, VPC networks, or IAM policies. Following the principle of least privilege, which IAM role should you grant to the developer at the project level?

Show answer & explanation

Answer: Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1)

Answer

Grant the predefined Compute Instance Admin (v1) role (roles/compute.instanceAdmin.v1) at the project level.
The Compute Instance Admin (v1) role (roles/compute.instanceAdmin.v1) grants full control over Compute Engine instances while omitting permissions for networking, security, and other GCP services, satisfying the principle of least privilege.

Step-by-Step Solution

1
Identify the required operational capabilities.
The user needs to manage Compute Engine instances (create, start, stop, delete).
Determining exact job requirements allows matching with the most granular IAM role available.
2
Select a role aligned with the principle of least privilege.
The Compute Instance Admin (v1) role provides full instance management without granting network administration or broad project permissions.
Predefined service roles target specific resource management needs, whereas primitive roles (Editor, Owner) grant overly broad permissions.
3
Identify the correct resource hierarchy scope.
Apply the role binding at the specific project level.
Permissions bound at higher levels (Folder or Organization) inherit downward to all child projects.

Key Concept

Least Privilege and IAM Predefined Roles
Estimated Time:1m 0s
Question 20Question

A security administrator needs to grant a data analyst permission to run SQL queries on a specific BigQuery dataset within a Google Cloud project, while adhering strictly to the principle of least privilege. Which of the following IAM role assignments should the administrator configure? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Assign the BigQuery Data Viewer (roles/bigquery.dataViewer) role on the specific dataset to allow reading table data.; Assign the BigQuery Job User (roles/bigquery.jobUser) role at the project level to allow executing query jobs.

Answer

To enable running SQL queries on a specific dataset under least privilege, assign the BigQuery Data Viewer role at the dataset level and the BigQuery Job User role at the project level.
Executing BigQuery queries requires both dataset read permissions and project job execution permissions. Granting BigQuery Data Viewer scoped to the specific dataset allows querying table data without altering table schemas or accessing other datasets. Granting BigQuery Job User at the project level allows running query jobs without granting access to dataset contents or administrative rights.

Step-by-Step Solution

1
Determine data access permission scoped to the resource.
Assigning BigQuery Data Viewer on the specific dataset provides read access to table contents without over-granting access to other datasets in the project.
The principle of least privilege requires scoping data access permissions to the specific target resource.
2
Determine job execution permission required for query processing.
Assigning BigQuery Job User at the project level grants permission to create and run query jobs.
Users must have job execution permissions in the project running the BigQuery job, independent of dataset read permissions.

Key Concept

Applying Least Privilege with Predefined Roles and Resource Scopes
Page 1 / 14Next