# GCP Security Interview Questions — IAM, VPC-SC, KMS & Cheat-Sheet Source: https://ai.techclick.in/blog_gcp_security_interview Markdown: https://ai.techclick.in/blog_gcp_security_interview.md Publisher: Techclick Infosec Pvt Ltd GCP (Google Cloud) security interview questions and answers (2026) covering IAM and the resource hierarchy, primitive vs predefined vs custom roles, service-account keys vs Workload Identity Federation, VPC firewall rules, VPC Service Controls, Cloud Armor, Cloud KMS (CMEK/CSEK/Google-managed), Secret Manager, Cloud DLP, Security Command Center and Audit Logs — scenario-led with a printable cheat-sheet. GCP Security Interview Questions — IAM, VPC-SC, KMS & Cheat-Sheet student learning map A visual study map for GCP Security Interview Questions — IAM, VPC-SC, KMS & Cheat-Sheet showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP GCP Security Interview Questions — IAM, VPC-SC, KMS... Google Cloud · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① IAM & the resource hierarchy 4. Practice ② Service accounts, Workload... How to use this page First build the mental model, then answer with the flow, evidence, safe fix, and verification. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. 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. Figure 1 — GCP IAM is hierarchy-inherited, not flat GCP organises everything as Org → Folder → Project → Resource. An IAM policy set high up is INHERITED downward and is additive — you cannot revoke an inherited grant lower down. Security Command Center sits above it all, watching every layer. - Org → Folder → Project → Resource (policies flow DOWN, never up) Organization (root) Folder: Production Folder: Sandbox Project: bank-prod IAM policy inheritance + Org Policy guardrails Service accounts (workloads) Predefined / custom roles IAM Conditions (when/where) SCC overlay (CSPM + threats) Key interview point: inherited grants are ADDITIVE — a role at the Org level lands on every project beneath it. To take access AWAY you use Org Policy constraints or IAM Conditions, not a 'deny lower down' that does not exist by default. ### The GCP security vocabulary every interview opens with Know these four cold before anything else. Tap each card. 🏛 Resource hierarchy tap to flip Org → Folder → Project → Resource — IAM policies are set at any level and INHERITED downward; grants are additive, not subtractive. 🤖 Service account tap to flip A non-human identity a workload runs as. Downloaded SA keys are the danger — prefer Workload Identity Federation. 🧱 VPC Service Controls tap to flip A data-exfiltration perimeter around APIs (Storage, BigQuery). Blocks data leaving even with valid IAM — GCP's signature control. 🛰 Security Command Center tap to flip 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 . Quick check · Q1 of 10 · Apply 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? a) roles/owner at the Organization b) roles/storage.objectViewer at the bucket (or project) c) roles/editor at the project d) A downloaded service-account key Correct: b. Least privilege: grant the predefined 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. 👉 So far: GCP IAM = hierarchy-inherited (Org → Folder → Project → Resource), additive grants; primitive = too broad, predefined = default, custom = surgical least privilege. The 'GCP IAM = AWS IAM' trap 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. Reveal answer Answer: Two layers. Set the Org Policy 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. “Just remove their role” isn't always enough 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. ① External token issued The workload gets a token from its own IdP (GitHub OIDC / AWS / Okta) — no GCP key involved. ▼ ② Token presented to STS The workload sends that token to GCP's Security Token Service via the Workload Identity Pool + provider. ▼ ③ GCP validates + maps GCP checks the issuer + attribute conditions (e.g. repo == flipkart/payments) and maps it to a principal. ▼ ④ Short-lived token returned GCP returns a short-lived access token (≈1 hour) for the impersonated service account — nothing to leak. Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Figure 2 — A request reaching a GCP app — the layered controls How an inbound request is filtered as it travels from the internet to a protected resource, in order, through GCP's network-security stack. ① Internet client (e.g. 49.36.x.x) a user or an attacker hits the public load balancer ▼ ② Cloud Armor (WAF + DDoS) edge: block OWASP attacks, rate-limit, geo / IP allow-deny ▼ ③ Global / Regional Load Balancer terminates TLS, forwards to backend ▼ ④ Hierarchical + VPC firewall rules stateful allow/deny by priority; implied deny-ingress ▼ ⑤ VPC Service Controls perimeter API-level: can this identity even call Storage/BigQuery? ▼ ⑥ IAM check on the resource does the caller hold a role with this permission? ▼ ⑦ Resource served (GCS / BigQuery / VM) only if every layer above said yes Two facts interviewers love: Cloud Armor protects the FRONT DOOR (inbound web attacks), while VPC Service Controls protects the BACK DOOR (an insider or stolen token exfiltrating data via the API). They solve different problems — name both. COLOUR KEY denied / exfil-blocked inspected / IAM-checked decision / perimeter point allowed 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. Quick check · Q2 of 10 · Analyze 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? a) Keys are slower than tokens b) JSON is hard to parse c) The key is long-lived and leakable — if the repo or a log leaks, the attacker authenticates as that SA forever d) The pipeline will run too fast Correct: c. A downloaded SA key never expires and grants the SA's full access to anyone who obtains it — the #1 GCP breach vector. The fix is Workload Identity Federation: GitHub's OIDC token is exchanged for a short-lived GCP token, so there is no key to leak. Pause & Predict Does disabling SA key creation org-wide break existing workloads? Type your guess. Reveal answer Answer: No — existing workloads keep using their current credentials; the 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. Likely cause Long-lived SA keys with broad roles — any leaked key is a permanent backdoor with the SA's full permissions. Diagnosis 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 findings Fix Migrate workloads to Workload Identity Federation (external) or attached service accounts (on-GCP); then set the Org Policy iam.disableServiceAccountKeyCreation and delete the old keys. Verify 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. The serviceAccountTokenCreator vs serviceAccountUser mix-up A 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. Reveal answer Answer: Because the role inherits down the hierarchy and applies to every service account in the project — so the holder can impersonate the highest-privileged SA there and escalate to its access. Always bind it on the single target SA (resource-level), not the project. This narrow binding is exactly how impersonation gives you keyless, least-privilege, fully-audited “act as” without a leakable JSON key. 👉 So far: Service accounts run workloads; downloaded SA keys are the top breach vector → use Workload Identity Federation (external) or SA impersonation / attached SAs (on-GCP) for short-lived, fully-audited tokens; bind 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. console.cloud.google.com · IAM & Admin ▸ IAM ▸ Grant access New principals * sneha@flipkart.com Resource level Project: bank-prod 1 Assign role * roles/storage.objectViewer 2 Second role roles/logging.viewer IAM Condition resource.name.startsWith('reports-') 3 Condition expiry request.time 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 ). Binary Authorization — only trusted images run 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). 'The firewall will stop the leak' over-confidence 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. Figure 4 — Access denied — why? The GCP triage ladder A ladder to isolate why a principal cannot reach a resource — work top-down: IAM first, then Org Policy, then VPC-SC, then the firewall. - Access denied — why? The GCP triage ladder Policy Troubleshooter does the principal hold the role? FAIL No matching role grant least-priv predefined role at the right level PASS ↓ check Org Policy constraints is a constraint blocking it? FAIL Constraint denies it an Org Policy (e.g. disable SA key creation) wins over IAM PASS ↓ check VPC-SC perimeter is the API call inside the perimeter? FAIL Perimeter blocks the API add an ingress/egress rule or the project to the perimeter PASS ↓ check firewall rules is the packet allowed? FAIL Implied/explicit deny add a higher-priority allow rule for the IP:port All pass → the layer is healthy; look one level up. The fastest first check is the IAM Policy Troubleshooter — it tells you exactly which policy granted or failed to grant the permission, across the whole inherited hierarchy. 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. Reveal answer Answer: Because Admin Activity logs only record configuration changes (who changed a policy), not data reads. Without Data Access logs you literally cannot prove who READ a sensitive bucket or BigQuery table — and Event Threat Detection has far less to work with. They are off by default (volume/cost), so for a regulated workload you turn them on deliberately, usually via Org Policy. Arjun at Wipro faces this SCC suddenly raises a 'Persistence: IAM Anomalous Grant' finding — a service account was granted roles/owner at 2 AM. Likely cause Event Threat Detection spotted an unusual IAM grant in the Admin Activity log — possible compromised credential escalating privilege. Diagnosis 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 Logs Fix Revoke 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. Verify Re-check SCC — finding resolved; the anomalous grant is gone and Audit Logs show the remediation. Triage an access-denied / governance issue from the CLI 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) Expected output ROLE MEMBERS roles/storage.objectViewer user:sneha@flipkart.com CONSTRAINT: iam.disableServiceAccountKeyCreation enforced: true PERIMETER: bank_data_perimeter restricted: storage.googleapis.com Quick check · Q4 of 10 · Apply 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? a) The VM needs more RAM b) DNS is down c) The bucket is empty d) A VPC Service Controls perimeter is blocking the API call Correct: d. When IAM clearly grants the permission but the API call still fails, the usual culprit is a VPC-SC perimeter denying the request (or an Org Policy constraint). Use the Policy Troubleshooter for IAM, then check the perimeter ingress/egress rules — the access-denied ladder. Kavya at HCL faces this A data-science team is blocked from querying a BigQuery dataset; IAM shows they hold roles/bigquery.dataViewer. Likely cause 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. Diagnosis 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 perimeters Fix Add 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. Verify Re-run the query → succeeds; the SCC and Audit Logs show the access permitted within the perimeter. Figure 5 — GCP security interview cheat-sheet One card: the hierarchy, role types, the SA-key danger, VPC-SC, the encryption trio and SCC. 🖨 Print this before your GCP security interview 🏛 Hierarchy Org → Folder → Project → Resource. IAM policies INHERIT downward & are additive. Curb with Org Policy / 🎭 Roles Primitive (Owner/Editor/Viewer = too broad) · Predefined (per-service, use these) · Custom (your exact 🔑 SA keys = danger Downloaded JSON keys are a top breach vector. Use Workload Identity Federation → short-lived tokens, no key to 🧱 Network Firewall = packets · VPC Service Controls = API data-exfil perimeter · Cloud Armor = WAF/DDoS at the edge. 🔐 Encryption Google-managed (default) · CMEK (your KMS key, you control rotation/disable) · CSEK (you supply raw key 🛰 Detection SCC = CSPM + Event Threat Detection on Audit Logs. Enable Data Access logs. Org Policy > IAM for Train hands-on. Pass with proof. — Techclick Tap the Preview button at the top to save this one-page card before your interview. Prove it with the ladder, don't guess 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. 👉 So far: SCC = CSPM + Event Threat Detection on Audit Logs; enable Data Access logs (off by default); triage access with the ladder — IAM (Policy Troubleshooter) → Org Policy → VPC-SC perimeter → firewall. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Primitive vs predefined roles? What is Workload Identity Federation? VPC firewall vs VPC Service Controls? CMEK vs CSEK vs Google-managed? What is Security Command Center? How do I stop data exfiltration? What is IAP / BeyondCorp? IAM deny policies vs allow? SA impersonation vs key files? 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. Q5 · Remember What is Workload Identity Federation in one line? a) A faster VPN for GCP b) A way for external/multi-cloud workloads to authenticate to GCP with their own IdP token and get a short-lived GCP token — no service-account key c) A managed firewall service d) A backup product for Cloud Storage Correct: b. Workload Identity Federation lets an external workload (GitHub Actions, AWS, on-prem) exchange its own OIDC/SAML token for a short-lived GCP access token, eliminating the long-lived downloaded service-account key — the top GCP breach vector. Q6 · Apply A vendor's on-prem app must read one BigQuery dataset for 90 days only. Most secure design? a) Use Workload Identity Federation + roles/bigquery.dataViewer scoped to that dataset, with an IAM Condition expiring in 90 days b) Email them a downloaded service-account JSON key c) Grant roles/owner at the project d) Make them a project Editor Correct: a. Least privilege + no key + time-bound: federate the vendor's identity (no downloadable key), grant only the predefined dataViewer role on that one dataset, and attach an IAM Condition with an expiry. Owner/Editor and a JSON key all over-grant and leak. Q7 · Analyze An insider with valid IAM runs gcloud storage cp from a sensitive bucket to a personal bucket and it SUCCEEDS. Which control was missing? a) A stronger firewall rule b) Cloud Armor WAF policy c) Rotating the encryption key d) A VPC Service Controls perimeter around Cloud Storage Correct: d. The firewall filters packets and Cloud Armor guards inbound web traffic — neither stops an authorised API call. Only a VPC Service Controls perimeter blocks the Storage API from copying data to a bucket outside the perimeter, even when IAM permits the read. Q8 · Analyze A team holds the correct predefined role but still gets PERMISSION_DENIED on a Storage API call. The MOST likely non-IAM cause? a) Their browser cache b) The bucket region is wrong c) An Org Policy constraint or a VPC Service Controls perimeter denying the call d) Their password expired Correct: c. When IAM clearly grants the permission yet the API still fails, the block is one layer up: an Org Policy constraint or a VPC-SC perimeter. Walk the ladder — Policy Troubleshooter for IAM, then org-policies list, then perimeters list. Q9 · Evaluate CMEK vs CSEK vs Google-managed keys — the crispest correct statement is… a) Google-managed = default, Google controls it; CMEK = your key in Cloud KMS, you control rotation/disable; CSEK = you supply raw key bytes per request, Google never stores them b) Google-managed = you own the key in KMS; CMEK = Google owns it; CSEK = no encryption c) They are identical d) CSEK works for every GCP service Correct: a. Default is Google-managed (you cannot disable it). CMEK puts a key YOU own in Cloud KMS as the KEK — your rotation, your kill-switch, audit-logged. CSEK means you pass raw AES-256 bytes per request (Storage/Compute disks only); Google uses then forgets them. Q10 · Evaluate Which combination best PREVENTS data exfiltration on GCP? Best interview answer? a) A bigger firewall and antivirus on every VM b) VPC Service Controls perimeter around the APIs + least-privilege IAM + CMEK with a disable kill-switch + Data Access audit logs feeding SCC c) Only rotating service-account keys monthly d) Turning off the internet gateway Correct: b. Exfiltration is an identity + API problem, not just a network one. The layered answer: VPC-SC to block the API leaving the perimeter, least-privilege IAM so a stolen token can do little, CMEK you can disable to render data unreadable, and Data Access logs into SCC/Event Threat Detection to detect the attempt. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: why is Workload Identity Federation safer than a service-account key? Then compare to the expert version. Compare with expert answer Expert version: Because there is no long-lived secret to leak. A downloaded service-account key is a static JSON private key that never expires — if it lands in a Git repo, a CI log or a laptop, the attacker authenticates as that service account forever. Workload Identity Federation instead lets the external workload present its OWN identity token (GitHub OIDC, AWS, Okta), which GCP validates against attribute conditions and exchanges for a short-lived (~1 hour) access token. Nothing durable is stored on the workload, the trust is scoped to specific attributes (e.g. one repo), and credentials rotate automatically. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Interview Prep at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 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. Term One-line plain-English meaning. ×N --> #### 📚 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. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt