Configuring Access Within a Cloud Solution Environment practice questions

Cloud Run Invoker (roles/run.invoker)

Why wrong: This role only allows invoking (calling) services, not managing them.

Cloud Run Viewer (roles/run.viewer)

Why wrong: This role is read-only and does not allow deploying or managing services.

Cloud Run Developer (roles/run.developer)

Why wrong: This role allows creating, updating, and deploying services, but not deleting or modifying IAM.

Create a custom role with bigquery.tables.getData and storage.objects.create, and assign to the group at the organization level.

Why wrong: Creating a custom role with bigquery.tables.getData and storage.objects.create and assigning at the organization level is wrong because it grants these permissions to all resources in the organization, violating the principle of least privilege.

Create a service account for the team and set up workload identity federation with the SAML IdP.

Why wrong: Creating a service account and setting up Workload Identity Federation with a SAML IdP is incorrect because this mechanism is designed for non-human workloads, such as applications or CI/CD pipelines, to authenticate to Google Cloud without service account keys. The question specifies a 'data science team', implying human users who would typically federate their external SAML IdP into Google Cloud Identity. Workload Identity Federation is highly effective for enabling secure, keyless access for external *workloads* to assume a Google Cloud service account's identity, making it the correct choice for machine-to-machine authentication.

Grant the group the BigQuery Data Viewer role at the project A level and Storage Object Admin at the project B level.

Why wrong: Granting the group BigQuery Data Viewer at the project A level and Storage Object Admin at the project B level is too broad: project-level access affects all datasets and buckets, and Storage Object Admin includes permissions like delete that are not needed.

Apply the organization policy constraint constraints/cloudkms.disableKeyDeletion with value True.

Why wrong: There is no such predefined constraint; the correct constraint is constraints/cloudkms.restrictAllowedOperations, but it's not a boolean to disable deletion.

Store the key material in a separate project with a private key access control.

Why wrong: This does not address the requirement to control disable/delete permissions.

Create an IAM allow policy at the organization level that grants the same permissions only to the security team.

Why wrong: Allow policies are overridden by deny policies, so this would not work.

Configure an organization policy to deny key creation if keys are older than 90 days.

Why wrong: Organization policies cannot enforce rotation or detect key age.

Use Cloud Logging to analyze logs for key creation and compute age.

Why wrong: Logs show creation events but not current key age; would require complex logic.

Create a custom IAM role that prevents using keys older than 90 days.

Why wrong: IAM roles cannot enforce key age restrictions.

Grant the service account the roles/iam.serviceAccountUser role on itself

Why wrong: This role allows impersonation but does not grant data access permissions.

Enable the Cloud Storage and BigQuery APIs in the project

Why wrong: APIs are enabled by default; if disabled, the error would be different, but this is less likely the cause.

Deploy a VPN between the IdP and Google Cloud

Why wrong: VPN is not required for SSO or IAP; it's for network connectivity.

Create a service account for each user to access the application

Why wrong: Service accounts are for non-human identities, not end users.

Create a Cloud Armor security policy to allow only SAML-authenticated requests

Why wrong: Cloud Armor does not handle SAML authentication; it is for WAF and DDoS protection.

roles/storage.objectAdmin with deletion permissions removed via a custom role

Why wrong: This is not a predefined role; it references a custom role. The question asks for predefined roles only.

roles/storage.admin

Why wrong: roles/storage.admin includes delete permissions, violating the requirement that engineers must not be able to delete any resources.

roles/storage.objectAdmin

Why wrong: roles/storage.objectAdmin includes delete permissions for objects, which violates the no-deletion requirement.

Use IAM Conditions to restrict service account key creation to only a specific project.

Why wrong: IAM Conditions apply to role bindings, not to prevent creation globally. They cannot block key creation across all projects in an organization without complex per-project configuration.

Create a custom role that excludes the permission iam.serviceAccountKeys.create and assign it to all users.

Why wrong: Custom roles cannot be enforced across all users; users with other roles (like Owner) would still have the permission. Also, this does not prevent creation of keys via service accounts themselves.

Create an IAM deny policy at the organization level to deny the permission iam.serviceAccountKeys.create.

Why wrong: While an IAM deny policy at the organisation level would deny the `iam.serviceAccountKeys.create` permission, it is not the most precise mechanism for this scenario. Deny policies are primarily for overriding allow policies for specific principals and permissions. For enforcing a blanket resource behaviour control, such as preventing the creation of service account keys across all projects, an Organization Policy with a custom constraint is the dedicated and more robust approach. This option is tempting because deny policies *can* prevent actions, and they are suitable for fine-grained permission denials for specific identities or groups, especially when overriding broad allow policies.

Use SAML 2.0 federation with AD FS to synchronize users.

Why wrong: SAML 2.0 provides SSO, not user synchronization. It does not automatically provision users in Google Cloud Directory.

Use Workload Identity Federation to connect AD to Google Cloud.

Why wrong: Workload Identity Federation is for granting external workloads (e.g., AWS, Azure, GitHub Actions) access to GCP, not for synchronizing user identities from AD.

Use the Cloud Identity API to manually create users and groups.

Why wrong: Manual creation is not scalable for 50,000 users and does not provide automatic provisioning/deprovisioning.

Create an IAM policy on the bucket that grants access to the instance's external IP address.

Why wrong: IAM policies do not support granting access based on IP addresses; they are identity-based, not network-based.

Use a signed URL with a long expiration time for the instance.

Why wrong: Signed URLs are for temporary, user-specific access, not for a service to programmatically read objects over time. They also require managing secrets.

Generate a JSON key for the service account, download it to the instance, and use it in application code.

Why wrong: Managing service account keys is a security risk and should be avoided. The instance can use the metadata server without keys.

Create an IAM deny policy at the organization level that denies the compute.instances.create permission unless the Shielded VM flag is set.

Why wrong: IAM deny policies cannot conditionally deny creation based on instance configuration; they deny specific permissions unconditionally or based on attributes like resource name, not VM settings.

Create a custom role that includes the permission to create instances only with Shielded VM, and assign it to all users.

Why wrong: Custom roles cannot enforce that Shielded VM must be enabled; they only grant permissions. Users with other roles could still create non-compliant instances.

Implement a service account that only has permission to create instances and use service account impersonation for all instance creation.

Why wrong: Service account impersonation does not enforce Shielded VM requirements. It only controls who can act as a service account.

To manage firewall rules for VPC networks.

Why wrong: VPC firewall rules are managed separately via the VPC firewall service, not IAP.

To provide a VPN connection between on-premises and Google Cloud.

Why wrong: That is the purpose of Cloud VPN or Cloud Interconnect, not IAP.

To act as a web application firewall (WAF) that blocks SQL injection and XSS attacks.

Why wrong: That is the purpose of Cloud Armor. IAP is for identity-based access control.

Grant the service account token creator role to the GitHub Actions runner.

Why wrong: The token creator role allows creating tokens for a service account, but without a mechanism to prove identity, it still requires a key or other credentials.

Download a JSON service account key and store it as a GitHub secret.

Why wrong: This is the traditional approach but involves long-lived keys, which should be avoided per best practices.

Create a Compute Engine instance with a service account and run GitHub Actions from there.

Why wrong: This is overly complex and not scalable; GitHub Actions is a SaaS service, not running on a GCP VM.

Read the user's email from the instance's metadata server.

Why wrong: The metadata server provides information about the instance and its service account, not about the IAP-authenticated user.

Use the Cloud Logging API to query the most recent IAP access logs.

Why wrong: Logging is asynchronous and not suitable for real-time identity extraction per request.

Call the IAP API to retrieve the user identity.

Why wrong: There is no IAP API to retrieve the current request's user identity; the identity is passed via headers.

Use Cloud Identity groups with membership restricted to example.com and grant access to the group only.

Why wrong: This restricts access to group members but does not prevent adding individual users from other domains to IAM policies directly. The group membership can be restricted, but other IAM bindings could still include external users.

Configure the IdP to only assert users from example.com.

Why wrong: The IdP only controls authentication, not authorization. Users from other domains could still be added as members in IAM and log in via other means (e.g., Google accounts).

Use IAM Conditions to restrict access to users with a specific claim (e.g., assertion.primary_email ending with @example.com).

Why wrong: IAM Conditions can be used, but they need to be applied to every role binding. They are effective but require more effort and can be overridden by other policies.

Use the Compute Engine default service account for all users.

Why wrong: Service accounts are for non-human identities (applications, VMs), not for human users.

Use Cloud Identity Premium edition.

Why wrong: Cloud Identity Premium is a paid tier that includes additional features not required for basic access to Google Cloud.

Use Google Workspace.

Why wrong: Google Workspace is a paid productivity suite that includes identity management, but it is more expensive than Cloud Identity Free.

gcloud projects add-iam-policy-binding PROJECT_ID --member=... --role=...

Why wrong: This adds an IAM policy binding at the project level, not create a custom role.

gcloud iam service-accounts create SA_NAME --display-name=...

Why wrong: This creates a service account, not a custom role.

gcloud organizations add-iam-policy-binding ORGANIZATION_ID --member=... --role=...

Why wrong: This command adds an IAM policy binding, not create a custom role.

Annotate the KSA with iam.gke.io/gcp-service-account=GCP_SA_EMAIL. No further steps are needed.

Why wrong: The annotation is necessary, but the IAM binding is also required to authorize the impersonation.

Create a JSON key for the GCP SA and store it as a Kubernetes secret, then mount it into the pods.

Why wrong: Using service account keys is discouraged and circumvents Workload Identity.

Grant the GCP SA the role roles/iam.serviceAccountUser on the KSA.

Why wrong: The role is reversed; the KSA needs the workloadIdentityUser role on the GCP SA, not the other way around.

compute.instances.setMetadata

Why wrong: This permission is for setting metadata, not Shielded VM configuration.

compute.instances.setMachineResources

Why wrong: This permission controls machine type changes, not Shielded VM settings.

compute.instances.update

Why wrong: This is a broader permission that includes many update operations, but the specific permission for Shielded VM is more targeted.

Enable automatic license assignment for all synchronized users.

Why wrong: License assignment is about assigning services, not about access control.

Configure GCDS to sync user passwords.

Why wrong: GCDS does not sync passwords; it only syncs identity attributes.

Create a custom role that allows only synchronized users to access resources.

Why wrong: Custom roles cannot distinguish synchronized users from manual users; they are identity-based.