Meridian's IT architecture currently couples its data storage tightly to one legacy reporting application, making it hard to add the AI workloads the ramp-safety computer-vision system needs without disrupting existing reports. Which data engineering principle should the PM push the team to apply to the AI infrastructure?
Select an answer to reveal the explanation.
Short Explanation
Bolting a new AI workload onto a tightly coupled legacy system is how you break the existing reports the moment you touch anything. Decoupling storage from compute is the engineering principle that lets new workloads plug in without disturbing what's already running.
Full Explanation
Applying data engineering principles to AI infrastructure typically means designing for decoupled storage and compute and schema flexibility, so new workloads (like a computer-vision pipeline) can be added or scaled independently of legacy systems that already depend on the existing architecture. This directly addresses Meridian's stated problem: tight coupling to the legacy reporting app makes any AI addition risky to existing reports. Option A doubles down on the exact coupling causing the problem, guaranteeing continued fragility as more AI workloads are added. Option C compounds the risk further by embedding new, different workload requirements directly into legacy code, increasing blast radius for any bug or outage. Option D is a governance anti-pattern; skipping documentation to preserve flexibility just defers pain and undermines the pipeline documentation enabler tested next in this domain. For the exam, connect 'decoupling' and 'scalable architecture' as the data-engineering answer whenever a scenario describes legacy-system rigidity blocking new AI workloads.