Cloud Bigtable Workload Isolation with App Profiles

PDE By islever Editorial Last updated

Using a data lake.

Short answer

C Add a second cluster and use single-cluster routing app profiles to isolate the batch analytics workload from the real-time application traffic.

Question

You're using Bigtable for a real-time application, and you have a heavy load that is a mix of read and writes. You've recently identified an additional use case and
need to perform hourly an analytical job to calculate certain statistics across the whole database. You need to ensure both the reliability of your production
application as well as the analytical workload.
What should you do?
  1. Export Bigtable dump to GCS and run your analytical job on top of the exported files.
  2. Add a second cluster to an existing instance with a multi-cluster routing, use live-traffic app profile for your regular workload and batch-analytics profile for the analytics workload.
  3. Add a second cluster to an existing instance with a single-cluster routing, use live-traffic app profile for your regular workload and batch-analytics profile for the analytics workload. Correct Answer
  4. Increase the size of your existing cluster twice and execute your analytics workload on your new resized cluster.

Key Takeaways

Single-cluster routing allows deterministic assignment of workloads to specific clusters, whereas multi-cluster routing distributes traffic automatically, making it unsuitable for strict workload isolation.

Learn how to isolate heavy analytical jobs from real-time Bigtable traffic using single-cluster routing app profiles and a secondary cluster.

Common mistake: Candidates often choose Option B (Multi-cluster routing) assuming it provides better performance or separation. However, multi-cluster routing is for high availability and geo-distribution, not for separating distinct workload types like batch vs. transactional.

Expert Analysis

The core challenge is workload isolation within Cloud Bigtable. The scenario involves a real-time application with mixed read/write traffic and a heavy, hourly analytical job that scans the entire database. Running these concurrently on the same cluster causes resource contention, degrading the latency of the real-time app.

To solve this, we must isolate the analytical load from the production traffic. Google Cloud Bigtable supports App Profiles, which allow different applications to use different routing policies for the same instance. By adding a second cluster to the existing instance, we enable data replication between clusters without needing multi-cluster routing features (which are for cross-region high availability).

Option C is correct because it uses single-cluster routing. Single-cluster routing directs all requests defined by an App Profile to one specific cluster. This allows us to create two profiles: one for the 'live-traffic' app routing exclusively to Cluster 1, and another for the 'batch-analytics' job routing exclusively to Cluster 2. This ensures the heavy analytical reads do not compete for CPU or I/O resources with the real-time application.

Option B is incorrect because multi-cluster routing automatically distributes requests across all available clusters in the instance based on proximity. It does not allow deterministic assignment of specific workloads to specific clusters; therefore, the analytical job would still contend with the live traffic on the same nodes. As noted in community comments, multi-cluster routing is designed for failover and global distribution, not workload segregation.

Option A involves exporting data, which introduces significant latency and complexity, failing the requirement for an integrated solution within the Bigtable instance. Option D scales the single cluster, but does not isolate the workloads, meaning the analytics job will still impact the real-time app's performance.

Exam Strategy

When asked about isolating different types of traffic (e.g., batch vs. online) within a single Bigtable instance, look for solutions involving App Profiles. Remember that 'Single-Cluster Routing' gives you control over which cluster handles which profile, while 'Multi-Cluster Routing' is for automatic failover and global access, not segregation.

Frequently Asked Questions

Why can't we use Multi-Cluster Routing for workload isolation?

Multi-cluster routing automatically balances traffic across all clusters based on latency. It does not allow you to pin a specific workload (like a batch job) to a specific cluster, so both workloads would still share resources.

Does adding a second cluster replicate data automatically?

Yes, when you add a second cluster to an existing Bigtable instance, data is automatically replicated between them. You do not need to manually sync data.

More PDE FAQ →

Community Votes

C
62%
B
38%

62% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 28 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 28

  1. aewis 👍 5 Answered C
    It was actually illustrated here https://cloud.google.com/bigtable/docs/replication-settings#batch-vs-serve
  2. MisuLava 👍 4 Answered C
    how can you use multi-cluster routing when you want to go to old instance with the regular load and to the new one with the analytical node ? MULTI will go to the nearest one... 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.
  3. dish11dish 👍 3 Answered B
    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
  4. carbino 👍 3 Answered C
    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
  5. juliobs 👍 3 Answered C
    C. This is exactly the example in the documentation. https://cloud.google.com/bigtable/docs/replication-settings#batch-vs-serve
Show 23 more comments
  1. hauhau 👍 3 Answered B
    It is B . Add one cluster means you have multi clusters so you use Multi-cluster routing
  2. DevShah 👍 3 Answered C
    https://cloud.google.com/bigtable/docs/replication-settings#batch-vs-serve
  3. MisuLava 👍 3 Answered B
    I meant to vote B not C
  4. slade_wilson 👍 2 Answered 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.
  5. Siant_137 👍 2
    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
  6. piotrpiskorski 👍 2 Answered C
    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.
  7. opt_sub 👍 2 Answered B
    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.
  8. AWSandeep 👍 2 Answered C
    C. Add a second cluster to an existing instance with a single-cluster routing, use live-traffic app profile for your regular workload and batch-analytics profile for the analytics workload.
  9. cloudmon 👍 2 Answered B
    It's B https://cloud.google.com/bigtable/docs/replication-overview#app-profiles https://cloud.google.com/bigtable/docs/replication-overview#routing-policies
  10. carbonscave 👍 1 Answered C
    C is correct: This is the standard Google Cloud architectural pattern for workload isolation in Cloud Bigtable. By adding a second cluster to your instance (which automatically enables replication between the two), you can create specific App Profiles that use single-cluster routing. You configure your real-time application's App Profile to route traffic exclusively to Cluster 1, and your analytical job's App Profile to route exclusively to Cluster 2. This ensures the massive, resource-heavy table scans of the analytics job do not steal CPU or disk I/O from your latency-sensitive production application.
  11. baimus 👍 1 Answered C
    To answer some confusion - "single cluster routing" is routing to one cluster per profile, rather than having failover options per profile. So we have two clusters, but it's not multicluster, because we have two profiles, so it's one cluster per profile, so "single cluster routing". We COULD use multicluster, but none of the answers give the steps required to do so, so the assumption as to be that we're using single.
  12. A4M 👍 1
    I see what you say on C but the question states high availability how do you handle that with option C when you have a single region cluster hence answer needs to be with multi-region cluster - To configure your instance for a high availability (HA) use case, create a new app profile that uses multi-cluster routing, or update the default app profile to use multi-cluster routing.
  13. oussama7 👍 1 Answered B
    Option C offers single-cluster routing, meaning that each query is directed to a single specific cluster. This does not protect the transactional workload from heavy analytical loads, which can lead to performance degradation. With multi-cluster routing (option B), Bigtable can automatically distribute the load and avoid congestion on a single cluster.
  14. gudiking 👍 1 Answered 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
  15. zevexWM 👍 1
    It actually addresses the issue of High availability in that same link if you scroll down a bit more. https://cloud.google.com/bigtable/docs/replication-settings#high-availability
  16. musumusu 👍 1
    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
  17. DevShah 👍 1
    Correct 2 jobs >> 2 cluster 3 jobs >> 3 cluster app profiles with single-cluster routing used to route to specific cluster Job1 >> Cluster 1 Job2 >> Cluster 2 .....
  18. 47767f9 👍 1 Answered B
    B better than C. Multi-cluster routing to handle failovers automatically. Reference: https://cloud.google.com/bigtable/docs/replication-settings#regional-failover
  19. baimus 👍 1
    (an example of multicluster in this case would be 4 clusters, 2 for the transactional load and 2 for the analytical load)
  20. desertlotus1211 👍 1 Answered B
    Multi-cluster satisfy reliability aspect of the question. single cluster may and will cause contention for resources...
  21. A4M 👍 1
    i meant single-cluster routing
  22. samdhimal 👍 1 Answered C
    I am going for C?
  23. sfsdeniso 👍 1
    Answer is C

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

How to establish consistent BigQuery spend?

S-grade

Triggering Airflow DAGs Reactively in Private Cloud Composer

S-grade

Monitoring Cloud Bigtable for Cluster Scaling Decisions

S-grade

How to resolve Cloud Composer 2 worker pod evictions and task failures?

S-grade

← Back to PDE Study Guide