The Google Cloud Certified - Associate Cloud Engineer (Associate-Cloud-Engineer)

If your apps are fault-tolerant and can withstand possible instance preemptions, then preemptible instances can reduce your Compute Engine costs significantly. For example, batch processing jobs can run on preemptible instances. If some of those instances stop during processing, the job slows but does not completely stop. Preemptible instances complete your batch processing tasks without placing additional workload on your existing instances and without requiring you to pay full price for additional normal instances.

https://cloud.google.com/compute/docs/instances/preemptible

https://cloud.google.com/iam/docs/understanding-roles#billing-roles

https://console.cloud.google.com/marketplace/details/gc-launcher-for-mongodb-atlas/mongodb-atlas

Cloud SQL Auth Proxy: This proxy ensures secure connections to your Cloud SQL database by automatically handling encryption (SSL/TLS) and IAM-based authentication. It simplifies the management of secure connections without needing to manage SSL/TLS certificates manually. IAM Database Authentication: This allows you to use IAM credentials to authenticate to the database, providing a unified and secure authentication mechanism that integrates seamlessly with Google Cloud IAM.

OS Login is a Google-recommended practice for managing access to Linux VMs in Compute Engine. It centralizes user account management by linking the Linux user accounts on the VMs to Google Cloud identities. You then use IAM roles to grant users the necessary permissions to access the VMs (e.g., roles/compute.osLogin or roles/compute.osAdminLogin). This simplifies management as you control access through IAM policies rather than managing individual SSH keys on each VM, thus minimizing operational costs.

Option B: While enabling OS Login is a good first step, writing custom startup scripts to manage user permissions adds complexity and operational overhead, contradicting the goal of simplification and minimizing costs.

Option C: Requiring developers to manage their own SSH keys and making the owner root is a significant security risk and not a recommended practice. It also doesn ' t centralize management.

Option D: This approach also involves managing individual SSH keys and custom scripts, which increases operational overhead and doesn ' t leverage the centralized management benefits of OS Login.

Reference to Google Cloud Certified - Associate Cloud Engineer Documents:

OS Login and its benefits for simplified and secure Linux VM access management are detailed in the Compute Engine documentation, which is a key area for the Associate Cloud Engineer certification. The integration with IAM for permission control is a central aspect of this service.

Navigate to Stackdriver Logging and select resource.labels.project_id=*. is not right.

Log entries are held in Stackdriver Logging for a limited time known as the retention period  which is 30 days (default configuration). After that, the entries are deleted. To keep log entries longer, you need to export them outside of Stackdriver Logging by configuring log sinks.

Ref: https://cloud.google.com/blog/products/gcp/best-practices-for-working-with-google-cloud-audit-logging

Configure a Cloud Scheduler job to read from Stackdriver and store the logs in BigQuery. Configure the table expiration to 60 days. is not right.

While this works, it makes no sense to use Cloud Scheduler job to read from Stackdriver and store the logs in BigQuery when Google provides a feature (export sinks) that does exactly the same thing and works out of the box.

Ref: https://cloud.google.com/logging/docs/export/configure_export_v2

Create a Stackdriver Logging Export with a Sink destination to Cloud Storage. Create a lifecycle rule to delete objects after 60 days. is not right.

You can export logs by creating one or more sinks that include a logs query and an export destination. Supported destinations for exported log entries are Cloud Storage, BigQuery, and Pub/Sub.

Ref: https://cloud.google.com/logging/docs/export/configure_export_v2

Sinks are limited to exporting log entries from the exact resource in which the sink was created: a Google Cloud project, organization, folder, or billing account. If it makes it easier to exporting from all projects of an organication, you can create an aggregated sink that can export log entries from all the projects, folders, and billing accounts of a Google Cloud organization.

Ref: https://cloud.google.com/logging/docs/export/aggregated_sinks

Either way, we now have the data in Cloud Storage, but querying logs information from Cloud Storage is harder than Querying information from BigQuery dataset. For this reason, we should prefer Big Query over Cloud Storage.

Create a Stackdriver Logging Export with a Sink destination to a BigQuery dataset. Configure the table expiration to 60 days. is the right answer.

You can export logs by creating one or more sinks that include a logs query and an export destination. Supported destinations for exported log entries are Cloud Storage, BigQuery, and Pub/Sub.

Ref: https://cloud.google.com/logging/docs/export/configure_export_v2

Sinks are limited to exporting log entries from the exact resource in which the sink was created: a Google Cloud project, organization, folder, or billing account. If it makes it easier to exporting from all projects of an organication, you can create an aggregated sink that can export log entries from all the projects, folders, and billing accounts of a Google Cloud organization.

Ref: https://cloud.google.com/logging/docs/export/aggregated_sinks

Either way, we now have the data in a BigQuery Dataset. Querying information from a Big Query dataset is easier and quicker than analyzing contents in Cloud Storage bucket. As our requirement is to Quickly analyze the log contents, we should prefer Big Query over Cloud Storage.

Also, You can control storage costs and optimize storage usage by setting the default table expiration for newly created tables in a dataset. If you set the property when the dataset is created, any table created in the dataset is deleted after the expiration period. If you set the property after the dataset is created, only new tables are deleted after the expiration period.

For example, if you set the default table expiration to 7 days, older data is automatically deleted after 1 week.

Ref: https://cloud.google.com/bigquery/docs/best-practices-storage

According to the Google Cloud documentation, you can use organization policy constraints to control the creation and expiration of service account keys. The constraints are:

constraints/iam.allowServiceAccountKeyCreation: This constraint allows you to specify which projects or folders can create service account keys. You can set the value to true or false, or use a condition to apply the constraint to specific service accounts. By setting this constraint to false for the organization and adding an exception for the pj-sa project, you can prevent developers from creating service account keys in other projects.

constraints/iam.serviceAccountKeyMaxLifetime: This constraint allows you to specify the maximum lifetime of service account keys. You can set the value to a duration in seconds, such as 86400 for one day. By setting this constraint to 86400 for the organization, you can ensure that all service account keys expire after one day.

These constraints are recommended by Google Cloud as best practices to minimize the risk of service account key misuse or compromise. They also help you reduce the cost of managing service account keys, as you do not need to implement a custom solution to rotate or delete them.

1: Associate Cloud Engineer Certification Exam Guide | Learn - Google Cloud

5: Create and delete service account keys - Google Cloud

Organization policy constraints for service accounts

Understanding IAM custom roles

Key Point: Custom roles enable you to enforce the principle of least privilege, ensuring that the user and service accounts in your organization have only the permissions essential to performing their intended functions.

Basic concepts

Custom roles are user-defined, and allow you to bundle one or more supported permissions to meet your specific needs. Custom roles are not maintained by Google; when new permissions, features, or services are added to Google Cloud, your custom roles will not be updated automatically.

When you create a custom role, you must choose an organization or project to create it in. You can then grant the custom role on the organization or project, as well as any resources within that organization or project.

https://cloud.google.com/iam/docs/understanding-custom-roles#basic_concepts

When encountering a quotaExceeded error in BigQuery, you should follow these steps to diagnose and mitigate the issue:

Understand the Error:

The error message indicates that a quota was exceeded (either a short-term rate limit or a longer-term limit).

The response payload contains information about which quota was reached.

Quotas can fall into two categories:

rateLimitExceeded: Short-term limits. Retry the operation after a few seconds using exponential backoff.

quotaExceeded: Longer-term limits. Wait 10 minutes or longer before retrying the operation.

Search Errors in Cloud Audit Logs (Option A):

Cloud Audit Logs provide detailed information about API requests and responses.

By searching the logs, you can identify the specific API call that triggered the quotaExceeded error.

This helps you understand which resource or operation exceeded the quota.

View Errors in Cloud Monitoring (Option C):

Cloud Monitoring (formerly known as Stackdriver) provides insights into your Google Cloud resources.

Check the monitoring dashboard for any alerts related to BigQuery quotas.

You can set up custom monitoring rules to track specific quotas and receive notifications.

Other Options:

B. Configure Cloud Trace: Cloud Trace is used for performance analysis and latency tracking. It’s not directly related to quota issues.

D. Use Information Schema Views: Information schema views provide metadata about your datasets and tables but won’t help diagnose quota errors.

E. Use BigQuery Bl Engine: There is no such tool called “BigQuery Bl Engine.” This option is invalid.

Remember that some quotas replenish incrementally over a 24-hour period, so you don’t always need to wait a full 24 hours after reaching the limit. Ifyou consistently hit longer-term quotas, consider workload optimization or requesting a quota increase