Document database such as Datastore or MongoDB. -> Correct. A document database aligns well with the requirement for a flexible schema, is well-suited for handling the semi-structured data typically found in catalogs, and allows for querying.

OLAP solution such as BigQuery. -> Incorrect. BigQuery is not optimized for transactional systems and lacks the flexibility needed for a changing schema in this use-case.

OLTP solution such as MySQL or PostgreSQL. -> Incorrect. While OLTP databases are built for transactional systems, their schema is usually not as flexible as a document database, making it a less suitable option for this specific use-case.

Wide-column database such as Bigtable -> Incorrect. Bigtable might be an overkill for this use-case and doesn't offer the same level of schema flexibility as document databases.

https://cloud.google.com/datastore/docs/concepts/overview

Invalidate the exposed service account key and create a new key for the service account. -> Correct. The best course of action is to invalidate the compromised key immediately. You can do this by revoking the key in the Google Cloud Console. After invalidating the old key, you should create a new key for the service account.

Delete the key file from your local system and push another commit. -> Incorrect. Deleting the key file from your local system and pushing another commit does not mitigate the risk because the key file is still available in the commit history on GitHub.

Delete the GitHub repository and create a new one. -> Incorrect. Deleting the GitHub repository does not guarantee that the key has not been already compromised, and it would not prevent misuse if someone already has the key.

Change the visibility of your GitHub repository from private to public. -> Incorrect. Changing the visibility of your GitHub repository from private to public would actually increase the exposure of your sensitive data. It does not mitigate the potential security risks.

A cluster of GPU machines for both training and serving. -> Correct. Deep learning models are computationally expensive to train and can benefit greatly from the parallel processing power of GPUs. A cluster of GPU machines would offer the high computational resources needed for efficient training. Also, if the model will be making predictions on a continuous basis in a production environment, a cluster of GPU machines can handle the load better and provide low-latency predictions. Thus, this option satisfies both the training and serving requirements.

A cluster of GPU machines for training and a single CPU machine for serving. -> Incorrect. While a cluster of GPU machines would be highly efficient for the training phase, using a single CPU machine for serving could become a bottleneck, especially if the model is complex and you need to make predictions on a continuous basis. This might not provide the low-latency or high throughput that could be essential in a production environment.

A cluster of CPU machines for training and a single GPU machine for serving. -> Incorrect. Training a deep learning model on a cluster of CPU machines would be less efficient compared to using GPUs. While a single GPU machine could be okay for serving predictions, it might not offer the same level of scalability and low-latency as a cluster of GPU machines, especially if the model is complex.

A single, powerful GPU machine for both training and serving. -> Incorrect. While a single, powerful GPU machine might offer reasonable performance, it's not scalable. If the computational demands of the training or serving phases increase, you'd likely face limitations. Additionally, relying on a single machine introduces a point of failure, making the system less robust.

You should do the following:

• Export audit logs to Cloud Storage.
• Grant external auditors the role of Storage Object Viewer on the logs storage bucket.
• Configure a lifecycle management policy on the logs bucket to delete objects older than 5 years.

https://cloud.google.com/storage/docs/audit-logging

https://cloud.google.com/storage/docs/access-control/iam-roles#standard-roles

https://cloud.google.com/storage/docs/lifecycle

TPU (Tensor Processing Unit) -> Correct. Here is why:

• Designed for ML: TPUs are specifically designed for accelerating machine learning workloads.
• High Throughput: TPUs can process large volumes of data more efficiently than CPUs and are optimized for the types of calculations required for machine learning models, potentially speeding up the processing time.
• Integration with ML frameworks: TPUs are easily integrated into machine learning frameworks like TensorFlow, making it easier to adapt existing ML models.

GPU (Graphics Processing Unit) -> Incorrect. While GPUs are also commonly used for machine learning tasks and offer a significant speedup compared to CPUs, they are generally not as efficient as TPUs for machine learning-specific calculations. For purely speeding up ML models, TPUs would generally offer better performance.

FPGA (Field-Programmable Gate Array) -> Incorrect. FPGAs are highly flexible but require specialized knowledge to program effectively for machine learning workloads. They can be efficient but generally take longer to set up and optimize for machine learning tasks compared to TPUs.

ASIC (Application-Specific Integrated Circuit) -> Incorrect. ASICs are designed for a specific application and are not flexible. Developing an ASIC for a specific machine learning model would be extremely costly and time-consuming. It's not a practical choice for speeding up existing ML models on standard servers.

Use bq load command-line tool to load data from Cloud Storage to BigQuery. -> Correct. The bq load command-line tool is the best option for this scenario. It's specifically designed to efficiently load large volumes of data from Cloud Storage into BigQuery.

Use Cloud Dataflow to stream data from Cloud Storage to BigQuery. -> Incorrect. While Cloud Dataflow could be used to stream data, it may be an overkill for a batch ingestion scenario from Cloud Storage to BigQuery, and it may also incur unnecessary costs.

Use BigQuery Data Transfer Service to schedule daily transfers from Cloud Storage to BigQuery. -> Incorrect. BigQuery Data Transfer Service is a good option, but it's generally used for transferring data from SaaS applications to BigQuery, not for Cloud Storage to BigQuery.

Use Cloud Storage Transfer Service to move data from Cloud Storage to BigQuery. -> Incorrect. Cloud Storage Transfer Service is used for moving data between buckets or from on-premises storage to Google Cloud Storage, not for Cloud Storage to BigQuery.

Use AI Platform Predictions for both online and batch predictions. -> Correct. AI Platform Predictions supports both online and batch predictions and can handle custom Tensorflow models, which satisfies all requirements.

Use Cloud Run for online predictions and AI Platform Predictions for batch predictions. -> Incorrect. While Cloud Run could serve the Tensorflow model for real-time predictions, it does not natively support batch predictions.

Use AI Platform Predictions for online predictions and Cloud Dataproc for batch predictions. -> Incorrect. Although feasible, using two separate services (AI Platform Predictions and Cloud Dataproc) would introduce unnecessary complexity. Furthermore, Cloud Dataproc is not specifically designed to serve machine learning models.

Use Cloud Run for online predictions and Cloud Dataflow for batch predictions. -> Incorrect. Cloud Dataflow is not designed to serve machine learning models.

Use Cloud Dataflow with autoscaling and utilize FlexRS (Flexible Resource Scheduling) to run the jobs during off-peak hours. -> Correct. Cloud Dataflow with autoscaling can handle the processing of large datasets. By using FlexRS to schedule jobs during off-peak hours, the cost can be significantly reduced while still ensuring job completion within the defined time window.

Use Cloud Dataproc with preemptible VMs and high-memory machine types to speed up processing. -> Incorrect. Cloud Dataproc with preemptible VMs can provide cost savings, but complex queries and transformations might not be the best fit for the Hadoop ecosystem.

Use Cloud Bigtable with high-performance SSD storage and use Cloud Functions for processing. -> Incorrect. Cloud Bigtable is designed for low-latency, high-throughput workloads rather than complex batch processing jobs. Cloud Functions is serverless and would not provide the capacity planning needed for this scenario.

Use BigQuery with on-demand pricing for query processing. -> Incorrect. BigQuery is excellent for running complex queries, but the on-demand pricing might be cost-prohibitive for such a large dataset.

Using a Cloud Pub/Sub topic to stream the data into BigQuery in near real-time. -> Correct. Here is why:

• Near Real-Time Analysis: Pub/Sub provides real-time messaging capabilities that can be seamlessly integrated with BigQuery for near real-time analysis.
• Handles Spikes in Traffic: Pub/Sub is designed to be a highly scalable and flexible messaging queue that can handle spikes in data rates.
• Automatic Scaling: Both Pub/Sub and BigQuery are fully managed services that scale automatically, meeting the criteria of handling increased load without manual intervention.

Using a Cloud Functions trigger to run a Python script that inserts the data into BigQuery every time a new transaction is added to the Cloud Storage bucket. -> Incorrect. This approach may not scale well to handle multi-terabyte data and spikes in traffic, as each function invocation would handle a single event. It can also become expensive and slow.

Using a Cloud Dataflow pipeline to process the data and insert it into BigQuery in batch intervals. -> Incorrect. While Dataflow is a powerful service for data transformation, it operates in batch intervals. This would not satisfy the requirement for "near real-time" analysis.

Using a Cloud Dataproc cluster to run Apache Spark jobs that process the data and insert it into BigQuery in batch intervals. -> Incorrect. Dataproc and Apache Spark are more suitable for batch processing and complex transformations. They do not offer "near real-time" analysis by default and would require manual scaling to handle spikes in load, which doesn't meet the requirements of this use case.

Cloud Composer -> Correct. Cloud Composer, based on Apache Airflow, provides a managed workflow orchestration service built on Apache Airflow. It can efficiently schedule, manage, and monitor complex workflows and pipelines, thus making it the ideal service for this scenario.

Cloud Functions -> Incorrect. Cloud Functions is a serverless execution environment for building and connecting cloud services, but it doesn't provide the extensive workflow orchestration capabilities required for this scenario.

Google Kubernetes Engine (GKE) -> Incorrect. Google Kubernetes Engine (GKE) provides a managed environment for deploying, managing, and scaling containerized applications using Kubernetes, but it doesn't provide workflow orchestration capabilities out of the box.

Cloud Pub/Sub -> Incorrect. Cloud Pub/Sub is a messaging service for event-driven systems and asynchronous messaging, but it does not inherently provide workflow orchestration or job automation capabilities.