Load Testing Requirements for GCE and Bigtable Services

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

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.)

Ensure that the load tests validate the performance of Cloud Bigtable Correct Answer
Create a separate Google Cloud project to use for the load-testing environment Correct Answer
Schedule the load-testing tool to regularly run against the production environment
Ensure all third-party systems your services use is capable of handling high load
Instrument the production services to record every transaction for replay by the load-testing tool
Instrument the load-testing tool and the target services with detailed logging and metrics collection Correct Answer

Answer Correct answer: A, B, F — 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.

Community Insight

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.

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.

Community Discussion (45 comments)

hitmax87 👍 1 Selected: BEF

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.

khadar2001 👍 2 Selected: BEF

From GCP practice test..

cloud_rider 👍 1 Selected: ABF

A - Validation of Big Table is correct B - Separate Project helps in ring fencing the test. F - To capture all the metrics

david_tay 👍 2 Selected: ABF

ABF for sure, even Gemini explains it correctly.

Kayceetalks 👍 4 Selected: ABF

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.

gcloud007 👍 1 Selected: BDF

The first line in the below doc reads ... "Bigtable delivers highly predictable performance that is linearly scalable. " then why do you need to test Bigtable performance... https://cloud.google.com/bigtable/docs/performance

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."

Nad1122 👍 2 Selected: ABF

It's ABF

e5019c6 👍 10 Selected: BDF

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.

guzmanelmalo 👍 2 Selected: ABF

The quota impact of not using an isolated project in a region with higher quota make me think about ABF

sampon279 👍 1

Don't think it would be this option: Ensure all third-party systems your services use is capable of handling high load. This is some extra information and we are not sure if the application in this question is even using any third party tools.

jlambdan 👍 6 Selected: BEF

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.

ductrinh 👍 1

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. lol you dont test on prd but still ned prd's records .... how can bro

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.

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.

surajkrishnamurthy 👍 2 Selected: ABF

ABF is the correct answer

Mahmoud_E 👍 2 Selected: ABF

A, B, F are the correct answer

andras 👍 5

why testing Bigtable... it's per definition of Google would absorb practically any load... don't you trust Google? :-)

AzureDP900 👍 2

ABF is right

alexandercamachop 👍 1 Selected: ADF

There is no necessary reason for running it in a separate project. A we have to test Bigtable. F Important to record all the outputs and be able to review it. D Important to stress test third party solutions or change it.

AMEJack 👍 3

It is Google best practice to create a separate project for testing

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

vincy2202 👍 2 Selected: ABF

ABF is the correct answer

joe2211 👍 3 Selected: ABF

Vote ABF

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...

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

PeppaPig 👍 1

You won't want load testing to consume the service quotas in your product project https://cloud.google.com/docs/quota

kopper2019 👍 1

hey guys new Qs posted as of July 12th, 2021, All 21 new Qs in Question #152

gionny 👍 1

Hi Kopper please send to [email protected]

firecloud 👍 1

Hi Kopper please send to [email protected]

k_grdn 👍 1

@kopper2019 - email [email protected] , many thanks.

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

kopper2019 👍 3

all New Questions released in June 2021 are in Question number 3 or share you email

Braindump 👍 1

Did any one got the new questions from Kopper? Plz share at [email protected]

gcpexam_ca 👍 1

are the new questions appeared in the real exam occurred after May 1st?

MrXBasit 👍 4

Answer should be BEF

__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

JustJack21 👍 1

Yes B because you don't want to disrupt production Not C because of the same reason.

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.

manhmaluc 👍 1

i also thing ADF is right answer

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.

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.

AK2020 👍 4

There is no relevance to D here. So ABF

Ashii 👍 4

I agree, should be BDF

rishab86 👍 4

Answer should be BDF

Comments & Corrections

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

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

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 →

Related Analysis

Practice All PCA Questions

Access 81 questions with complete answers and detailed explanations.

View Full PCA Practice Test →

← Back to PCA Study Guide