Configuring Access and Security practice questions

Add the auditor's email as a member with the Storage Admin role on the project.

Why it fails: Storage Admin (roles/storage.admin) grants full read/write/delete permissions on all Cloud Storage buckets and objects in the project, as well as the ability to configure bucket IAM policies. For an external auditor, this massively exceeds the principle of least privilege, exposing the organization to accidental or malicious data deletion or permission changes. A read-only role such as Storage Object Viewer is the appropriate baseline, and even then should be scoped to specific buckets using IAM Conditions.

Use a signed URL for each object the auditor needs to see.

Why it fails: Signed URLs provide time-bound, HMAC-signed links to a single object or, at most, a small set of explicit objects, and they grant access to anyone holding the URL without requiring a Google identity. They are not a governance mechanism for ongoing, auditable read access to a set of buckets: each object needs a separate URL, new URLs must be generated when the auditor returns, and URL expiration forces constant re-issuance. For an ongoing audit requirement, IAM with a scoped read-only role is more manageable, secure, and centrally revocable.

Add the auditor's email as a member with the Storage Object Viewer role on the project, and use IAM Conditions to restrict access to specific bucket resources.

Why it fails: Assigning Storage Object Viewer at the project level grants read-only access to all objects in all buckets by default, but binding that grant with an IAM Condition that checks the resource name (e.g., resource.name.startsWith("projects/_/buckets/audit-")) restricts the access to exactly the intended buckets at access time. The auditor can then list and read objects only within those matches, while the project-level policy remains a single, centrally managed binding that can be audited and adjusted without touching each bucket. This delivers the least-privilege read-only guarantee the auditor needs while keeping operations scalable and governance clean.

The firewall rule has a priority lower than 65535.

Why it fails: The priority value of a VPC firewall rule is a numeric ordering, where lower numbers take precedence over higher numbers. A priority lower than 65535 (e.g., the default 1000) simply means the rule is evaluated earlier, not that it is ineffective or overridden, provided no higher-priority rule matches first. In this scenario, the rule's action and direction are correct, so priority is irrelevant; the rule fails to apply because it targets a specific network tag, not because of its position in the evaluation order. Even a rule with priority 65535 would apply normally if its target matches the instance.

The instance is using a VPC with a custom subnet.

Why it fails: VPC firewall rules are scoped to the entire VPC network, not to individual subnets, so whether a subnet is auto-created or custom has no bearing on which firewall rules apply. Custom subnets only let you choose your own IP ranges and secondary ranges, but they do not change how firewall rules select instances—that selection is based on target tags, target service accounts, or all instances in the network. Therefore, an instance in a custom subnet is still subject to the same VPC-wide firewall evaluation as any other instance, and the missing 'web-server' tag is the actual reason the rule is ignored.

The firewall rule is denying outbound traffic.

Why it fails: GCP firewall rules are stateful, meaning that when an inbound connection is allowed, all subsequent outbound traffic belonging to that established connection is automatically permitted, even if a separate outbound deny rule exists. A rule that denies outbound traffic only blocks new outbound connections initiated from the instance; it does not block return packets for an already-allowed inbound flow. Since the engineer's rule is specifically allowing inbound HTTP, the return HTTP traffic from the instance is not affected by any outbound deny rule. The issue is not outbound denial but the instance's lack of the target network tag needed for the inbound allow rule to match.

Cloud Router only

Why it fails: A Cloud Router alone is only a BGP-based dynamic routing service that exchanges routes between your VPC and on-premises networks; it does not perform address translation. To provide outbound internet access to private instances, you must create a NAT gateway on the Cloud Router and assign NAT IP addresses. Without that gateway, the router has no mechanism to translate private source IPs, so instances remain unable to reach the internet.

Cloud VPN and Cloud NAT

Why it fails: Cloud VPN is used to create encrypted tunnels back to on-premises networks and is entirely unrelated to providing outbound internet access for private instances. Cloud NAT does not require or use a VPN tunnel; it runs on a Cloud Router and translates source IPs from private ranges to the NAT IPs. Adding a VPN would be an unnecessary and separate connectivity service, and it would not satisfy the need for a dedicated NAT gateway.

Cloud Interconnect and Cloud NAT

Why it fails: Cloud Interconnect provides dedicated, high-bandwidth connectivity between your on-premises network and Google's network, often for hybrid workloads; it does not perform NAT or manage outbound internet traffic. Cloud NAT's purpose is address translation for private VMs, which still requires a Cloud Router and a NAT gateway. Interconnect is an optional network connectivity product and cannot replace or complement NAT requirements in this scenario.

Create a rule with source tag 'subnet-a-instances', allow tcp:443, and target tag 'https-server'.

Why it fails: This rule cannot be created because VPC firewall rules only accept IPv4/IPv6 CIDR ranges as the source, not network tags or instance tags. Source tags are simply not a supported field in the firewall rule grammar, so the configuration is invalid from the start. Even if tags were allowed, they do not translate to the IP addresses of instances in subnet-a, so the intended source restriction would not be enforceable.

Create a rule with source range 0.0.0.0/0, allow tcp:443, and target the specific instance.

Why it fails: Setting the source range to 0.0.0.0/0 allows inbound TCP 443 traffic from any IP address on the internet, not just from subnet-a's 10.0.1.0/24 range. This directly violates the requirement to restrict access solely to the instances in subnet-a, creating an unnecessarily broad exposure. While targeting the specific instance limits the destination, the source is far too permissive, so the rule does not meet the stated security constraint.

Create a rule with source range 10.0.1.0/24, allow tcp:443, and apply to all instances in subnet-b.

Why it fails: This rule correctly specifies the source as 10.0.1.0/24, but by applying it to all instances in subnet-b (e.g., via a broad target tag or no target tag), it permits any instance in subnet-b to receive HTTPS traffic on port 443. The requirement is to allow traffic only to the one specific web server instance, so this rule over-permits and expands the blast radius beyond what was asked for. A more precise target, such as a unique network tag applied only to that instance, is needed.

gcloud iam service-accounts create and gcloud iam service-accounts add-iam-policy-binding

Why it fails: This command pair is incorrect because `gcloud iam service-accounts add-iam-policy-binding` modifies the IAM policy of the service account resource itself, not the project. That binding would grant principals permissions to use or administer the service account (e.g., roles/iam.serviceAccountUser), but it does not grant the service account any roles on the project. To grant the new service account a role on the project, you must add the service account as a member in the project's IAM policy using `gcloud projects add-iam-policy-binding`.

gcloud projects add-iam-policy-binding only

Why it fails: Running only `gcloud projects add-iam-policy-binding` fails for this scenario because the service account does not yet exist. The command expects the member identifier (the service account email) to already be present in the project, and creating a binding to a non-existent principal will either error out or have no effect. Since the requirement explicitly says to create a new service account, a `gcloud iam service-accounts create` step is mandatory before any project-level binding can be applied.

gcloud iam service-accounts create and gcloud iam roles create

Why it fails: The flaw in this pair is that `gcloud iam roles create` is used to define a new custom role in an organization or project, not to grant an existing role to a principal. Even after creating the service account, running this command would only create a role definition, leaving the service account without any actual permissions on the project. To grant the service account a role, you must use `gcloud projects add-iam-policy-binding` to add the service account as a member with a predefined or existing custom role.

Grant the roles/storage.admin role at the bucket level.

Why it fails: Granting roles/storage.admin at the bucket level is incorrect because this role grants full management control, including deleting the bucket and its objects, overwriting objects, and modifying IAM policies. For a workload that only needs to read data, such as a Compute Engine instance processing files, the principle of least privilege dictates using roles/storage.objectViewer instead. This overly permissive role increases the blast radius if the instance's credentials are compromised.

Grant the roles/storage.objectViewer role at the project level to the service account.

Why it fails: Assigning roles/storage.objectViewer at the project level to the service account would allow the instance to view objects in every bucket within the project, not just the intended one. This broad scope violates least privilege and could expose sensitive data stored in unrelated buckets. The correct approach is to grant this role at the specific bucket level, scoped to the custom service account, so access is limited to only the necessary resources.

Use the default Compute Engine service account.

Why it fails: Using the default Compute Engine service account is problematic because it typically has the project Editor role, which grants read/write access to most Google Cloud services, not just storage. This broad permission set contradicts the least-privilege model and makes it difficult to audit what the instance can actually do. A dedicated custom service account with only the required storage role should be created instead.

Use gcloud projects set-iam-policy with a policy file that includes the binding.

Why it fails: The `gcloud projects set-iam-policy` command replaces the entire IAM policy for the project with the policy specified in the file. While you could include the desired binding in that policy, this approach is error-prone because it overwrites all existing bindings; you must first call `projects get-iam-policy` and manually merge. For a simple grant, `add-iam-policy-binding` is designed to modify only the specific binding, so this is not a recommended or direct way to grant a role.

Use gcloud iam roles create to assign the role to the service account.

Why it fails: The `gcloud iam roles create` command defines a new custom IAM role by specifying its title, description, and a set of permissions. It does not attach the role to any member or service account, so it cannot be used to grant or assign the role. To assign a role, you must bind the role to a member using `add-iam-policy-binding` on a project, folder, or resource, or use `gcloud projects set-iam-policy`.

Use gcloud iam service-accounts add-iam-policy-binding.

Why it fails: `gcloud iam service-accounts add-iam-policy-binding` modifies the IAM policy of the service account itself, controlling which principals can act as or administer that service account. It does not grant permissions to the service account on other resources like a Cloud Storage bucket. To grant the service account access to a bucket, you must bind the role to the service account as a member on the bucket or project, using the appropriate add-iam-policy-binding command.

roles/iam.serviceAccountAdmin

Why it fails: This role includes the iam.serviceAccounts.delete permission, which allows deleting service accounts, contradicting the requirement that the user not be able to delete them.

roles/iam.serviceAccountDeleter

Why it fails: This is not a predefined IAM role.

roles/iam.serviceAccountUser

Why it fails: This role allows using existing service accounts but does not allow creating new ones.

gcloud compute firewall-rules create allow-http --allow tcp:80 --source-tags web-server --target-ranges 0.0.0.0/0

Why it fails: This command incorrectly uses `--source-tags` to define the source as `web-server`; source tags match traffic originating from instances with that tag, not internet CIDR blocks. It also uses `--target-ranges`, which is not a valid flag for GCP firewall rules—the destination is selected via `--target-tags` or the rule applies to all instances in the network if omitted. Since the requirement is to allow traffic from the internet (0.0.0.0/0) to your tagged webservers, you must use `--source-ranges` and `--target-tags`.

gcloud compute firewall-rules create allow-http --allow tcp:80 --source-ranges 0.0.0.0/0 --target-tags default

Why it fails: The rule defines the correct protocol, port, and source range (0.0.0.0/0), but it targets instances with the network tag `default` instead of `web-server`. If your webserver instances are tagged `web-server`, this rule will not apply to them, leaving HTTP traffic blocked. The `--target-tags` flag must match the tag actually installed on the intended VM instances.

Create a firewall rule with priority 2000 denying ingress from 0.0.0.0/0 and a rule allowing ingress from 10.0.0.0/16 on port 443 with priority 1000.

Why it fails: Incorrect: The default rules still exist and allow internet ingress; the deny rule has lower priority (higher number) than default allow rules (priority 65535), so the default rules take effect.

Create a firewall rule with priority 1000 allowing ingress from 0.0.0.0/0 on port 443 and deny all other traffic.

Why it fails: Incorrect: This still allows traffic from the internet on port 443.

Modify the default-allow-internal rule to only allow port 443.

Why it fails: Incorrect: The default-allow-internal rule cannot be modified; it must be recreated with the desired ports.

Create a script using Deployment Manager to enable audit logs in all projects.

Why it fails: Deployment Manager is a resource orchestration tool designed for provisioning infrastructure, whereas the requirement demands an automated policy enforcement mechanism. While this approach works when deploying specific cloud resources via templates, it fails to govern existing or future projects automatically as they are created. To ensure all new projects inherit these settings without manual intervention, you must use Organisation Policy constraints rather than imperative scripting.

Enable Data Access audit logs in each project individually using gcloud logging.

Why it fails: Incorrect: This would require manual effort for each new project.

Enable Admin Activity audit logs at the organization level, which automatically enables Data Access logs.

Why it fails: Incorrect: Admin Activity logs do not enable Data Access logs.

Use a firewall rule to block instances without the required service account.

Why it fails: Firewall rules are network-layer filters that inspect traffic based on protocols, ports, and targets; they cannot influence IAM or service account assignment during instance creation. Even if you create a rule that blocks traffic from instances lacking a specific service account, those instances would still be created with their (possibly wrong) service account and could still be listed, logged, or access metadata APIs. Thus this approach neither prevents creation nor enforces the required identity, so it does not satisfy the security team's requirement.

Enable Shielded VMs on the project.

Why it fails: Shielded VMs offer security features such as Secure Boot, virtual trusted platform module (vTPM), and integrity monitoring, which protect the instance's firmware and boot process. However, none of these mechanisms control or validate the Google Cloud service account attached to the instance at creation time. A misconfigured instance with an overly permissive service account can still be a Shielded VM with all protections enabled, so enabling Shielded VMs does nothing to enforce the 'required service account' policy.

Create a custom role with `compute.instances.create` and assign it to all users.

Why it fails: Granting all users a custom role containing compute.instances.create merely authorizes them to create VM instances; it does not constrain which service account they can select during the create operation. Users could specify any service account they have permission to use, or even the default Compute Engine service account, despite the security team's intent. To enforce a mandatory service account, you need an organization policy constraint that limits the serviceAccount field on the instance creation request, not just an IAM permission.

Grant the roles/storage.objectViewer and roles/pubsub.publisher roles to the service account.

Why it fails: roles/storage.objectViewer provides read-only access to objects in Cloud Storage, including the ability to list and get objects, while roles/pubsub.publisher permits only publishing messages to a topic without allowing administrative operations like topic creation or IAM changes. Together, these predefined roles deliver exactly the least-privilege permissions required by an application that needs to read stored objects and publish to Pub/Sub. Because predefined roles are curated and maintained by Google Cloud, they avoid the management overhead of custom roles while still being narrowly scoped.

Grant the roles/storage.admin and roles/pubsub.admin roles to the service account.

Why it fails: Assigning roles/storage.admin grants full control over Storage buckets and objects—creating, deleting, updating, and setting IAM policies—while roles/pubsub.admin allows complete management of topics, subscriptions, and IAM bindings. These permissions far exceed the application's needs for simple object reads and message publications, violating the principle of least privilege. An attacker who compromises a service account with admin roles could delete critical data or disrupt messaging infrastructure, whereas the required roles would only allow read and publish operations.

Grant the roles/editor role to the service account.

Why it fails: roles/editor is a legacy primitive role that grants broad write-access to almost all Google Cloud resources, including Compute Engine instances, Kubernetes clusters, and Cloud Functions, but it does not allow IAM administration. This is far too permissive for a service account whose only tasks are reading objects from Storage and publishing to Pub/Sub. Unnecessary permissions expand the attack surface and make it harder to audit the service account's actual impact; the least-privilege approach demands using only the purpose-built predefined roles that match the required actions.

Use the `--encryption-key` flag in the `gsutil mb` command.

Why it fails: The `--encryption-key` flag is not a valid option for `gsutil mb`; it is used with `gsutil cp` or `gsutil rsync` to apply a specific encryption key to individual object operations. To establish a bucket-wide default encryption key at creation, you must use `--default-encryption-key` instead, and pass the full KMS key resource ID, not just a key name. Attempting to use the former flag on `gsutil mb` will result in a command-line parsing error or be silently ignored.

Assign the Cloud KMS CryptoKey Encrypter/Decrypter role to the Cloud Storage service account.

Why it fails: Assigning the Cloud KMS CryptoKey Encrypter/Decrypter role to the Cloud Storage service account is a necessary IAM prerequisite, allowing Cloud Storage to encrypt and decrypt objects using the specified key. However, this role assignment alone does not create a bucket nor set the default key; it must be combined with either the `gsutil mb --default-encryption-key` command or the equivalent API/console configuration. Since the question asks for the specific step at the time of bucket creation, this IAM change is not the correct answer, as it is a separate configuration step that must occur beforehand.

Enable CMEK in the Cloud Console under the bucket's encryption settings after creation.

Why it fails: Although Cloud Storage allows you to change the default encryption key of an existing bucket through the Cloud Console bucket settings, the question explicitly asks about the step when creating a new bucket. In the Console's bucket creation flow, you must choose the customer-managed key during the 'Choose how to protect object data' step; there is no post-creation toggle that retroactively sets the key for a new bucket. Therefore, enabling CMEK after creation is not the action taken at bucket creation time and does not satisfy the requirement.

Cloud Router with BGP session

Why it fails: Cloud Router is needed for Cloud NAT, but the question asks for components, and Cloud NAT includes a Cloud Router. However, Cloud Router alone does not provide internet access. Typically, you create a Cloud Router and then a Cloud NAT on it.

VPC peering with the internet

Why it fails: VPC peering connects two private VPC networks using internal IPs and RFC1918 routes, so it cannot be used to reach the internet. Google Cloud does not offer a peering connection to 'the internet' as a construct; external connectivity is achieved only through external IPs, Cloud NAT, or VPN/interconnect routes. Including VPC peering in this architecture is incorrect because it addresses a different east-west connectivity need and would never enable private instances to access public resources.

roles/iam.serviceAccountAdmin

Why it fails: roles/iam.serviceAccountAdmin grants administrative permissions to create, update, delete, and manage IAM policies on service accounts, but it does not include iam.serviceAccounts.actAs or iam.serviceAccounts.implicitDelegation. This means the holder can manage the service account's lifecycle and permissions yet cannot assume its identity or use it to access other cloud resources. Therefore, while a powerful role for governance, it is the wrong choice when the goal is to grant the ability to act on behalf of the service account.

roles/serviceusage.serviceUsageConsumer

Why it fails: roles/serviceusage.serviceUsageConsumer is intended for inspecting and using enabled Google Cloud services, such as listing services, viewing quotas, and enabling/disabling services in some cases. It has no permissions on service accounts themselves, nor does it include any token generation or identity delegation capabilities. This role cannot be used to impersonate a service account or obtain credentials; it only governs interactions with the Service Usage API.

roles/iam.serviceAccountUser

Why it fails: roles/iam.serviceAccountUser is the correct role because it includes the permissions iam.serviceAccounts.actAs and iam.serviceAccounts.implicitDelegation. The actAs permission allows a principal to use the service account to access resources and create resources that are owned by or signed with the service account's identity. ImplicitDelegation also permits the principal to impersonate service accounts that are arranged in a delegated chain, making this the minimal standard role for granting a service account the ability to act on behalf of another entity.

Use gcloud compute firewall-rules update to enable logging on firewall rules.

Why it fails: This command only toggles firewall rules logging, which records metadata about connections allowed or denied by VPC firewall rules. It does not affect audit logging for data access, because firewall logging is a separate VPC flow log feature, not a Cloud Audit Log. Enabling it would generate firewall logs, not the Data Access logs you need for access audits.

Use gcloud logging sinks to export data access logs to a BigQuery dataset.

Why it fails: Creating a logging sink merely routes existing Cloud Logging entries to a BigQuery dataset for long-term storage or analysis. It does not turn on Data Access audit logs, because sinks only export what is already being collected. Without an auditConfig in the project's IAM policy that enables DATA_READ and DATA_WRITE, those logs are never generated, so there is nothing to export.

Use gcloud services enable to enable the Cloud Audit Logs API.

Why it fails: The Cloud Audit Logs service is built into Cloud Logging and is always on; there is no separate API to enable for audit logging. gcloud services enable only activates optional Google Cloud service APIs, and enabling them does not modify the auditConfig in IAM policy. Therefore, this command has no effect on whether Data Access logs are recorded.

Use the --encryption-key flag in gcloud compute instances create.

Why it fails: Incorrect. This flag is for compute instances, not for Cloud Storage bucket encryption.

No additional steps; Cloud Storage automatically uses CMEK if a key exists in the project.

Why it fails: Incorrect. Additional steps are required to specify the key; Cloud Storage does not automatically apply CMEK.

Enable CMEK by setting the bucket's IAM policy.

Why it fails: Incorrect. Setting IAM policies controls access but does not enable CMEK on the bucket.

Use gcloud iam service-accounts add-iam-policy-binding to grant the instance access.

Why it fails: This command modifies the IAM policy that governs who can impersonate or manage the service account itself, granting roles on the service account resource. It does not cause a compute instance to assume that service account identity. The service account attached to an instance is a property of the instance resource, configured separately with set-service-account, not an IAM role binding.

Use gcloud compute instances add-iam-policy-binding to assign the service account to the instance.

Why it fails: The add-iam-policy-binding operation on an instance grants IAM principals permissions to perform actions on that instance resource, such as compute.instances.get or compute.instances.delete. It does not select or change the service account that the VM uses to authenticate outbound API calls. Assigning a service account to an instance is an attribute update performed via set-service-account, not a policy binding on the instance itself.

Create a new instance with the service account and migrate the application.

Why it fails: Creating a new instance with the desired service account and migrating the application would eventually work, but it is a far heavier operation than necessary. It forces full VM re-creation, requires copying or reattaching disks, reconfiguring network interfaces, and risks downtime during migration. Since the existing instance can be updated in-place with set-service-account while stopped, the rebuild-and-migrate approach is unnecessary and not the recommended best practice.

constraints/compute.vmExternalIpAccess

Why it fails: The constraints/compute.vmExternalIpAccess policy controls whether VM instances can have external IPv4 addresses, either through allowlisting or blocking public IPs. While it is a common security baseline for limiting network exposure, it has no effect on the IAM service account attached to an instance. A VM could comply with an external-IP restriction while still being created with an arbitrary and unauthorized service account, so this constraint does not satisfy an identity-based requirement. It is wrong for this scenario because it addresses network reachability, not the instance's service account identity.

constraints/iam.allowedPolicyMemberDomains

Why it fails: The constraints/iam.allowedPolicyMemberDomains constraint governs which Google Cloud domains (such as your corporate domain) are allowed to appear as members in IAM policies across your resource hierarchy. It limits who can be granted IAM roles, but it does not restrict which service account is specified in the instance resource itself. Even if all IAM users are from an allowed domain, they could still assign an unauthorized service account to a Compute Engine instance unless a separate constraint such as constraints/compute.setServiceAccount is in place. Therefore, it is incorrect because it constrains policy membership, not the service account selected at VM creation.

constraints/compute.restrictCreateOnFirewall

Why it fails: constraints/compute.restrictCreateOnFirewall is not a recognized Organization Policy constraint in Google Cloud, so it cannot be enforced anywhere. The actual Compute Engine org policy list includes restrictions such as compute.vmExternalIpAccess and compute.setServiceAccount, but this name does not exist; attempting to set it in the policy would fail or be ignored. Firewall behavior is controlled by VPC firewall rules, not by a custom constraint named this way. Thus it is wrong because it is a fictitious policy, not because it addresses the wrong concern.