EIP common mistakes
EIP · Understand the traps and how to avoid them.
On integration design items, selects a pattern by name recognition - choosing 'ESB' or 'event-driven' because it appears in the option list - without first writing down the latency, coupling, and delivery-guarantee constraints stated in the scenario.
Pattern names are the most memorable part of the study material, so they are retrieved before the requirements are parsed; the scenario's constraints read like background colour rather than the deciding evidence.
What to do instead
Before reading the options, extract the explicit constraints (synchronous vs asynchronous, latency budget, exactly-once need, team ownership boundaries), eliminate every pattern that violates one of them, then justify the surviving option against each constraint in turn.
Designs asynchronous messaging flows that assume ordered, single-delivery behaviour and never add an idempotency key, a dead-letter path, or out-of-order reconciliation.
Most hands-on experience is request/response HTTP, where a 200 means the work happened exactly once; the failure semantics of queues and topics are learned abstractly and get dropped under time pressure.
What to do instead
For every asynchronous leg, state the delivery guarantee, then require a consumer-side idempotency key plus an explicit poison-message and replay path. If the preferred option omits these, treat that as a gap to flag rather than a detail to skip.
Models the data structure first (star schema, lake zones, streaming pipeline) and only afterwards states grain, keys, and business definitions, quietly bending the definitions to fit the chosen structure.
Tool and schema vocabulary is easier to recall than requirements elicitation, so candidates anchor on a familiar architecture and retrofit the problem statement onto it.
What to do instead
Write the grain and the natural/primary keys in one sentence before evaluating any model, confirm each candidate can hold them without duplication or loss, and only then choose between warehouse, lake, or hybrid.
Treats data quality rules, lineage, retention, and ownership as post-implementation clean-up, leaving them out of the target design and out of the migration plan.
These concerns produce no visible functionality, so under exam time pressure they feel optional, and options that mention them look like padding rather than substance.
What to do instead
For each data flow, name the accountable owner, the quality rule, the lineage record, and the retention period as design outputs. When two options are otherwise equal, prefer the one that makes these explicit and enforceable.
Applies security controls as a checklist ('encrypt everything', 'add MFA') without linking each control to a named threat, asset, or regulatory obligation described in the scenario.
Control catalogues are memorised as lists, and coverage feels like safety; candidates substitute breadth of controls for relevance to the stated risk.
What to do instead
Pair every proposed control with the specific risk it reduces and the data classification it protects, and drop controls whose corresponding risk is absent from the scenario - over-control is a frequent distractor.
Concludes a workload is compliant because the cloud provider holds the certification, without allocating the customer-side obligations such as identity management, secure configuration, data classification, and logging.
Shared responsibility is taught as a slogan but rarely rehearsed against a concrete workload, so the provider/customer boundary blurs in scenario items.
What to do instead
For any cloud compliance question, split the control list into provider-side and customer-side, then check which side the question is actually probing; the correct answer usually names the customer obligation the team must satisfy.
Describes governance as a committee that approves artefacts, assigning accountability to a board or change board instead of a named role with defined decision rights and an escalation path.
Governance is studied as org charts and meeting cadences, so candidates reproduce the structure without the decision rights that make it functional.
What to do instead
For each governance item, identify who decides, who is consulted, what evidence triggers the decision, and what happens when nobody decides. Options naming a role and a decision right outperform options naming a forum.
Plans a delivery or migration as a happy-path sequence only, omitting cutover entry criteria, measurable rollback triggers, and the reconciliation window after go-live.
Timelines are mentally built forwards from requirements, and planning for rollback feels like conceding that the plan will fail.
What to do instead
Add three lines to any plan you evaluate: entry criteria for cutover, a quantified rollback trigger, and a post-cutover verification window. Discard options that offer no reversibility.
Selects a resilience tier (backup and restore, pilot light, warm standby, active-active) without first deriving RTO and RPO from the business impact described in the scenario.
Tier names are easy to rank by cost and perceived robustness, so candidates sort by 'most resilient' rather than by 'meets the stated recovery objective'.
What to do instead
Extract or estimate RTO and RPO first, price each tier against them, and choose the least costly tier that satisfies both; revise upward only if the scenario supplies a regulatory or contractual recovery obligation.
Assumes managed elasticity removes capacity planning, and leaves quotas, egress cost, and workload-level saturation monitoring out of the operational design.
Elasticity is marketed as automatic, and quota, cost, and limit behaviour only becomes visible after deployment, so it is under-represented in candidates' notes.
What to do instead
For each operational scenario, state the scaling metric and its ceiling, the quota or service limit that binds first, the dominant cost driver, and the alert that detects saturation before users do.