Thanks Cornelius!
Your answer is logical, and I understand the processes depend on each other, in real life.
I was just worried that the PMBOK Guide and the exam might make other assumptions.

Arto,

The processes are practically never performed in a linear way. Yes, there is certainly a "preferred logic", in that you normally begin by planning and then you move on to executing. But during execution you will notice the need to re-plan, so you create a circle.

The best analogy that I have is therefore: Don't look at the "process interactions" neither as a straight line nor as a circle either. Instead, look at it as a game of three-dimensional chess, where you have constant interactions going back-and-forth, up-and-down and even sideways. In all dimensions.

The first paragraph of chapter 3.1 Common Project Management Process Interactions describes this nicely.

Wondering, is the answer here so obvious that nobody bothers saying, or is it too hard to find?

Some blogs and articles refer to a certain order of executing the 47 PM processes.

Also the answer to question 27 in our course's Self_Assessment_00_Pre_Course.pdf implies this.

Explanation: In accordance with the Planning process group, the order of processes are: Develop project management plan, Plan scope management, Collect requirements, Define scope, Create WBS, Plan schedule management, Define activities, Sequence activities, Estimate activity resources, Estimate activity durations, Develop schedule, Plan cost management, Estimate costs, Determine budget, Plan quality management, Plan human resource management, Plan communications management, Plan risk management, Identify risks, Perform qualitative risk analysis, Perform quantitative risk analysis, Plan risk responses, Plan procurement management, and Plan stakeholder management.
Reference: PMBOK Guide Fifth Edition, page 61.

This means you'd have to follow the order on p.61 in PMBOK 5th ed. Left to right, top to bottom

Sure, it's logical to do the Initiating processes before Planning etc, and there are dependencies between planning in several knowledge areas like scope, time and cost.
But, I don't see why I should perform quantitative risk analysis BEFORE I have planned procurements, for example. I'd say quite the other way around!

Another argument is that PMBOK 5th ed. p. 111 shows Stakeholder Management Plan as an input to Collect Requirements. Hence Plan Stakeholder Management must precede Collect Requirements.