recently i had an interview for Linux Admin. One of the questions i was asked was
"There is a kernel Panic Attack on your machine and your machine has stopped responding. Even when you reboot your machine, immediate kernel panic attack occurs and you are devoid of any terminal or console. How will you fix this issue?"

I answered: by using a live disc to mount and repair the fs....!

Please let me know the possible answers to this situation.

IMHO any well-structured diagnostics starts with an analysis of the situation. For example knowing if the machine is stored in a remote Data Centre (as in Out of or Side Band methods) or not, if it's a physical or virtual machine, if the machine is part of a cluster or if other fail-over methods are in place, if there's central syslog storage or not, any Service Level Agreements, response priority or explicit client instructions may (or may not) cause you to change your approach. Plus without diagnostics you won't be able to prove it's a file system error that lead to the kernel panic, its cause might be Something Completely Different. So depending on the situation and the priority of the incident you might not choose to resurrect this machine at all but first check if fail-over worked properly, or go for virtualization or syslog analysis first, mount an ISO via whatever method available or ask the colo people to do that for you, open a ticket, inform the client, etc, etc. Being able to start your explanation that way should convey you have practical experience with Real Life troubleshooting and its pitfalls in heterogeneous environments, an analytical mindset, know how to work efficiently and have an eye for client perception / relations ;-p

Note that a kernel panic does not necessarily indicate an attack (although some attacks could cause a kernel panic). A kernel panic is simply when the kernel experiences some unexpected condition that should never occur, and therefore stops itself (and the whole system) to prevent any further damage. As UnSpawn indicates, you would need to figure out what caused the kernel panic (it need not be filesystem related). If it turns out to be caused by something malicious, you would want to isolate the system and follow standard incident response procedures. There are many threads over on the security forum that go over this in detail; I suggest you read through them if you're looking for a career as a professional sysadmin.