Google Associate Cloud Engineer 1-10

The key to the requirement is that “the objects are written once and accessed frequently for 30 days.”
For frequently accessed “hot” data, Standard storage is optimal during the first 30 days.
After 30 days the data is rarely accessed, so moving it to Archive storage, the lowest-cost class intended for access less than once a year, is appropriate.
Nearline (30-day minimum) and Coldline (90-day minimum) are intermediate classes, and Archive is the cheapest for 3 years of long-term retention.
Choosing Standard for the frequent-access period and the cheapest Archive class for subsequent long-term retention is the lowest-cost configuration.
Storage classes | Cloud Storage | Google Cloud

Because image rendering is CPU-heavy relative to memory, a compute-optimized machine type specialized for CPU is well suited.
The other workloads, on the other hand, are optimized for n1-standard (general-purpose).
By separating node pools by workload characteristics and assigning a compute-optimized pool for image rendering and a general-purpose pool for the rest, each Pod runs on a node matched to its characteristics, using resources most efficiently.
Pod Priority controls scheduling order and is not a measure for optimizing resource efficiency.
Separating node pools according to each workload’s CPU and memory characteristics is the most efficient resource-optimization approach.
About node pools | GKE | Google Cloud

Google’s recommended practice for automating operations is to use autoscaling with a managed instance group (MIG).
By configuring autoscaling based on CPU utilization, instances are automatically added and removed according to load, maintaining high availability without interruption.
Manually increasing the instance count as in A and C is not automated and is operationally inefficient, and replacing instances as in B is not a substitute for autoscaling.
MIG autoscaling based on CPU utilization is the recommended configuration that satisfies both automation and high availability.
About autoscaling of instances | Compute Engine | Google Cloud

App Engine has a built-in traffic-splitting feature, and simply specifying weights for each version with the –splits option lets you perform a canary release with minimal complexity.
Setting the current version to 99 and the new version to 1 shows the new version to 1% of users.
Only one App Engine application can be created per project, so creating a new App Engine app as in C and D is not feasible.
–migrate shifts all traffic, so it is not appropriate for showing the version to only 1%.
Traffic splitting with App Engine’s –splits achieves a gradual release with minimal complexity.
Splitting traffic | App Engine standard environment | Google Cloud

The requirements are two points: “automatic restart on crash” and “high availability including during maintenance.”
Turning on Automatic Restart lets instances recover automatically when they crash.
Setting the on-host maintenance behavior to Migrate (live migration) means instances are moved to another host during planned maintenance and do not stop.
B terminates with Terminate and is inappropriate, and C and D do not satisfy both requirements of automatic restart and live migration.
Turning on Automatic Restart and setting live migration for on-host maintenance are the keys to meeting both requirements.
Setting instance scheduling options | Compute Engine | Google Cloud

To individually scale stateless microservices that run continuously on GKE, creating a Deployment for each microservice is the standard approach.
A Deployment manages the number of Pod replicas, and combined with HPA (Horizontal Pod Autoscaling) it can scale each service independently.
A Job is for batch processing that completes and exits and is inappropriate for a persistent service, Docker Compose is not a native Kubernetes feature, and a CRD is an extension definition for custom resources and is not used for placing ordinary services.
For persistent microservices that can be scaled individually, a Deployment per service is appropriate.
About Deployments | GKE | Google Cloud

In Google Cloud, resources are isolated and managed on a per-project basis.
To make the marketing department’s resources independent from the sales department, the correct answer is to create a new project dedicated to marketing and place the resources there.
A and B share the same project, so independence cannot be ensured.
D does not work because project IDs are globally unique and the existing acme-data-digest cannot be reused.
Independent management of resources is fundamentally achieved by separating projects.
Creating and managing projects | Resource Manager | Google Cloud

To switch between multiple accounts, regions, and zones from the CLI, the correct method is to create a named configuration for each account with gcloud config configurations create and switch to the desired configuration with gcloud config configurations activate.
Depending on the active configuration, the credentials and default region and zone change accordingly.
The “gcloud configurations list” and “config list” in B, C, and D are commands for listing configurations or checking settings and are not a means to launch an instance.
Switching between named configurations with gcloud config configurations create and activate is the proper approach.
Managing gcloud CLI configurations | Google Cloud CLI documentation

When creating an instance in a project that does not exist, you must first create the project itself.
The correct sequence is: create a new project with the Cloud SDK (gcloud), enable the Compute Engine API in that project, and finally create the instance specifying the new project.
B and C have the steps reversed, enabling the API in an existing project or specifying a nonexistent project first.
The “Create In A New Project” option on the form in D does not actually exist.
Create the new project, then enable the API, then create the instance—this order is the required flow.
Creating and starting a VM instance | Compute Engine | Google Cloud

Because the organizational policy requires using virtual machines directly, GKE (A), which uses containers, is excluded.
To scale quickly and efficiently based on CPU utilization, autoscaling of a managed instance group (MIG) using an instance template is optimal.
The time-of-day scheduled scaling in C cannot follow CPU load, and the third-party tools in D are operationally complex and inefficient.
A MIG can automatically increase and decrease VMs according to metrics such as CPU, and it also meets the requirement of using VMs directly.
To use VMs directly while scaling responsively based on CPU, MIG autoscaling is the optimal solution.
About autoscaling of instances | Compute Engine | Google Cloud