Re 1.) I disagree as there are plenty of wrong architectures and unfortunately once a bad decision at that level has been made it can be very hard to fix. You do get to the meat of the matter though when you said:
"Does the architecture fit our needs for scaling, maintainability, reliability and further extension of functionality?"
which I do agree with. These are good high-level questions but we still need to see what the overall architecture looks like and make sure that it makes sense. In my experience if a project is borked it's going to have a slew of problems, both low-level and likely high-level, including possibly the architecture.
Here's a made-up example conversation to help drive the point home:
"What's this Custom Cache project?"
"Oh we need to scale so we wrote our own caching solution."
This is probably a red flag as caching is a difficult subject and there are plenty of solutions available that do exactly this. Also if management indicates that there's no chance this application will ever need to scale and this custom caching code has tied in all over the app(s) in a way which aren't going to be easy to disable or remove completely, then we likely have an architecture-level problem.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.