A is not correct because having a persistent connection does not handle the case where the device is disconnected.
B is not correct because Cloud SQL is a regional, relational database and not the best fit for sensor data. Additionally, the frequency of the writes has the potential to exceed the supported number of concurrent connections.
C is correct because Cloud Pub/Sub can handle the frequency of this data, and consumers of the data can pull from the shared topic for further processing.
D is not correct because having a persistent connection does not handle the case where the device is disconnected.
https://cloud.google.com/sql/
https://cloud.google.com/pubsub/

Correct answer is B as you would need gcloud to create a kubernetes cluster. Once the cluster is created you can use kubectl to manage the deployments.
Refer GCP documentation : Kubernetes Cluster Tutorial
To create a cluster with the gcloud command-line tool, use the gcloud container clusters command:
gcloud container clusters create hello-cluster –num-nodes=3
To deploy and manage applications on a GKE cluster, you must communicate with the Kubernetes cluster management system. You typically do this by using the kubectl command-line tool.
Kubernetes represents applications as Pods, which are units that represent a container (or group of tightly-coupled containers). The Pod is the smallest deployable unit in Kubernetes. In this tutorial, each Pod contains only your hello-app container.
The kubectl run command below causes Kubernetes to create a Deploymentnamed hello-web on your cluster. The Deployment manages multiple copies of your application, called replicas, and schedules them to run on the individual nodes in your cluster. In this case, the Deployment will be running only one Pod of your application.
kubectl run hello-web –image=gcr.io/${PROJECT_ID}/hello-app:v1 –port 8080
Options A & C are wrong as you need kubectl to do a kubernetes deployment.
Options C & D are wrong as you need gcloud to create the kubernetes cluster.

B is correct because of the requirement to globally scalable transactions—use Cloud Spanner. CPU utilization is the recommended metric for scaling, per Google best practices, see linked below.
A is not correct because you should not use storage utilization as a scaling metric.
C, D are not correct because you should not use Cloud Bigtable for this scenario: The data will be transactional consistent and added from any location in the world.
Reference
Cloud Spanner Monitoring Using Stackdriver: https://cloud.google.com/spanner/docs/monitoring
Monitoring a Cloud Bigtable Instance: https://cloud.google.com/bigtable/docs/monitoring-instance
The correct answer is: Use Cloud Spanner for storage. Monitor CPU utilization and increase node count if more than 70% utilized for your time span.

The correct answer is B as Bigtable provides a scalable, fully-managed NoSQL wide-column database that is suitable for both real-time access and analytics workloads.
Refer GCP documentation – Storage Options
It is best suited for
-IoT, finance, ed-tech
-Personalization, recommendations
-Monitoring
-Geospatial datasets
-Graphs
Option A is wrong as Google Cloud SQL is mainly for OLTP (Transactional, CRUD) not for taking and storing streaming data. It does not have the scalability and elasticity to absorb this amount of data in real-time.
Option D is wrong as Google Cloud Datastore does not provide analytics capabilities. Google Cloud Datastore is a NoSQL document database built for automatic scaling, high performance, and ease of application development and integrating well with App Engine.
Option C is wrong as Google Cloud Storage is not suitable to handle real-time streaming data. It also needs to be used with BigQuery for analytics.
——Extended Explanation:
A: The data is unstructured so this is not correct.
B & C: Cloud Storage stores files, but Cloud BigTable will allow for labeled partitions of unstructured. So it is better than Cloud Storage.
This leaves the answer up between “B” and “D”.
D: The 10-second idle time of the ACID operations of option D eliminates this option.
Hence, B (Google Cloud Bigtable) is the most correct answer among the given options.

The correct answer is A as the machine type for the cluster cannot be changed through commands. A new node pool with the updated machine type needs to be created and workload migrated to the new node pool.
Refer GCP documentation – Kubernetes Engine – Migrating Node Pools
A node pool is a subset of machines that all have the same configuration, including machine type (CPU and memory) authorization scopes. Node pools represent a subset of nodes within a cluster; a container cluster can contain one or more node pools.
When you need to change the machine profile of your Compute Engine cluster, you can create a new node pool and then migrate your workloads over to the new node pool.
To migrate your workloads without incurring downtime, you need to:
-Mark the existing node pool as unschedulable.
-Drain the workloads running on the existing node pool.
-Delete the existing node pool.

Option B is the Correct choice because, Cloud Composer is a managed Apache Airflow service that helps you create, schedule, monitor, and manage workflows.
Option A is an Incorrect choice because you could install Apache Airflow on a VM instance but it would mean you will have to manage the infrastructure.
Option C is Incorrect because, Istio an open platform to connect, monitor, and secure microservices.
Option D is Incorrect because, Stackdriver is a monitoring and management for services, containers, applications, and infrastructure.
Read more about it here:
https://cloud.google.com/composer/

A Is not correct because the Load Balancer will just load balance access to the uploaded image itself, and not create or autoscale VMs based on that image.
B Is not correct because while the App Engine can scale as a proxy, all requests will still end up on the same Compute Engine instance, which needs to scale itself.
C is correct because a managed instance group can use an instance template to scale based on HTTP traffic.
D is not correct because unmanaged instance groups do not offer autoscaling.
Reference:
Managed instance groups and autoscaling
https://cloud.google.com/compute/docs/instance-groups/#managed_instance_groups_and_autoscaling
Exporting an Image
https://cloud.google.com/compute/docs/images/export-image
Adding a Cloud Storage Bucket to Content-based Load Balancing
https://cloud.google.com/compute/docs/load-balancing/http/adding-a-backend-bucket-to-content-based-load-balancing
The correct answer is: Create a managed instance group based on the instance template. Configure autoscaling based on HTTP traffic and configure the instance group as the backend service of an HTTP load balancer.

A is correct because this makes sure the VM gets replicated in the new zone.
B is not correct because this takes more steps than A.
C is not correct because this will generate an error because gcloud cannot copy disks.
D is not correct because the original VM will be moved, not replicated.
The correct answer is: Create a snapshot from the disk. Create a disk from the snapshot in the europe-west2-c zone. Create a new VM with that disk.

Correct answer is D as not all the users have google accounts, the Cloud Storage can be exposed to users using signed urls. The Signed URLs can be configured to expire after 24 hrs and does not need any manual intervention.
Refer GCP documentation – Signed URLs
In some scenarios, you might not want to require your users to have a Google account in order to access Cloud Storage, but you still want to control access using your application-specific logic. The typical way to address this use case is to provide a signed URL to a user, which gives the user read, write, or delete access to that resource for a limited time. Anyone who knows the URL can access the resource until the URL expires. You specify the expiration time in the query string to be signed.
Option A is wrong as Cloud Storage cannot be password protected.
Options B & C are wrong as App Engine would need setup and teardown. Also Cloud Identity would not work as there is no credentials provider.

The correct answer is B as JobUser access grants users permissions to run jobs and cancel their own jobs within the same project
Refer GCP documentation – BigQuery Access Control
roles/bigquery.jobUser Permissions to run jobs, including queries, within the project. The jobUser role can get information about their own jobs and cancel their own jobs.
Rationale: This role allows the separation of data access from the ability to run work in the project, which is useful when team members query data from multiple projects. This role does not allow access to any BigQuery data. If data access is required, grant dataset-level access controls.
Resource Types:
-Organization
-Project
Option A is wrong as the User would allow running queries across projects.
Option C is wrong as the Owner would give more privileges to the users
Option D is wrong as Viewer does not give user permissions to run jobs.