Scrum asks that Product Backlog items carry a size and names no technique for producing one. Those two facts together account for most of the confusion in this area, because the techniques teams use are so familiar that they get mistaken for requirements.
Sizing belongs to the Developers
The Developers who will be doing the work are responsible for the sizing, and the reason is empirical rather than political. An estimate is a claim about how much effort something will take, and the only people positioned to make that claim are the ones who will do the work and then find out whether they were right.
The Product Owner may influence the Developers by helping them understand and select trade offs. That is a real influence and it acts on the work rather than on the number. Explaining that a narrower version of a feature would satisfy the need may change what gets built and therefore change the size. Asking the Developers to lower a figure so that more items fit into the Sprint changes nothing except the accuracy of the forecast.
The framework names no technique
Story points, ideal hours, shirt sizes and counting items all sit outside Scrum, as do planning poker and the reference stories teams calibrate against. Any of them is legitimate and none of them is required, which means no exam answer can turn on a team having chosen one.
Velocity is worth stating separately, because the word does not appear in the Scrum Guide anywhere. It is a useful measure that many teams keep, and it is not a Scrum measure. A question that treats reporting velocity as an obligation of the Developers is testing whether the candidate knows the difference between the framework and the habits built on top of it.
Counting items often beats estimating them
Where a team has already split items so that they come out at broadly similar size, counting them forecasts about as well as adding up points, and it costs nothing. It also ends the long running argument about what a point means, a debate that consumes a surprising amount of a team's attention and produces nothing a customer can see.
The interesting work is the splitting rather than the arithmetic. A team that splits well ends up with items of comparable size as a side effect, at which point most of the value of estimating has already been collected.
An estimate is a forecast, not a promise
The commitment for a Sprint is the Sprint Goal. The selected items are a forecast of what the Developers expect will achieve it, and as they learn more the scope can be clarified and renegotiated with the Product Owner, provided the Sprint Goal is not put at risk.
Treating the estimate as the commitment inverts that relationship. The team then protects the number rather than the goal, and the usual way to protect a number under pressure is to trade quality quietly, which shows up two Sprints later as work nobody planned.
Why comparing velocity between teams is meaningless
A point is a unit one team invents for itself and calibrates against its own past work. Two teams using the same word are not using the same unit, so putting their figures side by side compares nothing.
The comparison is also actively harmful, because the measure is trivially inflated. A team that knows its velocity is being watched can estimate more generously and appear faster while delivering exactly what it delivered before. What can be compared usefully across teams is how quickly value reaches a customer, which describes the product and the organisation rather than one team's private units.