Notes from my Google’s Associate Cloud Engineer Exam — Part #1

I recently passed Google’s Associate Cloud Engineer exam and had shared my experience as well as the crucial topics and resources required to ace the exam in the below blog post. If you had missed that out, here’s the link to it.

How I aced Google’s Associate Cloud Engineer Exam in two months

Take a look at it before you proceed further on to read the notes which I had jotted down during my test preparation. I’m planning it to write it as a series of articles so that it doesn’t appear overwhelming and take longer to digest! I hope this is useful for future test-takers in their cloud journey to know about the wonders of Google Cloud Platform.

It’s important to note that even though the service limits are subject to a change in the future, the core concepts always remain the same. It’s equally important to go through the CLI commands for the below topics as mentioning them here would be exhaustive. So, without any further adieu, let’s get started!

Compute Engine

Essential topics — Machine Types, Service Accounts, Managed Instance Templates & Groups, Auto-scaling & Auto-healing and SSH’ing to VMs.

• Virtual Machines (VM) and Persistent Disks are zonal resources. To change the access scopes of VMs, a restart of instances are required. Similarly, to create custom images, delete your instance to detach the boot disk from the instance to preserve it.
• The metadata section allows you to specify key-value pairs associated with an instance. These values are stored in the metadata server, which is available for querying using the Compute Engine API.

Example — Setting metadata to enable-oslogin=true on a VM enables it to only accept connections from user accounts that have necessary IAM roles.

• The number at the end of the machine type indicates how many CPUs it has and the type tells you where in the range of allowable RAM that machine falls — from minimum (highcpu) to balanced (standard) to maximum (highmem). Cost depends on the amount of RAM and CPU usage (https://cloud.google.com/compute/docs/machine-types).
• Availability Policy sets three parameters.

1. Preemptibility — cost-savings 80% when compared to normal VM — not enabled by default. Preemptible instances are not suitable for production applications that need to be available 24*7.
2. Automatic restart — restarts server in case of a H/W failure or some non-user-controlled event — enabled by default.
3. On-host maintenance — live migrates tasks running in current VMs to similar VMs — enabled by default.

• Security can be enhanced by using SSH keys and Shielded VMs. GCP supports the concept of project-wide SSH keys to provide users project-wide access to VMs. You can block this behavior in the VM if you don’t wish to allow all the users access to this VM — allows only users whose public key is stored in instance-level metadata to access the resource.
• Access to GCP services using a service account is determined by the access scopes and IAM roles assigned to it.

Best Practice — Provide full GCP access scope to the instance but limit access to the service account using IAM roles (https://cloud.google.com/iam/docs/service-accounts)

• In order to enable auto-healing, group your instances into a managed instance group. They maintain high-availability by proactively keeping VMs available. If the auto-healer determines that the application isn’t responding as expected, it automatically re-creates that instance.
• It’s important to use separate health checks for load balancing and auto-healing. Health checks for load balancing determine if an instance receives user-traffic. In contrast, health checks for auto-healing cause the compute engine to proactively replace failing instances.
• Snapshot retention policy determines how long you wish to keep your snapshots and when to delete it. If you plan to set up a snapshot retention policy, do it so as a part of your snapshot schedule.
• SSH’ing into VMs is possible only when the public key of the user is either present in instance-level metadata or project-level metadata. Sharing SSH keys with a group is a strict no from a security point of view as this breaks auditing. Should one of the persons create a disaster, the security admin would be unable to identify the right person who caused this.

App Engine

Significant topics — App Engine Environments, Scaling options and Traffic Splitting.

• There can only be one App Engine application in a project. To build another application, you’ll have to use a different project.
• Available in two types — Standard & Flex environment.

1. Standard — First & Second generation — Language-specific runtime; well suited for applications that do not need OS packages or other compiled software that would have to be installed along with application code. Cloud VPN & SSH features are unavailable.
2. Flexible — Run Docker containers; well suited for applications that use customized runtimes or a third party software. Provides more options including working with background processes and writing to local disks.

To know about the list of supported languages in each generation of the standard environment, check out https://cloud.google.com/appengine/docs/standard.

• App Engine Standard provides rapid scaling as compared to the flexible environment and is ideal for apps requiring quick start times to handle extreme spikes. Furthermore, it’s not completely possible to scale the containers to zero in a flex environment as some nodes will still be required for running system components and hence are billed in the absence of traffic.
• The sole reason for developing versions of an App Engine application is to efficiently deploy updates or bug-fixes using CICD. If there’s a bug in your update, just roll-back to a previous stable version!
• app.yaml is the file used to specify App Engine configurations. Your configuration determines if the App Engine instances will be resident or dynamic. If you configure autoscaling or basic scaling, instances will be dynamic. If you configure manual scaling, your instances will be resident.
• When you have more than one version of your application, you can split traffic using three ways:

1. IP Address — Provides stickiness so that client is always routed to the same version, at least so long as the IP address doesn’t change.
2. HTTP Cookies — Use this when you wish to route the client to the same version even if the IP changes. Provides uniform user-experience.
3. Random — Evenly distribute the workload.

• The preferred way to split traffic is with a cookie. When you use a cookie, the HTTP request header for a cookie named GOOGAPPUID contains a hash value between 0 & 999. If there’s no GOOGAPPUID cookie, the traffic is routed randomly.

Best Practice — Use native logging mechanisms while using App Engine Flexible environment as integrations with Stackdriver Logging comes out of the box for the containers (https://cloud.google.com/solutions/best-practices-for-building-containers).

Thanks for reading till the end of the post! I love sharing information in the hope that it would help people out there. I also write about productivity and life. If you liked my writing, just hit the follow button on Medium to recieve more such updates. Connect with me on LinkedIn, Facebook or Twitter for any guidance or discussion on technology or help.

Thanks again for reading and have a wonderful day!