DMCP study materials
DMCP study resources

DMCP: Solution Design and Support

DMCP · Work through your exam, one topic at a time.

All guide sections

Solution Design and Support

Solution Design and Support is the synthesis domain: turning requirements into a sized, documented, supportable design, then supporting it through evidence-based troubleshooting and controlled change.

Core rules

  • Separate functional requirements (what it must do) from non-functional ones (RPO, RTO, performance, growth, compliance). Only the non-functional set lets you compare two technically valid architectures.
  • Size from measured data - performance counters, capacity trending, peak IOPS - not from vendor marketing figures or a single sample day.
  • Design to end-of-life, not to today: apply the stated growth rate across the service life, then add free-capacity headroom. Document every assumption; an undocumented assumption is the first thing a reviewer finds.
  • The HLD states components, flows, and constraints; the LLD states ports, IPs, VLAN IDs, LUNs, and naming. Blurring the two is a common review failure.
  • Support discipline: define severity levels and response targets, require a change record with a rollback step, and troubleshoot by hypothesis - start where the evidence points and check recent changes first.
  • Acceptance criteria agreed before the build are what turn a proof of concept into a sign-off; without them a PoC proves only that the hardware powers on.

Worked example

Current usable data is 120 TB with 35% annual growth over a three-year life, a 25% free-space floor, and RAID 6 at a 10-of-12 data-to-drive ratio. Compound growth: 120 x 1.35^3 = 295 TB. With the 25% floor, required usable = 295 / 0.75 = 394 TB. Raw at RAID 6 = 394 x 12/10 = 472 TB, so 24 x 20 TB drives. The reasoning: compound the growth first, then divide by 0.75 for headroom (do not multiply by 1.25), then gross up for parity.

Traps

  • Adding 25% instead of dividing by 0.75 - the two differ, and the exam knows it.
  • Using simple growth (120 x 2.05) instead of compounding.
  • Designing for today's peak with no growth line or decommission plan.
  • Running a PoC with no pass/fail criteria, or a design with no rollback step.
  • Omitting the assumptions and risk register, then being unable to justify the headroom.