While many people will choose to just go through the full list of resources, taking all of the

courses and working on all of the labs, it is helpful to know more about the areas you may need
to spend the most time on.
We will now go over each section in a bit more detail during the rest of this course, giving an
overview of each topic and explaining some fundamental concepts to help get you started.
The tasks listed under this section involve different areas of the Google Cloud Console -
including the projects, user, API and Stackdriver consoles.

Creating projects and assigning users to the predefined roles in those projects are very basic
first tasks, so we will look at these first two items together.

Let’s look at the overall structure of a typical Google Cloud account...

This is a diagram of an example resource hierarchy within an organization.
You will notice that all resources are arranged under the Organization node, including Projects.
You consume GCP services by attaching them to, or enabling them within, a project - this is how
they are billed and tracked and given permissions to operate.

Creating a basic project is quick and easy - but it requires some attention to labeling and
naming.
The two items highlighted are provided by the person setting up the project.
Project ID, once set, cannot be changed, so think this one through carefully.
The third - Project number - is automatically generated by the GCP system and also cannot be
changed.

The main thing to remember when it comes to organizing your projects is everything is arranged
in a hierarchy.
The top of this hierarchy is the organization node.
Everything else rests under this main node.

When you have a new organization node, by default it lets any user in the domain create
projects and billing accounts.
But best practice with a new organization node is to first decide who on your team really should
be able to do those things.
Then you can assign each user to a role (or roles) for easier and more secure administration.

Permissions in GCP are inheritable - this means that each resource that sits below another one
in the hierarchy includes all of the permissions given to its parent.
Parent permissions given to a child resource cannot be removed by that child or by another
resource at the same level or by anything further down in the hierarchy.
For example, if the parent gives a user or role permission to edit a resource, a child of that
parent cannot take that edit permission away.
A child resource, however, can add permissions to the ones inherited from its parent.
This is how you get “finer-grained” control over who can use or modify resources.
What is a “role” in the context of GCP resources?
A role is simply a collection of permissions.
Generally, roles exist to define what tasks can be performed on certain resources, and when
assigned to users, who can perform them.

Roles help to simplify assigning and maintaining permissions on project resources.

They assist administrators in providing everyone in the project just the right amount of access -
and no more - to get their jobs done.

There are three main types of roles that can be applied to your GCP users and resources:
Primitive, Predefined and Custom
We will not go into Custom roles in this module.
Let’s look at the three Primitive roles first.
These primitive roles are the Owner, Editor, and Viewer.
If you’re a viewer on a given resource, you can examine it but not change its state.
If you’re an editor, you can do everything a viewer can do plus change its state.
And if you’re an owner, you can do everything an editor can do plus manage roles and
permissions on the resource.

If you have several people working together on a project that contains sensitive data, primitive
roles are probably not fine enough.
Fortunately, GCP IAM provides other, finer-grained types of roles.
Permissions are said to define “who, can do what, on which resource.”
This is generally a very coarse way of assigning permissions in a project, as it generally means
assigning view, edit or administrate levels of access.
However, GCP also offers predefined roles, which help narrow the scope down to...

Who can do what (from a long list of unique possibilities) on that particular type of resource.

Each service has a defined list of possible permissions that can be granted to users working
upon that resource.
Pre-defined roles bundle selected permissions up into collections that correlate with common
job-related business needs.
So, instead of being granted all permissions, or an ad hoc list of separate permissions that
might be missing something important, a user can simply be assigned a predefined role instead.

Compute Engine, for example, offers a set of predefined roles which can be applied to Compute
Engine resources in a given project, a given folder, or over an entire organization.
Let’s look at this in more detail.
In this example, we see a partial list (the “...” indicates there are more options not shown) of the
Compute Engine permissions that have been bundled into the predefined “InstanceAdmin” role.
These permissions determine what that role is allowed to do with virtual machines.
(Other pre-defined roles in Compute Engine will have their own customized list of permissions,
depending on what tasks that role is generally expected to perform.)
Having these predefined roles in place for common job functions saves time and administrative
overhead, since Google keeps these up to date with any new permissions that are deemed
required for that role.
Wouldn’t just giving everyone every permission on a service be much simpler to maintain?
Simpler, maybe, but much more risky as this violates the security “principle of least privilege”
and increases the chance of accidental or deliberate damage to a company’s vital services and
data.
For example, an accountant as a user might need access to reporting data generated on a
Compute Engine instance, but does NOT need to be able delete that Compute Engine instance.
Giving them permissions to do so would not be good security practice, would increase risk of
accidental deletions, and might in fact cause a company to violate certain regulations.
Many new GCP customers get started by logging into the GCP console with a Gmail account.
To collaborate with their teammates, they use Google Groups to gather together people who are
in the same role. This approach is easy to get started with, but its disadvantage is that your
team’s identities are not centrally managed. For example, if someone leaves your organization,
there is no centralized way to remove their access to your cloud resources immediately.

GCP customers who are also G Suite customers can define GCP policies in terms of G Suite
users and groups. This way, when someone leaves your organization, an administrator can
immediately disable their account and remove them from groups using the Google Admin
Console.

GCP customers who are not G Suite customers can get these same capabilities through Cloud
Identity. Cloud Identity lets you manage users and groups using the Google Admin Console, but
you do not pay for or receive G Suite’s collaboration products.
There are four ways you can interact with Google Cloud Platform, but here we’ll talk about APIs.
(We will discuss the command-line interface in the last section.)
The services that make up GCP offer Application Programming Interfaces, so that code you
write can control them directly.
These APIs are what’s called “RESTful”; in other words, they follow the “Representational state
transfer” paradigm.
We don’t need to go into much detail of what that means here, but basically, it means that your
code can use Google services in much the same way that web browsers talk to web servers.

The GCP Console includes a tool called the APIs Explorer that helps you learn about available
APIs interactively.
These APIs expect parameters, and documentation on parameters and on using them is built-in.
You can try the APIs interactively, even with user authentication. Suppose you’ve explored an
API, and you’re ready to build an application that uses it.
Does that mean you now have to start coding your application from scratch?
No. Google provides client libraries to take a lot of the drudgery out of the task of calling GCP
from your code.

There are two kinds of libraries.

The Cloud Client libraries are Google Cloud’s latest and recommended libraries for its APIs.
They adopt the native styles and idioms of each language.
On the other hand, sometimes a Cloud Client library doesn’t support the newest services and
features.
In that case, you can use the Google API Client library for your desired languages.
These libraries are designed for generality and completeness.
One powerful option for logging and monitoring your servers and applications in Google Cloud is
a product called Stackdriver.
Stackdriver is already integrated into many GCP services and products.

The best way to study for this section is to actually use Stackdriver.
If you have never used Stackdriver, the Stackdriver Fundamentals Quest will give you hands on
experience provisioning and using a Stackdriver account.
It can be accessed at: https://www.qwiklabs.com/quests/35
The Google Cloud Platform Console has a command-line interface to GCP that’s easily
accessed from your browser - it’s called Cloud Shell.
From Cloud Shell, you can use the tools provided by the Google Cloud Software Development
Kit (SDK) without first having to install them somewhere.
What’s the Software Development Kit? We’ll talk about that next.

The Google Cloud SDK is a set of tools that you can use to manage your resources and your
applications on GCP.
These include the gcloud tool, which provides the main command-line interface for Google
Cloud Platform products and services.
There’s also gsutil, which is for Google Cloud Storage; and bq, which is for BigQuery.

The easiest way to get to the SDK commands is to click the Cloud Shell button in the GCP
Console.
You will get a command line interface in your web browser on a virtual machine with all these
commands already installed.
You can also install the SDK on your own computers: your laptop, your on-premises servers, or
virtual machines in other clouds.

The SDK is also available as a Docker image, which can be a really easy and clean way to work
with it if your applications are containerized.

The Google Cloud Platform (GCP) is a suite of cloud services hosted on Google's infrastructure.
From computing and storage, to data analytics, machine learning, and networking, GCP offers a
wide variety of services and APIs that can be integrated with any cloud-computing application or
project—be it personal or enterprise-grade.
In this introductory-level lab, you will take your first steps with GCP by getting hands-on practice
with the Google Cloud Platform console—an in-browser UI that lets you access and manage
Google Cloud services. You will identify key features of GCP and also learn the ins and outs of
the Qwiklabs environment. If you are new to cloud computing or looking for an overview of GCP
and Qwiklabs, you are in the right place!
This lab is part of the Qwiklabs GCP Essentials Quest.