Your customer is receiving reports that their recently updated Google App Engine application is taking approximately 30 seconds to load for some of their users.
This behavior was not reported before the update.
What strategy should you take?
Your customer is receiving reports that their recently updated Google App Engine application is taking approximately 30 seconds to load for some of their users.
This behavior was not reported before the update.
What strategy should you take?
The most appropriate strategy in this scenario is to roll back to an earlier known good release to immediately mitigate the impact on users. Following the rollback, using Stackdriver Trace and Logging to diagnose the problem in a development, test, or staging environment is a sound approach to ensuring the issue is accurately pinpointed without impacting the live production environment. This method minimizes downtime for users and allows thorough investigation and resolution of the problem, preserving application stability while addressing the root cause.
C is the answer
Key word: This behavior was not reported before the update A - Not Correct as it was working before with same ISP B - New code update caused an issue- why to open support ticket C - I agree with C D - This requires downtime and live prod affected too
"then use Stackdriver Trace and Logging to diagnose the problem in a development/test/staging environment" they are NOT asking us to setup Dev/Text/Stage.. meaning the environment already exist and we have to use it
"then use Stackdriver Trace and Logging to diagnose the problem in a development/test/staging environment" this is not asking for set environment either, it just says to diagnose problem in other environment so C it is
"then use Stackdriver Trace and Logging to diagnose the problem in a development/test/staging environment" this is not asking for set environment either, it just says to diagnose problem in other environment so C it is
More Ambiguity, I'm defaulting to a balance between frugality and likelihood. "A" would only be necessary if the ISP(Internet Service Provider) was causing the problem, most ISPs provide an error response faster than 30seconds. "B" would work, but Google Support agents are expensive... up from $50,000 annually. "C" is the best option as it will allow the GCP professional to find the root cause of the problem without increasing customer costs. "D" is the same as "C" but is testing in the exposed code based, "D" should only be chosen if the customer is not paying for other code bases already.
C is ok
C is the best option.
I'll go with C. A does not seem reasonable because the problem happened after the update and is likely not ISP-related. B does not seem reasonable even if Support could assist because that would depend on your support level and doesn't take advantage of the tools you have available. C seems a reasonable first approach as it gets production back quickly and takes advantage of the ability to provision a cloud staging environment immediatelyh. D seems feasible but not desirable because it runs the risk of interfering with users again and imposes a delay.
Final Decision to go with Option C
C is very correct
1. Prioritize User Experience: Rolling back to a stable version quickly minimizes user impact and restores the application to a functional state. This should be the immediate first step. 2. Controlled Environment: Diagnosing the issue in a development/test/staging environment allows you to investigate without affecting real users. You can reproduce the problem, gather data, and test potential solutions safely. 3. Powerful Diagnostic Tools: Stackdriver Trace helps you pinpoint performance bottlenecks by tracing requests across your application. Stackdriver Logging provides detailed logs to understand application behavior and identify errors.
A (Incorrect): Problem began with new version; B (Incorrect): Problem is about latency - not traffic restriction. D (Incorrect): CI/CD Pipeline encourages easy rollbacks and troubleshooting in Dev/Test environment. C is the most appropriate way to diagnose and troubleshoot.
C is the correct answer
I'll go with C
I would choose D. Because Roll back to an earlier known good release initially, then install StackDriver for option C without install the updated app would not allow you to able to find the problems in the updated app. For option C it did not say it will then install the updated app.
C. Roll back to an earlier known good release initially, then use Stackdriver Trace and Logging to diagnose the problem in a development/test/staging environment A and B are not relevant D - no IT manager will ever allow re-deployment of erroneous code in production, even in a quiet period...!
I agree why not D, but in the past I faced issues only reproducible in prd, at that situation D was a possibility but usually yep C is for sure
Option C is also a valid strategy in this scenario. Rolling back to an earlier known good release initially and using Stackdriver Trace and Logging to diagnose the problem in a development/test/staging environment can help diagnose the issue without impacting production users. However, the reason why option D may be a better approach is that it allows for investigation during a quieter period, which can reduce the impact of any issues that may occur during the investigation. Rolling back to a known good release and then pushing the release again at a quieter period can help to ensure that users are not impacted during the investigation.
D is the answer
C is the answer
C is the answer
answer: C
Agree with C...
C is the answer
C, for sure. Roll back to an earlier known good release initially, then use Stackdriver Trace and Logging to diagnose the problem in a development/test/staging environment
C is the answer without any impact on user.
I would rather go with "B". Rolling back (as suggested in "C" & "D") without enough evidence or investigations could be not a good approach.
answer is C
C is ok
C. Roll back to an earlier known good release initially, then use Stackdriver Trace and Logging to diagnose the problem in a development/test/staging environment
I go with D. How can we recurrent the problem after rollback to a good former release? You should see nothing useful for the problem from Trace & Logging when you are running on a good release. C should be correct only when you have trace & logging always on for the period this problems happened, which is not mentioned in the question and not practical as the cost may surge if you are running a busy service.
choose C
C is the answer.
C is the answer
should be C
Although it sounds like the right answer to do network tracing in stg again, this may be a network pass-through related issue and it is felt that the problem may not be reproduced if not checked in a prod environment.
I'm going for C. While D may be "better" in case this is an issue that only occurs in production, I think that keeping the disruption at minimum would be the best practice, which D would not really do. Plus, if the problem is load related, having this released at a quieter period may not surface the problem either.
Agree with option C
C is more meaningful.
seems like a C. don't want impact customers before it is tested well.
I'll go with C
I go with C
application is taking approximately 30 seconds to load for "some of their users" not All ! So in my opinion , we would want to get hold of the network and data flow log evidences before rollingback. Testing in lower environments might not always work unless you have like to like env , and might not be even able to replicate the issue. Guess "B" would be the right option
i will go with C
C: Correct answer App engine gives flexibility to roll back to previous version. Priority should be restore the services to working state. And trace the issue using Stackdriver where the logs are already captured from previous failed service.
Why C is correct is there should be an assumption made by the author that new release will be deployed in the dev/test/stage environment. Otherwise C doesn't make any sense here.
C is the ans For all those calling for D , the option dont tell they will install stackdriver, but will use it to analysie the logs. Then deploying back the faulty code without fixing does not make sences.
C is the only answer
Go for C
C is the correct answer
Answer is C
The correct answer is c.
How come everyone is agreeing to C!! In option C after rollback, the investigation will happen only on the earlier good release. Whereas in option D, all the troubleshooting will happen on current/problematic build. Option D should be the right option as it resolves the issue in short term and provides room for further investigation without downtime.
Option C is investigating the bad build in test. The problem with option D is it is user impacting. Always best to attempt to find the problem in a test environment first. D could end-up being an option of last resort if all attempts to diagnose in test fail but I doubt any business person would be happy with D as it impacts service.
you want to minimize the business loose, best option is to rollback and use stack-driver to diagnose the issue
correct answer is C use the standard practise
C is perfect to troubleshoot latency issues with app
C is the correct answer
ok for C
Although it sounds like the right answer to do network tracing in stg again, this may be a network pass-through related issue and it is felt that the problem may not be reproduced if not checked in a prod environment.
Your customer is receiving reports that their recently updated Google App Engine application is taking approximately 30 seconds to load for some of their users. This behavior was not reported before the update. What strategy should you take? Here the application (our code) is updated and only some users are facing lantecy (Cloud Trace) issue. The issue is not with ISP (A), Not an issue with Google (B). Rollback must be done as mitigation, but testing should be done in Non-Prod environments (C), not on prod environment (D). Hence C is correct answer.
C is correct
C provides all options to provide and backup this situation.