Bootstrapping a Google Cloud organization for DevOps practice questions

roles/artifactregistry.reader

Why wrong: This role allows reading artifacts but not writing, so it would cause permission denied when trying to push.

roles/artifactregistry.admin

Why wrong: This role provides full administrative access, including write, but it is overly permissive; the principle of least privilege suggests writer is sufficient.

roles/cloudbuild.builds.builder

Why wrong: This role is for Cloud Build itself, not for accessing Artifact Registry; it does not grant repository permissions.

Configure Cloud Shell to run a script that creates a perimeter when a new project is created.

Why wrong: Cloud Shell is not designed for automated enforcement triggers.

Use Deployment Manager to deploy a configuration that creates a perimeter for each new project.

Why wrong: This is reactive and not automatic; requires manual trigger or script.

Create a VPC Service Controls perimeter and add the organization node as a member.

Why wrong: Perimeters cannot be applied to the organization node directly; they apply to projects.

Project Creator and Service Project Admin

Why wrong: Project Creator allows creating projects but not attaching to host VPC.

Compute Shared VPC Admin

Why wrong: This role alone doesn't allow creating projects.

Owner and Service Project Admin

Why wrong: Owner is too broad and not minimal.

Configure Cloud Source Repositories to require code review for any changes to Terraform configurations that delete resources.

Why wrong: This only controls infrastructure-as-code changes, not direct API calls.

Implement Binary Authorization to require approvals for any delete commands.

Why wrong: Binary Authorization is for container deployment, not resource deletion.

Use VPC Service Controls to block delete operations on specific services.

Why wrong: VPC Service Controls control data exfiltration, not deletion.

Create a Cloud Function that triggers on project creation events and enables the required APIs.

Why wrong: This is reactive and may have delay; also requires additional setup.

Use Cloud Foundation Toolkit to deploy a project template that includes API enablement.

Why wrong: Templates don't enforce; users could choose not to use them.

Create a shared VPC and enable the APIs in the host project only.

Why wrong: Shared VPC does not enable APIs in service projects.

Use resource tags to label projects by environment and apply policies via tag-based conditions.

Why wrong: Tags can be used for conditions but not for hierarchical policy enforcement.

Create separate organizations for each environment.

Why wrong: Organizations are not meant for environment separation; it's costly and complex.

Use labels on projects to identify environments and then use Cloud Asset Inventory to enforce policies.

Why wrong: Labels are metadata, not a mechanism for applying policies hierarchically.

Use a user account for the CI/CD pipeline and assign it the necessary roles.

Why wrong: User accounts are not recommended for automation.

Store service account keys in Secret Manager and have the pipeline retrieve them at runtime.

Why wrong: Still uses a key, albeit stored securely.

Generate a single service account key and securely distribute it to the CI/CD system.

Why wrong: Long-lived keys are a security risk.

Use resource tags to label the projects and then create a tag-based perimeter.

Why wrong: There is no tag-based perimeter; perimeters are based on project membership.

Apply the perimeter to the folder directly.

Why wrong: Perimeters cannot be applied directly to folders.

Create an organization policy that forces all projects in the folder to be in a perimeter.

Why wrong: Organization policies can enforce that projects are in a perimeter, but you still need to create and assign the perimeter.

Enable logging and monitoring in each project individually and use the Cloud Console to view them.

Why wrong: No centralization; difficult to manage.

Enable Cloud Audit Logs in the organization and view them from the Organization level.

Why wrong: Only covers audit logs, not all logs.

Use Stackdriver (now Operations) to aggregate logs from all projects automatically.

Why wrong: Aggregation requires configuration, not automatic.

Grant the Owner role to a group of DevOps engineers to manage all projects.

Why wrong: Owner role grants excessive permissions; should use more specific roles.

Store service account keys in the source code repository for ease of use.

Why wrong: Storing keys in code is a security risk.

Create a single VPC network for all environments to simplify management.

Why wrong: Lack of isolation between environments is a security risk.

Assign the Owner role at the organization level to a small group of administrators.

Why wrong: Owner is a high-privilege role; should be limited to project level if possible.

Use primitive roles (Owner, Editor, Viewer) to simplify management.

Why wrong: Primitive roles are too broad; use predefined or custom roles.

Eliminates the need for project administrators to have any IAM roles.

Why wrong: Project admins still need roles to manage their own resources.

Ensures compliance with organizational policies.

Why wrong: Shared VPC does not enforce policies; it's a network architecture.

Automatically enables required APIs in all service projects.

Why wrong: APIs must be enabled explicitly.

The organization policy has not propagated to all projects yet.

Why wrong: Organization policies propagate quickly; delay is unlikely.

The developer used the wrong constraint name; the correct constraint is 'compute.restrictExternalIp'.

Why wrong: The correct constraint is 'compute.vmExternalIpAccess'.

The developer tagged the instance with a tag that exempts it from the organization policy.

Why wrong: Tags can be used in conditions, but if the policy is set to deny all, tags won't bypass unless there is a condition allowing it.

Grant the Application team the Compute Network Admin role on the host project.

Why wrong: This would give too much permission; they only need to use subnets.

Grant the Application team the Compute Network User role on the service project.

Why wrong: The subnet permissions are on the host project, not the service project.

Grant the Application team the roles/compute.subnetUser on the subnet.

Why wrong: The role is Compute Network User, not subnetUser.

Create a Cloud Deployment Manager template and share it with all project owners.

Why wrong: Cloud Deployment Manager templates are not automatically applied; they require manual deployment per project.

Set up VPC Network Peering between all projects to enforce network connectivity.

Why wrong: VPC Network Peering does not enforce network creation or configuration.

Configure a shared VPC host project and attach all new service projects to it.

Why wrong: Shared VPC provides shared networks but does not enforce creation of per-project networks.

Grant the service account the Storage Object Admin role on the service account itself.

Why wrong: Roles are granted to identities, not on identities; this does not apply to the bucket.

Grant the service account the Storage Object Admin role at the project level.

Why wrong: Project-level role grants access to all buckets in the project, which is unnecessary.

Grant the service account the Storage Admin role at the project level.

Why wrong: Storage Admin is a broad role that grants full control over all storage resources in the project.

Disable the ability to turn off Cloud Logging by using the Organization Policy 'compute.disableCloudLogging'.

Why wrong: Incorrect. The policy `compute.disableCloudLogging` is a built-in constraint, but it is used to *disable* Cloud Logging for Compute Engine, not to enforce it. Also, it only applies to Compute Engine, not all resources.

Use the built-in Organization Policy constraint 'constraints/gcp.resourceAuditLoggingExemption' to enforce audit logging.

Why wrong: Incorrect. The constraint `constraints/gcp.resourceAuditLogging` does not exist. The correct built-in constraint is `constraints/gcp.resourceAuditLoggingExemption`, which only enforces audit logging, not all Cloud Logging. Enforcing audit logging alone does not meet the requirement to enforce that Cloud Logging is enabled.

Set a project-level default for Cloud Logging using Organization Policies.

Why wrong: Incorrect. Organization Policies are used to set constraints, not defaults. You cannot set a "default" for Cloud Logging using Organization Policies; you can only enforce restrictions.

Configure the pipeline to impersonate a project-level service account in each project.

Why wrong: Impersonating a project-level service account per project would require the pipeline to hold the `iam.serviceAccountTokenCreator` role on each target project’s service account, which violates the requirement for minimal permissions by granting broad token-creation capability rather than scoped deployment permissions. This approach is tempting because impersonation is the standard pattern for cross-project access when a pipeline needs to act as a specific identity in each project, and it would be correct if the goal were to reuse a single pipeline identity without granting it direct resource-level roles across projects.

Grant the service account the Project Editor role at the organization level.

Why wrong: Organization-level Project Editor grants excessive permissions across all projects.

Use the Cloud Build service account and grant it permissions on each project.

Why wrong: Cloud Build service account is for Cloud Build itself, not for custom pipelines.

Use VPC Service Controls to restrict access to the bucket from only the CI/CD pipeline's VPC.

Why wrong: VPC-SC controls network access, not IAM; it does not enforce identity-based restrictions.

Create a custom IAM role with permissions to write to the bucket and assign it to the CI/CD service account.

Why wrong: This still allows other identities with the same role or higher to write.

Grant the Storage Object Admin role to the CI/CD service account at the bucket level.

Why wrong: This does not prevent other identities from writing if they have project-level access.

Share a single service account key across multiple projects for simplicity.

Why wrong: Sharing keys is insecure and violates the principle of least privilege.

Disable Organization Policies to allow maximum flexibility for DevOps teams.

Why wrong: Disabling policies undermines governance and security.

Create a single service account with broad permissions to be used by all projects.

Why wrong: A single service account with broad permissions is a security risk.