Road to Google Associate Cloud Engineer 2020 Certification — GCloud SDK and the command line
By: Emanuele Pecorari
Tags: Certification, Cloud, G Cloud, Google Cloud Sdk, Gcp

It is possible to control the Google Cloud Platform in several ways:

Through the web console (https://cloud.google.com/)

Through the Command Line installing the GCloud SDK

Through the REST API

At the beginning you will use more the web console. But then, you will realize that the certification exam requires a good knowledge of the GCloud SDK command line (CLI).

When I started to do the first exam dumps I was quite worried by the presence of this kind of questions thinking I had to memorize the exact syntax of the commands.

Have the Cheat Sheet with a list of the commands and other information is very useful while practicing with the GCloud SDK

Reading some blog posts I then realized that you’re not supposed to do learn exactly all the commands but rather understand the logic and the patterns behind the GCloud SDK.

Let’s consider the SDK already installed on the computer and let’s see what’s the logic behind the syntax of the commands.

Initialization

The initialization of the Gcloud SDK can be launched with:

gcloud init

This launches an interactive Getting Started workflow for the command-line tool:

Authorizes gcloud and other SDK tools to access Google Cloud Platform using your user account credentials, or from an account of your choosing whose credentials are already available.

Sets up a new or existing configuration.

Sets properties in that configuration, including the current project and optionally, the default Google Compute Engine region and zone you’d like to use.

gcloud init can be used for initial setup of gcloud and to create new or reinitialize gcloud configurations.

The initialization command can be present in some questions asking, for example, what’s the first action you should do after having installed the SDK.

Configuration

Another important concept to understand is the configuration. There are questions with the following scenario :

“You have succesfully deployed a new App Engine application with the command gcloud app deploy but you can’t see it in your project. You realize that it has been deployed in the wrong project. How can you see check in which project it has been deployed?”

In this case, you should just see the current configuration and see which project is active with the command:

gcloud config list

and see in the the value for the project in the core section (mycurrentproject in this case):

[app]

cloud_build_timeout = 1000

[core]

account = myemail@myemail.com

disable_usage_reporting = True

project = mycurrentproject

[gcloudignore]

enabled = true

So, gcloud config list will be the right answers.

When you have to manage several projects, it’s a good idea creating different configurations and activate the right one when needed. The command to do it is:

gcloud config configurations create my-config

The concept of default configuration can be found in some questions with a scenario similar to this:

“You created a compute instance by running gcloud compute instances create instance1. You intended to create the instance in project gcp-ace-proj-266520 but the instance got created in a different project. Your cloud shell gcloud configuration is as shown.”

$ gcloud config list [component_manager]

disable_update_check = True

[compute]

gce_metadata_read_timeout_sec = 5

zone = europe-west2-a

[core]

account = gcp-ace-lab-user@gmail.com

disable_usage_reporting = False

project = gcp-ace-lab-266520

[metrics]

environment = devshell

What should you do to delete the instance that was created in the wrong project and recreate it in gcp-ace-proj-266520 project?

In this case the right answers is (among the 4 that normally are proposed):

gcloud compute instances delete instance1

gcloud config set project gcp-ace-proj-266520

gcloud compute instances create instance1.

So globally, you first delete the wrong instance, you change the project of your default configuration and you create the instance that will be placed in the right project this time.

It’s a good idea to create different configurations with:

gcloud config configurations create my-config1

populate them with the correct values for each one and than switch between them with the command:

gcloud config configurations activate my_config1

You can list all the configurations you have created with:

gcloud config configurations list

Another important concept that help to spot correct answer for questions involving the configuration is the sections. Looking at the response to gcloud config list above, we find a [core] section and for example a [compute] one.

Remember that to change a value for a section different than [core] you will have to explicitly specify it in the command. For example, to change the default zone of the compute engine you will write

gcloud config set compute/zone europe-west1-b

using the pattern <section>/<argument> in compute/zone.

If you need to change the project for the default configuration you will write

gcloud config set project my-second-project

Since project is an argument of the core section, no need to use the notation <section>/<argument>

Structure of CLI commands

Let’s see an command example:

gcloud compute instances create myinstance –-zone=us-central1-a

This command crate a compute engine instance with name myinstance in the us-central1-a zone.

The structure of the commands for GCloud SDK follows the pattern below:

gcloud + release level (optional)+ component + entity + operation + positional args + flags

Looking at the example we’ll have:

Release level: not present in our example. It can be alpha or beta. For General Availability (GA) there is no need of release level in the command

Component: it’s the Gcloud service. In our example ‘compute’ for the Compute Engine service

Entity: it’s the component of the service for which we execute the command. It’s in the plural form. In this case ‘instances’

Operation, It’s a verb that says which action will be performed. ‘Create’ in our example

Positional args, It’s the argument needed to perform the command. In our example it’s the instance name ‘myinstance’

Flags, Any additional arguments that complete the command normally specifying more detailed configuration. It can be in the format — flag-only or — flag=<flag_value>. In our case it’s the –zone flag specifying the zone where we want create the instance ‘us-central1-a’

Learning the sequence of the parts composing a command makes possible to answer the questions about CLI command with a 100% accuracy.

Of course, learning also the operations and some positional args will make easier to spot the right answer but the command pattern is already enough to put you in the right direction.

A list of useful commands

A summary of important commands:

Commands for gcould config

gcloud config [configurations|get-value|list|set|unset]

List of all configurations

gcloud config configurations list

Create a new configuration for the Command Line:

gcloud config configurations create [NAME]

Switch/activate to a new configuration

gcloud config configurations activate [NAME]

List of active accounts

gcloud auth list

Check for beta commands

gcloud components install beta

Command to disable ssl validation

gcloud config set auth/disable_ssl_validation True

Help

gcloud help

Conclusions

We have seen some concepts around the initialization and configuration of the cloud SDK as well as some hints to spot and understand the right answers to some exam questions using the structure of the commands.

For every arguments we’ll explore, we’ll see some of the important CLI commands specific for each Google Cloud service. That will help to complete the notions and concepts to remember to find the right answer for questions involving the command line SDK.