I still think that E should be in te answer, yes the bigtable will scale, but still you can make a wrong architecture inside bigtable that will not scale correct. https://cloud.google.com/bigtable/docs/performance

A, B , C

What a question! no consensus here.

F = not a best practice to run load test in production
E = in the real world, you would do that, but we are here to say GCP is awesome.
D = The reason I did not choose this is if you replay what you recorded in production you would not get to test scalability you would just reproduce the scenario you saw in production when you recorded (and that you already have)

@Robert I don't think about 'B' that load tests need detailed logging and metrics

Load testing the Bigtable is not necessary as Bigtable provisions and scales to hundreds of petabytes automatically and can smoothly handle millions of operations per second by default and it is completely Managed. so not E

Performance testing should never be done on prod environment. so not F


D doesn‘t make sense when the answer is not F. so not D


A - we might need to include test-cases to test the performance of third-party systems integrated to the application to able to handle the load.

B: Detailed logging might be good idea

C - Though it is not required to have a new project to use for the load testing environment, it is not going to hurt.

So, I will go with A, B and C

D, since we want to have the asame pattern as we have in production: "record every transaction for replay by the load- testing"
But you can see that all A, E, F is nonsense so only D remains with B and C.

Why D, when not testing the production env?

B, C, D since
A - meaningless here
E - Cloud BigTable has seamless scaling, no need to test this
F - don't ruin your prod system with loadtests