Configuring access and security practice questions

Editor

Why wrong: Editor includes full read and write permissions on most resources — far more than read-only access.

Owner

Why wrong: Owner includes all Editor permissions plus billing account management and IAM policy changes — excessive for read-only access.

Browser

Why wrong: Browser provides access to browse the project hierarchy and some metadata but does not grant read access to resource data — it's more restricted than Viewer.

Rotate the key files every 90 days and redistribute them securely

Why wrong: Rotating keys reduces the window of exposure but doesn't eliminate the risk — key files on developer laptops remain vulnerable to theft.

Encrypt the JSON key files using Cloud KMS before distributing

Why wrong: Encrypting keys before distribution adds a step but doesn't solve the core problem — the key material still exists on developer machines.

Store the key files in Secret Manager and retrieve them at application startup

Why wrong: Storing keys in Secret Manager reduces distribution risk but the key still exists and must be materialized at runtime — eliminating the key entirely is preferable.

An ingress allow rule for port 443 and a separate egress deny rule for all other ports

Why wrong: Egress rules control outbound traffic from instances — they don't affect inbound traffic from the internet. An egress deny would also break outbound connectivity.

An ingress deny rule for all ports from 0.0.0.0/0, plus an ingress allow for port 443 with lower priority

Why wrong: An explicit ingress deny-all at a higher priority than the allow rule would override and block the allow — this configuration would break HTTPS access.

A Cloud Armor policy allowing only HTTPS requests to port 443

Why wrong: Cloud Armor applies at the load balancer layer for L7 policy enforcement — it doesn't replace VPC firewall rules for controlling which ports are accessible to instances.

Google-managed encryption keys (the default)

Why wrong: With GMEK, Google creates, stores, and manages encryption keys — the customer has no control over the keys and Google can theoretically access the data.

Client-side encryption before uploading to Cloud Storage, without using Cloud KMS

Why wrong: Client-side encryption works technically, but it doesn't use GCP's key management infrastructure — audit logging, key rotation, and IAM-based access control for keys are all missing.

Shielded VM with vTPM enabled on the storage backend

Why wrong: Shielded VM protects VM integrity (boot security) — it doesn't control encryption keys for Cloud Storage objects.

As a plain-text environment variable in the Cloud Run service configuration

Why wrong: Environment variables in Cloud Run configuration are visible in the Cloud Console and not encrypted — this exposes the password to anyone with Console access.

In a Cloud Storage bucket accessible to the service account

Why wrong: Cloud Storage stores objects but isn't designed for secrets — it lacks versioning for secrets, automatic rotation, and dedicated secrets-management IAM controls.

Baked into the container image at build time

Why wrong: Including secrets in container images is a critical anti-pattern — images are often stored in registries that are more widely accessible, permanently exposing the secret.

System event audit logs

Why wrong: System event logs capture GCP internal system actions (like live migration) — they don't record user-initiated data access.

Admin Activity audit logs

Why wrong: Admin Activity logs capture changes to resource configurations (creating/deleting datasets, modifying IAM policies) — not data reads.

VPC flow logs

Why wrong: VPC flow logs capture network traffic metadata (source/destination IPs, ports) — they don't record which user accessed which BigQuery dataset.

IAM deny policies restricting cross-project BigQuery operations

Why wrong: IAM deny policies block specific IAM actions — they don't prevent an authorized user from copying data to an external project if they have the necessary permissions there.

An organization policy preventing resource creation outside specific projects

Why wrong: Organization policies restrict what types of resources can be created — they don't prevent copying data between existing projects.

Cloud Armor rules blocking outbound API requests to BigQuery in other projects

Why wrong: Cloud Armor is a WAF for incoming HTTP traffic to load balancers — it doesn't control GCP API calls between projects.

Mount a service account JSON key file as a Kubernetes Secret and set GOOGLE_APPLICATION_CREDENTIALS

Why wrong: This works but requires managing key files — rotation, secure storage, and risk of key leakage. It's the pattern Workload Identity is designed to replace.

Rely on the GKE node's Compute Engine service account for all Pod authentication

Why wrong: Using the node's service account grants all Pods on the node identical GCP permissions — this violates the principle of least privilege.

Grant the GKE node pool's service account the Storage Admin role to cover all Pod needs

Why wrong: Granting broad roles to the node service account over-provisions permissions for all Pods on those nodes, violating least privilege.

VPC firewall rules with deny rules for known attacker IPs

Why wrong: VPC firewall rules block traffic by IP/port but cannot inspect HTTP payload content for SQL injection — and IP-based blocking is ineffective against distributed DDoS attacks.

Cloud NAT to hide backend IP addresses

Why wrong: Cloud NAT manages outbound connectivity from private VMs — it doesn't protect public-facing endpoints from attacks.

Identity-Aware Proxy (IAP) to require authentication before accessing the API

Why wrong: IAP enforces identity-based access control — it's not designed to defend against DDoS or to inspect request payloads for injection attacks.

IAM deny policies scoped to non-business hours

Why wrong: IAM deny policies block specific permissions regardless of allow policies, but using deny policies to enforce time-based access is overly complex and error-prone compared to Conditions.

VPC Service Controls with a time-based access policy

Why wrong: VPC Service Controls enforce which services are accessible from a perimeter — they don't support time-of-day access restrictions on individual IAM bindings.

Cloud Scheduler removing and re-adding the IAM binding on a schedule

Why wrong: Programmatically toggling IAM bindings via Cloud Scheduler is fragile, introduces latency, and is unnecessary given IAM Conditions.

Cloud SQL Editor

Why wrong: Cloud SQL Editor allows creating, editing, and deleting instances — far more than the read-only access needed.

Cloud SQL Client

Why wrong: Cloud SQL Client grants permission to connect to Cloud SQL databases — it doesn't provide access to view instance configuration details in the Console.

Project Viewer

Why wrong: Project Viewer grants read access to all project resources — it's broader than needed and violates the principle of least privilege.

Shielded VMs with Secure Boot enabled

Why wrong: Shielded VMs protect against boot-level attacks using TPM and Secure Boot — they don't encrypt network traffic between VMs.

VPC firewall rules denying all non-encrypted traffic

Why wrong: VPC firewall rules control whether traffic is allowed or denied based on port/protocol/IP — they can't inspect or enforce encryption of allowed traffic.

Enabling VPC Flow Logs on all subnets

Why wrong: VPC Flow Logs capture traffic metadata for analysis — they don't encrypt traffic.

A VPC firewall rule blocking pulls from unauthorized registries

Why wrong: Firewall rules control network-level traffic — they can't distinguish between authorized and unauthorized container registry pulls.

Cloud Armor rules blocking container pull requests from external sources

Why wrong: Cloud Armor is a WAF for incoming HTTP traffic to load balancers — it doesn't control container image registry operations.

Manually reviewing all Docker images before deployment

Why wrong: Manual review doesn't scale and can't enforce policy programmatically — Binary Authorization provides automated enforcement.

Artifact Registry Administrator

Why wrong: Artifact Registry Administrator includes repository creation and deletion — far more than a CI/CD pipeline needs for pushing images.

Storage Object Creator on the underlying Cloud Storage bucket

Why wrong: Artifact Registry has its own IAM roles separate from Cloud Storage — Storage Object Creator doesn't grant Artifact Registry push permissions.

Artifact Registry Reader

Why wrong: Artifact Registry Reader grants pull (read) access — not write/push access needed by a CI/CD pipeline.

Rotate the service account key to generate a new one, keeping the old key active briefly for transition

Why wrong: The old key remains active during transition and is still compromised — it must be immediately deleted, not kept active.

Change the service account's display name and email to invalidate the leaked key

Why wrong: Service account names and emails are metadata — changing them does not invalidate existing keys.

Remove all IAM roles from the service account to deny all actions until the investigation completes

Why wrong: Removing IAM roles may help but the key still exists and could be re-used if roles are re-added. The key itself must be deleted first.

Delete the bucket and recreate it with correct permissions

Why wrong: Deleting the bucket destroys all backup data — a drastic and unnecessary action for a permissions change.

Enable VPC Service Controls around Cloud Storage to block all external access

Why wrong: VPC Service Controls prevent access from outside a defined perimeter — configuring this is much slower and broader than simply removing the public IAM binding.

Apply a Cloud Armor policy to Cloud Storage to block external IPs

Why wrong: Cloud Armor applies to HTTP load balancers, not Cloud Storage directly — it cannot be applied to a bucket's public access.

A VPC firewall rule blocking external traffic to the data service's Node IPs

Why wrong: VPC firewall rules operate at the VM/node level, not the Pod level — they can't distinguish between Pods on the same node or enforce service-to-service policies within the cluster.

IAP (Identity-Aware Proxy) configured on the data service

Why wrong: IAP enforces identity-based access for external users — it's not designed for Pod-to-Pod traffic policy within a GKE cluster.

Using a private ClusterIP Service for the data service — it's automatically private

Why wrong: ClusterIP Services are cluster-internal but accessible by any Pod in the cluster, not just the web application. NetworkPolicy is needed for Pod-to-Pod isolation.

gcloud projects set-iam-policy [PROJECT] --member=serviceAccount:[SA] --role=roles/owner

Why wrong: `set-iam-policy` replaces the entire IAM policy with a new one — not for removing a single binding. This would erase all other IAM bindings.

gcloud iam remove-binding --project=[PROJECT] --member=[SA] --role=owner

Why wrong: `gcloud iam remove-binding` is not a valid command. Use `gcloud projects remove-iam-policy-binding`.

gcloud projects delete-member [PROJECT] --member=serviceAccount:[SA_EMAIL]

Why wrong: `delete-member` is not a valid gcloud command for IAM management.

Admin Activity logs only

Why wrong: Admin Activity logs capture resource configuration changes only — they don't record data read/write operations needed for full API audit coverage.

VPC Flow Logs + Cloud Monitoring metrics

Why wrong: VPC Flow Logs capture network traffic metadata, not API call content. Monitoring metrics don't capture individual API request details.

System event logs + Data Access logs

Why wrong: System event logs record GCP-generated system actions (like live migration) — they don't capture employee-initiated API calls.

Cloud VPN connecting the VPC to the internet

Why wrong: Cloud VPN connects a GCP VPC to an on-premises network or another VPC — it's not used for providing internet access to private VMs.

A VPC firewall rule allowing egress to 0.0.0.0/0 on all ports

Why wrong: A firewall egress rule allows outbound traffic, but VMs with only private IPs still can't reach the internet without a NAT gateway — routing is the issue, not firewall rules alone.

An internal load balancer with internet routing enabled

Why wrong: Internal load balancers route traffic within a VPC — they don't provide NAT or internet access for private VMs.