Validating the estimations

The Developers do the estimates as they do the work; however, their estimates are not commitments as they are forecasts, due to the uncertainty that complex product development has. 

I was asked in an Interview session that as Scrum Master, how would you ensure that the estimates provided by any team member is correct or not?

My answer would be to challenge the assumptions. Why would I even want to "ensure" such a thing? It's the developers who are collectively accountable for the estimates they make, and estimates are precisely that...estimates. Their only purpose is to help a team get its arms around how much work they can take on in a Sprint, so a Sprint Goal is met and a "Done" increment delivered. Everything else reduces to empiricism and the delivery of value. I would emphasise how important it is respect the Developers' ability to make their own forecasts and commitments as professionals.

Then again, I probably wouldn't get the job.

I'd be like @Ian Mitchell.  My response would probably be something like "Suppose I asked you to provide an estimate on reorganizing your division. How long do you think it would take you to come up with the plan? How long to get all of the financial/organizational paperwork completed?  How long to get it communicated to all impacted individuals? How would you ensure that those estimates are correct?"

I would show them how ridiculous it is to hold someone to a guess, which is what an estimate is.  I'd ask them how often any kind of estimate they have made was correct?  How would you ensure that the estimated drive time given by Google Maps is accurate or not? 

And much like @Ian Mitchell, I'd still be looking for a job.

Hit "Submit" too soon.  

Wanted to add that in addition to questioning their knowledge, I would also provide them with a lesson on empiricism and Scrum Theory.  An estimate is a guess based upon the knowledge you have now.  To accurately understand the effort you have to do the work taking into account all of the information you acquired while doing the work. 

I'd also take the opportunity to question their Scrum Values.  From the Scrum Guide

Commitment, Focus, Openness, Respect, and Courage

The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, to work on tough problems.

These values give direction to the Scrum Team with regard to their work, actions, and behavior. The decisions that are made, the steps taken, and the way Scrum is used should reinforce these values, not diminish or undermine them. The Scrum Team members learn and explore the values as they work with the Scrum events and artifacts. When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.

Your original statements show a complete lack of respect and expectation that there is no commitment, focus and openness.