Associate Cloud Engineer v1.0 Flashcards

The audit log files for your company must be kept for three years because it is a financial institution. There are several Google Cloud projects in your company. It would help if you practiced a cost-efficient log file retention strategy. What ought you to do?

Answer: Create a sink export that stores Cloud Audit logs to BigQuery

For long-term, cost-efficient retention of audit logs (three years in this case), exporting them to BigQuery via a sink export is the recommended strategy. BigQuery offers highly scalable, cost-effective storage and powerful querying capabilities, making it ideal for compliance and auditing needs over large datasets. Unlike Cloud Storage, BigQuery is optimized for analytical queries, which is beneficial for auditors needing to analyze historical log data.

For a latency-sensitive website, you wish to use GCP to run a single HTTP reverse proxy with caching. The CPU use for this specific reverse proxy is minimal. A 30-GB in-memory cache is desired, and an extra 2 GB of memory is required for the remaining processes. Cost savings are what you seek. How should this reverse proxy be used?

Answer: Run it on Compute Engine, and choose a custom instance type with 6 vCPUs and 32 GB of memory

The application requires a 30 GB in-memory cache plus 2 GB for other processes, totaling 32 GB of memory, with minimal CPU usage. Running it on Compute Engine with a custom instance type allows for precise resource allocation, providing exactly 32 GB of memory and a minimal number of vCPUs (e.g., 6 vCPUs to ensure sufficient processing power for the proxy). This approach optimizes for cost savings by matching resources closely to the application's specific needs, avoiding the over-provisioning of predefined instance types.

In your own data center, bare-metal servers are hosting an application. Cloud storage must be accessible to the application. Security regulations, however, forbid the servers hosting the application from having available IP addresses or internet access. It would help if you stuck to Google's advice to grant the application access to cloud storage. What ought you to do?

Answer: 1. Use Migrate for Compute Engine (formerly known as Velostrata) to migrate those servers to Compute Engine 2. Create an internal load balancer (ILB) that uses storage.googleapis.com as a backend 3. Configure your new instances to use this ILB as a proxy

This strategy involves first migrating the on-site bare-metal servers to Compute Engine instances in Google Cloud using Migrate for Compute Engine. This places the application within the GCP network, closer to Cloud Storage. To maintain the security requirement of no direct internet access for the application instances, an Internal Load Balancer (ILB) can be set up to front a proxy service. The application instances are then configured to route their Cloud Storage requests through this internal proxy, allowing them to access the service without needing public IP addresses or direct internet egress.

You wish to set up a Cloud Run application that handles Cloud Pub/Sub topic message processing. You want to adhere to Google's suggestions. What ought you to do?

Answer: 1. Deploy your application on Cloud Run on GKE with the connectivity set to Internal 2. Create a Cloud Pub/Sub subscription for that topic 3. In the same Google Kubernetes Engine cluster as your application, deploy a container that takes the messages and sends them to your application

To process Cloud Pub/Sub messages with a Cloud Run application on GKE while adhering to internal connectivity, deploy the Cloud Run application with connectivity set to Internal. Create a standard Cloud Pub/Sub subscription for the topic. Then, within the same GKE cluster, deploy a separate container that acts as a message puller, fetching messages from the Pub/Sub subscription and forwarding them internally to your Cloud Run application. This ensures secure, private message handling within the cluster.

A container image-packaged program has to be deployed in a new project. Not many requests are made daily to the application, which exposes an HTTP endpoint. You want to reduce spending. What ought you to do?

Answer: Deploy the container on Cloud Run on GKE

For a containerized application with low daily request volume, deploying it on Cloud Run on GKE is a highly cost-effective solution. Cloud Run on GKE allows the application to scale down to zero instances when idle, meaning you only pay for resources when requests are actively being processed. This minimizes infrastructure costs compared to maintaining a full GKE cluster with constantly running nodes or using App Engine Flexible for such low-traffic scenarios.

Your business already has a GCP organization with a billing account and numerous projects. Your business acquired a company with hundreds of projects and its billing account. You want to combine the GCP expenses of the two GCP entities into one invoice. You want to connect all costs starting tomorrow. What ought you to do?

Answer: Create a new GCP organization and a new billing account. Migrate the acquired company's projects and your company's projects into the new GCP organization and link the projects to the new billing account

To consolidate GCP expenses from two separate organizations and billing accounts into a single invoice, a new, unified GCP organization and billing account must be established. All projects from both the original company and the acquired company should then be migrated under this new organization and linked to the new billing account. This ensures all future costs are tracked and billed together from the specified start date, providing a single point of financial management.

You used Cloud Spanner to build a Google Cloud application. While monitoring the environment, your support staff shouldn't have access to table data. You want to adhere to Google's best practices, so you need an efficient way to grant the right rights to your support team. What ought you to do?

Answer: Add the support team group to the roles/spanner.databaseUser role

The `roles/spanner.databaseUser` role grants permissions to read and write data within a Cloud Spanner database, which is typically sufficient for support staff to troubleshoot and monitor application data. Crucially, this role does not grant permissions to manage the database schema or instances, preventing unintended modifications to the database structure. This adheres to the principle of least privilege, providing necessary access without exposing sensitive administrative capabilities.