Cloud Storage - Nearline Storage class -> Correct. Cloud Storage - Nearline Storage class is a cost-effective solution for storing infrequently accessed data for at least 30 days, such as data backup, long-tail multimedia content, and data archiving for regulatory compliance.

Cloud Storage - Archive Storage class -> Incorrect. Archive Storage is the most cost-effective storage class and is designed for long-term archiving (expect to access the data once a year or less). It's not ideal for meeting the needs.

Cloud Storage - Standard Storage class -> Incorrect. Standard Storage is ideal for performance-sensitive use cases and frequently accessed data. It is not the most cost-effective solution in this case.

Firestore -> Incorrect. Firestore is a NoSQL document database that is designed for storing, syncing, and querying data for your mobile and web applications at global scale. It's not the most cost-effective solution for long-term storage of infrequently accessed data.

Develop in a separate branch and merge changes into the production branch, triggering an automated build in Cloud Build. -> Correct. The best practice for source control management is to develop in separate branches and merge the changes into the main production branch. This can trigger automated builds in Cloud Build, allowing for continuous integration and delivery.

Make direct changes to the production branch in the repository and manually trigger a build in Cloud Build. -> Incorrect. Directly making changes in the production branch without proper testing could introduce errors. It's better to make changes in a separate branch and merge them into production after thorough testing.

Develop in the production branch, but only allow Cloud Build to execute builds in a testing environment. -> Incorrect. Even though developing in the production branch and testing in a different environment could work, it is generally not considered a best practice. Changes should be made and tested in a separate branch before merging into production.

Use a different Source Repository for each environment (e.g., development, testing, production) and manually trigger builds in each one. -> Incorrect. Using a different Source Repository for each environment could quickly become unmanageable and goes against the principles of a single source of truth and code reuse.

API Gateway -> Correct. API Gateway is designed for creating, securing, and monitoring APIs. It natively supports access control, rate limiting, quotas, and analytics making it the best choice for this scenario.

Cloud Endpoints -> Incorrect. Cloud Endpoints does provide features like access control, monitoring, and logging, but it does not natively support rate limiting and quotas.

Google Kubernetes Engine (GKE) Ingress -> Incorrect. Google Kubernetes Engine (GKE) Ingress is a Kubernetes object that manages external access to services in a cluster, but it does not provide the comprehensive API management features like rate limiting and analytics that API Gateway provides.

Cloud Load Balancing -> Incorrect. Cloud Load Balancing is a service for distributing network traffic but does not provide the comprehensive API management features that API Gateway provides.

Use Private Google Access from GKE nodes to the Cloud SQL instance. -> Correct. Private Google Access allows GKE nodes to connect to Google services like Cloud SQL using a private IP address, keeping all traffic within the Google network.

Use Cloud NAT to route traffic. -> Incorrect. Cloud NAT allows VM instances without external IP addresses to connect to the internet, but it's not designed for routing internal traffic within the Google network.

Use Cloud VPN to connect the GKE application to the database. -> Incorrect. Cloud VPN connects your on-premises network to your Google Cloud VPC network through an IPsec VPN connection, but it's not necessary for communication within the Google network.

Use VPC peering to connect the GKE application to the database. -> Incorrect. VPC peering is a networking connection between two VPCs that enables you to route traffic between them, it's not designed for connecting services within the Google network.

Deploying your application in multiple regions -> Correct. Deploying your application in multiple regions ensures that user requests can be served from the nearest region, thereby reducing latency.

Deploying your application in a single zone for centralization -> Incorrect. Deploying your application in a single zone does not reduce latency for users across the globe. It might even increase latency for users who are far from the zone where your application is hosted.

Deploying your application only in regions where Google Cloud has the highest number of zones -> Incorrect. The number of zones in a region does not directly affect the latency experienced by the end-users. User latency is more influenced by the geographical distance between the user and the region where your application is hosted.

Limiting API requests from users in regions far from your application's region -> Incorrect. Limiting API requests from users in far-off regions does not reduce latency. It merely prevents those users from accessing your application.

REST with JSON -> Correct. REST with JSON is a standard for many different client types and has wide compatibility. JSON is also easily human-readable, making it easier to debug than binary formats such as Protocol Buffers.

gRPC with Protocol Buffers -> Incorrect. gRPC with Protocol Buffers, while highly efficient and powerful, requires HTTP/2 and is not supported by all older web browsers. Protocol Buffers are also not easily human-readable.

REST with XML -> Incorrect. REST with XML is less popular and more verbose than JSON, making it a less desirable choice.

gRPC with JSON -> Incorrect. gRPC with JSON is not a common approach, as one of the main advantages of gRPC is its use with Protocol Buffers for efficiency.

Review the error logs in Cloud Logging. -> Correct. The first step to troubleshoot an application error should be checking the error logs. Cloud Logging can provide detailed error logs which can help identify the cause of the crashes.

Modify the Cloud Run concurrency parameter to handle more simultaneous requests. -> Incorrect. The concurrency parameter controls how many requests a single instance can handle simultaneously. Modifying this value without understanding the root cause may not resolve the issue and could potentially worsen it.

Migrate the application to Google Kubernetes Engine (GKE) for better fault tolerance. -> Incorrect. Migrating the application to GKE is a considerable undertaking and might not resolve the issue if the problem is within the application code or its configuration.

Use Cloud Profiler to diagnose performance issues. -> Incorrect. While Cloud Profiler is a powerful tool for diagnosing performance issues, the first step should be checking logs for errors causing the crashes.

Store user session data in a multi-regional Firestore database. -> Correct. A multi-regional Firestore database provides high availability and strong consistency across regions, which is ideal for managing user sessions in a highly resilient manner.

Store user session data in a regional Cloud SQL database. -> Incorrect. Storing user session data in a regional Cloud SQL database would not provide the best availability in case of a regional outage.

Store user session data in the instance memory of the application's Compute Engine instances. -> Incorrect. Storing user session data in the instance memory would not survive instance restarts and would not be shared across multiple instances.

Store user session data in Cloud Storage. -> Incorrect. While Cloud Storage is highly durable and available, it's not designed for the kind of frequent, small, and unpredictable read/write operations typical of session data.

Using a simple hash function to distribute keys evenly. -> Correct. Hashing keys before using them can help distribute writes across all nodes evenly, avoiding hotspotting and improving write performance.

Using monotonically increasing keys. -> Incorrect. Monotonically increasing keys can lead to hotspotting in Bigtable, as writes are concentrated on a single node, creating a bottleneck.

Using timestamps as keys. -> Incorrect. Similar to monotonically increasing keys, timestamps can also lead to hotspotting.

Using a single, static key for all data. -> Incorrect. Using a single, static key will result in a single row, which will not leverage Bigtable's design for large scale and would lead to poor performance.

Wall Time Profiling -. Correct. Wall Time Profiling measures the real time elapsed to execute a function, which includes waiting time for I/O or other processes. It is best suited to investigate latency issues.

CPU Time Profiling -> Incorrect. While CPU Time Profiling can provide useful information on where your application spends time while the CPU is executing, it doesn't necessarily help in identifying latency issues, especially if the delay is due to IO operations or other blocking calls.

Heap Profiling -> Incorrect. Heap Profiling is used for identifying memory usage and wouldn't be the first choice to investigate latency issues.

Threads Profiling -> Incorrect. Threads profiling could provide insights into the thread state, but it may not pinpoint the exact cause of latency.