CEH Wireless, IoT and Cloud Security Practice Question
You are the security lead for a multinational corporation that uses a hybrid cloud architecture with AWS and on-premises data centers. The company recently deployed a fleet of IoT sensors in a remote factory to monitor equipment. These sensors communicate via MQTT to an AWS IoT Core endpoint, which forwards data to an S3 bucket and a DynamoDB table. The factory network is isolated but has a site-to-site VPN to the corporate HQ. Over the past week, the S3 bucket has experienced an unusual number of PUT requests from an IP address that resolves to a known malicious host. The DynamoDB table shows write spikes at odd hours. The MQTT broker logs indicate that some sensors are publishing data with invalid client IDs. Meanwhile, the VPN logs show no anomalies. You need to identify the likely attack vector and recommend a course of action. Which of the following is the BEST course of action?
⚠ Common exam trap
The trap here is that candidates focus on network-level controls (VPN, bastion hosts) or data relocation, missing that the attack exploits weak IoT device authentication at the application layer, which requires identity-based controls like client certificates.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Implement client certificate authentication on AWS IoT Core and revoke any unregistered client IDs.
The attack exploits weak authentication on MQTT connections to AWS IoT Core. By implementing client certificate authentication, you ensure only registered devices with valid X.509 certificates can publish data, directly blocking the malicious PUT requests and write spikes. Revoking unregistered client IDs eliminates the invalid client IDs observed in the MQTT broker logs, closing the primary attack vector without disrupting legitimate sensor traffic.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Disable the site-to-site VPN and require all traffic to go through a bastion host.
Why it's wrong here
Disabling the site-to-site VPN is an inappropriate response as the VPN facilitates secure network connectivity between on-premises infrastructure and cloud resources, which is unrelated to unauthenticated PUT requests targeting AWS IoT Core. This action would severely disrupt legitimate business operations and data flows without addressing the specific vulnerability of unauthorized device communication with the IoT platform. A bastion host primarily secures administrative access to private network segments, not public-facing IoT endpoints.
- ✓
Implement client certificate authentication on AWS IoT Core and revoke any unregistered client IDs.
Why this is correct
Implementing client certificate authentication on AWS IoT Core mandates that all devices present a valid, trusted X.509 certificate to establish a secure, authenticated connection before publishing data. This cryptographic identity verification prevents unauthorized entities from injecting malicious PUT requests by ensuring only provisioned and registered sensors can interact with the platform. Revoking any unregistered client IDs further tightens security by invalidating any potential rogue or compromised credentials.
- ✗
Move the S3 bucket and DynamoDB table to the on-premises data center to reduce cloud exposure.
Why it's wrong here
Moving S3 buckets and DynamoDB tables to an on-premises data center is an extreme and costly measure that fundamentally misunderstands the source of the vulnerability. The issue stems from unauthenticated PUT requests targeting AWS IoT Core, indicating a lack of proper authentication at the IoT endpoint, not the exposure or security of the backend data storage services themselves. This action would introduce significant operational overhead and latency without resolving the critical authentication gap at the IoT platform.
- ✗
Replace all IoT sensors with new ones that have firmware-level encryption.
Why it's wrong here
Replacing all IoT sensors with new ones featuring firmware-level encryption is an unnecessary and expensive undertaking that misidentifies the attack vector. The problem described involves unauthorized PUT requests directly to the AWS IoT Core endpoint, indicating a lack of proper authentication at the cloud service level, not a compromise of the physical sensors or their inability to encrypt data during transmission. While firmware encryption is beneficial for data at rest or in transit from the device, it does not solve the issue of unauthenticated access to the IoT platform.
Visual reference
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
This CEH question is part of Courseiva's 870-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CEH practice question is part of Courseiva's free EC-Council certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CEH exam.