Load Testing Requirements for GCE and Bigtable Services

PCA By islever Editorial Last updated

Ensuring the reliability of solutions in production (e.g., chaos engineering, penetration testing, and load testing) Designing a solution infrastructure that meets technical requirements.

Short answer

ABF Validate Cloud Bigtable performance under load, create a separate Google Cloud project for isolation, and instrument both the load-testing tool and target services with detailed logging and metrics.

Question

You are helping the QA team to roll out a new load-testing tool to test the scalability of your primary cloud services that run on Google Compute Engine with Cloud
Bigtable.
Which three requirements should they include? (Choose three.)
  1. Ensure that the load tests validate the performance of Cloud Bigtable Correct Answer
  2. Create a separate Google Cloud project to use for the load-testing environment Correct Answer
  3. Schedule the load-testing tool to regularly run against the production environment
  4. Ensure all third-party systems your services use is capable of handling high load
  5. Instrument the production services to record every transaction for replay by the load-testing tool
  6. Instrument the load-testing tool and the target services with detailed logging and metrics collection Correct Answer

Key Takeaways

The question tests best practices for load-testing requirements: isolating the environment, validating every component in the service chain (including Bigtable), and enabling observability — the trap is assuming Bigtable needs no testing because it is a managed Google service.

When load-testing primary services running on Google Compute Engine with Cloud Bigtable, the QA team must include requirements to validate Bigtable performance under stress, isolate the load-testing environment in a separate Google Cloud project, and instrument both the load-testing tool and target services with detailed logging and metrics.

Common mistake: Many learners choose D (third-party system readiness) or E (recording all production transactions), believing comprehensive load testing requires testing external dependencies or full production replay. However, third-party systems were not mentioned in the question scope, and recording every production transaction for replay is impractical and not a standard load-testing requirement.

Expert Analysis

Why the Answer Is Correct

Option A is correct because Google Cloud's Bigtable performance documentation explicitly recommends running your own typical workloads against a Bigtable cluster during capacity planning to determine the best resource allocation. Despite being a managed service, Bigtable's performance depends on your schema design (row keys), cluster sizing, and application access patterns, all of which must be validated under load. Option B is correct because a separate Google Cloud project provides complete isolation from production, preventing accidental load against production resources and ensuring quota and resource separation. Option F is correct because detailed logging and metrics collection on both the load-testing tool and target services is essential to measure throughput, latency, error rates, and identify bottlenecks during the test.

Why the Other Options Are Wrong

Option C is incorrect because running load tests against the production environment risks degrading real user experience and can cause outages — load testing should always target a dedicated test environment. Option D, while a reasonable consideration in some contexts, is incorrect here because the question specifically scopes the load testing to your cloud services on GCE and Bigtable; third-party external systems were not identified as part of the test scope. Option E is incorrect because instrumenting production services to record every transaction for replay is impractical, creates security and privacy concerns, and is not a standard or recommended load-testing practice — synthetic or anonymized test data is the norm.

Community Comment Notes

The community is split between ABF and BEF. Those favoring ADF (like Svar) argue Bigtable must be tested because its performance depends on your usage patterns. Others, like e5019c6, chose BDF, reasoning that Bigtable will scale automatically as a managed service and therefore doesn't need explicit performance validation. However, Kayceetalks correctly noted that Bigtable performance must be assessed under stress for latency, throughput, and error rates, and rishab86 cited the Bigtable performance documentation recommending that you "Always run your own typical workloads against a Bigtable cluster" for capacity planning.

Official Reference

https://cloud.google.com/bigtable/docs/performance

This link opens the official vendor documentation in a new tab.

Exam Strategy

When asked for load-testing requirements, always prioritize environment isolation (separate project), comprehensive instrumentation (logging and metrics), and validating every component in your service chain — including managed databases like Bigtable whose performance depends on your schema and configuration choices.

Frequently Asked Questions

Why should load tests validate Cloud Bigtable performance if it is a managed Google service?

Bigtable's performance depends on your schema design, row key layout, cluster sizing, and access patterns. Google's own documentation recommends running your typical workloads against Bigtable for capacity planning, so you must validate it under load.

Why is running load tests against production or recording all transactions incorrect?

Running load tests against production risks degrading real users, and recording every production transaction for replay is impractical and raises privacy concerns. Load testing should use a dedicated isolated environment with synthetic or anonymized data.

More PCA FAQ →

Discussion 43 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 30 of 43

  1. rishab86 👍 35
    after reading link: https://cloud.google.com/bigtable/docs/performance A:Run your typical workloads against Bigtable :Always run your own typical workloads against a Bigtable cluster when doing capacity planning, so you can figure out the best resource allocation for your applications. B. Create a separate Google Cloud project to use for the load-testing environment F : The most important/standard factor of testing, you gather logs and metrics in TEST environment for further scaling.
  2. e5019c6 👍 10
    A: No. Not needed since it's a managed GCP product. It'll scale to satisfy demand. B: Yes. You could leave it in the same project as the app, but it'll eventually be deployed to production and be a risk if anyone accidentally runs it against prod. C: No. You musn't run load testing against prod. D: Yes. The capability of the third party systems should be tested. They are another link in the chain and if they are not up to the task, they may be replaced. E: No. There is no need to use real data in the requests, this is a load test, not a behavior one. F: Yes. Having detailed logs and metrics helps diagnosing problems during the tests.
  3. PeppaPig 👍 9
    AB&F Creating a separate project is highly recommended. It gives you total isolation from your product environment, and make sure it will not share the resources with your product env such as service quota
  4. jlambdan 👍 6
    Here is my take, I respectfully disagree with ya all :) A. Ensure that the load tests validate the performance of Cloud Bigtable Most Voted => not the requirement B. Create a separate Google Cloud project to use for the load-testing environment Most Voted => yes, you don't want to use production quota. C. Schedule the load-testing tool to regularly run against the production environment => yes please kill the prod ! D. Ensure all third-party systems your services use is capable of handling high load => well, that is what we shall test, so, it was more the task of the development team, not the QA team. E. Instrument the production services to record every transaction for replay by the load-testing tool => yes, this way you can build your test dataset with realistic behavior. F. Instrument the load-testing tool and the target services with detailed logging and metrics collection Most Vo => yes, otherwise you test for nothing, you have no data at the end to evaluate the system's performance.
  5. victory108 👍 5
    A. Ensure that the load tests validate the performance of Cloud Bigtable B. Create a separate Google Cloud project to use for the load-testing environment F. Instrument the load-testing tool and the target services with detailed logging and metrics collection
Show 25 more comments
  1. andras 👍 5
    why testing Bigtable... it's per definition of Google would absorb practically any load... don't you trust Google? :-)
  2. Kayceetalks 👍 4
    A. Ensure that the load tests validate the performance of Cloud Bigtable: This is essential. Your primary services rely on Cloud Bigtable, so the load tests must assess how Bigtable performs under stress (latency, throughput, error rates). B. Create a separate Google Cloud project to use for the load-testing environment: Isolation is key! A separate project prevents the load tests from interfering with your production environment and gives you better control over costs and resource usage. F. Instrument the load-testing tool and the target services with detailed logging and metrics collection: You need visibility! Without proper logging and metrics (e.g., request rates, error rates, resource utilization), it's impossible to analyze the results of your load tests and identify bottlenecks.
  3. Svar 👍 4
    ADF, A: Because if im using bigtable, is important test it too, D becuase if I don't do it the test could fail because a third cause, and F is obvious, I don't understand why you said B, I can use the same project for load test with different infrastructure and is completly right.
  4. AK2020 👍 4
    There is no relevance to D here. So ABF
  5. Ashii 👍 4
    I agree, should be BDF
  6. MrXBasit 👍 4
    Answer should be BEF
  7. rishab86 👍 4
    Answer should be BDF
  8. __INSIDEOUT__ 👍 3
    CEF. Not A: because the request il related to the requirements the test infrastructure shall have; the purpose is not to test Cloud BigTable but the specific application ! Not B: no need of another project (different VM is enough) Not D: that woud be a requirement of the developed application, not of the testing environment
  9. kopper2019 👍 3
    all New Questions released in June 2021 are in Question number 3 or share you email
  10. AMEJack 👍 3
    It is Google best practice to create a separate project for testing
  11. joe2211 👍 3
    Vote ABF
  12. MaxNRG 👍 2
    BCF 1) B - you need to have a separate project for Load-Testing tool. That would at least separate role based access - dev and test. Also, test will have their own code/project/config for testing, so no any chance of collision. 2) C - testing on production? because per Google recommendation, BigTable should be tested on production instances (not on development) and for at least 10 min / 300 GB of data. Check "Testing Performance with Cloud Bigtable" here. I understand this as a requirement for integration test for projects using BigTable. Testing of BigTable on Dev instances won't give proper results. 3) F - collecting of metrics would be useful anyway.... Why not A, D, E? 1) A - isolation testing of BigTable likely doesn't make sense, if anyway integration test will need to run. That's covered in C. 2) D - testing of 3rd party tools in isolated mode likely is a one time effort (only useful when upgrading these tools). No point to run them regularly. 3) E - collecting metrics on production env just to replay them on load-testing tool? What's a point? We need test max load anyway...
  13. omermahgoub 👍 2
    Why not B, C and E: B: creating a separate Google Cloud project to use for the load-testing environment, could also be a good idea by not necessary in order to ensure that the load tests do not impact the performance of the production environment. C: scheduling the load-testing tool to regularly run against the production environment, is not recommended, as this could potentially impact the performance of the production environment and could lead to unexpected behavior or issues. E: instrumenting the production services to record every transaction for replay by the load-testing tool, could also be a useful requirement, as it would allow the QA team to accurately replay real-world workloads during the load tests in order to more accurately simulate the expected production environment.
  14. omermahgoub 👍 2
    Answer ADF A: It is important to ensure that the load-testing tool is able to accurately test the performance of Cloud Bigtable in order to ensure that it can handle the expected load. D: It is important to ensure that all third-party systems that your primary cloud services rely on are able to handle the expected load in order to avoid any potential bottlenecks or failures. F: Instrumenting the load-testing tool and the target services with detailed logging and metrics collection can provide valuable insights into the performance and behavior of the system under test, allowing the QA team to identify any potential issues or bottlenecks.
  15. mikesp 👍 2
    I agree. It is important to verity that current BitTable cluster can deal with incoming traffic: A cluster must have enough nodes to support its current workload and the amount of data it stores. Otherwise, the cluster might not be able to handle incoming requests, and latency could go up. So although it is a managed service, it does not auto-scale.
  16. kiappy81 👍 2
    hi, in the sentence it's underline that you what to test the scalability of your primary CLOUD SERVICS, so I think that D is not required. For me it's ABF
  17. guzmanelmalo 👍 2
    The quota impact of not using an isolated project in a region with higher quota make me think about ABF
  18. david_tay 👍 2
    ABF for sure, even Gemini explains it correctly.
  19. Mahmoud_E 👍 2
    A, B, F are the correct answer
  20. surajkrishnamurthy 👍 2
    ABF is the correct answer
  21. khadar2001 👍 2
    From GCP practice test..
  22. AzureDP900 👍 2
    ABF is right
  23. Nad1122 👍 2
    It's ABF
  24. ryaryarya 👍 1
    It's ABF. You have to choose the size of your BT cluster, and you can easily structure your database in an inefficient way that would cause huge performance issues. Lower on the same page you link it says this: "Always run your own typical workloads against a Bigtable cluster when doing capacity planning, so you can figure out the best resource allocation for your applications."
  25. hitmax87 👍 1
    B (Separate Project): Isolation is a core cloud architecture tenant. Running aggressive load-testing tools requires enormous quotas and high network/compute consumption. E: For a load test to be realistic, it must mirror true user behavior rather than predictable, synthetic loops. F: Load testing is completely useless without comprehensive data capture.

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.

Multi-Regional vs Regional Cloud Storage for Global Software Downloads

S-grade

Surviving a Zone Outage With SQL Server on GCP

S-grade

Fixing BigQuery connection errors from a Compute Engine VM

S-grade

Moving 75 TB into Cloud Storage with Google-recommended practices

S-grade

Practice All PCA Questions

Access 81 questions with complete answers and detailed explanations.

View Full PCA Practice Test →

← Back to PCA Study Guide