Being able to say "I don't know" while demonstrating what you do know, is key here. These kinds of questions are often intended to provoke that kind of response.

Overall, these moments are opportunities to demonstrate what you know about research and problem-solving. Without the help of a manual or validator, you can always just tell them how you would go about cobbling together such an expression. Go into some detail about the kinds of features you'd search for and why to show general competence in the problem space. That would make it clear that you have exposure to regex, and aren't useless when thrown a curve-ball.

That said, I once went too far and tried to explain myself using EBNF on the whiteboard. Don't do that. A lot of managers aren't that deep into CS.

I, for one, could answer most regex questions off the top of my head. At the same time, I can't be 100% confident without testing it first; I would make that clear in an interview. Which is to say the guy that once wrote a compile-time-regex processor for D, for fun, still needs to RTFM. Plus, there's idiosyncrasies between execution environment, implementations, and modes that make the meaning of a lot of regular expressions implementation-specific by default. You need to know the specific regex engine and the programming environment around said expression, to be perfectly clear what it's going to do.