Frequently asked questions

Learn about common issues you may face while using Identity and Access Management (IAM).

About IAM

What is IAM?

IAM enables you to create and manage permissions for Google Cloud resources. It unifies access control for Google Cloud services into a single system and presents a consistent set of operations. For an overview of concepts, read IAM Overview.

Why do I need IAM?

IAM lets you adopt the security principle of least privilege, so you grant only the necessary access to your resources and prevent unwanted access to other resources. IAM allows you to meet compliance clauses around the separation of duty.

Which of the Google Cloud services support IAM?

All Google Cloud services use IAM to make sure that only authorized identities can access them. In addition, some services provide IAM roles specific to their services, or support granting access at the resource level. For more information on IAM support, see the overview.

How do I get started with using IAM?

To get started with IAM, read IAM Quickstart.

Can I use IAM policies to manage both authentication and authorization for my applications?

Use IAM to manage authorization to Google Cloud resources. To manage user authentication, use whatever methods you use to manage them today, for example, LDAP, Google groups, etc. Using IAM, you can grant access to a Google account, a service account, a Google group, a Cloud Identity domain, or a Google Workspace domain.

Roles and Policies

What is the relationship between a role and a policy?

Permissions determine what operations are allowed on a resource. In the IAM world, permissions are represented in the form of <service>.<resource>.<verb>, for example compute.instances.get. A role is a collection of permissions. You cannot assign a permission to the user directly; instead you grant them a role. When you grant a role to a user, you grant them all the permissions that the role contains.

IAM lets you control who (users) has what (roles) permission to which resources by setting IAM policies. An IAM policy on a resource is the full list of roles granted to principals on the resource.

For more information on permissions, roles, and policies, read IAM Overview.

What is the difference between basic roles and predefined roles?

Basic roles are the legacy Owner, Editor, and Viewer roles. IAM provides predefined roles, which enable more granular access than the basic roles.

When would I use basic roles?

Use basic roles in the following scenarios:

  • When the Google Cloud service does not provide a predefined role. See the predefined roles table for a list of all available predefined roles.

  • In development and test environments. It might be appropriate for some principals to have wide-ranging permissions in these environments.

  • When you need to allow a principal to modify permissions for a project, you'll want to grant them the owner role because only owners have the permission to grant access to other users for projects.

  • When you work in a small team where the team members don't need granular permissions.

Can I define my own (custom) roles?

Yes, see the article on Custom Roles.

How can I find out what roles are granted on a resource?

You can find out what roles are granted on a resource by using the Cloud Console , the getIamPolicy() method, or the gcloud command-line tool. Learn how.

What does an IAM policy look like?

An IAM policy is represented by a policy object that consists of a list of bindings. A Binding binds a list of principals to a role. This can be represented in code as shown in this example code snippet:

  "bindings": [
     "role": "roles/owner",
     "members": [
        "role": "roles/compute.networkViewer",
        "members": [""]

The example policy above assigns the owner role to,,, and, and the Network Viewer role to

How can I create and manage my IAM policies?

You can create and manage IAM policies using the Google Cloud Console, the gcloud tool, and the IAM methods. Learn how.

How can I find out my project's IAM policy?

You can find out a project's IAM policy by using the Cloud Console, the project.getIamPolicy() method, or the gcloud tool. Learn how.

How can I find out my organization-level policy?

You can find the organization-level policy using the Cloud Console, the organization.getIamPolicy() method, or the gcloud tool. For instructions on finding out organization-level policies, see Access Control for Organizations.

How do I update a policy?

You can update a policy by using the Cloud Console, the REST API, or the gcloud tool. Learn how.

Are there limits on how many principals I can include in a policy?

Yes, the number of principals in a policy is limited. For details, see the quotas and limits for IAM.

How do I troubleshoot my policies?

You can use the testIamPermissions() method to check which of the given permissions the caller has for the given resource. This method takes a resource name and a set of permissions as parameters, and returns the subset of permissions that the caller has.

You can validate what the effect of an IAM role is. For example a user cannot access the Cloud Console page for which they have not been granted access. For example, if you granted a user only the Logs Viewer role, they will see the following error message if they try to access the App Engine page:

You don't have permissions to perform the action on the selected resource.

Why do I get an error about "concurrent policy changes" when I try to update a policy?

To prevent concurrent policy changes from overwriting each other, each IAM policy includes an etag field, which changes each time you update the policy. If you try to write an updated policy, and the etag in your request does not match the existing policy, you receive the following error message:

There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.

To learn more about this issue, see Using etags in a policy. To learn how to implement retries with exponential backoff, see Retry failed requests.


To what identities can I grant IAM roles?

IAM enables you to grant access to the following types of identities:

  • Google account
  • Service account
  • Google group
  • Google Workspace domain
  • Cloud Identity domain

Can I use Google groups with IAM?

Usually. One exception is the owner role. A group can only be assigned the owner role for a project if they are both part of the same organization. Projects without an organization cannot have groups as owners, nor can groups be assigned as owners for projects in different organizations.

Otherwise, grant roles to Google groups instead of to individual users when possible. It is easier to add members to and remove members from a Google group instead of updating multiple IAM policies to add or remove users. If you need to grant multiple roles to allow a particular task, create a Google group, grant the roles to that group, and then add users or other groups to that group.

Each IAM policy can contain up to 250 Google groups.

Can I use IAM to create and manage my users?

No. You can use Cloud Identity or Google Workspace to create and manage users. You can also manage your users by your current methods such as LDAP or Google Groups. If you use LDAP to manage your users, you'll need to use Google Cloud Directory Sync to synchronize the data in your Google domain. However you manage your users, you'll need to bind them, preferably using Google Groups, to a role in an IAM policy to allow them to access resources.

How can I disable a user's access to IAM resources?

If you granted the user the IAM role via a Google group, you can remove the user from the group and they'll no longer have the access you granted to the group. If you didn't use a group, you'll need to review your policies to identify where you've granted access to the individual user, then remove them from the policy and update the policy. Using Google groups to grant access is easier because you won't have to update all of your policies to revoke an individual user's access rights. Learn more.

Why can a user not access resources shortly after permission is granted, or continue to access resources after permission is removed?

In general, it takes fewer than 60 seconds for a principal's access to be granted or revoked. However, under certain circumstances, it may take up to 7 minutes for these changes to fully propagate across the system.

How do I grant permissions to resources in my project to someone who is not part of my organization?

Using Google groups, you can add a user outside of your organization to a group and bind that group to the role. Note that Google groups don't have login credentials, and you cannot use Google groups to establish identity to make a request to access a resource.

You can also directly add the user to the IAM policy even if they are not a part of your organization. However, check with your administrator if this is compliant with your company's policy.

How can I manage who can access my instances?

To manage who has access to your instances, use Google groups to bind identities to roles. This binding will be surfaced as part of a policy which is applied at the project level where the instances will be launched. If a user (identified by their Google Account, for example, is not a member of the group that is bound to a role, they will not have access to the resource where the policy is applied.

How can I use Multi Factor Authentication (MFA) with IAM?

When individual users use MFA, the methods they authenticate with will be honored. This means that your own identity system needs to support MFA. For Google Workspace accounts, this needs to be enabled by the user themselves. For Google Workspace-managed credentials, MFA can be enabled with Google Workspace tools.

How does a service account differ from a user who uses IAM?

A service account is a special Google account that can be used by applications to access Google services programmatically. This account belongs to your application or a virtual machine (VM), instead of to an individual end user. Your application uses the service account to call the Google API of a service, so that the users aren't directly involved.

Service Accounts

What is the maximum number of service accounts I can have in a project?

By default, you can create up to 100 service accounts in a project. If you need to create additional service accounts in a project, you can request a quota increase.

How can I rotate the service account keys when using IAM?

The Google Cloud-managed keys are rotated daily. To rotate the user-managed keys, use the IAM service account API to automatically rotate your service account keys. You can rotate a key by creating a new key, switching applications to use the new key, disabling the old key, and deleting the old key when you are sure that it is no longer needed.

How do I control who can create a service account in my project?

Owner and editor roles have permissions to create service accounts in a project. If you wish to grant a user the permission to create a service account, grant them the owner or the editor role.

Can I create a service account under an organization?

Currently you can create service accounts only under a project; you cannot create a service account directly under an organization. But if you grant IAM permissions at an organization level, the permissions will be inherited by projects under that organization, and in turn by service accounts under the projects.

I have a dedicated team that manages network and firewall rules. How can I maintain this separation of duty so that my development teams can manage instances but not make any network or firewall changes?

First, grant the Compute Network Admin role at the organization or the project level to your network administrators. Then, grant the Compute Instance Admin role to your developers. This separation of duty allows developers to carry out actions on instances while also preventing the developers from making any changes to the network resources associated with the project.

I need to ensure that the teams in my organization cannot access each other's instances. How can I do this?

Create two projects one for each team. Then create separate policies for each project to control which teams can access what project and the instances contained within the project. An alternative approach is to use service accounts with different roles.

Can I change the service account that I use to launch my instance?

Yes, however you cannot change the service account for a running Compute Engine instance. The instance must be temporarily stopped. After the instance is stopped, assign a new service account, and then restart the instance. For more information, see the Compute Engine documentation.

In what scenarios would I use the Service Account Actor role?

The Service Account Actor role has been deprecated. If you need to run operations as the service account, use the Service Account User role.

In what scenarios would I use the Service Account User role?

The Service Account User gives permissions to run operations as the service account. When granted together with the compute.instanceAdmin role, the iam.serviceAccountUser role gives users the ability to create and manage Compute Engine instances that use a service account. Users who are serviceAccountUsers for a service account can access all the resources for which the service account has access.


How can I audit my IAM Policies?

You can use Cloud Audit logs to regularly audit changes to your IAM policy. Depending on the audit log type, they are retained for either 30 days (Data Access logs) or for 400 days (Admin Activity logs and System Event logs).

What is recorded in the audit logs?

Admin Activity audit logs contain an entry for every API call or administrative action that modifies the configuration or metadata of a service or project. Data Access audit logs contain an entry for the following events:

  • API calls or administrative actions that read the configuration or metadata of a service or project.

  • API calls or administrative actions that create, modify, or read user-provided data managed by a service, such as data stored in a database service.

  • Project-level setIamPolicy() method is recorded.

  • Service accounts and service account keys are logged.

How can I control who has access to my audit logs?

You can control access to logs using Cloud Logging roles.

How do I persist my audit logs?

Individual audit log entries are kept for a specified length of time and are then deleted. Cloud Logging Quota Policy explains how long log entries are retained. To persist your log entries beyond the quota policy limits, route your logs from Cloud Logging to a Cloud Storage bucket or to BigQuery.