New Year Sale 2026! 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

Amazon DVA-C02 Exam - Topic 6 Question 22 Discussion

Actual exam question for Amazon's DVA-C02 exam
Question #: 22
Topic #: 6
[All DVA-C02 Questions]

A company runs an application on AWS The application stores data in an Amazon DynamoDB table Some queries are taking a long time to run These slow queries involve an attribute that is not the table's partition key or sort key

The amount of data that the application stores in the DynamoDB table is expected to increase significantly. A developer must increase the performance of the queries.

Which solution will meet these requirements'?

Show Suggested Answer Hide Answer
Suggested Answer: B

Global Secondary Index (GSI):GSIs enable alternative query patterns on a DynamoDB table by using different partition and sort keys.

Addressing Query Bottleneck:By making the slow-query attribute the GSI's partition key, you optimize queries on that attribute.

Scalability:GSIs automatically scale to handle increasing data volumes.


Amazon DynamoDB Global Secondary Indexes:https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html

by Clay at Mar 16, 2024, 09:30 AM

Limited Time Offer

25%

Off

Get Premium DVA-C02 Questions as Interactive Web-Based Practice Test or PDF

Contribute your Thoughts:

0/2000 characters
Submit Cancel
Verda
3 months ago
GSI is a must if you're querying on non-key attributes!
upvoted 0 times
...
Kattie
3 months ago
Option C is interesting, but I think it might complicate things too much.
upvoted 0 times
...
Mayra
3 months ago
Wait, can you really just increase the page size and expect better performance? Sounds sketchy.
upvoted 0 times
...
Sang
4 months ago
I disagree, option D seems more straightforward for scaling.
upvoted 0 times
...
Isabelle
4 months ago
Definitely go with option B, a GSI is the way to improve query performance!
upvoted 0 times
...
Catarina
4 months ago
I wonder if auto-scaling would help, but it seems like that would just address capacity issues rather than query performance directly. I'm not confident about that one.
upvoted 0 times
...
Eleonora
4 months ago
I practiced a question similar to this where we had to optimize DynamoDB queries. I think creating a GSI was the solution we went with, so I'm leaning towards option B again.
upvoted 0 times
...
Catrice
4 months ago
I'm not entirely sure, but I feel like increasing the page size won't really solve the underlying issue with slow queries. It seems more like a workaround than a fix.
upvoted 0 times
...
Penney
5 months ago
I remember discussing global secondary indexes in class. They can really help with queries on non-key attributes, so I think option B might be the right choice.
upvoted 0 times
...
Shayne
5 months ago
I'm a little unsure about this one. I'm debating between B and D, but I think B might be the better choice since it directly addresses the issue of the slow queries involving an attribute that's not the partition or sort key. I'll have to double-check my understanding, but I'm leaning towards B.
upvoted 0 times
...
Yoko
5 months ago
I'm feeling pretty confident about this one. The question is specifically asking for a solution that will meet the requirements, and creating a GSI with the query attribute as the partition key (option B) is the best way to do that. The other options don't really address the core problem.
upvoted 0 times
...
Gertude
5 months ago
Okay, I think I've got this. The key here is that the slow queries involve an attribute that's not the partition or sort key. So we need to create a GSI to index that attribute and make the queries faster. B seems like the way to go.
upvoted 0 times
...
Lemuel
5 months ago
Hmm, I'm a bit confused on this one. I'm not sure if increasing the page size or doing a parallel scan would really address the root issue of the slow queries. Maybe B is the best option, but I'll have to think it through a bit more.
upvoted 0 times
...
Temeka
5 months ago
I'm pretty sure the answer is B. Creating a global secondary index (GSI) with the query attribute as the partition key should help speed up those slow queries.
upvoted 0 times
...
Mammie
5 months ago
Okay, I've reviewed the risk management framework and I think option D looks like the correct answer based on the standard risk treatments outlined in the guidance.
upvoted 0 times
...
Jacki
5 months ago
I'm a bit confused on the difference between profiles and public groups. I'll need to review that before deciding on the best approach.
upvoted 0 times
...
Whitley
5 months ago
Based on my understanding, the Endpoint Assessment feature is the most relevant one to update the client and meet the enterprise security policy. I'll go with that.
upvoted 0 times
...
Shenika
2 years ago
I think option C could also be worth considering. Performing a parallel scan operation might be a good solution for improving query performance.
upvoted 0 times
...
Samira
2 years ago
But wouldn't configuring the application to retry requests also be beneficial in ensuring faster performance?
upvoted 0 times
...
Jeffrey
2 years ago
I'm leaning towards option A. Increasing the page size for each request might help improve query performance.
upvoted 0 times
...
Madalyn
2 years ago
I disagree, I believe option D is the best choice. Turning on read capacity auto scaling can help with increased performance.
upvoted 0 times
...
Samira
2 years ago
I think option B could work because creating a global secondary index might help speed up the queries.
upvoted 0 times
...
Sol
2 years ago
Hmm, I see your point. But what about option D? Turning on read capacity auto scaling seems like a scalable solution as well.
upvoted 0 times
...
Gussie
2 years ago
I agree with Stacey, setting the query attribute as the partition key in a GSI could definitely help in improving query performance.
upvoted 0 times
...
Stacey
2 years ago
I disagree, I believe creating a global secondary index like option B would be more efficient in speeding up the queries.
upvoted 0 times
...
Sol
2 years ago
I think option A could work, by increasing the page size and configuring retries for requests that exceed throughput.
upvoted 0 times
...
Merrilee
2 years ago
Haha, I love how these DynamoDB questions always involve some kind of performance issue. It's like the AWS exam writers are just trying to keep us on our toes, you know? But yeah, I think the GSI is the way to go here. It's a classic DynamoDB solution for this kind of problem.
upvoted 0 times
...
Kattie
2 years ago
I'm not so sure about the GSI option. Isn't that going to cost more in terms of provisioned throughput? And what if the queries change in the future, then we'd have to update the index. I'm kind of leaning towards the auto-scaling option - that seems like a more hands-off and potentially cheaper solution.
upvoted 0 times
...
Rosann
2 years ago
I agree, the GSI option does seem like the best choice here. The partition key will allow for fast lookups, and it won't require any changes to the application code. Plus, it's a more scalable solution than just increasing the page size or doing a parallel scan.
upvoted 0 times
...
Adela
2 years ago
Hmm, this is an interesting question. The slow queries due to the non-key attributes are definitely a concern, especially with the expected increase in data. I'm leaning towards option B - creating a global secondary index (GSI) with the query attribute as the partition key. That seems like the most straightforward way to improve query performance.
upvoted 0 times
Elly
2 years ago
I'm convinced. Option B it is for optimizing the queries that involve non-key attributes in the DynamoDB table.
upvoted 0 times
...
Filiberto
2 years ago
Yeah, that's a good point. Option B seems like the most targeted approach to improving query performance, especially considering the expected increase in data volume.
upvoted 0 times
...
Shantell
2 years ago
It might work, but creating a global secondary index specifically targeting the query attribute seems more direct and effective. That's why B stands out to me as the better choice.
upvoted 0 times
...
Dalene
2 years ago
But wouldn't increasing the page size for each request and configuring the application to retry requests also be a valid approach? That's option A, right?
upvoted 0 times
...
Aracelis
2 years ago
I agree, B seems like the appropriate solution here. It will definitely help with the slow queries involving non-key attributes.
upvoted 0 times
...
Karma
2 years ago
I think B makes the most sense. Creating a global secondary index with the query attribute as the partition key should help improve query performance.
upvoted 0 times
...
...

Save Cancel