examhub .cc The most efficient path to the most valuable certifications.
In this note ≈ 22 min

Other Service Categories (Integration, DevTools, IoT, End-User Compute)

4,280 words · ≈ 22 min read

Beyond compute, storage, database, and networking, the AWS portfolio fans out into four additional service families that the CLF-C02 exam groups under Task 3.8. These families — AWS integration services, AWS DevTools, AWS IoT, and AWS end-user compute — glue modern cloud architectures together, accelerate software delivery, connect physical devices, and deliver applications to human beings. This page distills exactly what a Cloud Practitioner candidate needs to recognize about AWS integration services, AWS DevTools, AWS IoT, AWS end-user compute, Amazon WorkSpaces, and AWS Step Functions, without drifting into solutions-architect-level depth.

The CLF-C02 exam tests these categories at use-case recognition depth: you should be able to match a scenario ("decouple microservices with a queue" or "stream an enterprise app to a browser") to the right AWS service name. You do not need to configure them, price them precisely, or debug them. That lets us cover a wide swath of AWS integration services, AWS DevTools, AWS IoT, and AWS end-user compute in a single notes page without overloading your memory.

What Are AWS Other Service Categories?

"Other service categories" is the CLF-C02 Exam Guide's umbrella label for services that do not fit squarely into compute, storage, database, or networking. Task statement 3.8 lists four groupings that make up the bulk of this umbrella: AWS integration services (messaging, workflows, SaaS connectors), AWS DevTools (CI/CD pipelines, IDEs, IaC frameworks), AWS IoT (device connectivity and edge), and AWS end-user compute (virtual desktops, app streaming, browser access).

Think of the exam focus as a breadth-over-depth sweep. Domain 3 weighs 34% of the exam and Task 3.8 is its smallest bucket — only ~100 practice questions across this entire page in our budget. But the services you see here are the ones most likely to appear as distractors in scenario questions, or as the "obvious right answer" when the scenario clearly screams "message queue" or "virtual desktop."

The Four Sub-Categories at a Glance

  • AWS integration services — glue services that move messages, events, and data between other services and SaaS apps. Examples: Amazon SQS, Amazon SNS, Amazon EventBridge, AWS Step Functions, Amazon MQ, Amazon AppFlow.
  • AWS DevTools — services that help developers build, test, release, and observe software. Examples: CodeBuild, CodeDeploy, CodePipeline, CodeArtifact, CodeCatalyst, CodeGuru, AWS X-Ray, AWS Cloud9, AWS CDK, AWS SAM, AWS Amplify.
  • AWS IoT — services that let you connect, secure, manage, and analyze fleets of physical devices. Examples: AWS IoT Core, AWS IoT Greengrass, AWS IoT Analytics, AWS IoT Device Defender, AWS IoT SiteWise.
  • AWS end-user compute — managed ways to deliver desktops, apps, and browser sessions to end users. Examples: Amazon WorkSpaces, Amazon AppStream 2.0, Amazon WorkSpaces Web.

Why the Exam Groups Them Together

All four families share a common trait for Cloud Practitioner purposes: they are specialized consumption points that sit on top of the core compute/storage/database/network plumbing. You rarely architect a system starting from AWS integration services; you add them when you need messaging, pipelines, device fleets, or end-user access layers. Grouping them keeps the exam guide tidy and lets you study them as a recognition-only set.

A queue (as in Amazon SQS) holds messages until a consumer pulls them. A topic (as in Amazon SNS) pushes messages to multiple subscribers simultaneously. An event bus (as in Amazon EventBridge) routes events from many sources to many targets using pattern rules. These three AWS integration services form the backbone of event-driven architectures.

Plain-Language Explanation: AWS Other Service Categories

分析 1:機場行李系統(AWS integration services)

Imagine a big international airport. Bags arrive at check-in, travel along conveyor belts, go through security scanners, get sorted by destination, and finally end up on the right plane. Amazon SQS is the queue conveyor belt — bags (messages) line up and get picked off one at a time, in order, so the downstream sorter is never overwhelmed. Amazon SNS is the announcement PA system — one announcement ("Flight BA123 now boarding") is pushed to every gate simultaneously. Amazon EventBridge is the airport control tower — it watches every event happening anywhere in the airport (weather alerts, gate changes, delays) and routes them based on rules ("if gate change for Lufthansa flights, notify ground crew and update departures board"). AWS Step Functions is the boarding checklist that defines the exact order: scan ticket, verify ID, weigh carry-on, board — with branches for "overweight → charge fee" and "invalid ticket → send to gate agent." This is the mental model for AWS integration services end-to-end.

分析 2:汽車裝配線(AWS DevTools)

AWS DevTools behave like a modern car assembly line. AWS CodeCommit (in legacy accounts) is the parts warehouse storing all the blueprints (source code). AWS CodeBuild is the stamping and welding station that turns raw parts into sub-assemblies (compiling code into binaries). AWS CodeDeploy is the final assembly robot that installs the engine and wheels onto the chassis (deploying to EC2, Lambda, ECS). AWS CodePipeline is the conveyor belt orchestrator that moves the car from one station to the next in the correct order, with quality gates between stations. AWS CodeArtifact is the certified-parts inventory (private package registry). Amazon CodeCatalyst is the entire modern greenfield factory that wires all of this together with project templates and dev environments. AWS X-Ray is the telemetry harness clipped to finished cars during road testing — it records exactly which subsystem slowed the car down. This is AWS DevTools in one picture.

分析 3:辦公大樓租賃(AWS end-user compute)

AWS end-user compute works like leasing office space. Amazon WorkSpaces is a long-term office lease — each employee gets their own office (persistent virtual desktop) with their name on the door; they come back every day to the same room with their posters still on the walls and their files on the desk. Amazon AppStream 2.0 is a hot-desk co-working floor — employees grab any available workstation, do their work, and everything wipes clean when they leave (ephemeral app streaming). Amazon WorkSpaces Web is the visitor-badge lobby kiosk — guests can access approved web apps through a secure browser without getting keys to the building (managed secure browser). Amazon WorkSpaces is the right answer when the scenario says "persistent desktop"; Amazon AppStream 2.0 is the right answer when the scenario says "stream a single application on demand."

Core Operating Principles

All AWS integration services, AWS DevTools, AWS IoT services, and AWS end-user compute services share four operating principles that the CLF-C02 exam loves to test.

Principle 1: Managed Control Planes, Customer Data Planes

Every service in this topic is a managed service. AWS operates the infrastructure, patches the software, handles availability, and hands you an API. You bring the payload — the message body (AWS integration services), the source code (AWS DevTools), the device fingerprint (AWS IoT), or the user session (AWS end-user compute). This maps directly to the shared responsibility model: for AWS integration services, AWS DevTools, AWS IoT, and AWS end-user compute, AWS owns "security OF the cloud" and you own "security IN the cloud."

Principle 2: Event-Driven by Default

Most AWS integration services operate on an event-driven model. Amazon SQS consumers pull when ready. Amazon SNS pushes to subscribers the moment a message hits a topic. Amazon EventBridge routes events based on pattern matching the moment they arrive on the bus. AWS Step Functions executes one state, waits for completion (or an event), then moves to the next. Recognizing "event-driven" is half the battle in answering AWS integration services exam questions.

Principle 3: Pay-Per-Use Billing

AWS integration services, AWS DevTools, AWS IoT, and AWS end-user compute (except Amazon WorkSpaces, which also offers monthly bundles) are billed on consumption. SQS bills per million requests. CodeBuild bills per build-minute. IoT Core bills per message. AppStream bills per streaming hour. WorkSpaces is the outlier with hourly and monthly bundles — memorize that exception.

Principle 4: Integration Over Isolation

These services rarely live alone. AWS integration services plug into Lambda and ECS. AWS DevTools deploy to EC2, Lambda, ECS, and EKS. AWS IoT routes to S3, Kinesis, and Lambda via rules. AWS end-user compute reads files from FSx and authenticates via AWS Directory Service or IAM Identity Center. Exam scenarios usually name two services — you choose the right integration service for a given compute/storage anchor.

Application Integration: AWS Integration Services Deep Dive

AWS integration services are the highest-yield family in this topic. Expect at least one exam question on SQS vs SNS vs EventBridge, and at least one on AWS Step Functions.

Amazon SQS — The Queue

Amazon Simple Queue Service (SQS) is a fully managed message queue. A producer writes messages into the queue; a consumer polls the queue and processes messages one by one. Messages are retained up to 14 days (default 4 days) until a consumer deletes them. This pull-based, one-consumer-per-message model makes SQS the canonical decoupling tool in AWS integration services.

SQS offers two queue types. Standard queues deliver at-least-once with best-effort ordering — nearly unlimited throughput, but occasional duplicates and out-of-order messages are possible. FIFO queues deliver exactly-once in strict first-in-first-out order, at up to 3,000 messages per second with batching. When a CLF-C02 scenario emphasizes "strict order" or "no duplicates," pick FIFO. When the scenario emphasizes "massive throughput" or "order doesn't matter," pick Standard.

Amazon SNS — The Topic

Amazon Simple Notification Service (SNS) is a managed publish/subscribe service. A publisher sends one message to a topic, and SNS pushes that message to every subscriber — SQS queues, Lambda functions, HTTP endpoints, email, SMS, mobile push. One-to-many fan-out is the defining pattern: a single inventory event can simultaneously trigger a warehouse Lambda, an analytics SQS queue, and an SMS alert.

SNS topics also come in standard and FIFO flavors, mirroring SQS.

Amazon EventBridge — The Event Bus

Amazon EventBridge (the successor to Amazon CloudWatch Events) is a serverless event bus that ingests events from AWS services, SaaS partners (Zendesk, PagerDuty, Datadog, Shopify), and your own applications, then routes them to targets using rules with pattern matching. A rule can say "when any S3 PutObject event in bucket X occurs, invoke Lambda Y and put a message on SQS Z." EventBridge also supports a schema registry and event archiving, neither of which Amazon SNS offers.

Amazon EventBridge vs Amazon SNS — The Classic Trap

The difference is subtle but testable. Amazon SNS is a push-only pub/sub topic — every subscriber gets every message unless filter policies apply. Amazon EventBridge is richer: events carry structured JSON schemas, rules match on any event attribute ("detail-type equals 'Object Created' AND source equals 'aws.s3'"), and you can archive and replay events for audit or recovery. Use SNS for simple fan-out; use EventBridge when you need content-based routing, SaaS ingestion, or replayability.

SNS and EventBridge are both pub/sub-flavored AWS integration services, so candidates treat them as interchangeable. They are not. EventBridge supports schema validation, event pattern matching on content, and SaaS partner event sources — SNS does not. A scenario saying "ingest events from Zendesk and route based on event type" is EventBridge, not SNS. A scenario saying "fan out to 5 SQS queues and 2 Lambdas" is SNS's sweet spot.

AWS Step Functions — The Workflow Orchestrator

AWS Step Functions is a serverless workflow / state machine service. You define a JSON-based workflow (Amazon States Language) that stitches together Lambda, ECS tasks, SageMaker jobs, API calls, and human approval steps into a visual flow with branching, parallelism, retries, and error handling. When the CLF-C02 exam asks "which service coordinates multiple Lambda functions into a reliable sequence with retries," the answer is AWS Step Functions.

Two workflow types exist: Standard (up to 1 year duration, exactly-once execution, audit-friendly) and Express (up to 5 minutes, at-least-once, extremely high throughput for event-driven apps).

Amazon MQ — The Legacy Broker

Amazon MQ is managed Apache ActiveMQ and RabbitMQ. It exists for one specific exam scenario: migrating an on-premises message broker to AWS without rewriting application code. If your on-prem app uses JMS, AMQP, MQTT, or STOMP protocols, Amazon MQ keeps those wire protocols intact. New cloud-native designs should prefer SQS or SNS instead.

Amazon AppFlow — SaaS Integration

Amazon AppFlow is a fully managed SaaS data integration service. It moves data between SaaS apps (Salesforce, Slack, ServiceNow, Zendesk, Google Analytics, Marketo, SAP) and AWS services (S3, Redshift) on a schedule or via events, with built-in filtering and transformation. When the exam says "securely transfer data from Salesforce to S3 without writing code," Amazon AppFlow is the answer.

On the CLF-C02 exam, the AWS integration services family maps to these defaults: decouple producers and consumers → Amazon SQS; fan out one message to many subscribers → Amazon SNS; content-based routing across AWS and SaaS events → Amazon EventBridge; multi-step workflow with branches and retries → AWS Step Functions; migrate on-prem JMS/AMQP broker → Amazon MQ; zero-code SaaS-to-AWS data transfer → Amazon AppFlow. Memorize these six.

Developer Tools: AWS DevTools Deep Dive

AWS DevTools is the second pillar of this topic. The CLF-C02 exam expects you to recognize each service's one-line role, not configure them.

The AWS Code Suite

The original AWS DevTools lineup — the AWS Code Suite — covers the full source-to-production pipeline:

  • AWS CodeCommit — private Git repository service. Status note: CodeCommit is closed to new AWS accounts since mid-2024. Existing customers can continue using it, but new accounts must use third-party Git (GitHub, GitLab, Bitbucket) or Amazon CodeCatalyst.
  • AWS CodeBuild — fully managed CI build service. Compiles source, runs tests, produces artifacts. Pay per build-minute.
  • AWS CodeDeploy — automated deployment service for EC2, Lambda, ECS, and on-premises servers. Supports in-place, blue/green, and canary deployments.
  • AWS CodePipeline — the CI/CD orchestrator. Wires CodeCommit (or GitHub) → CodeBuild → CodeDeploy into a repeatable pipeline with manual approval gates and parallel stages.
  • AWS CodeArtifact — private package registry for npm, PyPI, Maven, NuGet, Gradle, and more. Acts as a proxy and caches public packages for air-gapped environments.

Together these five cover the software delivery lifecycle end to end.

Amazon CodeCatalyst — The Unified Experience

Amazon CodeCatalyst is the modern unified software development service — it bundles source control (its own Git, or GitHub), CI/CD, issue tracking, and cloud dev environments into a single project-based UI. Think of it as AWS's answer to GitHub + GitHub Actions + GitHub Issues + Codespaces in one place. Scenarios mentioning "set up a new project with source, pipeline, and dev environment in minutes" point to CodeCatalyst.

Amazon CodeGuru — Reviewer and Profiler

Amazon CodeGuru has two halves:

  • CodeGuru Reviewer — ML-powered code review that flags security issues, resource leaks, and AWS-best-practice violations in pull requests.
  • CodeGuru Profiler — runtime application profiler that identifies the most expensive lines of code and their CPU/memory hotspots in production.

AWS X-Ray — Distributed Tracing

AWS X-Ray traces requests as they travel across your distributed application — through API Gateway, Lambda, ECS, DynamoDB, SNS, SQS — and produces a service map with per-hop latency. Use it to find which downstream service is the bottleneck. When the exam says "find the slow component in a microservice architecture," the answer is X-Ray.

AWS Cloud9 — Cloud IDE

AWS Cloud9 is a browser-based IDE with pre-installed AWS CLI tools, terminal access, and real-time collaborative editing. It runs on an EC2 instance or your own server. Cloud9 is useful for quick edits from any device and for pair programming.

Infrastructure as Code Frameworks

Two AWS DevTools deserve separate mention because they are infrastructure-as-code (IaC) abstractions over CloudFormation:

  • AWS CDK (Cloud Development Kit) — write CloudFormation stacks in TypeScript, Python, Java, Go, or C#. The CDK synthesizes the CloudFormation template at build time.
  • AWS SAM (Serverless Application Model) — a simplified CloudFormation DSL for serverless apps (Lambda, API Gateway, DynamoDB, SQS, SNS). SAM templates are shorter than raw CloudFormation and come with a local testing CLI.

Both AWS CDK and AWS SAM ultimately emit CloudFormation, so they benefit from CloudFormation's rollback and drift detection.

AWS Amplify — Full-Stack App Framework

AWS Amplify is a full-stack web and mobile framework that bundles hosting (like Vercel or Netlify), CI/CD, authentication (Cognito), GraphQL/REST APIs (AppSync/API Gateway), storage (S3), and data (DynamoDB) behind a single CLI. Amplify is the right answer when a scenario says "quickly scaffold a React or Flutter app with sign-in and backend APIs."

When an AWS DevTools scenario names a specific phase, pick the service that owns only that phase. "Build only" → AWS CodeBuild. "Deploy only" → AWS CodeDeploy. "Orchestrate multiple stages" → AWS CodePipeline. "All-in-one modern project" → Amazon CodeCatalyst. "Trace latency across microservices" → AWS X-Ray. Do not reach for CodePipeline when the question only mentions one phase — that is a distractor trap.

AWS IoT Services Deep Dive

AWS IoT services connect, secure, and analyze fleets of internet-connected devices — thermostats, factory sensors, cars, drones. The CLF-C02 exam asks recognition-level questions only.

AWS IoT Core — Device Connectivity

AWS IoT Core is the front door for devices. It accepts millions of simultaneous MQTT, HTTPS, or WebSocket connections from devices, authenticates them with X.509 certificates, and routes their messages to other AWS services via the rules engine. Every AWS IoT architecture starts with IoT Core.

AWS IoT Greengrass — Edge Runtime

AWS IoT Greengrass is an edge computing runtime that runs on devices or on-prem gateways. It lets you execute Lambda functions, ML models, and Docker containers locally on the device — useful when the device has intermittent connectivity or needs sub-second response times. Greengrass syncs with IoT Core in the cloud whenever connectivity is available.

AWS IoT Analytics

AWS IoT Analytics is a managed service for cleansing, transforming, and analyzing high-volume IoT device data. It ingests from IoT Core, runs queries, and hands structured results to QuickSight or ML pipelines.

AWS IoT Device Defender

AWS IoT Device Defender audits and monitors your IoT fleet for security misconfigurations and anomalous device behavior (a thermostat suddenly sending gigabytes of data is flagged).

AWS IoT SiteWise

AWS IoT SiteWise is purpose-built for industrial IoT — it collects, stores, organizes, and visualizes data from factory equipment, PLCs, and SCADA systems.

Memorize the four AWS IoT exam keywords: IoT Core = device connectivity and message routing; IoT Greengrass = local edge runtime for offline/low-latency; IoT Analytics = managed data cleansing and analytics for device data; IoT Device Defender = security monitoring and auditing of the device fleet; IoT SiteWise = industrial equipment data collection. Every CLF-C02 IoT question reduces to one of these five keywords.

AWS End-User Compute Deep Dive

AWS end-user compute delivers workplace experiences — desktops, applications, and browser access — to end users without shipping physical hardware. Amazon WorkSpaces is the flagship service.

Amazon WorkSpaces — Virtual Desktops (DaaS)

Amazon WorkSpaces is a managed Desktop-as-a-Service (DaaS) offering. Each user gets a persistent Windows or Ubuntu Linux desktop in the AWS cloud, accessible from the WorkSpaces client on Windows, macOS, iPad, Chromebook, Android, or through a browser. Documents, installed apps, and customizations persist between sessions — a user logs in Monday, logs off, and finds everything exactly where they left it on Tuesday.

Amazon WorkSpaces is billed either hourly (for intermittent users) or monthly (for daily users) — the hourly-vs-monthly tradeoff is a known exam question. Amazon WorkSpaces integrates with Active Directory, AWS Directory Service, and IAM Identity Center for authentication. Amazon WorkSpaces is the default right answer when the exam scenario says "persistent virtual desktop for remote employees."

Amazon AppStream 2.0 — Application Streaming

Amazon AppStream 2.0 streams a single application (rather than a full desktop) to the user's browser. The application runs on a temporary EC2-backed streaming instance in AWS; the user sees only the app window. When the user logs off, the streaming instance is torn down — nothing persists by default unless you attach home folders or user data on S3.

When to pick Amazon AppStream 2.0 over Amazon WorkSpaces: the user only needs one specific application (a CAD tool, a training simulator, a licensed desktop app for a short engagement) rather than a full desktop they live in daily.

Amazon WorkSpaces Web — Secure Browser

Amazon WorkSpaces Web is a managed secure browser service. Users get a hardened Chromium browser session running in AWS that they access via their own browser. IT teams use it to give contractors, BYOD users, or internal staff secure, temporary access to internal web apps and SaaS portals without deploying VPN clients or full virtual desktops.

Amazon WorkDocs — Deprecated

Amazon WorkDocs was a managed document collaboration service (think Google Drive for enterprises). AWS deprecated WorkDocs in April 2025; it is no longer accepting new customers. You may still see it listed in older practice questions; the current CLF-C02 exam is unlikely to feature it as a correct answer.

Amazon WorkSpaces delivers a persistent full desktop (daily-use work environment). Amazon AppStream 2.0 delivers an ephemeral single application (one-off or short-duration app access). Amazon WorkSpaces Web delivers a secure browser session (web-app access without a full OS). All three are AWS end-user compute, but they solve different problems. When a scenario says "persistent desktop" → Amazon WorkSpaces. "Stream a single app" → AppStream 2.0. "Secure browser for internal web apps" → WorkSpaces Web.

Key Numbers and Must-Memorize Facts

The CLF-C02 exam rarely tests exact limits, but a handful of numbers and defaults do appear across AWS integration services, AWS DevTools, AWS IoT, and AWS end-user compute.

  • Amazon SQS message retention: 1 minute to 14 days, default 4 days.
  • SQS FIFO throughput: up to 3,000 messages/second with batching.
  • AWS Step Functions Standard workflow duration: up to 1 year.
  • AWS Step Functions Express workflow duration: up to 5 minutes.
  • AWS IoT Core protocols: MQTT, MQTT over WSS, HTTPS.
  • Amazon WorkSpaces billing modes: hourly (pay-as-you-use) and monthly (unlimited).
  • AWS CodeCommit status: closed to new accounts (2024+); use CodeCatalyst or third-party Git.
  • Amazon WorkDocs status: deprecated April 2025.

Common Exam Traps

Trap 1: SQS vs SNS — Pull vs Push

Amazon SQS is pull (consumers poll the queue); Amazon SNS is push (SNS pushes to subscribers the moment a message arrives). When a scenario says "the consumer processes messages at its own pace," that is SQS. "Notify multiple systems instantly" is SNS.

Trap 2: EventBridge is Not SNS

As covered earlier, EventBridge supports schemas, content-based pattern matching, SaaS partner events, and event archive/replay. SNS is simpler pub/sub. Any scenario mentioning Zendesk, Shopify, Datadog, schema, or replay points to EventBridge.

Trap 3: Step Functions vs Lambda

AWS Lambda runs one function triggered by an event. AWS Step Functions orchestrates many Lambdas (and other services) into a workflow with branches, retries, and wait states. If a scenario has a single function, pick Lambda. If it has "coordinate three Lambdas with conditional branching," pick AWS Step Functions.

Trap 4: CodeCommit Status for New Accounts

CodeCommit is closed to new AWS accounts. If the scenario involves a new customer setting up Git hosting, the right answer is GitHub/GitLab/Bitbucket + CodePipeline, or Amazon CodeCatalyst. Do not assume CodeCommit is available.

Trap 5: WorkSpaces vs AppStream

Persistent daily desktop = Amazon WorkSpaces. Ephemeral on-demand single app = Amazon AppStream 2.0. Do not confuse these.

Trap 6: CloudWatch Events vs EventBridge

Amazon EventBridge is the rebrand/evolution of Amazon CloudWatch Events. They share the same underlying service. Any new documentation says EventBridge. Old references to "CloudWatch Events" still work but should point your brain to EventBridge.

Service Scope Boundaries

Task 3.7 (AI/ML & Analytics) vs Task 3.8 (Other Service Categories)

AI/ML services (Bedrock, SageMaker, Rekognition, Comprehend) and analytics services (Athena, Redshift, Kinesis, Glue, QuickSight) belong to Task 3.7 — not this page. If a scenario mentions "run ML models" or "query S3 data lake," it is 3.7, not 3.8.

Task 3.1 (Deployment) vs Task 3.8 (DevTools)

AWS CloudFormation, AWS Elastic Beanstalk, and AWS OpsWorks live in Task 3.1 (Deployment & Operation Methods). AWS CDK and AWS SAM, though they emit CloudFormation, are AWS DevTools — they ship with a developer CLI and target a developer audience, so the exam guide classifies them under Task 3.8. This boundary is fuzzy; expect either grouping in practice questions.

Task 3.3 (Compute) vs Task 3.8 (End-User Compute)

Amazon EC2, AWS Lambda, AWS Fargate, ECS, and EKS are Task 3.3 compute. Amazon WorkSpaces, Amazon AppStream 2.0, and Amazon WorkSpaces Web are Task 3.8 end-user compute. The distinction: Task 3.3 compute runs your application code; Task 3.8 AWS end-user compute runs an interactive desktop or app for a human.

Side-by-Side Comparisons

AWS Integration Services Selection Matrix

  • Decouple producer and consumer, one-consumer-per-message → Amazon SQS
  • One message to many subscribers (fan-out) → Amazon SNS
  • Content-based routing, SaaS event ingestion, event replay → Amazon EventBridge
  • Multi-step workflow with branching, retries, human approval → AWS Step Functions
  • Migrate on-prem JMS/AMQP/MQTT broker without code rewrite → Amazon MQ
  • Zero-code data transfer from Salesforce/Slack/SAP to S3/Redshift → Amazon AppFlow

AWS DevTools Selection Matrix

  • Private Git (legacy accounts only) → AWS CodeCommit
  • Compile and test code → AWS CodeBuild
  • Deploy artifacts to EC2/Lambda/ECS/on-prem → AWS CodeDeploy
  • Orchestrate build and deploy stages → AWS CodePipeline
  • Private npm/PyPI/Maven registry → AWS CodeArtifact
  • Unified project (repo + CI/CD + issues + dev env) → Amazon CodeCatalyst
  • Automated code review and runtime profiling → Amazon CodeGuru
  • Distributed tracing → AWS X-Ray
  • Browser-based IDE → AWS Cloud9
  • IaC in TypeScript/Python → AWS CDK
  • Simplified serverless IaC → AWS SAM
  • Full-stack web/mobile app framework → AWS Amplify

AWS End-User Compute Selection Matrix

  • Persistent daily virtual desktop → Amazon WorkSpaces
  • Ephemeral single-application streaming → Amazon AppStream 2.0
  • Managed secure browser for internal web apps → Amazon WorkSpaces Web

FAQ — AWS Other Service Categories Top 6 Questions

Q1: When should I pick Amazon SQS over Amazon SNS? A: Use Amazon SQS when you need one consumer per message and the consumer processes at its own pace. Use Amazon SNS when you need fan-out — one message delivered to many subscribers simultaneously. A common pattern combines them: SNS publishes to a topic that fans out to several SQS queues.

Q2: What is the difference between Amazon EventBridge and Amazon SNS? A: Amazon SNS is a simple push-based pub/sub topic. Amazon EventBridge is a feature-rich event bus that supports structured event schemas, content-based pattern matching on any event attribute, SaaS partner event sources (Zendesk, Shopify, Datadog, etc.), and event archive/replay. Pick EventBridge when you need richer routing; pick SNS for simple fan-out.

Q3: Is AWS CodeCommit still available? A: AWS CodeCommit is closed to new AWS accounts as of mid-2024. Existing customers keep using it, but new accounts must use third-party Git providers (GitHub, GitLab, Bitbucket) or Amazon CodeCatalyst. Expect the exam to test recognition of this status change.

Q4: Amazon WorkSpaces vs Amazon AppStream 2.0 — which do I pick? A: Pick Amazon WorkSpaces when users need a persistent virtual desktop they return to every day (full work environment). Pick Amazon AppStream 2.0 when users need one specific application on demand (training software, CAD tool, licensed app for a short engagement) that does not need to persist between sessions.

Q5: What does AWS Step Functions do that AWS Lambda cannot? A: AWS Lambda runs a single function. AWS Step Functions orchestrates multiple Lambdas (and other AWS services) into a workflow with branching logic, parallel execution, retries with exponential backoff, wait states, and human approval steps. Step Functions provides a visual state machine diagram; Lambda is one node in the graph.

Q6: Why does AWS have both Amazon MQ and Amazon SQS? A: Amazon MQ exists for migration scenarios — it speaks the JMS, AMQP, MQTT, and STOMP wire protocols that on-premises apps built around ActiveMQ or RabbitMQ already use. Amazon SQS is an AWS-native HTTP API. New cloud-native designs should prefer SQS; Amazon MQ is primarily for lift-and-shift of existing broker-dependent apps.

At 100 questions in the Domain 3 budget, Task 3.8 is the smallest topic on the entire exam but one of the broadest in service count. Recommended study sequence:

  1. Drill AWS integration services scenarios — SQS vs SNS vs EventBridge vs Step Functions (~40 questions).
  2. Drill AWS DevTools service identification — Code Suite + CodeGuru + X-Ray + Amplify (~30 questions).
  3. Drill AWS IoT service recognition — IoT Core vs Greengrass vs Analytics vs Device Defender vs SiteWise (~15 questions).
  4. Drill AWS end-user compute — Amazon WorkSpaces vs AppStream vs WorkSpaces Web (~15 questions).

Final Exam Strategy

The CLF-C02 exam weights this topic lightly (smallest Domain 3 allocation), so your study ROI is in recognition speed, not depth. Treat AWS integration services as the highest-yield sub-family because the SQS/SNS/EventBridge/Step Functions matrix generates the most scenario questions. Treat AWS DevTools as medium yield — memorize the one-line role of each Code Suite service, CodeGuru, X-Ray, CDK, SAM, and Amplify. Treat AWS IoT and AWS end-user compute as recognition-only — memorize the five IoT keywords and the three end-user compute keywords. On exam day, if you see any service name from this page, pattern-match it to its sub-family and pick the scenario's most obvious fit.

AWS integration services, AWS DevTools, AWS IoT, and AWS end-user compute together account for roughly 5% of the total exam score — but they are disproportionately represented as distractors in other domains' scenario questions. Knowing Amazon WorkSpaces is a persistent desktop and AWS Step Functions is a workflow orchestrator will save you points across the entire exam, not just in Task 3.8.

Official sources