A common misconception among developers is that you can describe an application, or build an application, entirely by bolting together design patterns. Writing software is not a matter of choosing design patterns, arranging them properly, and then shipping a product. Software development has not become quite that modularized. If developers cannot build software entirely composed of design patterns, then software architects cannot have conceptual discussions about software entirely composed of design patterns.
A design pattern is a specific problem coupled with a general description of how to solve that problem. It is a tool for communication, primarily, so I can see how someone might think architects can speak in terms of design patterns. They do speak in terms of design patterns, but there is not a design pattern to solve every problem. Instead, architects will speak and think in terms of the bigger picture elements of software design. Design patterns are certainly part of an architect's vocabulary, but it extends far beyond that. Design patterns, architectural patterns (onion architecture, clean architecture, micro services architecture), design philosophies (domain-driven design) and design techniques (separation of concerns, interface segregation principle, polymorphism, encapsulation, data hiding, etc) can be the main tools of communication.
So, no. Architects cannot describe an application entirely using design patterns. They need architectural patterns, design philosophies and techniques as well.
That will very much depend on the size of the application and at what abstraction level the architect is working.
If the application is a trivial application (like a school assignment) solving a well known problem with a well know pattern, most probably its architect will know the design pattern and be able to describe it like that. In larger systems, this becomes a lot harder: many patterns overlap, every solution has some specific requirement breaking some patterns, platform limitations force out deviations, etc... On this size it becomes a lot harder to explain the whole architecture with design patterns, but might still be possible to some degree.
In large-scale software systems with millions of lines of code (or in some case hundreds of millions) completely new patterns start to emerge. Understanding, or even just describing what happens on that scale can still get you a PhD degree. At this size if the architect is responsible for some sub-system leading a team, they could describe their own part related to design patterns, but most likely will have no or limited overview of the entire system. If the architect is working on the "top of the system" coordinating other architects, sub-systems, maybe negotiating with business partners, etc... they might give you a description on the overall system, but they will not really be able to give detailed information on how each part works.
Please note, that after a size and complexity it is no longer an architects fault if they can not "understand"/"describe" the whole system in detail. Size and complexity can grow beyond anyone's capabilities (or at least with the tools we currently have).
Some personal observations on large-scale software systems: