Ans is B

B is the correct answer Error code starting like 5xx is something related to server 503 UNAVAILABLE Service unavailable. Typically the server is down.

Its very common that the Gateway goes down and throws 503 if the load on the server is beyond limit. Performance Bug is a good option but it will take a lot of time. Its always better to start debugging from the "step-1"; checking the project quota will be faster, hence, I go with B

In my opinion C

I vote for C

B. "What should the team investigate first?" Quota limits are easy to check, and considering the scaling issues this could be the cause even though Google Typically responds with a 429 to 'over Quota' issues. Checking for bugs can be very time consuming, especially if the bugs are related to scale or are intermittent. Go with the first easy thing to check... B.

Such symptoms occur when servers are overloaded which might have caused because of load testing. hence option D would be first thing I would do before I go into deep details of analyzing performance bug.

It cannot be A or B for Sure. If you exceeded a quota value with an HTTP/REST request, Google Cloud returns an HTTP 429 TOO MANY REQUESTS status code. Still not sure between C & D. Will prefer D. Any thoughts?

for me it's C. 503 is service unavailable, for quota problem in GCP we get 429 (https://cloud.google.com/docs/quota/troubleshoot : If you exceeded a quota value with an HTTP/REST request, Google Cloud returns an HTTP 429 TOO MANY REQUESTS status code.) A. Verify that the database is online - if db is down it would be down for all users B. Verify that the project quota hasn't been exceeded Most Voted - quota error is 429 https://cloud.google.com/docs/quota/troubleshoot C. Verify that the new feature code did not introduce any performance bugs - performance issues would translate into latency issue and possible 503 D. Verify that the load-testing team is not running their tool against production -

I think D is the correct one. A couldn't be because all players would get the error, not only a few. B I don't think it is because the Business objetives tell us that they want to scale globally. Setting a quota would limit their scalability to reduce costs, and the CFO didn't set any cost-reducing objectives. C is a good one to do, but would not be the first one. Searching the code for bugs is a task that would take long hours to complete, so I would do it only if the firsts and obvious checks didn't find anything. That leaves D as the first thing to check before going with C. Discarding A & B.

There has been new feature implemented last month, when the requests reached new level the infra didn't scale well anymore, I will first investigate that feature didn't cause performance issues or memory leaks.

It is B. They key here is "...which suddenly became very popular." Which might have caused a quota limit issue all sudden.

I think it should be D. Load testing should not be done in Production and if it is getting dome there and actual high traffic comes from users then application will crash.

my focus is 'quickly investigated first' - quota is the easiest and quickest to check

For me its both B & C, but since quota verification is simpler and can be done quickly, they should start there. (keyword: "What should they investigate first?")

For me is C. There is no reason to think about quota limit. Instead, is clearly that a new feature was released and from that there are errors.

A is the only one I think can be 100% ruled out as it says "..and very slow reasponse times", I think a DB down would just get a 5xx. B, C & D could all cause the problem being experienced. The only reason I can see B being the most correct is because it's easy to check and maybe more probable than D.