Setting up a cloud solution environment

A Cloud Billing budget with a threshold rule reaches 100 percent of its configured amount. With the default configuration, what happens to spending on the linked projects?

• ANew resource creation is blocked on the projects until the next billing cycle starts.
• BSpending continues uninterrupted while a notification is sent to the billing recipients.check_circle Correct
• CThe linked projects are automatically suspended so that no further charges accrue.
• DThe billing account is switched to a capped free tier for the rest of the month.

Why A is wrong: This assumes a budget acts as a hard quota, a common misconception, but a budget does not block provisioning; resources continue to be created and charged.

Why B is correct: A budget is a monitoring and alerting tool; reaching a threshold emails the configured recipients but takes no action to reduce or stop usage.

Why C is wrong: Automatic suspension feels like a safety net, but a budget performs no enforcement; suspending a project would require separate automation you build yourself.

Why D is wrong: There is no automatic downgrade to a capped tier; the budget neither changes the billing account nor imposes a spending ceiling on it.

A software company authenticates its engineers through Okta using SAML 2.0. The security team wants those engineers to sign in to the Google Cloud console and receive short-lived credentials, without any Cloud Identity or Google Workspace accounts being created for them. Which approach meets this requirement?

• ARun Google Cloud Directory Sync to provision the Okta users into Cloud Identity, then grant those synced accounts IAM roles on the projects.
• BConfigure Workload Identity Federation with an Okta provider so each engineer can impersonate a shared service account when opening the console.
• CCreate a service account for each engineer, generate a service account key per person, and hand the keys out based on Okta group membership.
• DCreate a workforce identity pool with a SAML provider for Okta, define attribute mappings, and grant IAM roles to the resulting federated principals.check_circle Correct

Why A is wrong: Directory Sync is tempting because it does bridge an external directory to Google, but it creates managed Google accounts in Cloud Identity, which is precisely what the team wants to avoid.

Why B is wrong: Workload Identity Federation sounds close, but it federates non-human workloads to impersonate service accounts and does not provide interactive human sign-in to the console.

Why C is wrong: Per-user keys feel like a way to reuse Okta groups, but service account keys are long-lived static credentials rather than short-lived, and they still rely on Google-managed identities.

Why D is correct: A workforce identity pool with a SAML provider lets Okta users authenticate and receive short-lived credentials for the console while no Google accounts are ever created for them.

A location-restriction organization policy is enforced at the organization node. One project must deploy in a location that policy blocks. Without changing the organization-level policy, how can an administrator permit the exception for that project?

• ASet an organization policy directly on that project defining the allowed locations, since a policy on a lower node governs that node's own effective policy.check_circle Correct
• BGrant the project owner the Organization Policy Administrator role, which then exempts every project that owner manages from the inherited location policy.
• CMove the project out of the organization into a standalone folder so that the inherited location policy no longer reaches it.
• DAdd the project number to an allow list on the organization-level policy, which the project reads at deploy time to bypass the location constraint.

Why A is correct: Correct: a policy set on a lower node can override the inherited one for that constraint, so a project-level policy listing the needed location grants the exception without touching the organization policy.

Why B is wrong: That role lets a principal set and edit organization policies, but holding it does not automatically exempt any resource from an enforced constraint.

Why C is wrong: Folders cannot exist outside an organization, so there is no standalone folder to move the project into, and the move would not lift the constraint anyway.

Why D is wrong: Organization policy constraints are not exempted by per-project number allow lists; exceptions are made by setting a policy on the lower node itself, not by editing the parent policy this way.

A batch rendering job needs 300 vCPUs of Compute Engine capacity in europe-west4, but the project's CPUs allocation quota for that region is 72. The engineer must let the job run without redesigning it. What should the engineer do before creating the instances?

• APurchase a committed use discount for 300 vCPUs in europe-west4 so that the additional cores become available to the project.
• BCreate a second project and split the instances across both projects to keep each one under its own regional quota.
• COpen the Quotas page, filter to the CPUs quota for the project in europe-west4, and submit a request to raise the limit above 300 before launching the instances.check_circle Correct
• DSelect a larger machine type so that fewer instances are needed and the deployment fits inside the current quota.

Why A is wrong: Tempting because a committed use discount concerns sustained Compute Engine spend, but it only lowers price for steady usage and does not change the quota ceiling, so instance creation would still fail.

Why B is wrong: Tempting because default quotas are per project, but sharding one workload across projects to dodge a quota fragments networking and IAM and is unnecessary when an increase can simply be requested.

Why C is correct: Correct: allocation quotas such as CPUs are enforced per project per region, so an approved increase in europe-west4 raises the ceiling and lets the 300 vCPUs be created.

Why D is wrong: Tempting, but a larger machine type consumes more vCPUs each, and the CPUs quota counts total cores regardless of shape, so the same 300 vCPUs still exceed the limit of 72.

A retail company runs a project called analytics-prod. A team of eight data analysts needs read access to the BigQuery datasets in that project, and roughly two new analysts join the team each quarter. The engineer wants to minimise the administrative work needed whenever the team membership changes. What should the engineer do?

• ACreate a group in Cloud Identity, add the analysts as members, and bind that group to the BigQuery Data Viewer role on the analytics-prod project.check_circle Correct
• BGrant the BigQuery Data Viewer role to each analyst's individual user account on the analytics-prod project, and repeat the grant for every new joiner.
• CBind each analyst's user account to the BigQuery Admin role on the analytics-prod project so that future access needs no further changes at all.
• DCreate a service account, grant it the BigQuery Data Viewer role on the project, and share the service account key with each of the analysts.

Why A is correct: Correct; the project IAM policy references the group once, so onboarding a joiner becomes a single membership change in Cloud Identity with no edit to the project IAM policy at all.

Why B is wrong: This is tempting because it works immediately, but it creates a separate binding per person and forces a manual IAM edit for every joiner or leaver, which is exactly the administrative burden the engineer wants to avoid.

Why C is wrong: This is tempting because a broad role appears to reduce later tweaks, but Admin grants write and delete permissions the analysts do not need, and it still binds individuals one at a time.

Why D is wrong: This is tempting as a single shared identity, but sharing service account keys with people is discouraged and removes per-person accountability, since service accounts represent workloads rather than human users.