Edge computing and IoT show up on the Professional Cloud Architect exam in scenarios where you have devices in the field generating data, and you need to decide where the processing happens and how the data gets back to Google Cloud. The two ideas are related but distinct, so I want to separate them clearly before getting into the architecture pattern that the PCA exam tests most often.
Edge computing means processing data locally, near the source that generated it, rather than shipping every byte back to a centralized cloud region for analysis. The source might be a sensor on a factory floor, a camera on a vehicle, or a phone in someone's pocket. The point is that compute happens close to the data instead of far away from it.
The reason to do this is usually one of three things. Latency, because a round trip to a cloud region and back is too slow for the use case. Connectivity, because the device operates in places where the network is unreliable or absent. Bandwidth, because sending raw video or telemetry from thousands of devices to the cloud is expensive and often unnecessary if you only care about the events that the data describes.
An autonomous vehicle is the canonical example. It cannot wait for a cloud region to tell it whether the object in front of it is a person. The decision has to happen on the vehicle, in milliseconds, using a model that has already been deployed to the device. Remote monitoring systems in oil fields or mining operations are similar. The connection to the cloud is intermittent, so the device has to be able to keep working when it is offline and sync up later.
The trend that makes this more interesting is that models keep getting smaller. Techniques like quantization and distillation are now good enough that you can run a useful language model on a phone, which means edge inference is no longer limited to small classification models on tiny sensors.
Edge computing answers where the processing happens. IoT connectivity answers how the device gets data back to the cloud when it does need to send something. These are different problems, and the PCA exam treats them as different problems.
The challenge with IoT connectivity is scale and unreliability. You might have hundreds of thousands of devices on cellular networks, where the signal cuts in and out, the bandwidth varies, and you cannot assume any single device is online at any given moment. The architecture has to absorb that variability without losing data and without falling over when traffic spikes.
The two protocols that come up are MQTT and HTTPS. MQTT is a lightweight publish-subscribe protocol designed for low-power devices and constrained networks. It uses a broker that sits between publishers and subscribers, and the messages themselves are small, which matters when you are paying for cellular data on every device. HTTPS is heavier but more universally supported, and it is the right choice when you need to integrate with devices that already speak HTTP or when you want maximum compatibility across vendors.
You ingest the messages into a broker like Eclipse Mosquitto for MQTT, or you point the devices at an HTTPS endpoint that you host yourself. From there, the standard pattern is to push everything into Cloud Pub/Sub so that downstream services can consume the stream reliably. Pub/Sub is what gives you the buffering, the at-least-once delivery, and the ability to fan out to multiple consumers without coupling the ingestion path to any single processing system.
If you took practice exams from a few years ago, you saw Cloud IoT Core as the recommended managed service for this. Google deprecated and shut down Cloud IoT Core, so any current PCA question that references it as the right answer is out of date. The current Google-recommended pattern is to roll your own ingestion using an MQTT broker or HTTPS endpoint, and then connect that to Pub/Sub.
This is the kind of thing that trips people up on the exam. If you see Cloud IoT Core in the answer choices, it is a distractor. The right answer is a custom architecture, not a managed IoT service from Google.
The exam likes to use a fictional case where a company called TerramEarth has 200,000 vehicles connected over cellular, and you have to design the ingestion architecture. The shape of the question is always the same. You see a list of components and you have to pick the ones that fit.
The right answer is a custom architecture using an MQTT broker or an HTTPS endpoint for ingestion, with Cloud Pub/Sub behind it as the messaging backbone. That combination handles the scale, the unreliability of cellular networks, and the requirement for secure transport.
The wrong answers tend to look like this. App Engine with custom SSL certificates is for web applications and does not have the IoT-specific characteristics you need. Cloud Functions with project-wide API keys can handle small event-driven workloads, but project-wide keys are a security problem and Functions is not the right fit for sustained high-volume ingestion from hundreds of thousands of devices. Cloud Run can serve as a piece of a larger IoT architecture, hosting your HTTPS endpoint or a downstream processor, but on its own it does not solve the connectivity problem.
If you internalize the pattern, MQTT or HTTPS in front, Pub/Sub behind, custom architecture rather than a Google-managed IoT service, you will get every variation of this question right.
For edge computing, know that it means processing close to the data source, why you would choose it over centralized cloud processing, and the categories of use cases where it applies. You do not need to memorize specific edge hardware or framework names. You need to recognize when a scenario requires edge processing and when it is fine to send everything to the cloud.
For IoT connectivity, know that Cloud IoT Core is gone, that the recommended pattern is a custom MQTT or HTTPS ingestion layer feeding Pub/Sub, and that the protocol choice depends on whether you need lightweight messaging on constrained devices or maximum compatibility through standard HTTP.
My Professional Cloud Architect course covers edge computing and IoT connectivity alongside the rest of the architecture and compliance material.
