In real business situations, it is often the case that complete normalization of the system would be wasteful. For example, if a customer is a company, and most companies have one address, but some have multiple addresses (e.g., two headquarters in Tokyo and Osaka), there is no need to create an address table for a group of repetitive addresses. There is no need to create an Address table just because it is a repeating group.
Normally, we would dare to table as Address1 and Address2 with the non-normative form so that most companies can fit in. Common sense dictates that if there is a reason at a level that makes sense to most people, then the denormalized form is acceptable. I have given a simple example here, but in reality there are aspects where denormalization decisions are necessary, which can be important decisions.
The user who purchases the system has the right to make such trade-offs, and the trade-offs differ each time. For this reason, it is important to understand the technology, and since normalization is an important part that affects the entire system, I am happy if this explanation has helped more people to understand.
Also, the normalization on the IPS exam is relatively simple, but the actual business is much more complex. There are a really large number of items. (And each item is difficult.) Therefore, database normalization is a job for engineers who are familiar with customer business, and I think that years of experience and continuous business learning are important to make the most of this theory.