Chapter 4 is about the suite you will still be able to change in six months: the Page Object Model, separating test data from test logic, keeping tests independent and readable, the sources of flakiness, and logging and reporting. A4Q allocates 150 instruction minutes here.
This is the chapter that separates people who have automated something from people who have maintained something they automated. The questions are less about syntax and more about consequences — a scenario is described, and you say what will hurt later.
Where candidates lose points:
What a page object method returns. A method that completes a navigation returns the page object of the page you land on — a login() that ends on the dashboard returns a DashboardPage, not void and not a boolean.
Assertions do not belong in page objects. A page object exposes state and actions; the test decides what is correct. Mixing them is the most frequently offered wrong answer in this area.
Locators duplicated across tests. One selector should live in exactly one place. When the page changes you want one edit, not a search across the suite.
Tests that depend on each other. If test B needs the record test A created, the suite cannot be run in parallel, cannot be run partially, and fails in a cascade that hides the real cause.
Not every flake is a timing bug in your code. A test that passes locally and fails on a loaded shared CI agent points at the environment, and the fix is a proper explicit wait rather than a longer sleep or a retry.
Reporting is part of maintainability. A failure that says only “assertion failed” costs an hour of investigation; a log line and a screenshot at the moment of failure cost nothing to add.
This chapter is covered most heavily (13 questions) in A4Q Selenium Tester — Mock Exam 6 (Waits, Synchronisation & Test Stability)