Configuring Access Within a Cloud Solution Environment practice questions

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 could block the permission, Organization Policy is the recommended approach for such resource-level constraints, and the built-in constraint is simpler and more straightforward.

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.

constraints/compute.requireOsLogin

Why wrong: This requires OS Login for SSH, not relevant to the stated requirements.

constraints/compute.restrictCloudArmorPolicies

Why wrong: This restricts the use of Cloud Armor policies, not relevant to the requirements.

Deny policies can only be applied at the organization level.

Why wrong: Deny policies can be applied at organization, folder, project, and even resource level.

Allow policies at the folder level are inherited by all projects in that folder and cannot be overridden by project-level allow policies.

Why wrong: Project-level allow policies add to folder-level allow policies; they can grant additional permissions, not override. However, they cannot remove permissions granted at the folder level. But statement says 'cannot be overridden', which is misleading because project-level allow policies can still grant more. The true statement is that allow policies are additive; they do not override in the sense of reducing access.

Allow policies are evaluated before deny policies.

Why wrong: Deny policies are evaluated first; if a deny applies, the allow is not considered.

Configure a Cloud Security Command Center (SCC) policy to scan and alert on non-compliant VMs.

Why wrong: SCC detects but does not enforce; it only alerts after the fact.

Use an IAM deny policy to prevent users from creating VMs without Shielded VM.

Why wrong: IAM deny policies control permissions, not resource configurations. They cannot enforce VM settings.

Create a custom organization policy using the Organization Policy Service.

Why wrong: A built-in constraint exists; a custom constraint is unnecessary and less efficient.

Assign the predefined roles/viewer role and add a condition to deny access to Cloud Storage.

Why wrong: Predefined roles cannot be easily restricted; conditions can deny but may be complex and less secure.

Use a deny policy to block access to storage.objects.get for the auditor.

Why wrong: Deny policies are used to explicitly deny permissions, but combining allow and deny is more complex and less precise than a custom role.

Assign the basic roles/reader role to the auditor.

Why wrong: Basic roles are broad and include storage read access.

Workload Identity Federation.

Why wrong: Workload Identity Federation is for non-human workloads, not user authentication.

SAML 2.0 federation with the web app.

Why wrong: SAML is used for SSO but IAP natively supports OIDC, not SAML for web apps.

Firebase Authentication with Google provider.

Why wrong: Firebase Auth is for consumer apps, not enterprise Google Workspace identity.

Store the service account key in Secret Manager and retrieve it at runtime.

Why wrong: This still requires a long-lived key to access Secret Manager or the key itself.

Use the default compute engine service account instead.

Why wrong: Default service accounts often have broad permissions and less control.

Use Workload Identity Federation to authenticate the batch job.

Why wrong: Workload Identity Federation is for external identities (e.g., AWS), not for Compute Engine VMs.

roles/iam.roleViewer

Why wrong: This role only lists roles, not IAM policies.

roles/viewer

Why wrong: Viewer does not include IAM policy read permissions.

roles/securityAdmin

Why wrong: Includes write permissions, too broad.