Question 1

What is Cloud IAM and what are its three core elements?

Accepted Answer

Cloud IAM controls who can do what on which resource. The three elements are the principal (a user, group, service account, or domain), the role (a collection of permissions), and the resource the binding applies to. A policy is the set of bindings attached to a resource, and it is evaluated together with everything inherited from above in the hierarchy. The phrase interviewers want is "you never grant permissions directly — you grant roles, which are bundles of permissions". Permissions follow the service.resource.verb format such as compute.instances.delete, and knowing that format lets you reason about custom roles.

Question 2

What are the three types of IAM roles?

Accepted Answer

Basic roles — Owner, Editor, Viewer — are the legacy, extremely broad roles that predate fine-grained IAM. Predefined roles are service-specific bundles curated and maintained by Google, such as roles/storage.objectViewer. Custom roles are ones you define yourself from an explicit list of permissions when no predefined role fits. The recommendation to state clearly is: never use basic roles in production. Editor alone grants tens of thousands of permissions across every service, including the ability to modify most resources, and it is the single most common finding in a GCP security review.

Question 3

How does IAM inheritance work in the resource hierarchy?

Accepted Answer

Policies set at the organisation, folder or project level are inherited by all descendants, and the effective policy on a resource is the union of its own bindings and every inherited binding. Inheritance is additive only — a policy lower in the hierarchy cannot remove a permission granted higher up. That "additive only, cannot subtract" rule is the most-asked IAM fact in GCP interviews. The consequence is that a wide grant at the organisation level cannot be walked back project by project, which is why organisation-level bindings should be extremely rare. IAM deny policies, added later, are the only mechanism that can actually subtract.

Question 4

What is an IAM deny policy?

Accepted Answer

A deny policy explicitly blocks a set of principals from using specified permissions on a resource and its descendants, and it is evaluated *before* allow policies. It is the only way to override an inherited grant, so it is used for hard guardrails — for example denying everyone except a break-glass group the ability to delete production log buckets. The evaluation order is the whole point: deny wins over allow regardless of where the allow came from. Before deny policies existed, the only way to prevent an inherited permission was to not grant it in the first place, which was a real gap in the model.

Question 5

What is a service account and what are the ways a workload can use one?

Accepted Answer

A service account is a non-human identity for an application or workload. A workload can use it by attachment — a VM, Cloud Run service or Cloud Function runs *as* it and gets tokens from the metadata server; by impersonation — a principal with the Service Account Token Creator role mints short-lived credentials for it; by Workload Identity on GKE; by Workload Identity Federation for external workloads; or, worst, by an exported JSON key file. The ranking is the answer: attachment and federation are best because credentials are short-lived and never stored; exported keys are worst because they are long-lived, copyable and frequently leaked to source control. Being able to give that ordering with reasons is exactly what a security-aware interviewer is testing.

Question 6

Why should you avoid downloading service-account keys, and what do you do instead?

Accepted Answer

A downloaded JSON key is a long-lived, non-expiring credential that can be copied anywhere, committed to a repository, or exfiltrated, and rotating it requires touching every consumer. Instead, attach a service account to the GCP resource, use Workload Identity on GKE, use Workload Identity Federation for workloads outside GCP, or use impersonation for human access. The organisational control to name is the constraint constraints/iam.disableServiceAccountKeyCreation, which blocks key creation across the estate. Saying "we would prevent it with an org policy rather than trusting people to follow a guideline" is a materially stronger answer than "we would avoid it".

Question 7

What is Workload Identity Federation?

Accepted Answer

Workload Identity Federation lets workloads running outside Google Cloud — on AWS, Azure, GitHub Actions, or any OIDC-compliant system — exchange their native identity token for a short-lived Google credential, with no service-account key involved. You configure a workload identity pool and a provider that trusts the external issuer, and map external attributes to Google principals. The most common concrete use is GitHub Actions deploying to GCP: instead of storing a service-account JSON key as a repository secret, the workflow presents its GitHub OIDC token and receives a short-lived GCP token. Naming that example immediately demonstrates you have implemented it.

Question 8

What is service account impersonation and when do you use it?

Accepted Answer

Impersonation lets a principal who holds roles/iam.serviceAccountTokenCreator on a service account generate short-lived access tokens, ID tokens or signed blobs as that service account. It is used so humans and CI systems can act with a workload's permissions without ever holding a permanent credential for it. The audit benefit is what makes it valuable: the logs record that a specific human impersonated the service account, so you keep attribution. With a shared exported key you only see the service account, and you cannot tell who used it. That accountability point is the strongest part of the answer.

Question 9

What is the difference between roles/iam.serviceAccountUser and roles/iam.serviceAccountTokenCreator?

Accepted Answer

Service Account User allows a principal to attach a service account to a resource — to deploy a VM or Cloud Run service that *runs as* that service account. Service Account Token Creator allows a principal to mint credentials and act as the service account directly, right now, without deploying anything. Both are privilege-escalation paths and interviewers probe this deliberately: if a user has Service Account User on a highly privileged service account, they can deploy code that runs with those privileges, effectively inheriting them. Auditing who holds these two roles is a standard part of a GCP security review.

Question 10

What are IAM conditions?

Accepted Answer

IAM conditions attach a CEL expression to a role binding so it only applies when the condition is true — based on request time (for temporary access), the resource name or type, or request attributes such as the access level in Access Context Manager. For example, granting Compute Admin only on instances whose name starts with dev-. The most valuable practical use is time-bound access: grant an elevated role that automatically expires at a timestamp, which removes the "we forgot to revoke it" failure mode entirely. Not every service supports conditions on every attribute, which is the limitation worth acknowledging.

Question 11

How do you implement least privilege in an existing GCP environment?

Accepted Answer

Start by replacing basic roles with predefined roles. Use IAM Recommender, which analyses 90 days of actual permission usage, to identify over-granted bindings and suggest tighter roles. Grant at the narrowest resource scope that works — a bucket rather than a project. Grant to groups rather than individuals. Use conditions for time-bound elevation, and add deny policies for hard guardrails. The caution to include: recommendations come from observed usage, so a quarterly job may not appear in the 90-day window and blindly applying every recommendation can break things. Describing a review-then-apply process rather than automatic enforcement is what makes this a realistic answer.

Question 12

Why should you grant IAM roles to groups rather than to individual users?

Accepted Answer

Because access then follows group membership, which is managed in your identity system alongside joining, moving and leaving. Onboarding and offboarding become a single membership change rather than an audit of every project. It also makes the policy far smaller and easier to review. The failure this prevents is the classic one where a departing employee's individual bindings are scattered across dozens of projects and nobody finds them all. Adding "and we review group membership rather than IAM policies" shows you understand where the control actually lives.

Question 13

What is the Policy Troubleshooter?

Accepted Answer

Policy Troubleshooter tells you whether a specific principal has a specific permission on a specific resource, and explains exactly which binding grants or fails to grant it — including inherited bindings and any conditions that were not satisfied. It answers "why can this user not access this bucket?" definitively. It is the right answer to any troubleshooting question about access, because manually reconstructing the effective policy across organisation, folder and project levels with conditions is genuinely error-prone. Naming it instead of describing manual inspection is a practical signal.

Question 14

What is the difference between authentication and authorisation in GCP?

Accepted Answer

Authentication establishes who the caller is — validating an OAuth token, an ID token or a federated credential. Authorisation decides whether that authenticated identity may perform the requested action, which is what IAM evaluates. A request must pass both, and a valid token with no matching role gives a 403, not a 401. The diagnostic value is real: a 401 means the credential is missing, expired or malformed, while a 403 means the identity is known but lacks the permission. Being able to route a debugging effort correctly from the status code alone is a small but telling competence signal.

Question 15

What are custom roles and what are their limitations?

Accepted Answer

Custom roles let you define a role from an explicit list of permissions at the organisation or project level, for cases where predefined roles are too broad or too narrow. Limitations: you must maintain them yourself as Google adds permissions, some permissions cannot be included in custom roles, and permissions in alpha or beta stages can change or be removed. The maintenance burden is the honest downside and interviewers respect hearing it. The recommendation is to prefer a predefined role at a narrow resource scope over a custom role at a broad one, because Google maintains the predefined role for you as services evolve.

Question 16

How long does an IAM change take to become effective?

Accepted Answer

IAM changes are eventually consistent and typically take effect within seconds, but Google documents that propagation can take up to seven minutes to be fully consistent everywhere. Automation that grants a role and immediately uses it should retry with backoff rather than assume immediate availability. This is the cause of intermittently failing Terraform runs and deployment scripts, where a resource is created, a binding is added, and the very next API call fails with 403. The fix is a retry loop, not a fixed sleep — that distinction is what makes the answer practical.

Question 17

What is the default service account and why is it a risk?

Accepted Answer

Compute Engine and App Engine create a default service account in each project, and unless you change it, VMs run as it. Historically it was granted the project Editor role, which means any workload on those VMs can modify almost anything in the project. It is a broad, shared identity with no separation between workloads. The fix to describe: create a dedicated, minimally-privileged service account per workload, and enforce the organisation policy constraint constraints/iam.automaticIamGrantsForDefaultServiceAccounts to stop the automatic Editor grant on new projects. This is one of the highest-value hardening steps in a GCP estate.

Question 18

What is Access Context Manager and what is an access level?

Accepted Answer

Access Context Manager defines access levels — named conditions based on attributes such as source IP range, device policy, geography or identity — that can be used by VPC Service Controls and by IAM conditions. An access level might be "corporate IP ranges and a company-managed, encrypted device". It is the building block for context-aware access, which is Google's BeyondCorp zero-trust model applied to cloud resources: instead of "on the VPN, therefore trusted", access depends on identity plus device and network context evaluated per request.

Question 19

What is Identity-Aware Proxy?

Accepted Answer

IAP enforces identity and context based access at the application layer, in front of App Engine, Cloud Run, GKE or Compute Engine backends behind a load balancer, and also for TCP forwarding to SSH and RDP. Users authenticate with Google identities and are authorised by IAM, so the application needs no VPN and no public exposure of the SSH port. The BeyondCorp framing is what to name: access decisions are per request based on identity and context, not on network location. The practical detail is that the application should verify the signed IAP JWT header rather than trusting a plain header, otherwise it can be bypassed if it is ever reachable directly.

Question 20

How do you audit who has access to what across a GCP organisation?

Accepted Answer

Use Cloud Asset Inventory to export all IAM policies to BigQuery and query them — that is the only practical way to answer questions like "which principals have storage.objects.get anywhere?" across hundreds of projects. Policy Analyzer answers targeted questions directly, and Security Command Center surfaces over-privileged and public grants as findings. The reason a manual approach fails is inheritance plus scale: effective access is the union of bindings at four levels across every project, and no console view shows that. Answering with "export to BigQuery and query it" is the answer of someone who has actually had to produce an access report for an auditor.

Question 21

What are Cloud Audit Logs and how do they relate to IAM?

Accepted Answer

Admin Activity audit logs record every IAM policy change and every configuration change, are always enabled and cannot be disabled, and are retained for 400 days by default. Data Access logs record reads and writes of user data and are disabled by default outside BigQuery because of their volume. Together they answer who granted access and who used it. The compliance pattern to name: sink audit logs to a separate project with restricted IAM and a locked retention policy, so that a compromised project owner cannot delete the evidence of their own actions. Log sinks with an aggregated organisation-level export are the mechanism.

Question 22

What is the difference between a Google account, a service account, a group and a domain as IAM principals?

Accepted Answer

A Google account represents a person and authenticates interactively. A service account represents a workload and authenticates with tokens. A Google group is a named collection of accounts used to grant roles collectively — groups can contain other groups. A domain or Cloud Identity domain grants to everyone in an organisation, and allUsers/allAuthenticatedUsers are the public special cases. The nested-groups point is worth adding because effective access through group nesting is a frequent audit surprise. And clarifying that allAuthenticatedUsers means any Google account anywhere, not "our employees", is a mistake worth pre-empting.

Question 23

How do you grant a user access to only one BigQuery dataset?

Accepted Answer

Grant the role at the dataset resource rather than the project — roles/bigquery.dataViewer on the dataset itself — and grant roles/bigquery.jobUser at the project level so they can run queries and be billed. Without the job-level role they can see the dataset but cannot query it. The two-part nature of this is exactly what the question tests: BigQuery separates *data* access from *compute* (job) access, so the naive single grant does not work. Being able to explain that split is a reliable marker of real BigQuery use.

Question 24

What is the principle behind separation of duties in GCP, and how would you implement it?

Accepted Answer

No single person should be able to both perform a sensitive action and conceal it. Implement it by splitting roles — the team that deploys does not administer logging; the security team owns the log sink project and the KMS keys; production changes go through CI with a service account rather than through human console access; and break-glass accounts are separate, monitored and time-bound with IAM conditions. The concrete GCP mechanisms are the answer: a separate logging project with its own IAM, CMEK keys owned by a security project, deny policies preventing log deletion, and approval gates in Cloud Deploy. Abstract statements about "separating duties" without naming mechanisms do not score.

Question 25

What happens to a resource when the service account it runs as is deleted?

Accepted Answer

The workload immediately loses its ability to authenticate and all API calls fail. Service accounts can be undeleted within 30 days, but if a service account with the same name is recreated instead, it gets a new unique ID, so existing IAM bindings that reference the old ID become invalid and show as deleted principals in the policy. The unique-ID detail is what makes this a good question: recreating "the same" service account does not restore access, which surprises people who assume the email address is the identity. Cleaning up those orphaned deleted: bindings is a standard hygiene task.

Question 26

What are IAM permissions for creating projects and who should have them?

Accepted Answer

Project creation requires resourcemanager.projects.create, granted through roles/resourcemanager.projectCreator at the organisation or folder level, plus billing.resourceAssociations.create on the billing account to link billing. It should be restricted to a platform team or, better, to an automation service account so projects are created through a vetted pipeline with standard labels, policies and networking. The governance argument is the substance: ungoverned project creation produces an estate with no consistent labelling, no log sinks and no network attachment, which is unmanageable later. A project-vending pipeline is the pattern to name.

Question 27

How would you give a contractor read-only access to production for two weeks?

Accepted Answer

Add them to a dedicated group, grant that group a narrow predefined viewer role at the smallest scope that covers what they need, and attach an IAM condition with an expiry timestamp so the binding stops working automatically. Enable Data Access audit logs for the resources involved, and confirm the group membership is removed at the end as a second control. The interviewer is testing whether you reach for time-bound conditions rather than a calendar reminder. Adding the audit-logging step shows you are thinking about verification, not just access, which is what a regulated environment requires.

Question 28

What is the difference between IAM and Cloud Identity?

Accepted Answer

Cloud Identity manages the identities themselves — user accounts, groups, devices, authentication, SSO and multi-factor policy. IAM controls what those identities may do with GCP resources. Cloud Identity answers "who exists and how do they prove it"; IAM answers "what may they do". The integration point worth naming is federation with an existing identity provider such as Okta, Azure AD or ADFS via SAML, so GCP access follows the corporate directory. Almost every enterprise does this rather than managing accounts separately in Google.

Question 29

What is an organisation policy constraint and give three you would always apply?

Accepted Answer

A constraint is a restriction on resource configuration enforced regardless of IAM. Three high-value ones: constraints/compute.vmExternalIpAccess to prevent public IPs on VMs; constraints/iam.disableServiceAccountKeyCreation to prevent long-lived exported keys; and constraints/storage.publicAccessPrevention to prevent public buckets. Also worth naming is constraints/gcp.resourceLocations to keep data in permitted regions. The reason to lead with these three is that they each close an entire class of incident — internet-exposed VMs, leaked credentials and public data — and none of them can be closed with IAM alone. Naming specific constraint IDs rather than describing them generally is what proves familiarity.

Question 30

How do IAM policies interact with resource-level ACLs, for example on Cloud Storage?

Accepted Answer

Cloud Storage historically supported both IAM at the bucket level and per-object ACLs, and access was granted if *either* allowed it. Uniform bucket-level access disables ACLs entirely so IAM is the single source of truth, which is what makes access auditable. The reason interviewers ask is that dual systems produce unanswerable questions: with ACLs enabled, "who can read this bucket?" requires inspecting every object. Recommending uniform bucket-level access, and explaining the 90-day window before it becomes permanent, is the complete answer.

Question 31

What is a short-lived credential and why does it matter?

Accepted Answer

A short-lived credential is an OAuth access token or ID token with a lifetime typically measured in an hour, minted on demand from an underlying identity. It matters because a leaked short-lived token expires on its own, drastically reducing the window of exposure compared with a static key that remains valid until someone notices and revokes it. The concrete link to make is that every GCP-native credential path — metadata server, Workload Identity, impersonation, federation — produces short-lived credentials, and the only path that does not is an exported key file. Framing the whole IAM security story around credential lifetime is a coherent, senior-sounding position.

Question 32

A developer says they cannot access a Cloud Storage bucket despite having Storage Admin. What could be wrong?

Accepted Answer

Several possibilities: the role was granted on a different project or resource; a VPC Service Controls perimeter is blocking access from their location; an IAM condition on the binding is not satisfied; an org policy or deny policy is overriding it; the bucket uses CMEK and they lack the KMS key permission; or the change simply has not propagated yet. The CMEK case is the one that separates strong candidates — with a customer-managed key, Storage Admin alone is not enough; the principal also needs roles/cloudkms.cryptoKeyEncrypterDecrypter on the key. Listing several hypotheses and then naming Policy Troubleshooter to decide between them is the ideal structure.

Question 33

What is the recommended way for a CI/CD pipeline to authenticate to GCP?

Accepted Answer

Workload Identity Federation from the CI provider — GitHub Actions, GitLab, Bitbucket — exchanging the pipeline's OIDC token for a short-lived GCP credential, with the pool provider restricted by attribute conditions so only the intended repository and branch can assume the identity. If the pipeline runs on GCP (Cloud Build), simply attach a dedicated service account. The attribute condition is the security-critical detail: without restricting on repository and ref, any repository in the organisation — or in some misconfigurations, any repository at all — could obtain the credential. That specific misconfiguration has caused real breaches, which is why it is asked.

Question 34

What is the difference between roles/owner and roles/resourcemanager.projectIamAdmin?

Accepted Answer

Owner is a basic role granting virtually every permission in the project plus the ability to manage IAM policies and delete the project. Project IAM Admin grants only the ability to manage IAM policies on the project — it cannot create or modify resources. Separating them is a core separation-of-duties control. The subtlety worth raising is that Project IAM Admin is itself a privilege-escalation path: someone who can edit the IAM policy can grant themselves Owner. Any answer that presents it as harmless misses the point; it should be tightly held and monitored with alerts on policy changes.

Question 35

How do you monitor for suspicious IAM changes?

Accepted Answer

Create a log-based alert on Admin Activity audit logs for SetIamPolicy events matching sensitive conditions — grants of Owner or Editor, grants to allUsers or allAuthenticatedUsers, service-account key creation, or changes to the audit-log configuration itself. Route these to a security channel and to Security Command Center. Naming the changes to the *logging configuration* as a signal is what marks a mature answer, because disabling logging is a standard early step in an intrusion. An alert that fires when someone alters the audit sink is one of the highest-value detections you can build.

Question 36

What is the "iam.serviceAccounts.actAs" permission and why does it matter?

Accepted Answer

It is the permission that allows a principal to deploy a resource that runs as a given service account, and it is contained in roles/iam.serviceAccountUser. It matters because it is a privilege-escalation boundary: a user with limited direct permissions can deploy a Cloud Function running as a highly-privileged service account and thereby execute arbitrary code with those privileges. This is one of the most important and least-known IAM facts on GCP. It means auditing "who can act as which service account" is as important as auditing direct role grants, and it is exactly the sort of question a cloud-security interviewer uses to find genuine depth.

Question 37

How does IAM apply to BigQuery, and what are dataset and table level controls?

Accepted Answer

BigQuery supports IAM at project, dataset, table and even column and row level. Project-level roles govern job execution and administration; dataset-level roles govern data access to everything in the dataset; table-level bindings narrow it further; policy tags with Data Catalog implement column-level security; and row-level access policies filter rows by a condition on the querying identity. Column-level security through policy tags is the feature to name for any question about protecting PII, because it lets one table serve both restricted and unrestricted consumers without duplicating data. Authorised views are the older pattern and still relevant to mention.

Question 38

What is an authorised view in BigQuery and how does it relate to IAM?

Accepted Answer

An authorised view is a view in one dataset that is granted access to a source dataset, so consumers can be given access to the *view* without any access to the underlying tables. The view's identity, not the user's, reads the source data, which lets you expose a filtered or aggregated slice safely. The value is enforcing a data contract: analysts see only the columns and rows the view exposes and physically cannot query around it. Authorised datasets and routines extend the same idea, and row-level security is the newer alternative for filtering by user.

Question 39

What is the recommended IAM structure for a company with 200 engineers across 15 teams?

Accepted Answer

Groups mirroring team and function, synced from the corporate identity provider; folders per business unit and environment; predefined roles granted to groups at the folder level for broad access and at the project or resource level for specific access; no basic roles anywhere; separate deployment service accounts per environment used by CI with Workload Identity Federation; deny policies and organisation policy constraints as guardrails; time-bound conditions for elevated access; and audit-log export plus IAM Recommender running continuously. This is the closing design question. The signals are granting to groups rather than users, applying at folder level to avoid per-project sprawl, and treating org policy as the enforcement layer rather than relying on IAM alone. Mentioning that you would keep a documented break-glass procedure completes it.

Question 40

What is Security Command Center and how does it help with IAM?

Accepted Answer

Security Command Center is GCP's centralised security posture and threat-detection service. For IAM it surfaces findings such as public buckets and datasets, over-privileged service accounts, primitive-role usage, service-account keys that have not been rotated, and anomalous IAM grants, and it can also detect active threats through Event Threat Detection on audit logs. The tiering matters in practice — the Standard tier gives basic findings while Premium and Enterprise add Event Threat Detection, Security Health Analytics at full breadth and compliance reporting. Knowing that some capabilities are paid tiers avoids promising things a Standard-tier customer will not see.

GCP Cloud IAM Interview Questions and Answers

How to use this set