The goal is to enable teams to deploy infrastructure independently while ensuring compliance with company practices, without requiring teams to understand the underlying details of those practices.
Option A provides deployment capability but doesn't enforce practices. The Editor role is overly broad, and using the gcloud CLI directly requires knowledge of how to configure resources compliantly.
Option B requires teams to learn all the practices, contradicting the requirement that they don't need to know the implementation details.
Option C (Organization Policies) is useful for setting constraints (e.g., disallowing public IPs, restricting regions), but it doesn't provide pre-configured, deployable components that embody best practices. Teams still need to figure out how to build compliant resources within the policy constraints.
Option D (Terraform Modules): This approach encapsulates the company's required practices within reusable infrastructure-as-code modules. Engineering teams can then use these modules as building blocks, providing only the necessary input parameters (like application name or size). The module handles the compliant implementation details internally. This allows teams to deploy independently and ensures compliance without needing deep knowledge of every practice.
Using standardized, compliant modules is a common pattern for enabling self-service infrastructure deployment while maintaining standards and governance.
References:
Terraform Modules: "Modules are containers for multiple resources that are used together... Modules allow complex resources to be abstracted away behind a clean interface." - https://developer.hashicorp.com
/terraform/language/modules
Google Cloud Architecture Framework - Security, privacy, and compliance: Recommends using IaC and pre- approved templates/modules to enforce security configurations. - https://cloud.google.com/architecture
/framework/security-privacy-compliance/define-and-enforce-security-configurations Organization Policy Service: "The Organization Policy Service gives you centralized and programmatic control over your organization's cloud resources... define constraints..." (Focuses on constraints, not providing deployable components). - https://cloud.google.com/resource-manager/docs/organization-policy/overview

Before you run the gcloud compute instances list command, you need to do two things: authenticate with your user account and set the default project for gcloud CLI.
To authenticate with your user account, you need to run gcloud auth login, enter your login credentials in the dialog window, and paste the received login token to gcloud CLI. This will authorize the gcloud CLI to access Google Cloud resources on your behalf1.
To set the default project for gcloud CLI, you need to run gcloud config set project $my_project, where
$my_project is the ID of the project that contains the instances you want to list. This will save you from having to specify the project flag for every gcloud command2.
Option B is not recommended, because using a service account key increases the risk of credential leakage and misuse. It is also not necessary, because you can use your user account to authenticate to the gcloud CLI3.
Option C is not correct, because there is no such thing as a Cloud Identity user account key. Cloud Identity is a service that provides identity and access management for Google Cloud users and groups4. Option D is not required, because the gcloud compute instances list command does not depend on the default zone. You can list instances from all zones or filter by a specific zone using the --filter flag.
1: https://cloud.google.com/sdk/docs/authorizing
2: https://cloud.google.com/sdk/gcloud/reference/config/set
3: https://cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys
4: https://cloud.google.com/identity/docs/overview
5: https://cloud.google.com/sdk/gcloud/reference/compute/instances/list

A is not correct because you should use "bq", not "gcloud", to estimate the amount of bytes read.
B is correct because this is the correct way to estimate the yearly BigQuery querying costs.
C is not correct because you should use "bq", not "gcloud", to work with BigQuery.
D is not correct because this will not give the amount billed for a query.