Deal of The Day! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions
Mail Us support@pass4success.com
Location US
Mob_nav_barsMENU

Salesforce Certified B2C Commerce Cloud Developer (Comm-Dev-101) Exam - Topic 3 Question 88 Discussion

A custom cartridge that seemed to be performing well in a sandbox has been installed in production. The production instance is showing increased page load times that seem to be related to the new custom code. What can a developer do to quickly track down the potential problem?
A) Use the Code Profiler in production instance. Set the mode to Development Mode and then wait a few minutes to collect data from onsite traffic. Click the refresh button to see the new data.
B) Use the Code Profiler in production instance. Set the mode to Development Mode and click the refresh button to see the new mode displayed.
C) Use the Code Profiler in a sandbox instance. Set the mode Extended Development Mode and then load the suspected pages and run the suspected process several times. Click the refresh button to see the new data.

Salesforce Certified B2C Commerce Cloud Developer (Comm-Dev-101) Exam - Topic 3 Question 88 Discussion

Actual exam question for Salesforce's Salesforce Certified B2C Commerce Cloud Developer (Comm-Dev-101) exam
Question #: 88
Topic #: 3
[All Salesforce Certified B2C Commerce Cloud Developer (Comm-Dev-101) Questions]

A custom cartridge that seemed to be performing well in a sandbox has been installed in production. The production instance is showing increased page load times that seem to be related to the new custom code. What can a developer do to quickly track down the potential problem?

Show Suggested Answer Hide Answer
Suggested Answer: A

by Yoko at Mar 20, 2025, 03:06 PM

Limited Time Offer

25%

Off

Get Premium Salesforce Certified B2C Commerce Cloud Developer (Comm-Dev-101) Questions as Interactive Web-Based Practice Test or PDF

Contribute your Thoughts:

0/2000 characters
Submit Cancel
Isabella
6 months ago
I think B is a bit too limited for real troubleshooting.
upvoted 0 times
...
Denise
6 months ago
Surprised that they would use production for profiling!
upvoted 0 times
...
Elenora
6 months ago
A seems like the most straightforward option here.
upvoted 0 times
...
Jeannetta
6 months ago
I disagree, C might give better results in a sandbox.
upvoted 0 times
...
Isadora
6 months ago
A is definitely the way to go for quick insights.
upvoted 0 times
...
Julio
7 months ago
I lean towards option C since it suggests running the suspected processes multiple times, which might give a clearer picture of the performance bottleneck.
upvoted 0 times
...
Shalon
7 months ago
I feel like we practiced a similar question, but I can't recall if we should use the profiler in production or sandbox. It’s a bit confusing.
upvoted 0 times
...
Justine
7 months ago
I think option A sounds right because it mentions collecting data from onsite traffic, which seems crucial for diagnosing performance issues.
upvoted 0 times
...
Gerry
7 months ago
I remember we discussed using the Code Profiler in class, but I'm not sure if it should be in Development Mode or Extended Development Mode for production issues.
upvoted 0 times
...
Dottie
8 months ago
I'm pretty confident that option A is the best approach here. Setting the Code Profiler to Development Mode in the production instance and then refreshing to see the new data seems like the quickest way to track down the potential problem. I'll go with that.
upvoted 0 times
...
Kenny
8 months ago
I'm a bit confused about the difference between Development Mode and Extended Development Mode. I think option C might be the way to go, but I'm not entirely sure. I'll need to review the details on the different profiler modes before deciding.
upvoted 0 times
...
Jill
8 months ago
Okay, so the question is asking us to quickly track down the potential problem, and it seems like using the Code Profiler in the production instance is the way to go. I'm leaning towards option A, where we set it to Development Mode and wait a few minutes to collect data from the onsite traffic.
upvoted 0 times
...
Adolph
8 months ago
I think the key here is to use the Code Profiler in the production instance, but I'm not sure if we should set it to Development Mode or Extended Development Mode. I'll need to double-check the details.
upvoted 0 times
...
Shawn
1 year ago
I bet the person who wrote option A has never actually worked in production before. It's like they're trying to add more fuel to the dumpster fire. C is the way to go, no doubt about it.
upvoted 0 times
Marg
1 year ago
I bet the person who wrote option A has never actually worked in production before. It's like they're trying to add more fuel to the dumpster fire. C is the way to go, no doubt about it.
upvoted 0 times
...
Murray
1 year ago
C) Use the Code Profiler in a sandbox instance. Set the mode Extended Development Mode and then load the suspected pages and run the suspected process several times. Click the refresh button to see the new data.
upvoted 0 times
...
Toshia
1 year ago
B) Use the Code Profiler in production instance. Set the mode to Development Mode and click the refresh button to see the new mode displayed.
upvoted 0 times
...
Art
1 year ago
A) Use the Code Profiler in production instance. Set the mode to Development Mode and then wait a few minutes to collect data from onsite traffic. Click the refresh button to see the new data.
upvoted 0 times
...
German
1 year ago
It's better to be safe than sorry when it comes to making changes in production.
upvoted 0 times
...
Winfred
1 year ago
I always test things out in a sandbox before touching production.
upvoted 0 times
...
Daron
1 year ago
Yeah, using the Code Profiler in a sandbox first is definitely the safer route.
upvoted 0 times
...
Geoffrey
1 year ago
I agree, option A sounds like a disaster waiting to happen.
upvoted 0 times
...
...
Vincenza
1 year ago
That's a good point, Jillian. It might be helpful to test in the sandbox before making changes in production.
upvoted 0 times
...
Jillian
1 year ago
I prefer option C, using the Code Profiler in a sandbox instance first to narrow down the issue.
upvoted 0 times
...
Maryanne
1 year ago
Hold up, did they really think we'd fall for using the Code Profiler in production? That's like trying to fix a leaky faucet by hitting it with a sledgehammer. C is the only sensible choice.
upvoted 0 times
...
Latosha
1 year ago
I agree with you, Vincenza. Setting the mode to Development Mode can help track down the problem quickly.
upvoted 0 times
...
Carissa
1 year ago
Hmm, I'm not sure about setting the mode to Development Mode in production. That sounds like a good way to bring the whole site down. C is the clear winner here.
upvoted 0 times
...
Norah
1 year ago
Ah, the age-old problem of production issues. Using the Code Profiler in production is risky, we don't want to slow down the site even more. C is the way to go - sandbox testing is the safest bet.
upvoted 0 times
Salome
1 year ago
C) Use the Code Profiler in a sandbox instance. Set the mode Extended Development Mode and then load the suspected pages and run the suspected process several times. Click the refresh button to see the new data.
upvoted 0 times
...
Karol
1 year ago
B) Use the Code Profiler in production instance. Set the mode to Development Mode and click the refresh button to see the new mode displayed.
upvoted 0 times
...
Lina
1 year ago
A) Use the Code Profiler in production instance. Set the mode to Development Mode and then wait a few minutes to collect data from onsite traffic. Click the refresh button to see the new data.
upvoted 0 times
...
...
Vincenza
1 year ago
I think the best option is to use the Code Profiler in production instance.
upvoted 0 times
...

Save Cancel