This article describes how you can extend an existing Microsoft Azure Active Directory–based identity management solution to Google Cloud Platform (GCP) to establish consistent authentication and authorization mechanisms in a hybrid computing environment.
Managing user accounts and controlling access to applications and computing resources is a key responsibility of enterprise IT departments. In the past, enterprises often relied exclusively on an on-premises Active Directory (AD), making it a cornerstone of their IT landscape and on-premises infrastructure.
Today, enterprises frequently use a combination of on-premises Active Directory and Azure Active Directory (Azure AD) to manage authentication and authorization. Although an on-premises Active Directory might be used to manage on-premises resources and might also be considered the system of record for managing user accounts and groups, Azure AD is often used to manage authentication and authorization for cloud-based deployments.
This article describes how you can extend your existing Active Directory and Azure AD–based identity management solution to GCP by using Cloud Identity. Although some of the discussion also applies to G Suite, the article focuses on Cloud Identity.
The article assumes that you are familiar with Active Directory and Azure AD.
Federating Active Directory, Azure AD, and GCP
GCP uses Google identities for authentication and access management. To access any GCP resources, an employee must have a Google identity. Manually maintaining Google identities for each employee would be cumbersome when all employees already have an account in Active Directory or Azure AD. By federating user identities between Cloud Identity and your identity management system, you can automate the maintenance of Google Accounts and tie their lifecycle to existing accounts.
If you are already using Active Directory and Azure AD, you have two options to integrate GCP:
You can federate Active Directory directly with Cloud Identity by using Google Cloud Directory Sync and Active Directory Federation Services (AD FS):
Although this approach gives you fine-grained control of how and what to synchronize between Active Directory and Cloud Identity, it doesn't take advantage of Azure AD. Also, this approach requires you to run Google Cloud Directory Sync and AD FS in your computing environment.
For more information about this approach, refer to a separate guide.
You can federate Cloud Identity with Azure AD. Azure AD itself might be federated with one or more on-premises Active Directory forests:
One advantage of this approach is that you don't need to install any additional software in your on-premises environment. The authentication mechanisms that Azure AD supports (including pass-through authentication and password hash synchronization) can be used for GCP as well.
The remainder of this article focuses on the second approach.
Federating Azure AD with Cloud Identity ensures the following:
- Active Directory and Azure AD remain the single source of truth for identity management.
- For all user accounts that are in Azure AD or a selected subset, a Google Account is created automatically.
- If an account is disabled or deleted in Azure AD, the corresponding Google Account is suspended or deleted as well. In contrast, suspending or deleting a Google Account has no effect on Active Directory, because the Google Account is re-created automatically during the next synchronization.
- Azure AD handles user authentication so you don't need to synchronize passwords to GCP.
Setting up federation between Azure AD and Cloud Identity involves two pieces:
Provisioning accounts: Relevant user accounts and groups are synchronized periodically from Azure AD to Cloud Identity. This process ensures that when you create an account in Azure AD or synchronize a new account from Active Directory to Azure AD, it's also made available in GCP so that it can be referenced in GCP even before the associated user has logged in for the first time. This process also ensures that account removals are being propagated.
Provisioning works one way, which means changes in Azure AD are replicated to Cloud Identity but not vice versa. Also, provisioning doesn't include passwords.
Single sign-on: Whenever a user needs to authenticate in GCP, Cloud Identity delegates the authentication to Azure AD by using the Security Assertion Markup Language (SAML) protocol. Depending on your Azure AD configuration, Azure AD might do one of the following:
- Perform authentication itself.
- Use pass-through authentication or password hash synchronization.
- Delegate authentication to an on-premises AD FS server.
Having Cloud Identity delegate authentication to Azure AD not only avoids having to synchronize passwords to GCP, it also ensures that any applicable policies or multi-factor authentication (MFA) mechanisms you have configured in Azure AD or AD FS are enforced.
Logical structure of Azure AD
When you use Azure, you use one or more Azure AD tenants (also referred to as directories). Azure AD tenants are a top-level structure. They are considered administrative boundaries, and serve as containers for users, groups, as well as resources and resource groups.
Each Azure AD tenant has at least one DNS domain associated with it. This DNS
domain is reflected in usernames (also referred to as User Principal Names or
UPNs), which take the form of
[domain] is one of
the DNS domains associated with the respective tenant.
An enterprise might maintain multiple Azure AD tenants. Common reasons for having multiple tenants include distinguishing between different parts of the organization, separating production resources from development and testing resources, and using separate tenants to integrate multiple forests from an on-premises Active Directory.
Logical structure of GCP
In GCP, organizations serve as containers for all resources, and they can be further segmented by using folders and projects. However, except for service accounts, organizations aren't used to manage user accounts and groups, making organizations different from Azure AD tenants.
For managing users and groups, GCP relies on Cloud Identity accounts (or G Suite accounts, which is beyond the scope of this document).
With Cloud Identity, you can create and manage private directories for user accounts and groups. Each private directory is managed independently and can differ, for example, in which authentication methods they allow or which password policies they enforce. In Cloud Identity, directories are referred to as Cloud Identity accounts and are identified by domain names.
When you create a Cloud Identity account, a GCP organization is created automatically for you and is associated with the Cloud Identity account. The Cloud Identity account and the GCP organization that's associated with it share the same name and are tied to each other. However, a GCP organization is allowed to reference users and groups from other Cloud Identity accounts.
Integrating Azure AD and GCP
Despite certain similarities between the logical structure of Azure AD and GCP, no single mapping between the two structures works equally well in all scenarios. Instead, the right approach to integrating the two systems and mapping the structure depends on multiple factors:
- How to map Azure AD tenants to Cloud Identity accounts
- How to map DNS domains
- How to map user accounts
- How to map groups
The following sections look at each of these factors.
GCP interacts only with Azure AD, not with your on-premises Active Directory. So the way you've mapped forests and domains of your on-premises Active Directory to Azure AD is of minor concern.
Mapping Azure AD tenants
If you use only a single Azure AD tenant, you can map the tenant to a single Cloud Identity account and set up federation between the two. This Cloud Identity account then provides the basis for a single GCP organization that you can use to manage all GCP resources.
In larger organizations, it's not uncommon to have more than one Azure AD tenant. Multiple tenants might be used to differentiate between testing and production environments, or to differentiate between different parts of an organization.
Although it's possible to provision users and groups from more than one Azure AD tenant to a single Cloud Identity account, it's currently not possible to set up single sign-on in a way that works for users across multiple Azure AD tenants. If you use multiple Azure AD tenants, you'll need to create a separate Cloud Identity account for each tenant and set up federation between each pair.
In GCP, a separate organization is created for each Cloud Identity account. Because GCP allows resources to be organized using projects and folders within a single organization, having more than one organization is often impractical. However, you can select one of the organizations and associate it with the other Cloud Identity accounts, effectively creating an organization that is federated with multiple Active Directory forests. The other organizations remain unused.
Azure AD B2B,
you can invite external users as guests to your Azure AD tenant. A new account
is created for each guest and Azure AD automatically assigns a UPN to these
guest accounts. The UPN that Azure AD generates uses a prefix derived from the
invitee's email address, combined with the tenant's initial domain:
When federating the tenant with a Cloud Identity account, Azure AD
attempts to provision such guest accounts to Cloud Identity. However,
onmicrosoft.comis a domain that cannot be added and verified in
Cloud Identity, this provisioning will always fail, effectively causing
guest accounts to be ignored.
If guest accounts originate from a different Azure AD tenant, one way to overcome this limitation is to create multiple Cloud Identity accounts as outlined in the previous section, each federated with a different Azure AD tenant.
To grant an external user access to certain GCP resources, it's not a prerequisite for the user to have an account in Cloud Identity. Unless restricted by policy, you can also add the external user directly as a member to the respective projects, folders, or organization, provided the user has a Google Account.
Mapping DNS domains
DNS plays a crucial role, both for Azure AD and for Cloud Identity. The second factor to look at when planning to federate Azure AD and GCP is how you can share or map DNS domains between Active Directory and GCP.
Usage of DNS domains in GCP
The Google Identity Platform, which GCP relies on for authentication purposes, uses email addresses to identify users. Using email addresses not only guarantees that they are globally unique, but also enables GCP to send notification messages to the addresses.
Google Identity Platform determines the account directory or identity provider
to use for authenticating a user based on the domain part of the email
addresses, which follows the @. For an email address that uses the
domain, for example, Google Identity Platform uses the directory of Gmail user
accounts for authentication.
When signing up for a
account, you are essentially creating a private directory that Google Identity
Platform can use for authentication. In the same way that the Gmail directory is
associated with the
gmail.com domain, G Suite and
Cloud Identity accounts must be associated with a custom domain. For
these purposes, three different kinds of domains are used:
- Primary domain: This domain identifies the Cloud Identity account and is used as the name for the organization in GCP. When signing up for Cloud Identity, you must specify this domain name.
- Secondary domain: Along with the primary domain, you can associate
other, secondary domains with a Cloud Identity directory. Each
account in the directory is associated with either the primary domain or
one of the secondary domains. Two accounts,
firstname.lastname@example.org, are considered separate accounts if
example.comis the primary domain and
secondary.example.comis the secondary domain of a directory.
- Alias domain: An alias domain is an alternative domain for the
primary domain. That is,
email@example.com to the same account if
alias.example.comis set up as an alias domain. An alias domain can only provide an alternative name for the primary domain; it's not possible to add alias domains for secondary domains.
All domains must satisfy the following requirements:
- They must be valid, global DNS domain names. During setup, you might need administrative access to the respective DNS zones in order to verify domain ownership.
- A domain, such as
example.com, can refer only to a single directory. However, you can use different subdomains, such as
subdomain.example.com, to refer to different directories.
- Primary and secondary domains should have a valid MX record so that messages sent to email addresses that are formed by using this domain name can be delivered properly.
Usage of DNS domains in Azure AD
The way Cloud Identity uses DNS is similar to how Azure AD relies on DNS to distinguish Azure AD tenants and associate usernames with tenants. But be aware of two notable differences:
Initial domains: When you create an Azure AD tenant, the tenant is associated with an initial domain, which is a subdomain of
onmicrosoft.com. This domain is different from any custom domain name that you might register in that you don't own the domain and that you don't have administrative access to the respective DNS zone.
Cloud Identity doesn't have an equivalent of an initial domain and instead requires that you own all domains that you associate with a Cloud Identity account. This requirement means that you cannot register an
onmicrosoft.comsubdomain as a Cloud Identity domain.
Domains used in user identifiers: Azure AD distinguishes between email addresses MOERAs (Microsoft Online Email Routing Addresses) and UPNs. Both follow an RFC 822 format (
user@domain), but they serve different purposes: Where UPNs are used to identify users and are used in the sign-on form, only MOERAs are used for delivering email.
The domain suffix used by UPNs is required to match one of the registered domains of your Azure AD tenant—the same requirement does not apply to email addresses.
Cloud Identity doesn't rely on the concept of a UPN and instead uses a user's email address as an identifier. Consequently, the domain used by the email address must match one of the registered domains of the Cloud Identity account.
Azure AD and Cloud Identity can use the same DNS domains. Considering the two differences outlined above, you should base your domain mapping on how you plan to map user accounts between Azure AD and Cloud Identity.
Mapping user accounts
The third factor to look at when planning to federate Active Directory and GCP is how to map user accounts between Azure AD and Cloud Identity.
Successfully mapping Azure AD accounts to Cloud Identity accounts requires two pieces of information for each account:
- A stable, unique ID that you can use during synchronization to track which Azure AD account corresponds to which Cloud Identity account.
- An email address for which the domain part corresponds to a Cloud Identity primary, secondary, or alias domain. Because this email address will be used throughout GCP, the address should be human-readable.
Internally, Azure AD identifies users by ObjectId, which is a randomly generated, globally unique ID. While this ID is stable and therefore meets the first requirement, it's meaningless to humans and doesn't follow the format of an email address. To map users, the only practical options are to map by UPN or by email address.
If the user enters an email address that belongs to a Cloud Identity account that is configured to use single sign-on with Azure AD, the user is then redirected to the Azure AD sign-on screen.
Azure AD uses UPNs, not email addresses, to identify users, so the sign-on screen prompts the user to provide a UPN.
If the Azure AD tenant is configured to use AD FS for sign-on, another redirect
takes the user to the AD FS sign-on screen. AD FS can identify users either by
their Active Directory UPN or by their Pre–Windows 2000 logon name
If the email address used for Cloud Identity, the UPN used by Azure AD,
and the UPN used by Active Directory all differ, the sequence of sign-on screens
can easily become confusing for end users. In contrast, if all three identifiers
are the same as in the example screenshots (
firstname.lastname@example.org), then users
aren't exposed to the technical differences between UPNs and email
addresses, minimizing potential confusion among your users.
Mapping by UPN
From a user-experience perspective, mapping Azure AD UPNs to Cloud Identity email addresses might be considered the best option. Another benefit of relying on UPNs is that Azure AD guarantees uniqueness so that you avoid the risk of naming clashes.
However, in order to map Azure AD UPNs to Cloud Identity email addresses, you must meet these requirements:
- The Azure AD UPNs should be valid email addresses so that any notification emails sent by GCP are correctly delivered to the user's mailbox. If this isn't the case already, you might be able to configure alias email addresses to ensure that the user receives such email.
- The UPNs of all relevant users in Azure AD must use a custom domain as
[user]@[custom-domain]). UPNs that use the Azure AD initial domain (
[user]@[tenant].onmicrosoft.com) cannot be mapped to email addresses in Cloud Identity, because the initial domain isn't owned by you, but by Microsoft.
- All custom domains used by Azure AD for UPNs must be registered in
Cloud Identity as well. This requirement means that you must have
access to the respective DNS zones in order to perform domain validation.
To avoid overriding existing
TXTDNS records you might have created for verifying domain ownership in Azure AD, you can use a
CNAMErecord to verify domain ownership in Cloud Identity.
For Cloud Identity, it doesn't matter if the UPNs in Active Directory and Azure AD are equivalent. If you use AD FS, however, users will have a better experience if the UPN in Active Directory is the same as the UPN in Azure AD.
Mapping users by email address
If mapping Azure AD UPNs to Cloud Identity email addresses isn't an option, you can map accounts by email address.
When you specify an email address in Active Directory, it's stored in the
user object and Azure AD Connect will
synchronize the value to the
Crucially, the Azure AD
Mapping users by email address requires that you meet the following additional requirements:
- Email assignments must be complete. All user accounts that are subject
to synchronization must be assigned an email address. Especially when users
are synchronized from an on-premises Active Directory, this might not be
the case because
- Email addresses must be unique across the Azure AD tenant. Although Active Directory doesn't check uniqueness on account creation, Azure AD Connect detects collisions by default, which might cause the synchronization of affected user accounts to fail.
- The domains used by email addresses don't need to be registered in Azure
AD, but they must be registered in Cloud Identity. This
requirement means that you must have access to the respective DNS zones in
order to perform domain validation, and it rules out the use of email
addresses with domains that you don't own (like
The fourth factor to look at when you are planning to federate Active Directory and GCP is whether to synchronize groups between Active Directory and GCP and how to map them.
In GCP, groups are commonly used as a way to manage access efficiently across projects. Rather than assigning individual users to Cloud Identity and Access Management (Cloud IAM) roles in each project, you define a set of groups that model common roles in your organization. You then assign those groups to a set of Cloud IAM roles. By modifying the membership of the groups, you can control users' access to an entire set of resources.
Mapping groups between Azure AD and GCP is optional. After user accounts are federated, you can create and manage groups directly in Cloud Identity, which means that Active Directory or Azure AD remains the central system for identity management but not for GCP access management.
To maintain Active Directory or Azure AD as the central system for identity management and access management, we recommend that you synchronize groups from Azure AD instead of managing them in Cloud Identity. With this approach, you can set up Cloud IAM so that you can use group memberships in Active Directory or Azure AD to control who has access to resources in GCP.
Groups in Cloud Identity
In Cloud Identity, there is only a single type of group. Groups in Cloud Identity aren't confined to the scope of the Cloud Identity account where they were defined. Instead, they can include user accounts from different Cloud Identity accounts, support being referenced and nested in other Cloud Identity accounts, and be used across any GCP organization.
As it does with user accounts, Cloud Identity identifies groups by email address. The email address doesn't have to correspond to an actual mailbox, but it must use one of the domains registered for the respective Cloud Identity account.
When working with groups in Cloud IAM, you often need to specify groups by email address rather than by name. So it's best for groups to have not only a meaningful name, but a meaningful and recognizable email address.
Groups in Azure AD
Azure AD supports multiple types of groups, each catering to different use cases. Groups are scoped to a single tenant and identified by an Object ID, which is a randomly generated, globally unique ID. Groups can be nested and can contain either users from the same tenant or users invited from other tenants using Azure B2B. Azure AD also supports dynamic groups, whose members are determined automatically based on a query.
In the context of integrating Azure AD with Cloud Identity, two properties of groups are of primary interest—whether a group is mail-enabled and whether it is security-enabled:
- A security-enabled group can be used to manage access to resources in Azure AD. Any security-enabled group is therefore potentially relevant in the context of GCP.
- A mail-enabled group has an email address, which is relevant because Cloud Identity requires groups to be identified by an email address.
In Azure AD, you can create groups of type Security or Office 365 (sometimes called unified groups). When synchronizing groups from an on-premises Active Directory or when using the Office 365 type, you can also create groups of type Distribution list.
The following table summarizes the differences between these different kinds of groups regarding being mail-enabled or security-enabled, and how they map to Active Directory group types, assuming a default Azure AD Connect configuration:
|Source||Active Directory group type||Azure AD group type||Mail-enabled||Security-enabled|
|Azure AD||-||Office 365 group||Always||Optional|
|Azure AD||-||Security group||Optional||Always|
|on-premises||Security group (with email)||Security group||Yes||Yes|
|on-premises||Security group (without email)||Security group||No||Yes|
|on-premises||Distribution list (with email)||Distribution list||Yes||No|
|on-premises||Distribution list (without email)||(ignored by Azure AD Connect)|
Unlike for users, Azure AD requires that email addresses assigned to groups use a domain that has been registered as a custom domain in Azure AD. This requirement results in the following default behavior:
- If a group in Active Directory uses an email address that uses a domain that has previously been registered in Azure AD, then the email address is properly maintained during synchronization to Azure AD.
- If a group in Active Directory uses an email address that has not been
registered in Azure AD, then Azure AD auto-generates a new email address
during synchronization. This email address uses the tenant's default
domain. If your tenant uses the initial domain as the default domain, the
resulting email address will be in the form of
- If you create an Office 365 group in Azure AD, then Azure AD also auto-generates an email address that uses the tenant's default domain.
Mapping group identities
Successfully mapping Azure AD groups to Cloud Identity groups requires a common identifier, and Cloud Identity requires this identifier to be an email address. On the Azure AD side, this requirement leaves you with two options:
- You can use the email address of a group in Azure AD and map it to a Cloud Identity email address.
- You can derive an email address from the name of the group in Azure AD and map the resulting address to an email address in Cloud Identity.
Mapping by email address
Mapping groups by email address is the most obvious choice, yet it requires you to meet several requirements:
- All groups that are subject to synchronization must have an email address. In practice, this means that you can only synchronize mail-enabled groups. Groups that lack an email address are ignored during provisioning.
- The email addresses must be unique across the tenant. Because Azure AD doesn't enforce uniqueness, you might have to implement custom checks or policies.
- The domains used by email addresses must be registered in both Azure AD
and Cloud Identity. Any groups with email addresses that use
domains not registered in Cloud Identity, including the
[tenant].onmicrosoft.comdomain, will fail to synchronize.
If all relevant groups meet these criteria, identify the domains that are used by these email addresses and ensure that the list of DNS domains registered in Cloud Identity covers these domains.
Mapping by name
Meeting the criteria required to map groups by email address can be challenging, particularly if many of the security groups you intend to provision to Cloud Identity aren't mail-enabled. In this case, it might be better to automatically derive an email address from the group's display name.
Deriving an email address presents two challenges:
- An email address derived from a group's name might clash with an email address of a user.
- Azure AD doesn't enforce uniqueness for group names. If multiple groups in your Azure AD tenant share the same name, email addresses derived from this name will clash, causing only one group to synchronize successfully.
You can overcome the first challenge by using a domain for the generated email
address that is different than any of the domains used by users. For example, if
all your users use email addresses with
example.com as the domain, then you
groups.example.com for all groups. Registering subdomains in
Cloud Identity doesn't require domain verification, so the DNS zone
groups.example.com doesn't even have to exist.
You can overcome the second challenge, duplicate group names, only technically by deriving the group email address from the Object ID. Because the resulting group names are rather cryptic and difficult to work with, it's better to identify and rename duplicate group names in Azure AD before setting up provisioning to Cloud Identity.
Managing the user account lifecycle
Identifying the right mapping between tenants, domains, users, and groups allows you to automate the management of user accounts and groups in Cloud Identity. But which user accounts and groups should you provision and enable single sign-on for?
Depending on how you plan to use GCP, every user with an account in Azure AD or which you create a new account for might also be granted the permission to GCP. More likely, only a subset of your users need to be able to access GCP. So it's worth distinguishing between four sets of user accounts in Azure AD:
- Accounts in Azure AD denotes the total number of accounts in Azure AD.
- Accounts provisioned to Cloud Identity is the subset of Azure AD accounts that have been assigned for provisioning to Cloud Identity.
- Accounts enabled for SSO is the subset of Azure AD accounts that have been assigned for single sign-on.
- Accounts granted access in Cloud IAM is the subset of Azure AD accounts provisioned to Cloud Identity that have granted access to any resources in GCP.
To be able to use GCP resources, an account must be provisioned to Cloud Identity, enabled for SSO, and granted access in Cloud IAM.
An account that has been provisioned to Cloud Identity and enabled for SSO, yet has not been granted access in Cloud IAM, won't be able to use GCP, but might still be able to use other Google tools such as Data Studio.
An account that has been provisioned to Cloud Identity, but hasn't been enabled for SSO has little value for the user because they cannot use the account to sign on. However, the existence of the account in Cloud Identity blocks the user from using their corporate email address to sign up for a consumer account in YouTube, Google Search, or on other Google sites. Allowing employees to use consumer accounts for business purposes can be risky because your company doesn't control the account, its lifecycle, and its security, so blocking sign-up might be in your best interest.
Enabling an account for SSO but not provisioning the account to Cloud Identity is useful when migrating existing consumer accounts to Cloud Identity. Outside of a migration, there is little reason to enable SSO for an account that isn't also being provisioned to Cloud Identity.
Provisioning and enabling SSO for all accounts
Considering the interplay of these four sets of users, the most straightforward approach is to provision all Azure AD accounts to Cloud Identity and to enable SSO for all accounts, but to only grant a relevant subset of users access to resources:
In larger organizations, it's a best practice to grant permissions based on groups, not individuals. The groups you use for this purpose can either be groups created in Cloud Identity or groups provisioned from Azure AD.
If you decide to use Cloud Identity to create and manage the groups for controlling access to GCP resources, this approach has the advantage that all user accounts are readily available in Cloud Identity when you decide to grant more users access to a group. Otherwise, granting a user access to GCP might require you to first perform changes in Azure AD, wait until the user account has been synchronized, and then perform other actions in Cloud Identity.
Provisioning and enabling SSO for the smallest set of accounts
Provisioning all Azure AD accounts to Cloud Identity and enabling SSO for them implies that all users can access non-GCP tools such Data Studio and might seem unnecessary. An alternative approach is to provision only the smallest possible set of accounts to Cloud Identity. Ideally, this set covers only the accounts that have also been granted access in Cloud IAM.
If you use groups to manage access, but decide to manage these groups in Azure AD instead of Cloud Identity, then you can ensure that only relevant accounts are being provisioned by using the same groups to control assigning to the respective enterprise app. Alternatively, you might be able to approximate the set of accounts potentially requiring access to GCP by creating a dynamic group in Azure AD.
A downside of this approach is that users whose accounts aren't being provisioned can still sign up for a consumer account using their corporate email address.
Provisioning all users and enabling SSO for the smallest set of accounts
You can overcome the drawback of the previous approach by provisioning all accounts to Cloud Identity, yet enabling SSO only for those users that you also plan to grant access in Cloud IAM.
This approach prevents the creation of consumer accounts and avoids more users being able to sign on to Google services than necessary.
Granting users access to GCP when they need it is as important as revoking that access when they leave or change roles. When a user is deleted in Azure AD, subsequent single sign-on attempts for that user will fail. Also, the corresponding user account in Cloud Identity will be suspended.
Similarly, if you remove a user from a group that is being synchronized to Cloud Identity, then that membership removal will be reflected in Cloud Identity, which in turn will cause the user to lose any permissions that are associated with the group.
- Learn how to configure provisioning and single sign-on between Azure AD and Cloud Identity.
- Read about best practices for setting up GCP organizations for your enterprise.
- Lean about best practices for managing super administrator accounts.
- Try out other Google Cloud Platform features for yourself. Have a look at our tutorials.