Common Exam Traps: Premature Complexity & POC-as-Production

This is a senior architect exam. Expect scenario items that hand you a business goal plus constraints (latency SLA, volume, cost ceiling, data sensitivity) and ask which architecture, pattern, or decomposition fits -- and *why the alternatives don't*. Two failure modes recur across those scenarios.

Common Exam Traps

• Jumping to "use an agent" or "use the biggest model" before the requirements justify it. The correct answer anchors on the stated constraint, not on the most powerful or most autonomous option available. If the scenario describes fixed, known steps with a predictability requirement, the answer is a workflow -- not an agent, no matter how capable the model.
• Treating a proof-of-concept design as production-ready. A POC that merely demonstrates the model can produce the right output in a demo is not the same system as a production architecture. Production adds evaluation, observability, security, and lifecycle management -- all first-class from day one, not bolted on later.

Why These Traps Are Tempting

Both traps share a root cause: solving for capability instead of solving for the stated requirement. A bigger model or a fully autonomous agent is *more capable* in the abstract, but capability that the requirements don't call for adds cost, latency, and unpredictability without a corresponding business benefit. Similarly, a POC that "works" in a demo has not yet answered the non-functional requirements (data sensitivity, criticality, monitoring) that production actually needs.

How to Avoid Them

1. Before recommending autonomy or scale, restate which of the six requirement dimensions (see requirements elicitation) justifies it.
2. When asked to "design a solution" rather than "build a demo," explicitly include evaluation, observability, security, and lifecycle as parts of the answer, not afterthoughts.
3. Treat "the biggest model" and "full agentic autonomy" as answers that require justification, not defaults.