Answer is C When you use a single cluster to run a batch analytics job that performs numerous large reads alongside an application that performs a mix of reads and writes, the large batch job can slow things down for the application's users. With replication, you can use app profiles with single-cluster routing to route batch analytics jobs and application traffic to different clusters, so that batch jobs don't affect your applications' users. https://cloud.google.com/bigtable/docs/replication-overview#use-cases

B is correct. Two different job profiles to redirect trafiic to two different cluster. C is incorrect because there is no tpoint in creating app profile for two different workloads in the same cluster. One cluster handles writes and another handle reads.

IIt is C: "Workload isolation: Using separate app profiles lets you use different routing policies for different purposes. For example, consider a situation when you want to prevent a batch read job (workload A) from increasing CPU usage on clusters that handle an application's steady reads and writes (workload B). You can create an app profile for workload B that routes to a cluster group that excludes one cluster. Then you create an app profile for workload A that specifies single-cluster routing to the cluster that workload B doesn't send requests to. You can change the settings for one application or function without affecting other applications that connect to the same data." https://cloud.google.com/bigtable/docs/app-profiles

It was actually illustrated here https://cloud.google.com/bigtable/docs/replication-settings#batch-vs-serve

https://cloud.google.com/bigtable/docs/replication-settings#batch-vs-serve

C. This is exactly the example in the documentation. https://cloud.google.com/bigtable/docs/replication-settings#batch-vs-serve

Answer B: reason 1: If you don' t have any cost constraint use multi-cluster routing, reason 2: Single cluster is less scalable as we need high scalability i would go with B

I am going for C?

When you use a single cluster to run a batch analytics job that performs numerous large reads alongside an application that performs a mix of reads and writes, the large batch job can slow things down for the application's users. With replication, you can use app profiles with single-cluster routing to route batch analytics jobs and application traffic to different clusters, so that batch jobs don't affect your applications' users. Single cluster routing - You can use single-cluster routing for this use case if you don't want your Bigtable cluster to automatically fail over if a zone or region becomes unavailable. Multi-cluster routing - If you want Bigtable to automatically fail over to one region if your application cannot reach the other region, use multi-cluster routing.

C is the answer. https://cloud.google.com/bigtable/docs/replication-settings#batch-vs-serve When you use a single cluster to run a batch analytics job that performs numerous large reads alongside an application that performs a mix of reads and writes, the large batch job can slow things down for the application's users. With replication, you can use app profiles with single-cluster routing to route batch analytics jobs and application traffic to different clusters, so that batch jobs don't affect your applications' users.

Answer is C "When you use a single cluster to run a batch analytics job that performs numerous large reads alongside an application that performs a mix of reads and writes, the large batch job can slow things down for the application's users. With replication, you can use app profiles with single-cluster routing to route batch analytics jobs and application traffic to different clusters, so that batch jobs don't affect your applications' users." https://cloud.google.com/bigtable/docs/replication-overview#batch-vs-serve

Answer is C

Option B is correct An app profile specifies the routing policy that Bigtable should use for each request. Single-cluster routing routes all requests to 1 cluster in your instance. If that cluster becomes unavailable, you must manually fail over to another cluster. Multi-cluster routing automatically routes requests to the nearest cluster in an instance. If the cluster becomes unavailable, traffic automatically fails over to the nearest cluster that is available. Bigtable considers clusters in a single region to be equidistant, even though they are in different zones. You can configure an app profile to route to any cluster in an instance, or you can specify a cluster group that tells the app profile to route to only some of the clusters in the instance. Cluster group routing sends requests to the nearest available cluster within a cluster group that you specify in the app profile settings. Reference:-https://cloud.google.com/bigtable/docs/app-profiles#routing

https://cloud.google.com/bigtable/docs/replication-settings#batch-vs-serve "When you use a single cluster to run a batch analytics job that performs numerous large reads alongside an application that performs a mix of reads and writes, the large batch job can slow things down for the application's users. With replication, you can use app profiles with single-cluster routing to route batch analytics jobs and application traffic to different clusters, so that batch jobs don't affect your applications' users." It is C.

C - "With replication, you can use app profiles with single-cluster routing to route batch analytics jobs and application traffic to different clusters, so that batch jobs don't affect your applications' users." - https://cloud.google.com/bigtable/docs/replication-overview#batch-vs-serve

It's B https://cloud.google.com/bigtable/docs/replication-overview#app-profiles https://cloud.google.com/bigtable/docs/replication-overview#routing-policies

It is B . Add one cluster means you have multi clusters so you use Multi-cluster routing