GCP Associate Cloud Engineer Practice Test

An IAM policy is always attached to a specific Google Cloud resource such as a project, folder, or organization. Inside the policy, each binding pairs one role with one or more members (principals). Therefore, to recreate a binding you must know: 1) the resource that the policy is attached to, 2) the role being granted, and 3) the member (principal) receiving that role. Other items sometimes found in policies-such as conditions, audit log sinks, or service perimeters-are optional features that may be absent from many bindings, so they are not required in every case. Capturing the resource, role, and principal ensures the binding can always be reconstructed.

The compute.vmExternalIpAccess organization-policy constraint controls whether VMs can be created with external IPv4 addresses. By setting a policy at the Organization node that denies all principals, every folder and project automatically inherits the restriction. Because policies are inherited but can be overridden lower in the hierarchy, you can add a second policy only on the vpc-test project that specifies the network-engineering service account in the allowed list (or simply clears the enforcement flag). This keeps the default deny posture everywhere, avoids per-project repetition, and follows the principle of least privilege. The other options either rely on IAM roles (which do not block external IP assignment), network topologies that do not stop users from requesting external IPs, or IAM Deny rules that do not offer the fine-grained exception handling provided by the organization-policy constraint.

A zone is the most granular Google Cloud deployment area and is identified by a region name followed by a lowercase letter, such as "-a" or "-b". "us-central1-a" fits this pattern, meaning it is a single zone inside the "us-central1" region. "northamerica-northeast1" lacks the final letter and therefore represents an entire region. "us" is a multi-regional location, and "global" indicates a service that is not tied to any specific geography. Only "us-central1-a" is a zonal identifier.

Google Cloud uses quota limits to prevent any single customer-intentionally or accidentally-from consuming a disproportionate share of shared infrastructure. By throttling sudden, large spikes in resource usage, quotas help maintain service reliability and fair access for all customers. While quotas can incidentally help control costs, are unrelated to regulatory compliance, and do not function as high-availability reservations.

To create a new service account you use gcloud iam service-accounts create. The command requires only the account ID; optional flags like --display-name (and --description) let you set metadata at creation time. Supplying the --project flag ensures the account is created in the intended project. The other commands either try to bind roles (which presumes the account already exists), add a key, or update an existing account-all of which do not create a new service account.

The Editor primitive role grants broad read-write access to nearly all resources in a project, so the developers can create, update, and delete Compute Engine instances, Cloud Storage buckets, and other resources. Editor does not include permissions such as resourcemanager.projects.setIamPolicy (modify IAM policies), resourcemanager.projects.delete (delete the project), or billing.projectManager (link or unlink billing accounts). Therefore, it meets the security team's constraints better than the Owner role, which is overly permissive. Viewer is read-only and would not let developers modify resources, and a custom role is unnecessary because the Editor role already satisfies the requirements.

The immediate blocker is that the regional vCPU quota has been exhausted. The fastest way to allow the pipeline to proceed is to request a quota increase for the CPUS resource in europe-west1. This is done in the Quotas page of the Google Cloud console (or with gcloud/serviceusage API) and, once approved, raises the regional limit so future deployments will succeed without code changes.

Choosing a different machine type or region might unblock today but does not ensure deployments will work the next time the quota is hit, and it forces changes to infrastructure code. Creating a new project gives a fresh quota allotment but requires configuring networking, IAM bindings, and billing links, which is slower than requesting additional quota and is not necessary when a single region quota is the only constraint.

The Google Cloud Ops Agent is a single agent that collects both system metrics (CPU, memory, disk, network, etc.) for Cloud Monitoring and application and system logs for Cloud Logging. Installing it on the VM satisfies the need for comprehensive observability while keeping operational overhead low because only one agent must be deployed and managed.

Enabling the Cloud Logging and Cloud Monitoring APIs alone is insufficient; without an agent, most guest-level metrics and many application logs are not captured. The legacy Stackdriver Monitoring agent collects metrics only, and the legacy Logging agent collects logs only-using both would require two separate agents, which conflicts with the requirement to minimize agent management. Cloud Trace client libraries capture distributed traces, not general logs or system metrics.

Linking a project to a billing account requires permissions on two separate resources:

1. Billing account - you need the billing.accounts.get and billing.accounts.update permissions, which are included in the Billing Account User role (roles/billing.user).
2. Project - you need the resourcemanager.projects.updateBillingInfo permission, provided by the Project Billing Manager role (roles/resourcemanager.projectBillingManager).

Granting Billing Account User on the billing account plus Project Billing Manager on the project satisfies these requirements and follows the principle of least privilege. Billing Account Administrator or Owner roles would also work but grant unnecessary additional permissions. Similarly, granting Editor on the project is broader than needed.

Therefore, selecting Billing Account User for the billing account together with Project Billing Manager for the project is the correct and most restrictive solution.

Folders are the recommended way to group projects that share common administrators or policy requirements. By creating one folder for Finance and another for Engineering, you can:

• Move each team's projects into the appropriate folder once, then rely on inheritance for both IAM and Organization Policy.
• Grant department leads roles on their folder so they automatically manage all current and future projects inside it.
• Let central administrators attach constraints (such as blocking external VM IPs) to just the Engineering folder without touching Finance. Labels do not influence IAM or Organization Policy inheritance, so using only labels would require per-project administration. Maintaining separate Organizations would add unnecessary complexity and prevent shared billing or networking. Keeping projects outside any Organization would remove the ability to apply Organization Policies entirely. Therefore, structuring the hierarchy with dedicated top-level folders is the most efficient and scalable solution.

The Google Cloud Ops Agent is a single package that replaces the older standalone Monitoring and Logging agents. It ships system metrics and logs out of the box and can be extended by creating /etc/google-cloud-ops-agent/config.yaml, where you add receivers such as the built-in type: nginx_access to capture NGINX access logs. Installing both legacy agents or exporting logs in other ways would require two components or extra infrastructure, contrary to the requirement for one agent and one configuration file.

Auto mode VPC networks always create one subnet per region at creation time and automatically add new subnets whenever Google Cloud launches a new region, so they cannot guarantee that only the two required subnets will exist. The most straightforward way to meet the requirement is to create the VPC in custom mode, which starts with no subnets, and then explicitly create just the two needed subnets, each with its region and IP CIDR range. Deleting subnets from an auto-mode network or trying to rename/resize default subnets is error-prone and still would not stop future automatic subnet creation. Therefore, the sequence that builds a custom-mode network and then adds the two subnets is the only correct solution.

Google Cloud Organization Policy lets you set constraints that are inherited by all descendants in the resource hierarchy unless an ancestor overrides them. The constraint constraints/compute.vmExternalIpAccess controls whether new VM instances can obtain external IPv4 addresses. By setting this constraint to Deny at the prod folder level, every current and future project inside that folder will automatically block external IP assignment, while projects in the dev folder remain unaffected because they inherit policies from their own (less-restricted) ancestors. Applying the policy at the organization level would also affect dev projects, and using other constraints or IAM changes would not reliably block external IP creation. Deleting default VPC networks does not prevent users from adding external addresses to new VMs in custom networks.

A regional location (for example, europe-west3) keeps resources inside a single Google Cloud region, ensuring that data does not leave that geographic area. At the same time, the service can deploy synchronously replicated resources across multiple zones within that region, providing resilience against a single-zone outage. A zonal location provides no cross-zone redundancy, while a multi-regional or global location would place data in more than one region, violating the residency constraint.

Granting the Storage Object Viewer role (roles/storage.objectViewer) on the specific bucket gives Alice permission to list objects and read their data in that bucket only. Because the binding is applied at the bucket level, it does not cascade to other buckets or project resources, preserving least-privilege. Granting the same role or any broader role (such as Viewer or Storage Admin) at the project level would allow Alice to read objects in every bucket in the project. Granting Storage Admin on the bucket would let her create, overwrite, or delete objects, violating the read-only requirement.

An Organization resource is created automatically for a domain after someone in that domain signs up for Google Cloud and the domain is managed by either Google Workspace or Cloud Identity. Because the company does not want Google Workspace, the correct approach is to enroll the company's domain in Cloud Identity (free or premium) and complete domain verification. When a user from that Cloud Identity domain next accesses Google Cloud, the Organization node is created and projects can be migrated under it. Creating billing accounts, requesting support, or manipulating service accounts do not create an Organization resource.

The VPC network itself is a global resource. Its control plane spans Google's backbone and is not tied to any particular region or zone, so it is still manageable even if a single region goes down. Subnetworks inherit the regional location of the IP ranges they are created in, Cloud NAT gateways are regional resources that depend on regional subnets, and Compute Engine virtual machines are zonal resources that exist in a specific zone within a region.

Exporting Cloud Billing data to BigQuery at the detailed usage cost level writes every usage record-including project, service, SKU, and label information-into a managed BigQuery dataset each day. Finance analysts can run SQL against the tables, join them with other datasets, and retain the data for as long as needed. Exporting to Cloud Storage creates files that must be ingested separately, the Billing Reports page is a UI without raw records, and budget-based Pub/Sub notifications only emit threshold events, not detailed cost lines.

Predefined roles such as Storage Object Admin or Storage Admin bundle all storage.objects.* permissions, which include storage.objects.getIamPolicy-violating the security team's restriction. A custom role lets you pick only the necessary permissions (for example, storage.objects.create and storage.objects.delete) and omit the disallowed storage.objects.getIamPolicy. You can then bind that custom role to the analysts' group at the bucket level. Combining IAM conditions with broader roles would still include the prohibited permission, and using ACLs or Uniform bucket-level access does not remove permissions embedded in the predefined roles. Therefore, defining and assigning a custom IAM role is the correct and least-privilege solution.

A self-serve (online) Cloud Billing account is designed for automatic payments. You register a credit card or bank account, and Google automatically bills the payment method when the accrued charges hit the threshold (or at the end of the billing cycle if the threshold is not reached). This model does not generate paper invoices or require purchase-order approval. In contrast, invoiced (offline) accounts are available only to customers that meet Google's credit requirements, generate a monthly invoice with net-30 terms, and typically involve manual payment by wire or check. Operating without a billing account would block paid usage, and using a reseller would delegate billing control to the partner. Therefore, a self-serve billing account is the appropriate choice.