🌍 Cloud Computing · flashcards

Cloud Computing Serverless and Application Services Flashcards

50 question-and-answer cards covering Serverless and Application Services as it is examined in Cloud Computing. 24 of them are printed below, taken from across the deck — no signup, no paywall on the preview.

50Cards in deck
24Free preview
15Syllabus topics
~225Chars per answer
FreePrice

24 sample cards from the Serverless and Application Services deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

  1. Contrast REST and GraphQL APIs.

    REST exposes multiple endpoints, each returning fixed resource representations, and can over-/under-fetch. GraphQL exposes a single endpoint where clients query exactly the fields they need in one request, reducing over-fetching but adding server-side complexity and harder HTTP caching.

  2. What are the core REST architectural constraints?

    Client-server separation, statelessness, cacheability, uniform interface, layered system, and (optionally) code-on-demand. Resources are identified by URIs and manipulated via standard HTTP methods.

  3. Map common HTTP methods to CRUD operations in REST.

    POST = Create, GET = Read (safe, idempotent), PUT = Replace/Update (idempotent), PATCH = Partial update, DELETE = Delete (idempotent). GET, PUT, DELETE are idempotent; POST is not.

  4. What are the three GraphQL root operation types?

    Query (read data), Mutation (write/modify data), and Subscription (real-time updates over a persistent connection, typically WebSockets).

  5. What is the N+1 problem in GraphQL and how is it mitigated?

    Resolving a list plus a related field triggers 1 query for the list and N queries for each item's relation. It is mitigated with batching/caching via a DataLoader that coalesces requests into a single batched fetch.

  6. What is an API Gateway?

    A managed service that sits in front of backend services as a single entry point, handling request routing, authentication/authorization, rate limiting/throttling, request/response transformation, caching, and protocol translation.

  7. List key features provided by a managed API Gateway.

    Routing, authN/authZ (API keys, JWT, IAM, OAuth), throttling/rate limiting, caching, request/response mapping/validation, usage plans, TLS termination, WAF integration, and monitoring/logging.

  8. Compare REST APIs and HTTP APIs in Amazon API Gateway.

    REST APIs offer richer features (API keys, usage plans, request validation, WAF, private endpoints) at higher cost. HTTP APIs are lower-latency, cheaper, and simpler, supporting JWT auth and Lambda/HTTP integrations but fewer advanced features.

  9. What is throttling in an API Gateway and how is it typically configured?

    Limiting the rate of requests to protect backends. Usually configured with a steady-state rate limit (requests per second) plus a burst limit (bucket capacity) using a token-bucket algorithm; excess requests receive HTTP 429.

  10. Explain the token-bucket algorithm used for rate limiting.

    A bucket holds up to $b$ tokens (burst capacity) and refills at rate $r$ tokens/sec. Each request consumes a token; if the bucket is empty the request is throttled. It allows short bursts up to $b$ while enforcing average rate $r$.

  11. What are common API versioning strategies?

    URI path versioning (/v1/users), query-parameter versioning (?version=1), custom header versioning (Api-Version: 1), and media-type/content-negotiation versioning (Accept: application/vnd.api.v1+json).

  12. Why version an API, and what is a breaking change?

    Versioning lets you evolve an API without breaking existing clients. A breaking change alters the contract in a backward-incompatible way (removing/renaming fields, changing types, altering required params, changing response structure).

  13. What is OpenAPI (Swagger) and what is it used for?

    A standard, language-agnostic specification (YAML/JSON) that describes REST APIs: endpoints, methods, parameters, request/response schemas, and auth. It enables auto-generated documentation, client SDKs, server stubs, and request validation.

  14. What is a managed message queue and what pattern does it enable?

    A fully managed service (e.g., Amazon SQS, Azure Service Bus) that stores messages between producers and consumers, enabling asynchronous, decoupled point-to-point communication where each message is processed by one consumer.

  15. Compare Amazon SQS Standard and FIFO queues.

    Standard: nearly unlimited throughput, best-effort ordering, at-least-once delivery (possible duplicates). FIFO: strict ordering within a message group, exactly-once processing (deduplication), but limited throughput (300 msg/s, up to 3000 with batching).

  16. What is the SQS visibility timeout?

    The period after a consumer receives a message during which the message is hidden from other consumers. If not deleted before the timeout expires, the message becomes visible again for reprocessing (default 30s).

  17. What is a dead-letter queue (DLQ)?

    A separate queue where messages are routed after failing to be processed successfully a configured number of times (max receive count). It isolates poison/problematic messages for later inspection without blocking the main queue.

  18. Contrast message queues with pub/sub notification services.

    A queue delivers each message to exactly one consumer (point-to-point, competing consumers). Pub/sub delivers each message to all subscribers of a topic (one-to-many broadcast/fan-out).

  19. What is Amazon SNS and how does it work?

    A managed pub/sub notification service. Publishers send messages to a topic; SNS pushes each message to all subscribers of that topic. Subscribers can be SQS queues, Lambda functions, HTTP(S) endpoints, email, or SMS.

  20. What is Google Cloud Pub/Sub and how does its delivery model differ from plain SNS?

    A managed messaging service combining pub/sub with durable message storage. Unlike push-only SNS, Pub/Sub decouples topics from subscriptions: each subscription retains messages and supports both pull and push delivery with at-least-once guarantees and acknowledgements.

  21. What is an event bus, and what is Amazon EventBridge?

    An event bus is a router that receives events and delivers them to targets based on rules. EventBridge is AWS's serverless event bus that ingests events from AWS services, SaaS partners, and custom apps, then routes them via content-based rule matching.

  22. How does EventBridge route events, and how does this differ from SNS?

    EventBridge uses rules with content-based filtering (event patterns matching JSON fields) to route to many targets, plus a schema registry and archive/replay. SNS routes by topic subscription with simpler attribute filtering and no built-in content routing or replay.

  23. When would you choose SQS vs. SNS vs. EventBridge?

    SQS: decouple with a durable queue and one consumer per message. SNS: high-throughput fan-out/broadcast to many subscribers. EventBridge: event-driven routing with rich content-based filtering, schema management, and many SaaS/AWS integrations.

  24. What delivery guarantee levels exist in messaging, and what do they mean?

    At-most-once (may lose messages, no duplicates), at-least-once (never lost but possible duplicates, requires idempotent consumers), and exactly-once (each message processed precisely once, hardest and costliest to guarantee).

What this deck covers

The Serverless and Application Services deck follows the Cloud Computing Serverless and Application Services syllabus — 4 chapters and 15 topics — so questions land on material that is genuinely examinable rather than trivia around it. That works out to roughly 12.5 cards per chapter.

Answers are written to be recallable, not just readable — averaging about 225 characters, which is long enough to carry the reasoning and short enough to say out loud.

A deck like this earns its keep on the second and third pass. Read the syllabus first so you know the shape of the subject, then use the cards to find the specific facts that have not stuck.

Serverless and Application Services flashcards FAQ

How many Serverless and Application Services flashcards are in this Cloud Computing deck?

50 cards. This page previews 24 of them, sampled evenly across the deck so you can judge the difficulty before installing anything.

Are these Cloud Computing flashcards free?

Yes. The preview here is free to read with no signup, and the full 50-card deck is free inside the Examius app.

What do the Serverless and Application Services cards cover?

They follow the Cloud Computing Serverless and Application Services syllabus — 4 chapters and 15 topics — so the questions track what is actually examinable.

How should I use these flashcards?

Read the syllabus first so you know the shape of the subject, then drill the deck. Examius schedules each card with spaced repetition, so cards you keep missing come back sooner and ones you know drift further apart.