CWIIP common mistakes
CWIIP · Understand the traps and how to avoid them.
Treating MQTT quality-of-service levels as end-to-end delivery guarantees, so a candidate answers that QoS 2 means the subscriber's application has processed the message exactly once.
The QoS handshake is between a client and a broker per hop; candidates memorize the three levels without tracing which pair of parties each PUBACK/PUBREC/PUBCOMP flow actually involves, and they conflate broker acknowledgement with application-level processing.
What to do instead
Redraw the delivery path as publisher to broker and broker to subscriber, then mark where each QoS handshake terminates. State explicitly that exactly-once applies per hop, that a persistent session stores undelivered messages for a disconnected subscriber, and that application-level idempotency is still required for duplicate-sensitive work.
Choosing CoAP confirmable versus non-confirmable messages by message size or payload type rather than by the reliability requirement, and assuming CoAP's default transport provides delivery assurance.
Candidates transfer TCP intuition to CoAP and forget it runs over UDP with its own retransmission scheme; they also overlook that observation notifications and block-wise transfer change the reliability picture.
What to do instead
Anchor the choice on whether the sender needs an acknowledgement: confirmable for commands and state changes that must be retried, non-confirmable for high-rate telemetry where a lost sample is tolerable. Then rehearse the retransmission parameters (ACK timeout, exponential backoff, max retransmit) and how observe notifications and block-wise options interact with them.
Describing DDS as a broker-based publish/subscribe system, or failing to explain how a QoS policy mismatch prevents a reader and writer from matching.
Candidates generalize from MQTT and AMQP, where a broker is central, and they treat DDS QoS as tuning knobs rather than as part of the compatibility contract between endpoints.
What to do instead
State that DDS is brokerless with discovered peers and a global data space keyed by topic and type. Learn the request/offered compatibility rule for a handful of policies (reliability, durability, deadline, ownership) and practise predicting whether a pair of endpoints will match given their policy values.
Confusing AMQP's link-level flow control and settlement with broker queue semantics, or answering that AMQP is a messaging protocol only for one transport or one broker product.
AMQP exposes sessions, links, transfers, and dispositions that look similar to MQTT concepts, so candidates collapse the two models and lose track of which layer owns credit-based flow control and message settlement.
What to do instead
Build a layer map: connection, session, link, transfer, disposition. Place flow-control credit at the link level and settlement (accepted, rejected, released, modified) at the disposition level, then contrast with MQTT's topic-filter subscription model and its acknowledgement packets.
Answering IoT security scenarios with a single control, such as 'use TLS', without addressing device identity, credential lifecycle, or least-privilege authorization for the protocol in use.
Candidates recall transport encryption as the headline control and stop there, missing that mutual authentication, per-device credentials, revocation, and broker or resource-level authorization are separate layers that the scenario usually tests.
What to do instead
Structure every security answer as a layered checklist: identity and provisioning (per-device keys or certificates), transport protection, authorization at the broker or resource server, credential rotation and revocation, secure update path, and audit logging. Name the concrete mechanism for the protocol in the scenario rather than a generic control.
Recommending a relational database for high-rate time-series sensor ingestion without discussing write amplification, retention, or downsampling, or conversely dismissing relational storage entirely for integration metadata.
Candidates frame the choice as relational versus NoSQL as a binary preference and do not separate the workload types an integration project actually has: high-volume telemetry, device and asset metadata, and configuration or state.
What to do instead
Split the data by workload and justify each store: time-series or wide-column for high-rate readings with retention and downsampling policies, relational for referential metadata and configuration, and a cache or stream for hot state. Mention indexing on time and device key, batch or bulk writes, and how the integration layer reconciles identifiers across stores.
Writing API integration answers that ignore idempotency, pagination, rate limiting, and error taxonomy, treating a successful call as the whole design.
Candidates focus on the happy-path request and response shape and have not practised reasoning about retries, partial failure, or long-running operations, which is where integration designs usually break.
What to do instead
For each endpoint described, state the idempotency mechanism for retried writes, the pagination or cursor strategy for reads, the handling of throttling responses with backoff, and which error classes are retryable versus terminal. Include how asynchronous operations are polled or notified and how versioning is handled.
Producing Python answers that mutate a default mutable argument, rely on truthiness where None is meaningful, or misjudge integer division and floating-point comparison.
These are habits from quick scripting; under exam pressure candidates write the shortest snippet that looks right and do not trace the shared-default-argument behaviour or the difference between a missing value and a falsy one.
What to do instead
Adopt a fixed review pass over any snippet: default arguments use None with an in-function assignment, comparisons against None use identity, division and rounding are stated explicitly, and float equality is replaced with a tolerance. Practise predicting output for small snippets that combine these traps.
Naming a Python IoT library without matching it to the protocol, transport, or client role in the scenario, or assuming an asynchronous client can be used like a blocking one.
Candidates memorize library names as vocabulary and do not connect them to what they actually implement, so they pick a client library that does not speak the required protocol version or misuse an event-loop-based client in synchronous code.
What to do instead
Maintain a small mapping table of library to protocol, client or server role, sync or async model, and notable limitations. For each entry, be able to sketch the minimal connect, publish or request, and disconnect flow, and note how it is integrated into a synchronous program or an existing event loop.
Writing requirements as implementation statements ('the gateway shall use MQTT') or omitting measurable acceptance criteria, then failing to trace a design or test back to a requirement.
Candidates describe the solution they have in mind instead of the observable need, and they have not practised distinguishing functional from non-functional requirements or writing verification conditions.
What to do instead
Rewrite each requirement in the form actor, observable behaviour, condition, and measurable threshold, and separate what the system does from qualities such as latency, availability, and security. For every requirement, name how it will be verified and keep a trace link to the design element and test that satisfy it.