Why Performance Bugs Appear Only in Production
Ensuring the reliability of solutions in production (e.g., chaos engineering, penetration testing, and load testing)
Evaluating quality control measures
Deployment and release management
Your solution is producing performance bugs in production that you did not see in staging and test environments. You want to adjust your test and deployment procedures to avoid this problem in the future. What should you do?
Answer
Correct answer: C — Increase the load on your test and staging environments so performance bugs surface before production.
Community Insight
The question tests whether your test environment realistically mirrors production load; the trap is picking canary rollout (D), which limits blast radius but may never generate the traffic that triggers the performance bug.
This PCA question tests how to fix test and deployment procedures when performance defects escape to production. It establishes that raising load in test and staging environments (option C) reproduces production conditions and catches performance bugs before release.
Option D (canary rollout to a small subset of users) is the most-chosen wrong answer: it only narrows the impact and still puts real users at risk, and a small user subset typically does not reach the load level that exposes performance bugs.
Community Discussion (214 comments)
hitallo
👍 1
Selected: C
Deploy changes to a small subset of users before rolling out to production WILL NOT AVOID bugs in production. So by elimination, the answers should be C.
tim777
👍 1
Selected: D
D because Canary Deployment, Not C because load testing in staging does not capture all the complexity of the production environment.
WayneHsu
👍 1
Selected: D
D is the answer.
Wayne90040
👍 1
Selected: D
D is the answer
Johnb9682
👍 1
Selected: C
Should duplicate the production like env in staging
CyberPeter
👍 1
Selected: C
Question ask to adjust test environment, not to fix production bugs, so C
Dusan93
👍 1
Selected: D
D is correct
mahi_h
👍 2
Selected: D
I am going with the key words in the question "adjust your test and deployment procedures", Increasing the load on test/stage env does not realistically adjust any test procedure. Besides that, in my experience as Infra SME, we never design capacity of non-prod environment same as prod (always 50% or even 25%), so amplifying load will not provide "production" like behavior. Option D sounds like making "adjustments" in your procedure.
khadar2001
👍 2
Selected: D
confirmed from practice Exam
Yass92
👍 1
Selected: C
performance = load
halifax
👍 2
Selected: D
No matter how efficiently you load tests in the development stage, you will never catch 100% of possible bugs. This is why CI/CD was invented (option D: continuous development).
hpf97
👍 1
Selected: C
I have that king of questions as C and D would be correct. But as it is said to "adjust", I would prefer C than setting a new canary deployment strategy. Furthermore in case D would a small set of users rises up the performance issue ? not sure.
RVivek
👍 1
Selected: C
Performance Bug (not functional). Hence increasing the load on test environment will help to identify and ifx the bugs
deep316
👍 1
Selected: C
Bugs are related to performance. So you would need to perform performance testing thoroughly.
Daniaw
👍 2
Selected: D
C could be correct but this can help identify performance bottlenecks, but it might not fully replicate the complexity and unpredictability of real-world production traffic. So D is the most correct one.
alihabib
👍 1
Selected: C
"Performance" bug, not a "Development" Bug, so it more aligns with C, to increase the load to determine performance related bugs
drinkwater
👍 1
I think the right answer here is D. It applies a best best practice of the release managment like canary deplyments. Why is not C; adding more load in staging and testing environments can help identify some performance issues, it is often impossible to replicate the exact conditions of a production environment.
Ekramy_Elnaggar
👍 1
Selected: C
Guys, you need to focus on the KEYWORDS in any question, it will help you to determine the best answer. The keyword for this question is "Performance", it is very clear that the load test on stage was not planned correctly (i.e/ lower than it should), so the performance bugs didn't appear, but when it comes to production with much bigger load the issues appear.
nareshthumma
👍 1
C & D both works but D make sense
dfizban
👍 2
Selected: D
It's D
maxdanny
👍 2
Selected: C
C because The performance issues in production might not have been seen in staging or test environments because the load (number of users, transactions, data volume, etc.) in those environments is not representative of the load in production. By increasing the load on your test and staging environments to match or exceed production levels, you can better simulate real-world conditions and catch performance issues before deployment
Hungdv
👍 1
I will choose D. C: The question does not say the error caused by the load.
Haigk
👍 3
Selected: D
Without overthinking the wording, canary (and similar) deployment methodologies are often recommended in Google documentation, whereas increasing load in dev environments aren't. (My $0.02...)
alihabib
👍 3
"Performance" bug is a result of Load
a2le
👍 1
Selected: C
Me too! I can't see how a "performance bug" might be mitigated via a canary deployment. However, I see that C doesn't cover the "deployment" part of the question, then I deduce that the question is ambiguously formulated.
Robert0
👍 1
Selected: C
Although all answers can be good practices, I think only option C address the problem described.
santoshchauhan
👍 2
Selected: D
D. Deploy changes to a small subset of users before rolling out to production. This approach, known as canary releasing or canary deployment, involves rolling out changes to a small group of users before deploying them to the entire user base. It is a very effective way to catch performance issues that might not have been apparent during testing. C. Increase the load on your test and staging environments: This is definitely a good practice, as it can help simulate production-like conditions more closely. However, it may still not capture all real-world scenarios and user behaviors that can lead to performance issues.
Patrick2708
👍 2
C looks good to me
MahAli
👍 6
Selected: C
Canary deployment is perfect to test new feature but to do stress testing, I do development for 25 years, when we want to resolve performance and scalability issues we do stress and load testing in pre prod environment, something you can't do by exposing the new feature to subset of users.
MarekPL
👍 2
Selected: D
as for C: synthetic load may not cover all scenarios. For D obviously we need to have monitoring in place to see if e.g. system load or response times increased after canary deployment
Prakzz
👍 1
It talks about test and deployment Procedures NOT Environment. Answer is D
yilexar
👍 1
It is really about Canary deployment
jrisl1991
👍 4
Selected: D
I'm going for D. According to ChatGPT: D. The best approach to avoid performance bugs in production that weren't detected in staging and test environments is to gradually roll out changes to a small subset of users before deploying them to production. This way, you can identify and address any issues that may arise in a controlled environment before affecting all users. Why not C: Increasing the load on your test and staging environments, as suggested in option C, can be a valuable strategy for detecting certain types of performance issues related to scalability and load handling. However, it may not address all types of performance bugs or issues that are specific to the production environment. A and B seem a bit obviously wrong. A is incorrect because it would be incompatible with CI/CD, and deploying fewer changes may still introduce bugs regardless of the low frequency. B would help root causing, but may also introduce new bugs that are exclusive to production.
Gregwaw
👍 3
Selected: D
From the question we don't know anything about reasons of performance problems in production environemnt. We also don't know anything about tests that were performed in test in staging environments. There is no reason to believe that load in test environment is not sufficient. It is always possible that some performance problems occurs only in production environment. It is also not economically reasonable to reproduce full production load in test environemnt. Taking all of this into account I am incling to answer D.
duzapo
👍 1
C if you test with a subset group of users you cant test the performance properly
Johnny_K35
👍 3
Selected: D
It says bugs "that you did not see in staging and test environments" so should be D
rescolar
👍 1
Bard says it's C so everyone saying D back off inmediately.
DA95
👍 1
Answer is D https://www.devopsdigest.com/bugs-in-production-how-to-avoid-unpleasant-surprises
PKookNN
👍 3
Selected: C
Since this is a performance bug, more loads in test and stage would help
oriori123123
👍 3
Selected: C
The correct answer is C
Atanu
👍 1
The question asks about test and deployment procedures and option D is the only option covering deployment as well. And deploying to small subset of user will cover the real time testing scenario as well. Seems Option D quite close.
salim_
👍 2
Selected: D
It's canary deployment to reduce the impact on users in case of issues & bugs.
Zimcruza
👍 1
How can rolling out to a small subset of users in Prod help if that generates a load that does not reproduce the fault? The only way to determine the root cause is to use environments where your end-users are not impacted - and Staging is where you should mimic Production workloads and processes
Nidhal1920
👍 1
Both C&E are correct , but since we have this requirement "You want to adjust your test and deployment procedures" , if we choose "C" we don't adjust our deployment procedures.. So by elimination I'll go for "D".
naless
👍 1
If the issue is about performances I can't see how D could be the right choice, since deploying changes to a smaller subset means decreasing the number of users and therefore the issue could never arise.
h7m
👍 2
Selected: C
You want to avoid this problem, which you can only do if you load test it in a test environment. With a, b and d you might find the problem and the solution faster (or not since it's a performance problem), but you do not avoid the problem.
mifrah
👍 2
I go with C: Increate the load. Question is: You want to adjust your test and deployment procedures to avoid this problem in the future. To find performance bugs, I need requests to my application. Deploy changes to a small set of users, might not trigger the performance bugs. So, no benefit.
wisnu_ink
👍 2
The keyword is "performance bugs in production that you did not see in staging and test environments" so D should be the answer
JC0926
👍 3
Selected: B
This issue is likely a result of a difference in the environment between your staging/test environments and your production environment. Smaller changes in production deployments allow for more granular control of your infrastructure and are generally easier to troubleshoot in the event of issues. By deploying smaller changes, you can more easily identify where the issue is and reduce the likelihood of encountering performance bugs in production.
MestreCholas
👍 2
Selected: C
C. Increase the load on your test and staging environments. One possible reason why performance issues may not be caught in staging and testing environments is that they may not be subject to the same load as the production environment. By increasing the load on the test and staging environments, you can more accurately simulate the conditions that the system will be operating under in production, and thus be more likely to catch performance bugs before they make it to production. Deploying fewer or smaller changes to production may help reduce the risk of introducing bugs, but it may not necessarily catch performance issues that only occur under high load. Deploying changes to a small subset of users before rolling out to production (also known as a canary deployment) can help catch bugs before they impact the entire user base, but it may not necessarily catch performance issues that only occur under high load.
giovanicascaes
👍 1
Initially I've chosen C, but actually D is the correct option, as the statement claims to "adjust your test and deployment procedures", not "deployment environments".
Deb2293
👍 1
Selected: C
A & B are the same so rejected. D is rejected as prod bugs would still be faced by users (also it's not like A/B testing). Hence it's C. You need to improve stage testing
gcpprofessional
👍 1
C. performance improvement
PST21
👍 1
If it is a performance bug (assumption -load testing) then deploying to a small set of users may or may not help. This needs to be load tested in test & staging hence C.
vinayvinay3
👍 1
Selected: C
goal is to detect performance issues
sameer2803
👍 1
people are missing the keyword "test & deployment procedure" which relates to deployment on production. its about handling the procedure in a different way. so D fits well. Option C will only help with "test" environment and not with "& Deployment Procedure".
Yaa
👍 1
Selected: C
if one thinks logically, C is the only correct answer that will really lead to a reduction in such issues.
omermahgoub
👍 2
D. Deploy changes to a small subset of users before rolling out to production One way to mitigate the risk of deploying changes that may have performance issues in production is to first deploy the changes to a small subset of users before rolling them out to the entire production environment. This approach, known as "dark launching" or "canary releasing," allows you to test the changes in a real-world environment and identify any potential issues before they affect the entire user base. Other options, such as deploying fewer or smaller changes to production or increasing the load on your test and staging environments, may not be effective at preventing performance issues from occurring in production. It is important to thoroughly test changes in a variety of environments before deploying them to production to ensure that they will function as expected in the live environment
greyhats13
👍 1
Selected: C
it is regarding the performance. So C must be the answer.
jaxclain
👍 4
Selected: C
If you watched the Design Material from the PCA course, you will remember one of the videos where they recommend to increase the load on your test/staging to instead of just having a small test to because the more you test, obviously you will have more chances to find bugs that will not be found it you do a small test so once you go live and the load is high, of course the bug will be there but you can prevent by giving more load against the app during test/staging so yes, Option C is correct.
jaxclain
👍 1
And also on top of doing this, option D will follow (Canary Deployment) so you can Deploy to a small subset of users but for the question itself the correct answer is C :)
AniketD
👍 2
Selected: C
Correct answer is C
ashrafh
👍 1
Selected: C
If its a performance bug then how can we test it with small set of user by implementing canary deployment(which is option D)?. So I choose C as a answer.
ajbot
👍 1
It's D C is not correct because adjusting resources in non-production environments wouldn't guarantee that your can recreate production issues.
salisali
👍 1
Selected: C
I think the option "C" is correct cause you should so many test before passing to production
Aninina
👍 1
Selected: C
The question is asking about changes in "test and deployment procedures ", so C is the correct
0xE8D4A51000
👍 2
Selected: C
C - question states it is a performance problem Therefore load testing will expose such issues in the test and staging env
Nuwan_SriLanka
👍 1
Selected: D
As per the story they have tested well in non-prod environments, and the bugs in the production is unexpected. To cater these issues we should go with canary deployments where smaller set of users are being tested.
zr79
👍 1
measure your performance by using load tests on your apps Answer is C
AzureDP900
👍 1
C is appropriate to catch the bug in lower environment, D just kind of canary release
minmin2020
👍 1
Selected: C
C. Increase the load on your test and staging environments - The whole purpose is to test a production-like load....
prekair0
👍 3
Answer is most likely D. Since it says: "You want to adjust your test and deployment procedures to avoid this problem in the future." so we are talking about a change in procedure, not about increasing capacity of the same procedure.
BubblesMind
👍 2
The solution is producing performance problem on production, then how can testing with smaller subset of users help. So, I think it can not be D. C seems more appropriate.
abirroy
👍 1
Selected: C
Answer is C. not sure why people voted for D. D wont do RCA.
Amit_arch
👍 1
Selected: C
Canary rollout can not find performance issues. Because moment you rollout to full userbase, performance issues will crop up. Therefore right strategy to detect production performance issues is to properly load test the application in stage.
n43jl
👍 1
Selected: C
D does not help to reveal performance bugs, so "C".
gee1979
👍 2
how would you replicate a "performance bug" with a small subset of users? secondly, a canary would make the test and dev environment redundant...
Jay_Krish
👍 3
Selected: C
I tend to think it is C although D also looks really like a good solution too. The keyword that caught my attention is the question asks "You want to adjust your test and deployment procedures.." so the action has to be anything that is done on these environments so I go with C.
Jay_Krish
👍 2
On the other hand reading the question again I feel it should be D because the problems in prod and not seen in Dev environment. And we aren't sure that the problem is load related in prod.. it could be various other reasons which can only be analyzed by replicating the error with a small subset of users.
chickennuggets
👍 2
Answer is C- proactively changing in test to avoid in prod - small subset rollout doesnt mean it will capture issues with larger load
AashishAggarwal2000
👍 2
D. As this gives the flexibility to first test with smaller set of users to ensure zero functional issues and then gradually increase to larger user base to insure zero performance issue.
kiappy81
👍 3
here the question says that you have PERFORMANCE bugs that you cannot see in previuos environments. how can you detect the performance bugs/issues if you introduced to small group? with canary tests (D option) how can you replicate the performances?
michael_m
👍 1
I like this explanation
sgofficial
👍 3
Selected: D
You want to adjust your test and deployment procedures(kindly note here they its not environment) to avoid this problem in the future. ---- they are talking about test and deployment strategy which is canary deployment where we can test the application in production load for limited users
sgofficial
👍 2
I would go with D, its canary deployment strategy -- where we can see for some users(small set of production users 10% traffic), if no issues with this 10% users then release to 100% traffic
n_nana
👍 2
Option D: cannot detect the performance bugs/issues as it is also introduced to small group. Answer is C
deenee
👍 2
Selected: D
Canary approach is used for both testing and deployment in prod for subset of users. Since same behavior was not observed in test environment, it might be good idea to check it in PROD with subset of traffic - again as per documentation load has to be almost same in both canary and baseline version to compare the performance.
tino_teraflow
👍 1
Selected: D
The answer is D. D covers both testing & deployment procedures, by releasing a canary build & testing on a subset of users. The small percentage of users acting as testers for feedback.
szanio
👍 1
For me is D
Superr
👍 1
Selected: C
we need to tweak non-prod envs
amxexam
👍 1
Selected: B
We are talking about performance bug hence B over D . D would be valid if functional bug
amxexam
👍 1
Selected: C
We are talking about performance bug The only way to replicate then is create same load and in staging and test environment. I would go with D if they where functional bugs. Hence C.
Novice2unlearn
👍 1
performance means doing what is intended. If not performing means not doing that. Load is about capacity. So I think "D" deals with testing with users to see if the changes can "perform" as intended for the users.
potorange
👍 1
Selected: D
D. Will help identifying problems pertaining to production env that even higher load on other envs could not uncover
juanbc
👍 1
Selected: D
I Agree on 'D', since 'C' is assuming that the failure is the lack of load on stage. However in order to investigate something you can't start by assuming stuff. I chose 'D' since it'll be a good method for investigation.
YAS007
👍 3
from the question, the problem is "performance bugs in production that you did not see in staging and test environments", therefore, I guess that there is more load in prod than in test and staging. the other part of the question said : "You want to adjust your test and deployment procedures to avoid this problem in the future." so, the action has to be taken in test environment so : A : incorrect (action taken in prod B: same C: correct, will try to simulate prod load + action taken in test env D: incorrect, because, bugs are not due to users,
Nirca
👍 2
Selected: C
I think the challenge here is performance issues. Only to be present in production. Not functional bugs.
pakochiu
👍 1
Selected: D
bugs in production that you did not see in staging and test environments <~which mean answer C is not helping, so would be D
Nirca
👍 1
Performance bugs. Not functional issues.
welkinwalker
👍 1
Selected: D
A and B are the same. Since only part of the relaease is updaed, this may not reproduce the original problem. C may not reproduce the problem, since the root cause might coming from the load test data and the data in the produnction environment which not exits in the test and staging environment. So, whatever load you do in the test envionment, is just do not work.
Meyuchito
👍 2
Why not C? Because if there are bugs that you don't discover with the actual tests you made, increasing the quantity of tests will not make them appear. It's just more of the same. You have to change the way you are doing things!
slars2k
👍 2
I go with C as the issues are around performance and one may not be able to catch them by rolling out to small subset of users, the canary way. Hence D is ruled out.
kapara
👍 1
How is C is the answer? the question does not mention anything about staging ENV. the question clearly states that the adjustments are to be made for the test AND deployment ENV to avoid the issue. I would rule out C just for mentioning "increase load on test and STAGING" as we do not use and stg ENV in the context of the question. Correct answer should be D.
mary72
👍 1
The answer is D
ahsangh
👍 2
Selected: D
canary
Davidik79
👍 4
Selected: D
The answer must be "D". I assume that any architect roughly knows the number of requests per minute of their applications, the peak time, etc... Load tests would be done accordingly. Therefore, if you did not notice this in the test/staging envs, it means that something in production effects the performance issues, and the Canary deployment approach helps you to observe the application in the prod env before to hit the wider audience
GARY1119
👍 2
Selected: C
It is about load in production.
RJDBA
👍 1
performance related issues or not always related to load, an improper where clause on a column with no index can have a huge performance problem. so testing it on few users makes sense. i agree it is tricky question but "Performance" is what throwing off and making to lean towards load testing. so i believe D is the correct answer
KevPinto
👍 2
Selected: C
The Challenge here is to address Performance and doing it by adressing test and deployment procedures - This clearly indicates that loads in test need to be increased to simulate Live traffic
sjmsummer
👍 2
Selected: C
load is related to preformance. Select C.
kkhurana
👍 1
D is about both test and deployment strategy . Canary does support QA in production and deploy conservatively. I think right answer is D
Moss2011
👍 1
Selected: C
The sentence mention "how to adjust TEST and STAGGING" not the best practice to deploy
Charanjit
👍 1
Answer should be D as it is talking about Canary test pattern. Have a look the diagram in below link and read about it more in this link: https://cloud.google.com/architecture/application-deployment-and-testing-strategies#canary_test_pattern
vincy2202
👍 1
Selected: C
Correction. C is the correct answer. If the performance issue is the key reason, then how come with small set of users in production (canary deployment) be able to simulate this ?
MF2C
👍 3
Selected: D
canary is way of testing and deployment
StelSen
👍 1
My answer would be C. Because with the smaller user load in production might not produce the performance bug. Also playing around in production for performance bug is wrong choice. However I can still increase more load in test/staging env and play with test/staging env.
ABO_Doma
👍 1
Selected: C
Canary deployments will not identify the issue in testing
phantomsg
👍 3
Selected: C
The problem is that performance issues were not caught in test and staging environments. It may be due to insufficient load during tests. To improve the situation, we need to catch performance issues in test and staging environments itself. For that, one way is to increase the load so that issues show up before production itself.
pakilodi
👍 3
Selected: D
D. Canary rollout
haroldbenites
👍 1
Go for D
duocnh
👍 2
Selected: C
vote C
vincy2202
👍 1
Correct answer is D.
fwfw
👍 1
D https://cloud.google.com/architecture/application-deployment-and-testing-strategies#canary_test_pattern
MaxNRG
👍 3
D or C (prefer D) D – deploy changes to a small subset of users before rolling out to production. D is most likely, assuming that staging/test env provides an equivalent load to production. If this is not a heavy load case, then that’s smth else, an unaccounted bottleneck in production. In this case D would work perfect. C would be right if the problem is caused by heavy production traffic. In this case, an increase in test load will solve the problem. But, since Q asks for changes in “test and deployment” procedures, then D will be most probably answer – canary releases.
raj1984
👍 3
correct answer is C, this is a performance bug, do a load testing in the lower environments to identify the issue.
PeppaPig
👍 4
I go with D. As a developer I can tell that In real life some performance issue only happen in production no matter how much load testing you perform in test and staging.
_warrior_
👍 3
Question talks about performance issue, D would not help in identifying performace issue because it would make available to all users , C would be correct answer ,as we have to indentify performace issue.
selected
👍 2
C. because it says "You want to adjust your test and deployment procedures" so increasing the load is the way to go, canary imply prod changes
aviratna
👍 5
C: Is the correct answer as problem statement is performance issue in production. D: Is not the right answer as its talking about releasing the code to small batch of users which only delay the performance issue from happening but will not avoid it. Application needs to be tested with load similar to production to identify the issue early in test & staging environment before pushing it to production.
sebafranek
👍 2
That should be at the top of answers. It's all about PERFORMANCE.
certificationjjmmm
👍 4
it is a performance issue. So the answer is C
victory108
👍 1
D. Deploy changes to a small subset of users before rolling out to production
victory108
👍 3
C is correct --> Increase the load on your test and staging environments
un
👍 2
I would go with D
Ausias18
👍 2
Answer is C, the question is talking about performance, if we deploy to small number of users we won't see the bug errors
lynx256
👍 3
IMO - C os ok. D (canary) will not help "to adjust your test and deployment procedures" concerning "performance bugs " (it depends of app, of course, but as a rule).
michael_m
👍 1
It has nothing to do with the "performance bugs"
Pokchok
👍 1
But they are asking in the context of - in future
guid1984
👍 1
IMO Answer should be D as google says move/analyze(canary) and then scale if needed. It will also save costs and also avoids over-provisioning of resources.
guid1984
👍 1
Correction here question is asking specifically about performance issue and not a bug that is introduced due to regular prod deployment. C seems to best fit in this situation.
Rightsaidfred
👍 2
Ans is C
ahmedemad3
👍 1
Sorry Ans: C it is related to load test for performance issues
ahmedemad3
👍 1
ANS:D https://cloud.google.com/solutions/application-deployment-and-testing-strategies
bnlcnd
👍 1
C sounds right. D sounds right too. Seems only D is about "deployment procedure". So, maybe D. Real life is always different with taking exam. In real life, I will do more than C+D. But this is just an exam. You gonna be keen to guess what the tester is trying to lead you to think what they think. LOL.
HBM
👍 3
Correct is C
Prakzz
👍 3
Given that it's a performance bug. Load testing is necessary before production release. Hence C
MaverickSri
👍 1
the question says 'in future'...nothing to do with current adjustments - so 'D' makes more sense
avik_ibm
👍 1
It also says you want to change dev and test plans.
Khaled_Rashwan
👍 2
Answer is D The choice should in the scope of "adjust your test and deployment" A, B are part of the development not testing or deployment. C is part of testing only not deployment D is part of the deployment but also it inherit testing by a small portion of users
michael_m
👍 1
I totally agree
trainor
👍 5
So I think C is better.
occupatissimo
👍 1
keep in mind canary is a testing strategy !! should be D?
gautam23
👍 9
U should copy and paste TarTar... what a lame logic. Noone is perfect. Please understand. C looks like a better option to me as performance is the issue and customer is unable to find the same in Dev and Test scenarios. So scaling up might help. U may disagree and thats fine
trainor
👍 4
Deploying changes to a small subset of users wouldn't provide enough load to highlight performance bugs. Also, we'd notice the bug once in production (even thoug for a small number of users), not satisfying the requirement "to avoid this problem in the future". We'd be faster to fix them with a rollback, though.
hems4all
👍 1
C As explained above, the most likely cause of the performance issue in production is the higher volume of requests, so your best bet is to run a similar volume in your testing environments to identify and fix such issues before deploying in production.
venkik555
👍 3
I would choose option C. We can exclude A and B. Now we have only C and D. We can not choose D, the reason is you will not know the performance if you expose your code only to small subset of users. This approach is helpful to test functionality not performance. Hence i will go with option C.
brbep
👍 2
D is ok. "In canary testing, you partially roll out a change and then evaluate its performance against a baseline deployment..." https://cloud.google.com/solutions/application-deployment-and-testing-strategies#canary_test_pattern
LoganIsh
👍 2
in reality specifically banking clients the performance testing environment like prod-1 or UAT 1 environments were sized more than 50% and make sure closer to the production and test the workloads. thus looks like C is the right pick.
LoganIsh
👍 2
in reality specifically banking clients the performance testing environment like prod-1 or UAT 1 environments were sized closer to the production and test the workloads. thus looks like C is the right pick. more than 50% load and make sure
francescogugliottagm
👍 10
With canary deployment we expose the new version to a small portion of users. With this approach maybe we don't see performance bugs in the canary release, since we don't have the 100% of traffic on the canary. But when we migrate the 100% of traffic to the new release (previous canary) we can see performance bugs.
kimberjdaw
👍 1
B is the definition of a microservice architecture, which deals with small deployable units. However, since a is a synonym for B, and you can only select one, both are out. C has nothing to do with anything. Thus D, even though it's incomplete.
AshokC
👍 1
https://cloud.google.com/solutions/application-deployment-and-testing-strategies
AshokC
👍 1
C - Increase the load on your test and staging environments C or D? D - the reason being the canary approach is one of the standard ways of the rollout in production. Also, performance bug may not be only code related, it may be due to some environment infrastructure in Production and hence not reproducible in the test , staging env.
AshokC
👍 1
C is correct
dayody
👍 1
The correct answer is C
wiqi
👍 1
1) The bugs are performance 2) Need to adjust test & deployment procedure. A & > the code will to production will have the same performance impact. C. Fixes the performance factor and test and staging environment D. Deploying to small subset wont give any performance feedback. because the number is small.
haidertanveer0808
👍 2
I will go with D , the reason being canary approach is one of the standard way of rollout in production. Also performance bug may not be only code related , it may be due to some environment infrastructure in Production and hence not reproducible in test ,statging env.
khadar
👍 1
correct since the issue can't produced in test and staging only option is to test with a set of PRD users.
sou123454
👍 1
C is right answer .
certificatores
👍 12
if you want to pass the test, trust tartar's answers. to support his claim, check this https://cloud.google.com/solutions/application-deployment-and-testing-strategies#canary_test_pattern Canary test pattern In canary testing, you partially roll out a change and then evaluate its performance against a baseline deployment, as the following diagram shows.
elnagmy
👍 2
the question say " You want to adjust your test and deployment procedures to avoid this problem in the future." so they need procedures for both test and deployment so we should chose both C and D
pupi08
👍 1
You can have a perfomance bugs also with one user logged: just thinking to a not optimized sql query. So D should be right!
mexblood1
👍 3
If that's the case you would have see that in staging and test also.
Gobblegobble
👍 4
D could detect functional issues not performance bug. Since question is related to performance issue correct answer is C
nezih
👍 4
This is about performance issue and testing the app with small group won't reveal the performance bug. D is not correct, I'll go with C
cetanx
👍 8
Canary testing sounds like a good approach but performance is the problem here so therefore redirecting 10% of users to new release may not help you to test the performance thoroughly. So I'd vote for "C"
mlantonis
👍 1
D, because it is called Canary Deployment.
Pupina
👍 2
C for sure
Tushant
👍 1
D is the right answer.
bubai01
👍 3
C The question clearly mentions performance bugs . D can't test performance bugs but code issue .
Nirms
👍 2
D is the correct answer
Ziegler
👍 3
I'll go with C because the question says "You want to adjust your test and deployment procedures to avoid this problem in the future ..." So that mean the scope of the answer is around test and staging not being rouged enough to catch the error being noticed in production. C, please
SudevG
👍 3
Question is about adjusting test and deployment procedures/strategy... so i believe C is better option to identify performance bottlenecks early
AD2AD4
👍 3
Final Decision to go with Option D
wazza88
👍 3
I think C is correct, the key is 'Performance Bug' in Prod, which essentially means performance issues at Prod size load, so the way to recreate the 'Bug' is to simulate a load with increased size comparable to production.
Rathish
👍 4
You want to adjust your test and deployment procedures to avoid this problem in the future: Instead of deploying at one go, deploy to few users and see the response and monitor the system, then proceed with entire roll-out. Its one of the best practise to test it for smaller number of users in production. The question talks about test and deployment procedure, not the test & stag environment, any changes to these environment, does not guarantee of occurence of this bug.
laksg
👍 1
D is right . Canary
gcp_aws
👍 1
D is the answer
skywalker
👍 3
Vote for C.. as performance issues not seen in test/dev environment can due to not enough testing to handle loadstress on the app.
GunjGupta
👍 3
I will go with D as in question they are asking for test and deployment procedure but not test environments strategy. It is also stated already that bug is not seen in lower environments.
gcp_aws
👍 1
I will go with D. When you configure the new changes (v2, for example) to be deployed for 10% of the users (in canary deployments), you would normally have a baseline setup with the similar load. You would compare v2 vs baseline deployment to find if there are any issues including performance issues, based on different metrics.
clouddude
👍 7
I'll go with C as it's the only solution that involves modifying the test environment.
skywalker
👍 2
The production is facing performance issue.. which may be due to high user load. Thus Should be C as it increase load to test/dev environment to see we can determine the issues.
vindahake
👍 3
C Since it is referring to performance
mpguard
👍 5
Performance bugs are not necessarily linked to high load; you can have a performance bug even with 1 user. So while C sounds reasonable, the right answer is D (canary deployment)
cetanx
👍 2
Then it would be recognized in test environment as well if it was a bug in the code which would affect one or a few users. Therefore I go with "C".
2g
👍 2
answer: D
sri007
👍 2
D is the Correct as we use same kinda approach is our project
ghitesh
👍 88
Question Statement: You want to adjust your test and deployment procedures to avoid this problem in the future So based on this, I think the option "C" is correct, since it is the only one talking about doing changes in the test environment.
Sephethus
👍 3
There is no indication given anywhere that the load is the problem or that the bugs are a result of load and not some other issue encountered when using a specific feature.
RegisFTM
👍 19
"Your solution is producing performance bugs in production..." - I don't see how "D" would help to detect performance bugs. - "C" looks more adequate.
Urban_Life
👍 9
The answer is D
VedaSW
👍 20
C. Increase the load on your test and staging environments. As you have pointed out in "Question Statement", I do not see C covering "deployment procedures". Test and Staging environment is more on testing, but not about deployment procedure to production. So, the only option that cover test and deployment is D. (Yes, kind of unacceptable to have the users to do "testing", but we make it "ok" by calling it "canary deployment")
AWS56
👍 3
D is the one
addy007
👍 5
It should be D, think Canary Analysis, for similar issues. https://whatis.techtarget.com/definition/canary-canary-testing
chiar
👍 7
I think, it`s C, because you test the performance increasing the load, in D you could do too, but don't say anythink about increasing load to check the performance
Ani26
👍 2
It does not mention performance issue is due to load in Prod, it says 'your solution' creates performance issues in Prod not seen in testing...so I would say D...test your solution with 10% users and then roll out
Eroc
👍 39
A wouldn't prevent the bugs, it would just avoid them. B would help with root-cause analysis because it'd be a smaller change to review. C would test the performance of the system at its peak processing rates, so this assumes the bugs in production only occur because of usage. D would allow you to test the new code against smaller user sets to see if it occurs then, and if it still does you know it is not because of more user responses. So it's a tossup between C and D, D would be the cheaper/quicker answer so I'd choose D first then C if it's because of usage.
AzureDP900
👍 2
C is the best
RitwickKumar
👍 5
@eroc Looks like you missed the point here it is about the "performance" bugs which are related to the load. Apart from Option C there is no other way to test out the load prior to production role out. I would chose Option "C": Increase the load on your test and staging environments
michael_m
👍 2
According to the question, [Your solution is producing "performance" bugs in production], so I think it is about the load. Plus canary test will not reproduce the bugs related to high load, I vote for C
nitinz
👍 7
D, canary rollout
Sreekey
👍 18
The question is about the performance of the existing Code that they did not detect in Test environments . This is not about new API release . In order to test the performance they should increase the load in test environment and hence answer C.
tartar
👍 19
D is ok.
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The defect is a coverage gap: staging never ran at production load, so load-dependent performance bugs stayed invisible. Option C directly closes that gap by increasing the load on test and staging environments, which is exactly the load testing the Well-Architected reliability pillar recommends before release. It is preventive rather than reactive, because failures surface in QA instead of after deployment. Only option C changes the environment where the stated problem actually occurred.Why the Other Options Are Wrong
Option A merely slows the release cadence; deploying fewer changes does not make hidden performance bugs detectable and just delays their eventual discovery. Option B shrinks the change set, which helps root-cause analysis after a failure but still leaves test environments unable to reproduce production-scale load. Option D is a canary rollout that limits blast radius, yet it deliberately sends only partial traffic, so load-dependent performance defects can stay hidden until full rollout and real users still receive the buggy build. It also contradicts the goal of avoiding the problem, because it detects rather than prevents exposure.Community Comment Notes
ghitesh argued C is "the only one talking about doing changes in the test environment," and Sreekey agreed that the issue concerns existing code performance, so "increase the load in test environment." VedaSW pushed back that C covers only testing, contending "the only option that cover test and deployment is D," while tartar simply asserted "D is ok." certificatores supported that pick by linking the canary test pattern page, but francescogugliottagm undercut it by noting that with only part of traffic on a canary, "we don't see performance bugs in the canary release." Urban_Life concluded flatly "The answer is D," showing the community is genuinely split.Official Reference
Exam Strategy
When a question says a bug appeared only in production, first identify which environment lacked fidelity (load, data, topology) and choose the option that restores that fidelity. Reserve canary and staged rollout answers for questions about limiting blast radius of changes, not for uncovering load-dependent defects.
Frequently Asked Questions
Why isn't canary deployment (D) the right answer for performance bugs?
A canary sends only a small share of traffic, so load-dependent performance bugs may never appear until full rollout. It limits blast radius but does not reproduce production load during testing.
Does increasing staging load address deployment procedures too?
The question permits adjusting either test or deployment procedures; fixing unrealistic test load removes the root cause before any deployment occurs.
Related Analysis
Practice All PCA Questions
Access 81 questions with complete answers and detailed explanations.
View Full PCA Practice Test →