Setting up cloud projects and accounts

Study guide for Associate Cloud Engineer, Unit 1 · Topic 1. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Setting up cloud projects and accounts. Considerations include:

1. Creating a resource hierarchy
2. Applying organizational policies to the resource hierarchy
3. Granting members IAM roles within a project
4. Managing users and groups in Cloud Identity (manually and automated)
5. Enabling APIs within projects
6. Provisioning and setting up products in Google Cloud’s operations suite
7. Assessing quotas and requesting increases

Setting up cloud projects and accounts

Seven jobs an engineer does before anything is deployed

Structure — the resource hierarchy and the organization policies attached to it. People — IAM roles in a project, and the users and groups in Cloud Identity who receive them. Readiness — enable the APIs, set up observability, and check the quotas before a workload needs them.

This is the first topic of the Associate Cloud Engineer exam, and every objective in it is something you do rather than something you explain. The guide lists seven considerations for setting up cloud projects and accounts. They fall into three groups. Structure: creating the resource hierarchy, and applying organization policies to it. People: granting identity and access management (IAM) roles within a project, and managing the users and groups in Cloud Identity who receive those roles, both by hand and automatically. And readiness: enabling the application programming interfaces (APIs) a project needs, setting up the observability products, and checking quotas before a workload runs into one. The exam asks these as tasks — which command, which console page, which resource to attach something to — so this deck shows the commands Google documents for each job, and the reason each one is shaped the way it is.

Creating a resource hierarchy

Organization at the root, folders to group, projects to hold resources

• The organization resource is the root node — it stands for the company
• Folders are optional; they hold projects, other folders, or both
• Projects hold the actual resources: VMs, buckets and the rest
• Every resource except the root has exactly one parent

Worked example (synthetic). A retailer creates folders for Production, Development and Shared, then creates each new project inside the folder it belongs to — so a later rule attached to Production reaches every production project at once.

The first objective is building the hierarchy, and Google describes its shape in one sentence: the organization at the top as the root, folders as an optional grouping layer, and then projects, which contain the actual service resources such as Compute Engine virtual machines (VMs) and storage buckets. The organization resource represents an entity such as a company and serves as the root node. A folder can contain projects, other folders, or a combination of both, and Google names three reasons to use them: to delegate administrative duties, to enforce environment-specific organization policies, and to streamline cost management across departments. The one structural rule that makes everything else work is this: all resources except the highest one in a hierarchy have exactly one parent. That single parent is why inheritance is predictable — a role or a policy attached higher up reaches everything below it. And the organization changes who owns the work: with an organization resource, your projects belong to your organization, not to the employee who created them. Managed users in the company's domain must create projects inside the organization; they cannot create a project that is not associated with it.

Three identifiers for one project

Only one of them is chosen by you and can never change

Worked example (synthetic). A team creates acme-web-prod as its project ID, then the product is renamed. The project name can follow the rename; the project ID stays acme-web-prod for the life of the project.

Every project carries three identifiers, and the exam likes to swap them. The project name is the human-readable one: Google says you can edit it at any time during or after project creation, and project names don't need to be unique. The project identifier, the project ID, is different in both respects. It is a unique string that differentiates your project from all others in Google Cloud, and after project creation it is permanent. The third, the project number, is an automatically generated unique identifier that you never choose. So when a scenario says a team wants to rename its project, the answer turns on which of the three it means — the name can follow a rebrand, the ID cannot, and the number was never the team's to pick.

Building the hierarchy from the command line

Create the folder, then create the project inside it

Figure. Three command cards: creating a folder under the organization with gcloud resource-manager folders create, creating a project inside a folder with gcloud projects create and the folder flag, and creating a project with no parent flag.

Worked example (synthetic). An engineer scripts a new environment: one folders create call, then a projects create … --folder call per project. Passing both --folder and --organization fails, because a project has one parent.

Here is the same hierarchy built with the gcloud command-line tool. Google's folder page says that to create a folder under the organization resource using the gcloud command-line tool, you run gcloud resource-manager folders create, with a display name and the organization's identifier. Projects are created with gcloud projects create followed by the project identifier. To give the project a parent, the projects page says to use the organization flag or the folder flag — and then the rule from the previous slide appears as a command-line restriction: as a resource can only have one parent, only one of these flags can be used. So a project inside a folder is gcloud projects create, the project identifier, and the folder flag with the folder's identifier. The exam's favourite wrong answer is a command passing both flags, or a folder command used to create a project.

Applying organization policies to the hierarchy

Attach once, and every descendant inherits it

Figure. An organization resource at the root with three folders — Production, Development and Shared — each holding one project. An organization policy is attached to the Production folder, and the callout says it is inherited by every project inside that folder and by no project outside it.

Worked example (synthetic). Security wants every production project limited to approved locations. One organization policy on the Production folder does it — including for production projects created next year.

The second objective puts constraints onto that hierarchy. Google says the Organization Policy Service gives you centralized and programmatic control over your organization's resources, and it is built on constraints: a constraint is a particular type of restriction against a Google Cloud service or a list of services — restricting the physical location of newly created resources is one of Google's own examples. An organization policy is set on an organization, folder or project resource, and it enforces the constraint on that resource and any child resources. The figure shows why the attachment point is the whole decision. The policy sits on the Production folder, so descendants of the resource to which the organization policy is attached inherit it: every production project, including ones created later, and none of the development or shared ones. Each organization policy enforces exactly one constraint, in active mode, dry-run mode, or both — so a folder with three restrictions carries three policies, not one.

Organization Policy against IAM, and the commands

IAM decides who; Organization Policy decides what

Worked example (synthetic). A developer holds the Owner role on a project but cannot create a resource outside the approved locations. Nothing is wrong with the IAM grant: an organization policy limits what can be configured, whoever asks.

The distinction the exam tests most is between organization policy and identity and access management (IAM), and Google draws it in two sentences. IAM focuses on who, and lets the administrator authorize who can take action on specific resources based on permissions. Organization Policy focuses on what, and lets the administrator set restrictions on specific resources to determine how they can be configured. That is why an Owner can still be refused: the role answers who, and the policy answers what. The commands follow the same lifecycle. You write the policy to a file and run gcloud org-policies set-policy with that file. Because a policy set on a resource can merge with any policy inherited from its parent, you check the result with describe and the effective flag, which returns the organization policy as it is evaluated at that point in the hierarchy with inheritance included. And the reset command resets the policy to use the constraint's default behavior.

Granting members IAM roles within a project

An allow policy binds principals to roles, on a resource and below it

• Access is granted through allow policies, also called IAM policies
• Each role binding ties principals — users, groups, service accounts — to a role
• A grant on a project also reaches every resource inside it
• Console: the IAM page; command line: add-iam-policy-binding

Worked example (synthetic). An engineer grants a support group a role on the web-prod project: gcloud projects add-iam-policy-binding web-prod --member=group:support@example.com --role=ROLE_NAME. Every resource in the project is now covered.

The third objective is the grant itself. In identity and access management (IAM), Google says, access is granted through allow policies, also known as IAM policies. Each allow policy contains a collection of role bindings that associate one or more principals, such as users or service accounts, with an IAM role — and common types of principals include Google Accounts, service accounts, Google groups and domains. The binding works downward: role bindings grant the roles both on the resource the allow policy is attached to and on all of that resource's descendants. So a role granted on a project reaches every resource in the project. There are two everyday ways to make the grant. In the console, go to the IAM page. On the command line, the add-iam-policy-binding command lets you quickly grant a role to a principal — gcloud projects add-iam-policy-binding, the project, a member such as a user or a group, and the role. Granting to a group rather than to each person is what makes the next objective, managing users and groups, pay off.

Which kind of role to grant

Broad, granular, or exactly the permissions you list

Worked example (synthetic). A network team needs to manage networking in production. Granting Editor would also let it delete databases; the predefined Compute Network Admin role gives it the networking job and nothing else.

Which role to put in the binding is the second half of the objective. Google names three types. Basic roles provide broad access to Google Cloud resources — the legacy basic roles are Owner, Editor and Viewer — and Google's guidance on them is blunt: in production environments, do not grant basic roles unless there is no alternative. Predefined roles provide granular access for a specific service and are managed by Google Cloud; Google's own example of a user holding several is the Compute Network Admin and Logs Viewer roles on a project. Custom roles provide granular access according to a user-specified list of permissions, and Google says they help you enforce the principle of least privilege, so principals have only the permissions they need. On the exam, a scenario that says production and names a narrow job almost always wants the predefined role for that job, and treats Editor as the distractor.

Managing users and groups in Cloud Identity

By hand in the Admin console, or synchronized from your directory

• Cloud Identity centrally manages users and groups; IAM then grants them access
• Manually: add users and create groups in the Google Admin console
• Automated: GCDS synchronizes users and groups from Active Directory
• Dynamic groups keep membership current from employee attributes

Worked example (synthetic). A startup with twelve staff adds each person in the Google Admin console. A bank with thousands of staff in Active Directory runs Google Cloud Directory Sync instead, so a leaver disabled in its directory is disabled for Google Cloud too.

The fourth objective asks for users and groups in Cloud Identity, and the guide specifies both manual and automated. Cloud Identity is an identity-as-a-service solution that centrally manages users and groups, and you can then use identity and access management (IAM) to manage access for each Cloud Identity account. The reason to bother is control: if developers use personal accounts, such as Gmail accounts, those accounts are outside of your control. The manual path is the Google Admin console — Google's setup guide notes that you might later return to the Admin console to add more users and create groups. The automated path matters once a directory already exists. Google says manually maintaining Google identities for each employee can add unnecessary management overhead when all employees already have an account in Active Directory, and that by federating, you can automate the maintenance of Google identities and tie their lifecycle to existing users. The tool is Google Cloud Directory Sync (GCDS), a free Google-provided tool that implements the synchronization. Two details are tested: provisioning works one way, from Active Directory to Google Cloud, and provisioning does not include passwords. Dynamic groups add a middle path — memberships managed automatically from a query on employee attributes such as job role.

From the directory to a role binding

Identities flow one way; access is granted on the Google side

Figure: A flow chart: Active Directory users and groups are synchronized one way, without passwords, by GCDS into Cloud Identity; users can also be added manually in the Google Admin console. A Cloud Identity group then receives an IAM role binding on a project.

Worked example (synthetic). An administrator grants the web-admins group a role on web-prod once. Every new hire synchronized into that group from Active Directory gets the access with no IAM change at all.

Drawn out, the fourth objective connects to the third. Identities enter Cloud Identity by one of two doors: synchronized from Active Directory by Google Cloud Directory Sync (GCDS), or added by hand in the Google Admin console. The synchronization arrow only points one way — Google says changes in Active Directory are replicated to Google Cloud but not the other way around — and it carries users and groups, not passwords. Access is not synchronized at all. It is granted on the Google side, as an identity and access management (IAM) role binding, and the figure shows the binding going to a group rather than to people. That is the practical pay-off: once the group holds the role, provisioning a new member into the group from the directory is all it takes to give that person access, and removing them from the group in the directory removes it.

Enabling APIs within projects

Most APIs are off until you turn them on, per project

Figure. Four cards: enabling an API in the console under APIs and Services, the gcloud services enable and disable commands, the Service Usage Admin role needed to do it, and the guidance to use the console for one-off changes and the command line for scripts.

Worked example (synthetic). A deployment script fails on its first Compute Engine call in a new project. The fix is one line before it — gcloud services enable compute.googleapis.com — run by someone holding Service Usage Admin.

The fifth objective is short and it catches people. Google's Service Usage overview says that before you can use most Google application programming interfaces (APIs), you must first enable them in a Google Cloud project. The service that does it is Service Usage itself, which you can use to enable or disable any available service for your projects. In the console you select the project, find the API and click Enable. On the command line, the gcloud services enable command enables a service with the name specified for the current project, and gcloud services disable does the reverse. Google's own guidance on which to use is practical: most users can enable and disable services with the console, and for scripts, use the command line. The permission matters too — to enable and disable services you need the Service Usage Admin role on the project. So when a new project's first API call fails, the first question is not the code; it is whether the API was ever enabled in that project.

Setting up Google Cloud Observability

The guide's “operations suite” is Google Cloud Observability today

• Monitoring, Logging and Trace are on by default in every new project
• Telemetry for most Google Cloud services is collected automatically
• Inside Compute Engine VMs, install the Ops Agent to collect telemetry
• To watch several projects from one, configure a metrics scope

Worked example (synthetic). A team wants memory and disk metrics from inside its Compute Engine VMs and one dashboard across three projects. It installs the Ops Agent on the VMs and adds the other two projects to its project's metrics scope.

The sixth objective uses the guide's old name, Google Cloud's operations suite. Google's documentation now calls it Google Cloud Observability — observability services that help you understand the behavior, health and performance of your applications — so expect either name. Setup is lighter than candidates expect, because most of it is already on: Google says Monitoring, Logging and Trace are enabled by default when you create a Google Cloud project, and telemetry data is collected automatically for most Google Cloud services. Two setup tasks remain, and both are tested. The first is inside virtual machines (VMs): the Ops Agent is the primary agent for collecting telemetry from your Compute Engine instances. The second is scope. By default, the metrics scope of a project only includes that project; if you want to chart and monitor data collected by multiple projects, some configuration is required. Cloud Logging, for its part, is a real-time log-management system with storage, search, analysis and monitoring support, and Trace follows the flow of a request through spans.

What is on already, and what you set up

Three services arrive enabled; two tasks are yours

Worked example (synthetic). An exam item offers "enable the Cloud Monitoring API" as the first step for a brand-new project. It is already enabled; the real first step for in-VM metrics is the Ops Agent.

This table is the objective reduced to what an engineer actually has to do. Monitoring, Logging and Trace are enabled by default when a project is created, so any answer that begins by switching them on is a distractor. Telemetry for most Google Cloud services is collected automatically. What is not automatic is telemetry from inside your own virtual machines (VMs), which is the Ops Agent's job — Google calls it the primary agent for collecting telemetry from Compute Engine instances. And what is not automatic is a view across projects: the metrics scope of a project defines the set of resource containers whose time-series data the project can chart and monitor, and by default it holds only that project. So a central operations project that must watch production and development needs its metrics scope configured to include them.

Assessing quotas and requesting increases

Quotas can be raised on request; system limits cannot

• Allocation quotas cap how much you hold; rate quotas cap how fast you use
• System limits are fixed — they cannot be increased or decreased
• Assess on IAM & Admin > Quotas & System Limits
• Request increases per project; the quota adjuster can request them for you

Worked example (synthetic). A project cannot create another VM because it has reached its allocation quota. The engineer finds the quota on the Quotas & System Limits page and requests an increase for that project.

The last objective is quotas, and Google explains their purpose first: quotas protect the community of Google Cloud users by preventing the overloading of services. There are two kinds the exam separates. Allocation quotas restrict how much of a resource Google Cloud allocates to you — the number of virtual machines in a project is Google's example. Rate quotas restrict the rate at which you can consume a resource. And beside both sit system limits, which Google calls fixed constraints, such as maximum file sizes, which cannot be increased or decreased. That last sentence is the trap: a scenario that hits a system limit is not solved by any request. Assessing quotas happens in the console's identity and access management (IAM) and Admin section, on the Quotas and System Limits page, which lists quota usage and values for the project, and quotas can also be managed through the Cloud Quotas application programming interface (API) and the command line. Requests are mostly per project — Google says that in most cases, quota increase adjustments must be made at the project level. And the quota adjuster can do the watching for you: it observes your consumption and proactively submits adjustment requests on your behalf, while you can still request increases manually at any time.

A request is refused: which limit was it?

Name the limit before you ask for more

Figure: A decision flow: when a request is refused for exceeding a limit, first ask whether it is a system limit, which is fixed and must be designed around. If it is a quota, ask whether it is an allocation or a rate quota, and request an increase for the project on the Quotas and System Limits page, or let the quota adjuster request it.

Worked example (synthetic). Two failures reach an on-call engineer: a VM count reached and a file too large for a service. The first is a quota to raise; the second is a system limit, and no request will move it.

The figure turns the objective into the order an engineer should think in. The first question is not how to ask for more, but which kind of limit refused the request. If it is a system limit, it is fixed — Google says system limits cannot be increased or decreased — and the only answer is to design around it. If it is a quota, the next question is its kind. An allocation quota, such as the number of virtual machines in a project, is raised by requesting an increase for that project on the Quotas and System Limits page. A rate quota restricts how fast a resource is consumed, so an increase request is one answer and spreading the calls over time is another. And for quotas that approach their values regularly, the quota adjuster observes consumption and submits the requests proactively, without anyone watching a dashboard.

What this topic actually tests

Where it attaches, who versus what, and which limit

Where does it attach? a role or a policy on a folder reaches every project inside it. Who or what? IAM grants who; Organization Policy restricts what. Which identity path? Admin console by hand, GCDS from a directory — one way, no passwords. Which limit? a quota can be raised; a system limit cannot.

Close the topic on the four decisions the exam keeps returning to. First, attachment: every resource has one parent, so a role or an organization policy attached to a folder reaches every project inside it and none outside it — choose the attachment point, not the list of projects. Second, who against what: identity and access management (IAM) authorizes who can act, Organization Policy restricts how resources can be configured, which is why an Owner can still be refused. Third, the identity path: users and groups are added by hand in the Google Admin console, or synchronized one way from Active Directory by Google Cloud Directory Sync (GCDS), without passwords, and then granted roles as groups. Fourth, the limit: allocation and rate quotas can be raised by a request for the project, while system limits are fixed. Add the two readiness habits — enable the application programming interface (API) before the first call, and install the Ops Agent for metrics from inside a virtual machine (VM) — and this topic's commands will read as tasks rather than trivia.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 1
• Resource hierarchy — Resource Manager
• Creating and managing folders — Resource Manager
• Introduction to the Organization Policy Service
• Manage access to projects, folders, and organizations — IAM
• Overview of Cloud Identity
• Set up Cloud Identity as a Google Cloud admin
• Federating Google Cloud with Active Directory
• Groups API overview — Cloud Identity
• Service Usage overview
• Enabling and disabling services — Service Usage
• Google Cloud Observability overview
• Ops Agent overview — Cloud Monitoring
• Metrics scopes overview — Cloud Monitoring
• Cloud Logging overview
• Cloud Quotas overview
• View and manage quotas — Cloud Quotas
• Quota adjuster — Cloud Quotas
• Creating and managing projects — Resource Manager
• Creating and managing organization policies
• Roles and permissions — IAM