Where should input validation occur to prevent invalid data from entering deeper layers?

• A. At the boundary (edge) and again in domain logic
• B. Only at the database layer
• C. Only at the presentation layer
• D. In the logging subsystem

Answer: (A)

The idea being tested is defense in depth for input data: validate at the system boundary to catch bad data early, and also validate inside the domain logic to enforce business rules regardless of how data arrives.

Validating at the boundary (the edge where data enters) stops obviously invalid input from propagating deeper, giving quick feedback and reducing unnecessary work. But data can still come from trusted internal paths or be misused, so validating again in domain logic ensures invariants are always enforced and prevents invalid data from corrupting core business processes.

Relying only on the database layer misses early error detection and can let invalid data slip through if boundary checks are bypassed. Validating only at the presentation layer leaves the system vulnerable to internal components or automated processes that bypass UI input validation. The logging subsystem isn’t a validation mechanism and doesn’t guarantee data integrity.

So, the best approach is to validate at the boundary and again in domain logic to maintain data integrity across the system.