Solution Design
Solution design is the discipline of turning business requirements into the smallest configuration that satisfies them. The exam rewards a standard-first hierarchy: use the standard object and field if one exists; otherwise configure it (record types, page layouts, Lightning record pages, dynamic forms, validation rules, flows); only then consider a custom object; and code last. Every custom object you add costs reporting complexity, storage, integration surface and admin effort.
Key concepts to name: record types to drive different business processes and picklist values on one object; dynamic forms to show fields conditionally without multiplying layouts; field-level security and permission sets versus profiles; sharing (organization-wide defaults, role hierarchy, teams) to answer "who can see this"; and design documentation (solution design document, field matrix, process flows) to prove the design is testable.
Traps appear as questions that push you toward over-engineering - a custom object where Opportunity record types suffice, a validation rule where a required field works, a profile per team instead of permission sets, an Apex trigger where a Flow or roll-up summary works. Watch also for solutions that break reporting (fields buried on a custom object) or blow up limits.
Worked example: "Renewal deals must show different fields and different stage values than new business." The correct pattern is two record types on Opportunity, each assigned a sales process with its own stage picklist values, plus a Lightning record page or dynamic form per record type - not a second custom object called Renewal__c. Keeping renewals on Opportunity preserves forecasting, pipeline reporting and standard renewal features.
Rule of thumb: standard → configure → extend → code; at each step ask what reporting, sharing and integration cost it introduces.