GCP Security Engineer common mistakes
GCP Security Engineer · Understand the traps and how to avoid them.
When asked to grant a service account access to a single bucket, the candidate assigns a primitive role such as roles/editor or roles/storage.admin at the project level instead of binding roles/storage.objectViewer on the bucket's IAM policy.
Primitive roles are the first thing candidates remember from introductory material, and project-level binding feels simpler than reasoning about resource-level IAM. The candidate translates 'needs access to the bucket' into 'needs storage permissions' and stops there.
What to do instead
Default to the least-privilege predefined role scoped to the narrowest resource that supports IAM. For Cloud Storage that means an IAM condition or resource-level binding on the bucket (and, where object-level granularity is required, uniform bucket-level access with object-level conditions). Explicitly state in your answer that primitive roles violate least privilege and are not allowed by organizational policy in most designs.
The candidate explains that a user's effective permissions are the union of all their role bindings, ignoring deny policies, IAM conditions, VPC Service Controls, and inherited org/folder bindings when asked to trace why access is or is not granted.
Most study material covers allow policies only. Deny policies, conditions, and perimeter enforcement are newer and are evaluated in a specific order that candidates rarely rehearse.
What to do instead
Memorize the evaluation order: deny policies are evaluated before allow policies; an explicit deny always wins; conditions must evaluate true; then VPC Service Controls blocks API calls from outside the perimeter even when IAM allows them. When debugging an access question, walk the chain from organization policy, to deny policy, to allow policy and inheritance, to conditions, to service perimeter, to the resource's own policy.
For a workload running on GKE or Compute Engine that needs to call a Google Cloud API, the candidate downloads a service account JSON key and mounts it into the workload rather than using Workload Identity Federation or attached service accounts.
Key files are the most familiar pattern from on-premises and other clouds, and the question may not explicitly forbid them, so the candidate reaches for the pattern they know.
What to do instead
For GKE use Workload Identity Federation for GKE so the Kubernetes service account maps to a Google service account with no key. For Compute Engine, attach the service account to the instance and rely on the metadata server. Reserve keys for cases with no alternative, and when a question asks how to eliminate key sprawl, answer with workload identity federation, not key rotation.
When asked to protect a public-facing application, the candidate lists Cloud Armor and an external load balancer but omits that the backend service must be referenced by the security policy, and does not mention that a global external Application Load Balancer is required for global-scope policies.
Candidates learn Cloud Armor as a product name and a list of rule types but skip the attachment model, so the design looks complete while traffic never actually passes through the policy.
What to do instead
Always describe the full path: global external Application Load Balancer, backend service, then a Cloud Armor security policy attached to that backend service (or to the edge). Mention that policies are scoped global or regional and must match the load balancer type. Add preconfigured WAF rules for OWASP-style attacks and rate limiting for abuse, and note that Cloud Armor does not protect traffic that bypasses the load balancer.
The candidate proposes a Shared VPC but puts the firewall rules and subnets in the service project, or forgets that the host project owns the network and that firewall rules apply to the network as a whole.
Shared VPC terminology (host versus service project) is easy to state but hard to apply, and candidates conflate project boundaries with network boundaries.
What to do instead
State clearly that the host project owns subnets, firewall rules, Cloud NAT, and Cloud Router, while service projects attach their resources to shared subnets. Firewall rules are defined on the VPC network and apply to all instances in that network regardless of project. Use IAM on the host project to delegate subnet-level permissions to service project admins.
The candidate recommends Cloud VPN alone to connect an on-premises network to a VPC and calls the link private, without noting that traffic still traverses the public internet and must be encrypted with HA VPN plus strong IPsec parameters, or that Dedicated Interconnect or Partner Interconnect is needed for private dedicated paths.
The word 'VPN' implies privacy, so candidates skip the transport discussion and the HA requirement, and they miss questions that hinge on SLA and redundancy.
What to do instead
Distinguish HA VPN (99.99% SLA, two interfaces, two tunnels, dynamic routing with Cloud Router) from Classic VPN, and distinguish both from Interconnect. Say explicitly that VPN traffic crosses the public internet inside IPsec tunnels, while Interconnect avoids the public internet. For any production design, specify HA VPN with two tunnels and BGP, and mention MACsec for Interconnect encryption.
For a requirement to protect sensitive data at rest, the candidate answers 'enable encryption' or 'use CMEK' without distinguishing Google-managed default encryption, CMEK, CMEK with Cloud HSM or Cloud EKM, and client-side encryption, and without noting that CMEK does not by itself restrict who can decrypt.
Encryption options are presented as a ladder of increasing security, so candidates assume CMEK automatically satisfies a compliance control about key custody or separation of duties.
What to do instead
Map each requirement to a specific option: default encryption covers baseline at-rest protection; CMEK gives you control of key rotation and disable/destroy; Cloud EKM keeps the key outside Google; Cloud HSM gives FIPS 140-2 Level 3 hardware keys; client-side encryption removes plaintext from Google entirely. Note that key access is governed by Cloud KMS IAM, so a CMEK design must also restrict decrypt permission on the key ring to prevent the data owner from reading the data.
When asked to find and redact sensitive data such as credit card numbers or personal identifiers in Cloud Storage or BigQuery, the candidate proposes writing a custom regex job instead of using Sensitive Data Protection (Cloud DLP) infoTypes, inspection templates, and de-identification transforms.
Candidates know general-purpose tooling (Dataflow, Cloud Functions) better than the dedicated data-protection service, and they underestimate how much detection coverage built-in infoTypes provide.
What to do instead
Name Sensitive Data Protection explicitly: discovery scans for Cloud Storage, BigQuery, and Dataproc; inspection with infoTypes and likelihood; de-identification with masking, tokenization, format-preserving encryption, and date shifting; templates for reuse; and integration with Dataflow or the API for inline redaction. Mention that discovery findings flow to Security Command Center for centralized review.
The candidate treats Cloud Audit Logs as a single stream and cannot say which log type captures data reads and writes, or how long each is retained by default and where to route them for long-term retention.
Admin Activity, Data Access, System Event, and Policy Denied logs differ in default enablement, cost, and retention, and candidates memorize the names without the operational differences.
What to do instead
Memorize the four types: Admin Activity and System Event are always on with 400-day retention; Data Access is off by default (except for BigQuery) and must be enabled per service; Policy Denied logs record VPC Service Controls denials. For long-term retention and tamper resistance, create an aggregated sink to a locked Cloud Storage bucket or BigQuery dataset, and mention that log exclusions reduce cost without losing required audit coverage.
When asked to detect and respond to threats, the candidate lists Security Command Center findings but does not describe how to route them (Pub/Sub notifications, SIEM export), how to triage by severity, or how to distinguish Premium-tier detectors such as Event Threat Detection and Container Threat Detection from the Standard tier.
Security Command Center is taught as a dashboard, so candidates describe what it displays rather than how findings become an operational workflow.
What to do instead
Describe the pipeline: findings from Event Threat Detection, Security Health Analytics, and Web Security Scanner land in Security Command Center; continuous export to Pub/Sub feeds a SIEM or automation; severity and mute rules drive triage; remediation steps reference the specific finding. State which detectors require the Premium tier and note that organization-level activation is needed for full coverage.
The candidate answers a compliance question by asserting that a certification such as ISO/IEC 27001 or SOC 2 'covers' the customer's workload, instead of explaining the shared responsibility model and pointing to the specific Google Cloud compliance reports and the customer's own obligations.
Compliance certifications are described as badges, and candidates do not separate the provider's audited controls from the controls the customer must implement, such as IAM hygiene, logging, and data classification.
What to do instead
Frame every compliance answer with shared responsibility: Google's certifications cover the infrastructure and Google-managed services; the customer must configure and evidence its own controls. Point to Compliance Reports Manager for the actual attestations, note that data residency is controlled through location constraints and organization policy, and name the relevant controls (for example, Assured Workloads for regulated data) rather than claiming blanket coverage.
For a requirement to keep data in a specific country or to restrict which services may be used, the candidate proposes IAM roles or firewall rules instead of organization policy constraints such as resource location restrictions and service usage restrictions.
Candidates reach for the access-control tool they know best and miss that some requirements are guardrails on resource configuration, not on identities.
What to do instead
Match the requirement to the guardrail type: organization policy constraints (for example, restricting resource locations, disabling service account key creation, or limiting allowed services) enforce configuration rules across the hierarchy; VPC Service Controls enforce data-exfiltration boundaries around APIs; IAM governs identities. State that organization policies are inherited and that a constraint at the organization node overrides project-level settings.