The fact that you are already bringing up all your expertise on redundancy shows that you can think about this better than others and probably give an answer that fits this requirement well.
Unless we completely reinterpret the requirements (as per your suggestion), (s)he really can't. It is impossible to meet the requirement "Architected never to go down."
What actually confuses me more than anything is how wildly the strength of the writer's connection to reality varies. I mean, two of the "requirements" are:
# Architected to never go down
# Employs security features
Eh, I dunno.
If I asked you to recommend a car that is fast and safe you wouldn't reply "all cars are fast" and "no car can be perfectly safe", you would suggest a car that maximises those requirements.
Similarly, the author is looking for what frameworks/stacks maximise (among other things) reliability and security.
Engineering a web scale service for robustness is a series of tradeoffs, increasingly expensive tradeoffs as you make the system proof against bigger threats. Geographical redundancy alone more than doubles your costs, and (if you're doing it right) only adds a third or fourth 9 to your availability numbers.
But "Architected to never go down." does not guide the implementer, it doesn't communicate anything they need to know about what the limits of system are; and most importantly it ignores the reality principle.