KQL sort defaults to descending, so ascending order requires an explicit asc modifier
Short answer
B No. KQL sort defaults to descending, so without an explicit asc modifier the results are not ordered ascending as required.
Question

Key Takeaways
KQL sort/order by defaults to desc; an ascending requirement is only satisfied when 'asc' is explicitly provided, which is a frequent trap in eventstream/KQL questions.
In Kusto Query Language, the default sort order is descending (high to low); to return results ordered by a column in ascending order you must specify the asc modifier explicitly. A solution that relies on the default sort therefore does not meet a requirement for ascending order.
Common mistake: Assuming KQL sorts ascending by default like SQL; KQL's default is descending, so omitting the asc modifier yields the wrong order.
Expert Analysis
Why the Answer Is Correct
The goal requires results ordered by No_Bikes in ascending order. In KQL, the sort/order by operator defaults to descending (high to low); ascending order must be explicitly specified with the asc modifier. The proposed solution (presented as an image) did not explicitly request ascending order, so it would return data in descending order and does not meet the goal. Hence the answer is No.
Why the Other Options Are Wrong
Option A (Yes) would only be correct if the solution explicitly specified ascending order, which the documented KQL default behavior indicates it did not; KQL does not default to ascending like T-SQL.
Community Comment Notes
Community voting favors No (68 vs 32). Comments (mauriciorosa8, MuffiSan, 8d6881f) cite the KQL sort-operator doc stating the default is desc and asc must be specified. The solution code itself was provided as an image in the source item, so the determination relies on the documented default combined with community consensus.
Official Reference
https://learn.microsoft.com/en-us/kusto/query/sort-operator?view=microsoft-fabric
This link opens the official vendor documentation in a new tab.
Community Votes
68% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 9 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 9
-
benni_ale 👍 3 Answered Bno, order by by default is desc in kql
-
QAZdbarhate12345678 👍 2 Answered AThe provided solution meets the goal. Analysis: Filtering Condition: The code includes filter Neighbourhood == "Sands End" and No_Bikes >= 15, which satisfies the requirement to only include rows where the neighborhood is "Sands End" and No_Bikes is at least 15. Ordering: The order by No_Bikes clause ensures that the results are sorted by No_Bikes in ascending order, meeting the stated requirement. Projection: The project BikepointID, Street, Neighbourhood, No_Bikes, No_Empty_Docks, Timestamp ensures that the necessary columns are returned. Conclusion: The solution fulfills all the requirements. Correct Answer: A. Yes.
-
MuffiSan 👍 2 Answered Bno. In kql desc is default for sort by: "asc sorts into ascending order, low to high. Default is desc, high to low." https://learn.microsoft.com/en-us/kusto/query/sort-operator?view=microsoft-fabric
-
mauriciorosa8 👍 2 Answered BThe default sorting order in KQL is descending (desc); ascending (asc) must be explicitly specified when needed.
-
Bharat 👍 2 Answered Athe answer is yes since you don't have to specify the "asc" option. It is the default.
Show 4 more comments
-
568f95c 👍 2 Answered AThey are asking for the order of No_Bikes in ascending order in this question
-
8d6881f 👍 1 Answered Bno. In kql desc is default for sort/order by: "asc sorts into ascending order, low to high. Default is desc, high to low." https://learn.microsoft.com/en-us/kusto/query/sort-operator?view=microsoft-fabric
-
Tuki93 👍 3 Answered Bdefault is desc in Kusto
-
amli123 👍 2 Answered Bdefault is desc
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.