# Smoke test data: AWS Documentation MCP server + 100 prompt links.
# Apply with: mcpctl apply -f smoke-data.yaml
# Used by proxy-pipeline smoke tests — do NOT depend on personal resources.

servers:
  - name: smoke-aws-docs
    description: "AWS Documentation MCP server (smoke test instance)"
    packageName: "awslabs.aws-documentation-mcp-server"
    runtime: python
    transport: STDIO
    replicas: 1
    env:
      - name: FASTMCP_LOG_LEVEL
        value: "ERROR"

projects:
  - name: smoke-data
    description: "Smoke test project with 100 AWS documentation prompt links"
    gated: true

serverattachments:
  - server: smoke-aws-docs
    project: smoke-data

prompts:
  # ── Amazon S3 (10 prompts) ──

  - name: aws-s3-overview
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/s3/"
    content: |
      Amazon Simple Storage Service (Amazon S3) is an object storage service offering industry-leading scalability, data availability, security, and performance. S3 stores data as objects within buckets. An object consists of a file and optionally any metadata that describes that file. A key uniquely identifies an object within a bucket. S3 provides virtually unlimited storage capacity with 99.999999999% (11 9s) durability and 99.99% availability. Use cases include data lakes, website hosting, mobile applications, backup and restore, archive, enterprise applications, IoT devices, and big data analytics. S3 offers multiple storage classes for different access patterns: S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, S3 One Zone-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, and S3 Glacier Deep Archive.

  - name: aws-s3-buckets
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/s3/latest/userguide/creating-bucket.html"
    content: |
      An Amazon S3 bucket is a container for objects stored in Amazon S3. Every object is contained in a bucket. Bucket names must be globally unique across all AWS accounts, between 3 and 63 characters long, consist only of lowercase letters, numbers, hyphens, and periods. Buckets are created in a specific AWS Region. When creating a bucket, you can configure options such as bucket versioning, server access logging, default encryption, object lock, and tags. The bucket owner has full control by default through bucket policies and access control lists. S3 Block Public Access settings can be applied at the bucket level to prevent public access. A single AWS account can own up to 100 buckets by default, but this limit can be increased to 1000 through a service limit increase request.

  - name: aws-s3-objects
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/s3/latest/userguide/UsingObjects.html"
    content: |
      Objects are the fundamental entities stored in Amazon S3. An object consists of object data and metadata. The metadata is a set of name-value pairs that describe the object, including default metadata like date last modified and standard HTTP metadata like Content-Type. Each object is uniquely identified within a bucket by a key (name) and a version ID if versioning is enabled. Object keys can be up to 1024 bytes long using UTF-8 encoding. Objects can be up to 5 TB in size. For objects larger than 100 MB, multipart upload is recommended; for objects larger than 5 GB, multipart upload is required. S3 supports copying objects within S3, creating presigned URLs for temporary access, and tagging objects with up to 10 key-value pairs for lifecycle management, access control, and analytics.

  - name: aws-s3-versioning
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/s3/latest/userguide/Versioning.html"
    content: |
      S3 Versioning enables you to keep multiple variants of an object in the same bucket, preserving, retrieving, and restoring every version of every object. With versioning enabled, you can recover from both unintended user actions and application failures. A bucket can be in one of three states: unversioned (default), versioning-enabled, or versioning-suspended. Once versioning is enabled, it can never be fully disabled, only suspended. When you PUT an object in a versioning-enabled bucket, the noncurrent version is not overwritten. When you DELETE an object, instead of removing it permanently, S3 inserts a delete marker which becomes the current version. You can restore a previous version by either deleting the delete marker or copying a specific version over the current one. MFA Delete can require additional authentication for changing versioning state or permanently deleting an object version.

  - name: aws-s3-lifecycle
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/s3/latest/userguide/object-lifecycle-mgmt.html"
    content: |
      S3 Lifecycle configuration enables you to manage objects and their cost-effectiveness throughout their lifecycle by defining rules that transition objects to lower-cost storage classes or expire objects that are no longer needed. A lifecycle rule consists of a filter (prefix, tags, or object size) and one or more actions (Transition or Expiration). Transition actions move objects between storage classes, for example from S3 Standard to S3 Glacier after 30 days. Expiration actions delete objects after a specified period. Lifecycle rules can also clean up incomplete multipart uploads, expire noncurrent versions of versioned objects, and transition noncurrent versions to cheaper storage classes. Rules are processed asynchronously and may take some time to complete. Up to 1000 lifecycle rules can be configured per bucket.

  - name: aws-s3-encryption
    project: smoke-data
    priority: 7
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/s3/latest/userguide/serv-side-encryption.html"
    content: |
      Amazon S3 provides server-side encryption to protect data at rest. There are three options: SSE-S3 (S3-managed keys using AES-256), SSE-KMS (AWS Key Management Service keys), and SSE-C (customer-provided keys). As of January 2023, S3 automatically applies SSE-S3 encryption to all new objects. With SSE-KMS, you can use the AWS managed key or a customer managed key, enabling additional access control through key policies and audit trails via CloudTrail. SSE-C lets you manage your own encryption keys; S3 performs encryption and decryption but you must provide the key with every request. S3 also supports client-side encryption where you encrypt data before uploading. Bucket policies can enforce encryption by denying PUT requests that don't include encryption headers. S3 Bucket Keys reduce costs by decreasing requests to AWS KMS.

  - name: aws-s3-replication
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/s3/latest/userguide/replication.html"
    content: |
      S3 Replication enables automatic, asynchronous copying of objects across buckets. Same-Region Replication (SRR) copies objects between buckets in the same AWS Region. Cross-Region Replication (CRR) copies objects across buckets in different Regions. Replication requires versioning enabled on both source and destination buckets. Replication rules specify what to replicate using filters (prefix, tags), which destination bucket to use, and optional configurations like storage class override, encryption, and ownership. Replication Time Control (RTC) provides an SLA that 99.99% of objects will be replicated within 15 minutes. S3 Replication Metrics provides detailed replication monitoring. Batch Replication can replicate existing objects that were added before replication was configured. Delete markers can optionally be replicated with delete marker replication enabled.

  - name: aws-s3-access-points
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/s3/latest/userguide/access-points.html"
    content: |
      Amazon S3 Access Points simplify managing data access at scale for shared datasets. Each access point has its own permissions, network controls, and Block Public Access settings. Access points are named network endpoints attached to buckets that enforce distinct permissions and configurations. You can create up to 10,000 access points per Region per account. Access points support both internet and VPC-restricted access. Each access point has a unique hostname and can have an access point policy that works in conjunction with the underlying bucket policy. Multi-Region Access Points provide a single global endpoint for routing S3 requests across multiple Regions, automatically routing requests to the closest bucket for lowest latency. Access points can be restricted to VPC origins using VPC endpoint policies.

  - name: aws-s3-event-notifications
    project: smoke-data
    priority: 3
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/s3/latest/userguide/EventNotifications.html"
    content: |
      S3 Event Notifications enable you to receive notifications when certain events happen in your bucket. Supported events include object creation (PUT, POST, COPY, multipart upload), object removal (DELETE, lifecycle expiration), object restore from Glacier, replication events, and S3 Intelligent-Tiering transitions. Notifications can be sent to Amazon SNS topics, Amazon SQS queues, AWS Lambda functions, or Amazon EventBridge. When using EventBridge as the destination, you gain access to advanced filtering, multiple destinations, and integration with over 18 AWS services. Event notification messages are delivered at least once and are typically delivered within seconds. The notification configuration is set on the bucket and can include filters based on object key name prefixes and suffixes.

  - name: aws-s3-transfer-acceleration
    project: smoke-data
    priority: 3
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/s3/latest/userguide/transfer-acceleration.html"
    content: |
      S3 Transfer Acceleration enables fast, easy, and secure transfers of files over long distances between your client and an S3 bucket. Transfer Acceleration uses the globally distributed edge locations of Amazon CloudFront. Data is routed to S3 over an optimized network path using Amazon backbone network infrastructure. Transfer Acceleration is useful when uploading from across the world to a centralized bucket, when transferring gigabytes to terabytes regularly, or when utilizing less than the available bandwidth over the internet. To use Transfer Acceleration, enable it on the bucket and use a distinct endpoint URL with the format bucketname.s3-accelerate.amazonaws.com. Transfer Acceleration incurs an additional per-GB data transfer fee. The Speed Comparison tool helps estimate whether Transfer Acceleration will improve performance for your location.

  # ── AWS Lambda (10 prompts) ──

  - name: aws-lambda-overview
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/lambda/"
    content: |
      AWS Lambda is a serverless compute service that runs your code in response to events and automatically manages the underlying compute resources. Lambda runs your code on high-availability compute infrastructure and performs all the administration of compute resources including server and operating system maintenance, capacity provisioning, automatic scaling, and logging. You organize your code into Lambda functions, which run only when triggered and scale automatically from a few requests per day to thousands per second. You pay only for the compute time you consume with no charge when code is not running. Lambda supports multiple programming languages including Node.js, Python, Java, C#, Go, Ruby, and custom runtimes via the Runtime API. Functions can be triggered by over 200 AWS services and SaaS applications, or called directly via HTTP endpoints.

  - name: aws-lambda-functions
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/lambda/latest/dg/lambda-functions.html"
    content: |
      A Lambda function is the fundamental resource in AWS Lambda. You can configure a function using the Lambda console, Lambda API, AWS CloudFormation, or AWS SAM. A function's configuration includes its name, runtime, handler, IAM execution role, memory allocation (128 MB to 10240 MB), timeout (up to 15 minutes), and environment variables. Lambda allocates CPU power proportional to the memory configured. Functions can access resources in a VPC by configuring VPC subnets and security groups. Ephemeral storage (/tmp) can be configured from 512 MB to 10240 MB. Functions support up to 5 layers providing shared code and libraries. Lambda function URLs provide HTTPS endpoints for direct invocation without API Gateway. Qualified ARNs include the version or alias, while unqualified ARNs always reference the $LATEST version.

  - name: aws-lambda-layers
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html"
    content: |
      Lambda layers provide a convenient way to package libraries and other dependencies to use with Lambda functions. Layers reduce the size of uploaded deployment archives and promote code sharing and separation of concerns. A layer is a ZIP archive containing libraries, a custom runtime, or other dependencies. A function can use up to 5 layers at a time. The total unzipped size of the function and all layers cannot exceed 250 MB. When a layer is included, its contents are extracted to the /opt directory in the execution environment. Layers support versioning and each version is immutable. Layers can be shared across accounts by granting usage permissions. AWS and AWS Partners provide public layers for popular libraries and runtimes.

  - name: aws-lambda-runtimes
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html"
    content: |
      Lambda runtimes provide a language-specific environment that runs in an execution environment. Lambda supports managed runtimes for Node.js, Python, Java, .NET, Ruby, and OS-only runtimes for Go and Rust (via provided.al2023). Each runtime has a maintenance policy: after end-of-support, Lambda no longer applies security patches and functions using deprecated runtimes may be blocked from creation. Custom runtimes can be built using the Runtime API, packaged as either a layer or included in the function deployment package. The runtime interface implements the Lambda Runtime API to coordinate with the Lambda service. Container image support allows packaging functions as OCI-compatible container images up to 10 GB in size using Lambda-provided base images or alternative base images that implement the runtime interface client.

  - name: aws-lambda-cold-starts
    project: smoke-data
    priority: 8
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html"
    content: |
      Cold starts occur when Lambda creates a new execution environment to handle a request. During a cold start, Lambda downloads the function code, creates the execution environment, initializes the runtime and extensions, and runs the function initialization code. This typically adds latency of 100ms to several seconds depending on runtime, package size, and initialization logic. Provisioned Concurrency pre-initializes a requested number of execution environments so they are prepared to respond immediately. SnapStart (for Java) reduces cold start latency by caching a snapshot of the initialized execution environment. Best practices for minimizing cold starts include keeping deployment packages small, initializing SDK clients outside the handler, using provisioned concurrency for latency-sensitive workloads, and choosing lightweight runtimes. After initialization, the execution environment is reused for subsequent invocations.

  - name: aws-lambda-event-sources
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html"
    content: |
      Lambda functions can be triggered by events from AWS services through event source mappings and direct invocations. Event source mappings poll services like SQS, Kinesis, DynamoDB Streams, Amazon MSK, and self-managed Apache Kafka for records and invoke the function with batches. The mapping manages the polling, batching, and error handling. Direct invocation sources include API Gateway, Application Load Balancer, CloudFront (Lambda@Edge), S3 event notifications, SNS, EventBridge, and Cognito triggers. Synchronous invocations wait for the function to complete and return the response. Asynchronous invocations place the event in a queue and return immediately. For asynchronous invocations, Lambda manages retries (up to 2 additional attempts) and can send failed events to a dead-letter queue or on-failure destination.

  - name: aws-lambda-vpc
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html"
    content: |
      Lambda functions can access resources in your Amazon VPC by configuring the function with subnet IDs and security group IDs. Lambda creates an elastic network interface (ENI) in each subnet, using a Hyperplane ENI that is shared across functions with the same security group and subnet combination. VPC-connected functions can access RDS databases, ElastiCache clusters, internal APIs, and other VPC resources. By default, VPC-connected functions do not have internet access. To enable internet access, route outbound traffic through a NAT gateway in a public subnet. The execution role must have permission to create and manage ENIs (AWSLambdaVPCAccessExecutionRole). VPC configuration adds latency only during cold starts as ENI setup is reused across invocations. PrivateLink endpoints allow functions to access AWS services without traversing the public internet.

  - name: aws-lambda-concurrency
    project: smoke-data
    priority: 7
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html"
    content: |
      Concurrency is the number of in-flight requests your Lambda function is handling at the same time. Each account has a default concurrency limit of 1,000 concurrent executions per Region (can be increased). Reserved concurrency guarantees a set number of concurrent executions for a function, preventing other functions from consuming that capacity. It also limits the function to that maximum. Provisioned concurrency initializes a requested number of execution environments prepared to respond immediately without cold starts. Provisioned concurrency can be configured with Application Auto Scaling to scale based on utilization. Unreserved concurrency is shared across all functions without reserved concurrency. Burst concurrency provides an initial burst of 500-3000 concurrent executions depending on Region, after which concurrency scales at 500 additional instances per minute.

  - name: aws-lambda-deployment
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-package.html"
    content: |
      Lambda functions can be deployed as ZIP file archives or container images. ZIP archives can be uploaded directly to Lambda (up to 50 MB) or via S3 (up to 250 MB unzipped). Container images can be up to 10 GB and are stored in Amazon ECR. Lambda supports deployment automation through AWS SAM, AWS CDK, CloudFormation, and CI/CD pipelines. Function versions create immutable snapshots of the function code and configuration. Aliases are pointers to specific versions and support weighted routing for canary deployments and blue-green deployments. AWS CodeDeploy integrates with Lambda to automate traffic shifting between versions with configurable deployment strategies: Canary, Linear, and AllAtOnce. The Lambda console provides a built-in code editor for quick changes to functions with deployment packages under 3 MB.

  - name: aws-lambda-monitoring
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/lambda/latest/dg/lambda-monitoring.html"
    content: |
      Lambda automatically monitors functions and reports metrics through Amazon CloudWatch. Key metrics include Invocations (number of times function is invoked), Duration (execution time in milliseconds), Errors (invocations that result in a function error), Throttles (invocations that are throttled), ConcurrentExecutions, and IteratorAge (for stream-based sources). Lambda sends logs to CloudWatch Logs automatically. Lambda Insights provides enhanced monitoring with system-level metrics like CPU time, memory usage, disk utilization, and network data. AWS X-Ray integration enables distributed tracing to identify bottlenecks and troubleshoot errors. CloudWatch Lambda Insights uses a Lambda extension layer to collect and aggregate telemetry data. CloudWatch Alarms can be configured on any metric to trigger notifications or automated actions.

  # ── Amazon EC2 (10 prompts) ──

  - name: aws-ec2-overview
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/ec2/"
    content: |
      Amazon Elastic Compute Cloud (Amazon EC2) provides resizable compute capacity in the cloud. EC2 allows you to launch virtual servers (instances), configure security and networking, and manage storage. EC2 offers the broadest and deepest compute platform with a choice of processor, storage, networking, operating system, and purchase model. Instance types are optimized for different workloads: general purpose (M, T series), compute optimized (C series), memory optimized (R, X series), accelerated computing (P, G, Inf series), and storage optimized (I, D, H series). EC2 supports multiple purchase options: On-Demand (pay by the second), Reserved Instances (1 or 3 year commitment), Savings Plans, Spot Instances (up to 90% discount), and Dedicated Hosts. EC2 integrates with most AWS services and provides a foundation for building scalable applications.

  - name: aws-ec2-instances
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/ec2/latest/userguide/Instances.html"
    content: |
      An EC2 instance is a virtual server in the AWS cloud. Instances are launched from Amazon Machine Images (AMIs) which contain the operating system, application server, and applications. When you launch an instance, you select an instance type that determines the hardware of the host computer. Instance types comprise varying combinations of CPU, memory, storage, and networking capacity. You can stop, start, reboot, and terminate instances. Stopped instances do not incur compute charges but EBS volumes remain and are billed. Instance metadata and user data are available at http://169.254.169.254. Instance profiles allow attaching IAM roles to instances. The instance lifecycle includes pending, running, stopping, stopped, shutting-down, and terminated states. Placement groups control how instances are placed on underlying hardware for performance or resilience.

  - name: aws-ec2-amis
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/ec2/latest/userguide/AMIs.html"
    content: |
      An Amazon Machine Image (AMI) provides the information required to launch an instance. An AMI includes a template for the root volume, launch permissions that control which AWS accounts can use the AMI, and a block device mapping that specifies volumes to attach. AMIs can be backed by Amazon EBS (EBS-backed) or instance store (instance-store-backed). You can create AMIs from running instances, import from virtual machine images, or use AWS-provided, marketplace, or community AMIs. AMIs are Region-specific but can be copied across Regions. AMI deprecation allows setting an expiry date after which the AMI cannot be used to launch new instances. AMI sharing enables sharing with specific accounts, organizations, or making AMIs public. Golden AMIs are pre-configured images used as a base for standardized deployments.

  - name: aws-ec2-security-groups
    project: smoke-data
    priority: 7
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/ec2/latest/userguide/ec2-security-groups.html"
    content: |
      A security group acts as a virtual firewall for EC2 instances, controlling inbound and outbound traffic. Security groups are stateful: if you allow an inbound request, the response is automatically allowed regardless of outbound rules. Each security group contains a set of rules that filter traffic based on protocol, port range, and source/destination (CIDR blocks or other security groups). By default, security groups allow all outbound traffic and deny all inbound traffic. You can reference other security groups as sources, enabling secure communication between tiers of an application. Security groups are associated with network interfaces and an instance can have up to 5 security groups. Rules are evaluated as a union (if any rule allows the traffic, it's permitted). Changes to security group rules take effect immediately for all associated instances.

  - name: aws-ec2-ebs-volumes
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/ebs/latest/userguide/"
    content: |
      Amazon Elastic Block Store (EBS) provides persistent block storage volumes for EC2 instances. EBS volumes behave like raw, unformatted block devices that persist independently from the life of the instance. Volume types include General Purpose SSD (gp3, gp2), Provisioned IOPS SSD (io2, io1), Throughput Optimized HDD (st1), and Cold HDD (sc1). gp3 volumes offer a baseline of 3,000 IOPS and 125 MiB/s independent of volume size. io2 Block Express volumes support up to 256,000 IOPS and 4,000 MiB/s with 99.999% durability. EBS supports snapshots for point-in-time backups stored in S3. Snapshots are incremental. EBS Multi-Attach allows a single io2 volume to be attached to multiple instances in the same AZ. EBS encryption uses AWS KMS keys and supports both boot and data volumes with no performance impact.

  - name: aws-ec2-auto-scaling
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/autoscaling/"
    content: |
      Amazon EC2 Auto Scaling helps you maintain application availability and allows you to automatically add or remove EC2 instances according to conditions you define. An Auto Scaling group (ASG) contains a collection of instances treated as a logical grouping. You specify the minimum, maximum, and desired capacity. Launch templates define the instance configuration (AMI, instance type, security groups, key pairs). Scaling policies include target tracking (maintain a metric at a target value), step scaling (scale based on CloudWatch alarm thresholds), simple scaling (single adjustment), and scheduled scaling (scale at specific times). Predictive scaling uses machine learning to forecast demand. Health checks replace unhealthy instances automatically. Instance warm-up periods prevent premature scaling decisions. Lifecycle hooks allow custom actions during instance launch or termination.

  - name: aws-ec2-load-balancers
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/elasticloadbalancing/"
    content: |
      Elastic Load Balancing distributes incoming application traffic across multiple targets such as EC2 instances, containers, and IP addresses in multiple Availability Zones. There are four types: Application Load Balancer (ALB) for HTTP/HTTPS at layer 7, Network Load Balancer (NLB) for TCP/UDP/TLS at layer 4, Gateway Load Balancer (GWLB) for third-party virtual appliances, and Classic Load Balancer (legacy). ALB supports path-based routing, host-based routing, redirects, fixed responses, and authentication integration with Cognito. NLB handles millions of requests per second with ultra-low latencies and supports static IP addresses, PrivateLink, and TLS termination. Target groups route requests to registered targets and support health checks. Cross-zone load balancing distributes traffic evenly across all registered targets in all enabled AZs.

  - name: aws-ec2-spot-instances
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/ec2/latest/userguide/using-spot-instances.html"
    content: |
      Spot Instances are spare EC2 compute capacity available at up to 90% discount compared to On-Demand prices. AWS can reclaim Spot Instances with a two-minute interruption notice when capacity is needed. Spot Instances are ideal for fault-tolerant, flexible workloads like batch processing, data analysis, image rendering, CI/CD, and containerized workloads. Spot Instance requests can be one-time or persistent. Spot Fleets request and maintain a target capacity across instance types and Availability Zones using allocation strategies: lowest-price, capacity-optimized, or diversified. EC2 Fleet combines On-Demand, Reserved, and Spot Instances in a single API call. Spot placement scores help identify pools with high Spot capacity. Capacity Rebalancing in Auto Scaling groups proactively launches replacement instances before existing Spot Instances are reclaimed.

  - name: aws-ec2-placement-groups
    project: smoke-data
    priority: 3
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/ec2/latest/userguide/placement-groups.html"
    content: |
      Placement groups influence the placement of instances on underlying hardware. Cluster placement groups pack instances close together inside an Availability Zone, providing low-latency, high-throughput networking ideal for tightly-coupled HPC applications. Spread placement groups place instances on distinct hardware, reducing correlated failures. Each spread group can have a maximum of 7 running instances per AZ. Partition placement groups divide instances into logical segments (partitions) where each partition is placed on separate racks with independent network and power. Partition groups support up to 7 partitions per AZ. Placement groups are free to use. You can move or merge existing instances into placement groups by stopping, modifying placement, and restarting. Not all instance types support all placement group strategies.

  - name: aws-ec2-networking
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/vpc/latest/userguide/"
    content: |
      Amazon VPC lets you provision a logically isolated section of the AWS cloud where you can launch resources in a virtual network. A VPC spans all AZs in a Region. Subnets are IP address ranges within a VPC mapped to specific AZs. Public subnets have a route to an internet gateway; private subnets typically route through a NAT gateway for outbound internet access. Route tables control traffic routing between subnets and gateways. Network ACLs provide stateless filtering at the subnet level, while security groups provide stateful filtering at the instance level. VPC peering connects two VPCs for private traffic. Transit Gateway acts as a central hub connecting VPCs and on-premises networks. VPC endpoints (gateway and interface) enable private connectivity to AWS services without internet access. Flow logs capture network traffic metadata for monitoring and troubleshooting.

  # ── Amazon DynamoDB (10 prompts) ──

  - name: aws-dynamodb-overview
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/dynamodb/"
    content: |
      Amazon DynamoDB is a fully managed NoSQL database service providing fast and predictable performance with seamless scalability. DynamoDB offers single-digit millisecond response times at any scale, built-in security, backup and restore, and in-memory caching. Tables automatically scale throughput capacity without downtime or performance degradation. DynamoDB supports key-value and document data models. Data is stored on solid-state drives and automatically replicated across multiple AZs in a Region for high availability and data durability. DynamoDB provides both provisioned and on-demand capacity modes. Features include DynamoDB Streams for change data capture, global tables for multi-Region active-active replication, point-in-time recovery, and integration with AWS Lambda for serverless architectures. DynamoDB Accelerator (DAX) provides an in-memory cache for microsecond response times.

  - name: aws-dynamodb-tables
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.html"
    content: |
      A DynamoDB table is a collection of items, and each item is a collection of attributes. Each table requires a primary key that uniquely identifies each item. The primary key can be a simple key (partition key only) or a composite key (partition key + sort key). The partition key value is used by DynamoDB's internal hash function to determine the partition where the item is stored. Tables are schemaless beyond the primary key — each item can have different attributes. Table capacity can be provisioned (specify read and write capacity units) or on-demand (pay per request). Auto Scaling can adjust provisioned capacity based on utilization. Tables support encryption at rest using AWS-owned, AWS-managed, or customer-managed KMS keys. Table classes include Standard and Standard-Infrequent Access for cost optimization of infrequently accessed data.

  - name: aws-dynamodb-items
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithItems.html"
    content: |
      Items in DynamoDB are analogous to rows in a relational database. Each item is a collection of attributes and is uniquely identified by its primary key. The maximum item size is 400 KB including attribute names and values. DynamoDB supports scalar types (String, Number, Binary), set types (String Set, Number Set, Binary Set), and document types (List, Map). The PutItem operation creates or replaces an item. GetItem retrieves a single item by primary key. UpdateItem modifies attributes of an existing item using update expressions. DeleteItem removes an item. Conditional expressions allow operations to succeed only if specified conditions are met. Atomic counters enable incrementing or decrementing numeric attributes without interfering with other write requests. Batch operations (BatchGetItem, BatchWriteItem) process up to 25 items per call.

  - name: aws-dynamodb-indexes
    project: smoke-data
    priority: 7
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html"
    content: |
      Secondary indexes enable efficient queries on attributes beyond the primary key. A Global Secondary Index (GSI) has a partition key and optional sort key that can be different from the table's primary key. GSIs are eventually consistent and have their own provisioned throughput settings. A Local Secondary Index (LSI) has the same partition key as the table but a different sort key. LSIs share throughput with the base table and support strongly consistent reads. Each table can have up to 20 GSIs and 5 LSIs. LSIs must be created when the table is created. GSIs can be added or removed at any time. Index projections determine which attributes are copied to the index: KEYS_ONLY, INCLUDE (specified attributes), or ALL. Sparse indexes can be created by only including items that have the index key attributes, enabling efficient filtering.

  - name: aws-dynamodb-streams
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html"
    content: |
      DynamoDB Streams captures a time-ordered sequence of item-level modifications in a table and stores this information in a log for up to 24 hours. Stream records contain the primary key attributes and optionally the before and after images of modified items. Stream view types include KEYS_ONLY, NEW_IMAGE, OLD_IMAGE, and NEW_AND_OLD_IMAGES. DynamoDB Streams integrates with AWS Lambda through event source mappings, enabling real-time processing of changes. Use cases include replication, materialized views, analytics, notifications, and search index updates. Kinesis Data Streams for DynamoDB is an alternative that captures changes to a Kinesis data stream for more flexible processing, longer retention (up to 1 year), and integration with Kinesis Data Firehose and Kinesis Data Analytics. Each shard in a DynamoDB stream can support up to 1000 records per second and 2 MB/s of read throughput.

  - name: aws-dynamodb-backups
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html"
    content: |
      DynamoDB provides two backup mechanisms: on-demand backups and point-in-time recovery (PITR). On-demand backups create full backups of tables at any time with no impact on table performance. Backups are retained until explicitly deleted and can be used to restore to a new table. Point-in-time recovery enables continuous backups, allowing you to restore a table to any point in time during the last 35 days with per-second granularity. PITR protects against accidental writes or deletes. Restoration always creates a new table. Both backup types preserve the table's provisioned throughput settings, LSIs, GSIs, streams, and encryption settings. AWS Backup provides centralized backup management for DynamoDB tables alongside other AWS services, supporting backup scheduling, retention policies, and cross-account, cross-Region backup copies.

  - name: aws-dynamodb-global-tables
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html"
    content: |
      DynamoDB Global Tables provide a fully managed multi-Region, multi-active database that delivers fast local read and write performance for globally distributed applications. When you create a global table, you specify the Regions where you want the table replicated. DynamoDB propagates changes between Regions typically within one second. Writes can be made to any replica and are propagated to all other replicas. Global tables use last-writer-wins conflict resolution for concurrent updates to the same item in different Regions. Version 2019.11.21 global tables (current) offer improved efficiency and cost. Global tables require DynamoDB Streams enabled with NEW_AND_OLD_IMAGES view type. Each replica has its own capacity settings and can use either provisioned or on-demand mode independently. Cross-Region replication charges apply for data transfer between Regions.

  - name: aws-dynamodb-capacity
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ProvisionedThroughput.html"
    content: |
      DynamoDB offers two capacity modes: provisioned and on-demand. In provisioned mode, you specify the number of read capacity units (RCUs) and write capacity units (WCUs). One RCU provides one strongly consistent read per second for items up to 4 KB, or two eventually consistent reads. One WCU provides one write per second for items up to 1 KB. Auto Scaling can automatically adjust provisioned capacity between minimum and maximum values based on utilization targets. On-demand mode charges per read and write request and automatically scales to accommodate workload volume. Tables can be switched between modes once every 24 hours. Reserved capacity offers discounted pricing for provisioned mode with one or three year commitments. Burst capacity allows temporary exceeding of provisioned throughput by using unused capacity from previous seconds.

  - name: aws-dynamodb-transactions
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transaction-apis.html"
    content: |
      DynamoDB transactions provide atomicity, consistency, isolation, and durability (ACID) for operations across one or more tables within an AWS account and Region. TransactWriteItems groups up to 100 write actions (Put, Update, Delete, ConditionCheck) in a single all-or-nothing operation. TransactGetItems groups up to 100 read actions. Transactions use a two-phase commit protocol and are serializable isolated. Transaction operations consume twice the capacity of non-transactional operations. Idempotency tokens prevent duplicate transaction processing when retrying. Transactions fail if any condition check fails, any item exceeds 400 KB after the update, or the transaction exceeds 4 MB of data. Transactions do not support operations across Regions or accounts. Use cases include financial transactions, multiplayer gaming, and any operation requiring coordinated changes across multiple items.

  - name: aws-dynamodb-ttl
    project: smoke-data
    priority: 3
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html"
    content: |
      DynamoDB Time to Live (TTL) allows you to define a per-item expiration timestamp after which items are automatically deleted from the table. TTL is useful for removing irrelevant data such as session data, event logs, usage data, or temporary records. You specify a TTL attribute name on the table, and DynamoDB checks this attribute on each item. The attribute value must be a Number type containing a Unix epoch timestamp in seconds. Items with expired timestamps are deleted within 48 hours at no additional cost (deletions do not consume WCUs). Expired items appear in queries and scans until actually deleted; use a filter expression to exclude them. TTL deletions are captured by DynamoDB Streams if enabled, allowing you to archive expired items to S3 or process them with Lambda before permanent removal.

  # ── AWS CloudFormation (10 prompts) ──

  - name: aws-cloudformation-overview
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/cloudformation/"
    content: |
      AWS CloudFormation gives you an easy way to model a collection of related AWS and third-party resources, provision them quickly and consistently, and manage them throughout their lifecycles by treating infrastructure as code. You create a template that describes all the AWS resources you want, and CloudFormation takes care of provisioning and configuring those resources. Templates are written in JSON or YAML and describe the desired state. CloudFormation determines the right operations to perform when managing your stack and rolls back changes automatically if errors are detected. CloudFormation is free; you pay only for the resources it creates. StackSets enable deploying stacks across multiple accounts and Regions with a single operation. CloudFormation Guard enables policy-as-code validation of templates before deployment.

  - name: aws-cloudformation-templates
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-anatomy.html"
    content: |
      A CloudFormation template is a JSON or YAML formatted text file that describes your AWS infrastructure. Template sections include: AWSTemplateFormatVersion (the template version), Description (a text string describing the template), Metadata (additional information about the template), Parameters (input values supplied at stack creation), Mappings (key-value lookup tables), Conditions (control whether resources are created based on parameter values), Resources (required section declaring AWS resources and their properties), Outputs (values returned after stack creation such as resource IDs or URLs). The Resources section is the only required section. Intrinsic functions like Ref, Fn::Join, Fn::Sub, Fn::GetAtt, Fn::Select, and Fn::If enable dynamic values and conditional logic. CloudFormation supports template macros for custom processing during deployment.

  - name: aws-cloudformation-stacks
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacks.html"
    content: |
      A stack is a collection of AWS resources that you can manage as a single unit. All the resources in a stack are defined by the stack's CloudFormation template. By creating, updating, and deleting stacks, you can create, update, and delete a collection of resources. Stack operations include: CREATE, UPDATE, DELETE, and ROLLBACK. If resource creation fails during stack creation, CloudFormation rolls back and deletes all created resources. Stack policies protect specific resources from unintentional updates during stack update operations. Termination protection prevents a stack from being accidentally deleted. Stack events provide a timeline of resource operations. Stack status includes CREATE_IN_PROGRESS, CREATE_COMPLETE, CREATE_FAILED, UPDATE_IN_PROGRESS, UPDATE_COMPLETE, DELETE_IN_PROGRESS, DELETE_COMPLETE, and ROLLBACK states.

  - name: aws-cloudformation-change-sets
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html"
    content: |
      Change sets allow you to preview how proposed changes to a stack might impact your running resources before implementing them. When you create a change set, CloudFormation compares the stack's current template and parameter values with the proposed changes and generates a summary of modifications. The summary shows which resources will be Added, Modified, or Removed, and whether the change requires recreation of the resource (Replacement). After reviewing the change set, you can execute it to apply the changes, or delete it to abandon them. Multiple change sets can be created for a stack to compare different change scenarios. Import change sets enable importing existing resources into CloudFormation management. Change sets do not indicate whether a stack update will succeed; they only describe the planned changes.

  - name: aws-cloudformation-nested-stacks
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-nested-stacks.html"
    content: |
      Nested stacks are stacks created as part of other stacks using the AWS::CloudFormation::Stack resource. They allow you to decompose large templates into smaller, reusable components. A root stack is the top-level stack that creates nested stacks. Nested stacks can have their own nested stacks, forming a hierarchy. When you update a root stack, CloudFormation detects changes in nested stack templates and updates them accordingly. Output values from nested stacks can be referenced in the parent stack using Fn::GetAtt. Nested stacks share the same IAM permissions as the parent stack. Common patterns include separating networking, compute, and database resources into dedicated nested stacks. Cross-stack references using Export/ImportValue provide an alternative to nested stacks for sharing values between independent stacks.

  - name: aws-cloudformation-macros
    project: smoke-data
    priority: 3
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-macros.html"
    content: |
      CloudFormation macros enable custom processing of templates from simple actions like find-and-replace to extensive transformations of entire templates. A macro consists of a Lambda function that processes template fragments and a macro resource registered in the account. The AWS::Include transform fetches and includes template snippets from S3. The AWS::Serverless transform (SAM) processes simplified serverless resource definitions into standard CloudFormation resources. Custom macros are invoked using the Fn::Transform intrinsic function or at the template level in the Transform section. During processing, CloudFormation sends the template fragment to the Lambda function, which returns the processed fragment. Macros can add, modify, or delete resources, mappings, parameters, and outputs. Template-level macros process the entire template, while snippet-level macros process only specific fragments.

  - name: aws-cloudformation-drift-detection
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html"
    content: |
      Drift detection enables you to detect whether a stack's actual configuration differs from its expected template configuration. Resources can drift when they are modified outside of CloudFormation, such as through the AWS console or CLI. You can detect drift on an entire stack or individual resources. The drift status can be IN_SYNC, DRIFTED, NOT_CHECKED, or DELETED. For drifted resources, CloudFormation shows the expected and actual property values along with the difference type (ADD, REMOVE, or NOT_EQUAL). Drift detection does not modify any resources. Import operations can bring drifted or externally created resources under CloudFormation management. Not all resource types support drift detection. CloudFormation resource import allows you to bring existing resources into CloudFormation management without recreating them.

  - name: aws-cloudformation-custom-resources
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html"
    content: |
      Custom resources enable you to write custom provisioning logic in templates that CloudFormation runs anytime you create, update, or delete stacks. Custom resources are backed by Lambda functions or SNS topics. When CloudFormation processes a custom resource, it sends a request to the service token (Lambda ARN or SNS ARN) containing the operation type (Create, Update, Delete), resource properties, and a response URL. The backing service performs the operation and sends a response (SUCCESS or FAILED) to the presigned response URL. Custom resources are useful for including resources not natively supported by CloudFormation, performing complex provisioning logic, or integrating with third-party services. The cfn-response module simplifies sending responses. Resource properties from the template are passed to the Lambda function and can be used to configure the custom resource behavior.

  - name: aws-cloudformation-stacksets
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html"
    content: |
      AWS CloudFormation StackSets extends stack functionality by enabling you to create, update, or delete stacks across multiple accounts and Regions with a single operation. An administrator account creates a stack set and stack instances in target accounts. Self-managed permissions use IAM roles while service-managed permissions use AWS Organizations for automatic deployments. Stack set operations can deploy to organizational units (OUs) and automatically deploy to new accounts added to the OU. Operation preferences control concurrency: maximum concurrent accounts/percentage and failure tolerance. Automatic deployments keep stack instances synchronized when new accounts are added to target OUs. Delegated administrators allow member accounts to create and manage stack sets. Stack set drift detection checks all stack instances across accounts and Regions.

  - name: aws-cloudformation-outputs
    project: smoke-data
    priority: 3
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/outputs-section-structure.html"
    content: |
      The Outputs section declares output values that you can import into other stacks (cross-stack references), return in response to describe stack API calls, or view in the CloudFormation console. Each output has a logical name, a Value (required), an optional Description, an optional Condition, and an optional Export name. Export names must be unique within a Region and account. Other stacks import exported values using Fn::ImportValue. Cross-stack references create a dependency: you cannot delete a stack that exports values imported by other stacks. Outputs are useful for returning resource identifiers (instance IDs, DNS names, ARNs), connection strings, and URLs. You can reference parameters, resources, mappings, and pseudo parameters in output values. The maximum number of outputs per template is 200.

  # ── AWS IAM (10 prompts) ──

  - name: aws-iam-overview
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/iam/"
    content: |
      AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely. IAM lets you create and manage AWS users, groups, roles, and their associated permissions. IAM is a global service and is free to use. The root user has complete access to all AWS services and should be secured with MFA and used only for account-level tasks. IAM follows the principle of least privilege: grant only the permissions required. IAM supports identity federation through SAML 2.0 and OpenID Connect, allowing users from corporate directories or social identity providers to access AWS. IAM Access Analyzer helps identify resources shared with external entities. IAM Policy Simulator tests the effects of policies before applying them. AWS Security Token Service (STS) provides temporary security credentials for IAM roles and federated users.

  - name: aws-iam-users
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html"
    content: |
      An IAM user is an identity with long-term credentials that represents a person or application that interacts with AWS. Users authenticate with passwords (console access) or access keys (programmatic access). Each account can have up to 5,000 IAM users. Users can belong to up to 10 groups. Permissions are attached to users through user policies (inline or managed) or inherited through group membership. Access keys consist of an access key ID and secret access key. Users can have at most two active access keys for rotation purposes. Best practice is to use IAM Identity Center for human users and IAM roles for applications. When IAM users are needed, enforce MFA, use strong passwords, rotate credentials regularly, and use conditions in policies to restrict access by IP, time, or MFA status.

  - name: aws-iam-roles
    project: smoke-data
    priority: 7
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html"
    content: |
      An IAM role is an identity with permission policies that can be assumed by anyone who needs it, without long-term credentials. Roles are used for EC2 instance profiles, Lambda execution roles, cross-account access, and federation. A role has a trust policy that defines who can assume it and permission policies that define what they can do. When an entity assumes a role, it receives temporary security credentials from STS with an expiration. Service-linked roles are predefined by AWS services and contain all permissions the service requires. Role chaining allows a role to assume another role, with a maximum session duration that applies to the entire chain. Roles support session tags for attribute-based access control (ABAC). The maximum session duration can be set between 1 and 12 hours. External ID is used as a condition in trust policies to address the confused deputy problem in cross-account scenarios.

  - name: aws-iam-policies
    project: smoke-data
    priority: 8
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html"
    content: |
      IAM policies are JSON documents that define permissions. Policy types include identity-based (attached to users, groups, roles), resource-based (attached to resources like S3 buckets), permission boundaries (maximum permissions for an entity), Organizations SCPs (maximum permissions for accounts), session policies (limit role session permissions), and access control lists. A policy statement contains Effect (Allow/Deny), Action (AWS API operations), Resource (ARNs), and optional Condition elements. AWS managed policies are created and maintained by AWS. Customer managed policies are custom policies you create. Inline policies are embedded directly in a single entity. Policy evaluation logic: explicit Deny always wins, then explicit Allow is checked, otherwise implicit deny. The policy simulator and Access Analyzer validate policies and identify issues. Policy variables like ${aws:username} enable dynamic references.

  - name: aws-iam-mfa
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html"
    content: |
      Multi-factor authentication (MFA) adds an extra layer of protection on top of a user name and password. AWS supports virtual MFA devices (Authenticator apps), FIDO2 security keys, and hardware TOTP tokens. Virtual MFA devices are the most common and support standards-based TOTP codes. FIDO2 security keys provide phishing-resistant authentication using the WebAuthn standard. MFA can be required for console sign-in, API calls, and specific actions. You can enforce MFA through IAM policies using the aws:MultiFactorAuthPresent condition key. MFA-protected API access requires calling GetSessionToken with the MFA serial number and token code, then using the temporary credentials. Best practice is to enable MFA for all IAM users, especially the root user. IAM Identity Center also supports MFA and can enforce it organization-wide.

  - name: aws-iam-access-keys
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html"
    content: |
      Access keys are long-term credentials for IAM users consisting of an access key ID (AKIA...) and a secret access key. They are used for programmatic access to AWS via the CLI, SDKs, or direct API calls. Each user can have a maximum of two access keys for seamless rotation. Access keys should be rotated regularly. The rotation process involves: create a second access key, update all applications to use the new key, verify the old key is no longer used (using the Last Used information), then deactivate and delete the old key. IAM Credential Reports list all users and their credential status including access key age and last used dates. Best practice is to use IAM roles instead of access keys whenever possible. For workloads running on AWS, use instance profiles, Lambda execution roles, or ECS task roles instead of embedding access keys.

  - name: aws-iam-permissions-boundary
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html"
    content: |
      A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. When you set a permissions boundary, the entity can only perform actions allowed by both the identity-based policy AND the permissions boundary. Permissions boundaries do not grant permissions on their own. Use cases include safely delegating user creation: an admin creates a permissions boundary and allows developers to create users only with that boundary attached. This prevents privilege escalation because the created users cannot exceed the boundary permissions. Permissions boundaries work with the intersection logic: the effective permissions are the intersection of the identity-based policy and the permissions boundary. Service control policies (SCPs) further restrict the maximum permissions at the account or OU level.

  - name: aws-iam-service-control
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html"
    content: |
      Service Control Policies (SCPs) are a type of organization policy that manage permissions in your AWS Organization. SCPs offer central control over the maximum available permissions for all accounts in your organization. SCPs do not grant permissions; they define a guardrail limiting what actions are available. The effective permissions for a principal are the intersection of the SCP, permissions boundary (if any), and the identity-based policies. SCPs affect all users and roles in member accounts, including the root user, but do not affect the management account. SCPs use the same policy language as IAM policies. Common SCP patterns include preventing member accounts from leaving the organization, restricting Regions where resources can be created, requiring encryption on specific services, and preventing disabling of security services like CloudTrail or GuardDuty.

  - name: aws-iam-identity-federation
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html"
    content: |
      Identity federation lets users from external identity providers (IdPs) access AWS resources without creating IAM users. IAM supports SAML 2.0 federation for enterprise identity providers like Active Directory, Okta, and Ping Identity. OIDC federation supports web identity providers like Amazon Cognito, Google, Facebook, and any OIDC-compatible provider. When federated users access AWS, they assume an IAM role and receive temporary security credentials from STS. SAML federation involves creating a trust relationship between the IdP and AWS IAM, then configuring the IdP to send SAML assertions to AWS. Web identity federation uses AssumeRoleWithWebIdentity to exchange provider tokens for AWS credentials. IAM Identity Center (successor to AWS SSO) is the recommended approach for federating workforce identities, providing a centralized portal for access to multiple AWS accounts and applications.

  - name: aws-iam-cross-account
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html"
    content: |
      Cross-account access allows IAM principals in one AWS account to access resources in another account. The pattern involves creating an IAM role in the target account with a trust policy allowing the source account, then granting the source account's users or roles permission to assume the target role. The trust policy specifies the source account ID and optionally an external ID for additional security. Users assume the cross-account role using sts:AssumeRole and receive temporary credentials scoped to that role's permissions. Resource-based policies on services like S3, KMS, and SNS provide an alternative by directly granting cross-account access without assuming a role. AWS Organizations enable easier cross-account access management with organization-level policies. The confused deputy problem is addressed using the ExternalId condition in trust policies to ensure only the intended party assumes the role.

  # ── Amazon RDS (10 prompts) ──

  - name: aws-rds-overview
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/rds/"
    content: |
      Amazon Relational Database Service (Amazon RDS) is a managed service for relational databases in the cloud. RDS supports multiple database engines: Amazon Aurora (MySQL and PostgreSQL compatible), MySQL, MariaDB, PostgreSQL, Oracle, and Microsoft SQL Server. RDS handles routine database tasks such as provisioning, patching, backup, recovery, failure detection, and repair. RDS instances run in a VPC and can be accessed from EC2 instances or from outside the VPC through a public endpoint. RDS provides cost-efficient, resizable capacity with high availability through Multi-AZ deployments. RDS Custom allows access to the underlying database and operating system for Oracle and SQL Server. RDS Proxy improves application resilience and database efficiency by pooling and sharing database connections.

  - name: aws-rds-instances
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.html"
    content: |
      A DB instance is an isolated database environment running in the cloud. Each DB instance runs a database engine and has its own compute and storage resources. DB instance classes determine the computation and memory capacity: Standard (db.m), Memory Optimized (db.r, db.x), and Burstable (db.t). Storage options include General Purpose SSD (gp2, gp3), Provisioned IOPS SSD (io1, io2), and Magnetic (previous generation). Maximum storage varies by engine: up to 64 TB for most engines, up to 128 TB for Aurora. DB instances can be stopped for up to 7 days and are automatically started after that period. Instance status values include available, backing-up, creating, deleting, failed, modifying, rebooting, resizing, storage-full, and upgrading. Parameter groups control engine configuration. Option groups enable additional features specific to each database engine.

  - name: aws-rds-snapshots
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html"
    content: |
      DB snapshots are point-in-time backups of a DB instance stored in Amazon S3. RDS creates automated snapshots during the backup window and retains them according to the backup retention period (1-35 days). Manual snapshots are created on-demand and persist until explicitly deleted. Snapshots capture the entire DB instance including data, engine, configuration, and DB instance class. Snapshots can be used to restore to a new DB instance at any point within the retention period. Snapshot copy enables copying snapshots within the same Region or across Regions for disaster recovery. Snapshots can be shared with other AWS accounts or made public. Encrypted snapshots can only be shared by sharing the KMS key. Exporting snapshots to S3 converts data to Apache Parquet format for analytics with Athena, Redshift Spectrum, or SageMaker.

  - name: aws-rds-read-replicas
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html"
    content: |
      Read replicas provide enhanced performance and durability by allowing you to create one or more read-only copies of your database instance. Read replicas use asynchronous replication from the primary instance. They can be created in the same Region or a different Region (cross-Region replicas). Up to 5 read replicas can be created for MySQL, MariaDB, PostgreSQL, and Oracle. Aurora supports up to 15 read replicas with millisecond replication lag. Read replicas can be promoted to standalone instances for disaster recovery or to offload read traffic. Cross-Region replicas serve multiple purposes: closer geographic proximity for users, disaster recovery, and migration. Replica lag metrics help monitor replication delay. Multi-AZ read replicas create replicas with their own standby for high availability. Read replicas of read replicas (cascading) are supported for MySQL and MariaDB.

  - name: aws-rds-multi-az
    project: smoke-data
    priority: 7
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html"
    content: |
      Multi-AZ deployments provide enhanced availability and durability for DB instances. In a Multi-AZ deployment, RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone. The primary instance synchronously replicates data to the standby. Failover to the standby occurs automatically during planned maintenance, DB instance failure, or AZ failure. Failover typically completes in 60-120 seconds. During failover, the DNS endpoint is updated to point to the standby (now primary). Multi-AZ DB Cluster deployments use two readable standbys that also serve read traffic, providing up to 2x the read capacity with faster failover (typically under 35 seconds). Multi-AZ does not serve as a scaling solution for read traffic (except DB Cluster deployments) — use read replicas for read scaling. The standby cannot be accessed directly for reads or backups.

  - name: aws-rds-aurora
    project: smoke-data
    priority: 7
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/"
    content: |
      Amazon Aurora is a MySQL and PostgreSQL-compatible relational database built for the cloud, combining the performance and availability of high-end commercial databases with the simplicity and cost-effectiveness of open-source databases. Aurora provides up to 5x the throughput of MySQL and 3x the throughput of PostgreSQL. Aurora storage automatically grows in 10 GB increments up to 128 TB and replicates data six ways across three AZs. Aurora Serverless v2 scales compute capacity instantly between a minimum and maximum ACU (Aurora Capacity Unit). Aurora Global Database enables a single database to span multiple Regions with replication lag typically under 1 second. Aurora features include backtrack (rewind a DB cluster to a specific time), cloning (create a copy using copy-on-write protocol), and parallel query for analytical queries alongside transactional workloads.

  - name: aws-rds-parameter-groups
    project: smoke-data
    priority: 3
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html"
    content: |
      DB parameter groups act as a container for engine configuration values applied to one or more DB instances. Default parameter groups are created with preset values for each engine type and version. Custom parameter groups allow you to customize engine behavior. Parameters can be static (require reboot to apply) or dynamic (applied immediately). DB cluster parameter groups apply to Aurora DB clusters. Key parameters include max_connections, innodb_buffer_pool_size (MySQL), shared_buffers (PostgreSQL), max_wal_size, work_mem, and timezone. Changes to dynamic parameters take effect when applied; changes to static parameters take effect after the next reboot. You cannot modify default parameter groups; instead, create a custom parameter group, modify values, and associate it with your DB instance. Parameter groups are engine and version specific.

  - name: aws-rds-security
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.html"
    content: |
      RDS security encompasses network isolation, access control, encryption, and monitoring. DB instances run in a VPC with network access controlled by security groups. IAM database authentication allows using IAM credentials instead of passwords for MySQL, PostgreSQL, and MariaDB. Kerberos authentication is supported for SQL Server, Oracle, MySQL, and PostgreSQL. Encryption at rest using KMS encrypts the underlying storage, automated backups, read replicas, and snapshots. Encryption must be enabled at creation time and cannot be disabled. Unencrypted instances can be encrypted by restoring from an encrypted snapshot copy. SSL/TLS encrypts connections between applications and DB instances. RDS provides audit logging through database engine logs and integration with CloudTrail for API activity. Amazon RDS Proxy uses IAM for authentication and Secrets Manager for database credentials.

  - name: aws-rds-monitoring
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html"
    content: |
      RDS provides multiple monitoring tools. CloudWatch metrics include CPU utilization, database connections, freeable memory, read/write IOPS, read/write throughput, free storage space, and replica lag. Enhanced Monitoring provides OS-level metrics in real time at 1-second granularity including process lists, CPU breakdown, memory, file system, and disk I/O. Performance Insights provides a dashboard to visualize database load and identify bottlenecks using database wait events and top SQL queries. Performance Insights helps determine when the database is the performance bottleneck and which SQL statements are responsible. Event notifications through SNS alert you to changes in DB instances, snapshots, parameter groups, and security groups. Database engine logs (error log, slow query log, general log) can be published to CloudWatch Logs for centralized analysis and alerting.

  - name: aws-rds-backups
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html"
    content: |
      RDS automated backups enable point-in-time recovery of your DB instance. When enabled, RDS creates a storage volume snapshot of your DB instance during the backup window and captures transaction logs. Automated backups are retained for a configurable period of 1-35 days. Point-in-time recovery restores to a new DB instance at any second during the retention period. The latest restorable time is typically within 5 minutes of the current time. Backup storage up to the total database storage is provided free. Automated backups can be replicated to another Region for disaster recovery. Manual snapshots are not affected by the backup retention period and persist until deleted. AWS Backup provides centralized backup management with policies, schedules, and compliance reporting across multiple AWS services including RDS, Aurora, DynamoDB, and EBS.

  # ── Amazon ECS (10 prompts) ──

  - name: aws-ecs-overview
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/ecs/"
    content: |
      Amazon Elastic Container Service (Amazon ECS) is a fully managed container orchestration service that helps you deploy, manage, and scale containerized applications. ECS supports Docker containers and allows you to run applications on a managed cluster of Amazon EC2 instances or serverless with AWS Fargate. ECS integrates deeply with AWS services including Elastic Load Balancing, Amazon VPC, IAM, CloudWatch, and AWS CloudFormation. Key concepts include clusters (logical grouping of tasks or services), task definitions (blueprint for your application describing containers), tasks (instantiation of a task definition), and services (maintain desired count of tasks). ECS Anywhere extends ECS management to on-premises servers. ECS Exec enables interactive command execution in running containers for debugging.

  - name: aws-ecs-clusters
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonECS/latest/developerguide/clusters.html"
    content: |
      An ECS cluster is a logical grouping of tasks or services. Clusters can contain tasks using both Fargate and EC2 launch types. When creating a cluster, you can configure default capacity provider strategies, CloudWatch Container Insights for monitoring, and execute command configuration. Cluster capacity providers define the infrastructure that tasks run on: Fargate, Fargate Spot, or Auto Scaling groups for EC2 launch type. The default capacity provider strategy determines which capacity providers to use when no strategy is specified. Clusters support namespaces for Service Connect and Cloud Map integration. Cluster settings include containerInsights for enhanced monitoring. A cluster can contain a mix of Fargate tasks, EC2 tasks, and external instances (ECS Anywhere). Account settings control default cluster behavior like awsvpcTrunking for increased ENI density.

  - name: aws-ecs-tasks
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html"
    content: |
      A task definition is a JSON text file that describes one or more containers forming your application. Task definitions specify the Docker images, CPU and memory requirements, port mappings, environment variables, volumes, networking mode, IAM roles, logging configuration, and health check commands. Each task definition has a family name and revision number. Container definitions within a task can share volumes and communicate through localhost. The task execution role grants the ECS agent permissions to pull images and send logs. The task role grants permissions to the application running in containers. Task definition parameters include requiresCompatibilities (Fargate or EC2), networkMode (awsvpc, bridge, host, none), and placement constraints. Fargate tasks require awsvpc networking and specific CPU/memory combinations. Ephemeral storage for Fargate can be configured up to 200 GB.

  - name: aws-ecs-services
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html"
    content: |
      An ECS service enables you to run and maintain a specified number of instances of a task definition simultaneously. If a task fails or stops, the service scheduler launches a new task to maintain the desired count. Services support rolling updates with configurable minimum healthy percent and maximum percent for deployments. Blue/green deployments are available through CodeDeploy integration. Circuit breaker with rollback automatically stops and rolls back failed deployments. Services can be configured with load balancers (ALB, NLB) for traffic distribution and health checking. Service auto scaling adjusts the desired count based on CloudWatch metrics, target tracking, step scaling, or scheduled scaling. Service Connect provides service mesh capabilities for inter-service communication. Deployment controllers include ECS (rolling update), CODE_DEPLOY (blue/green), and EXTERNAL.

  - name: aws-ecs-fargate
    project: smoke-data
    priority: 7
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html"
    content: |
      AWS Fargate is a serverless compute engine for containers that removes the need to manage EC2 instances. With Fargate, you specify CPU and memory requirements at the task level. Fargate provisions the right amount of compute, eliminating the need to choose instance types, manage cluster capacity, or optimize utilization. Fargate supports specific CPU and memory combinations ranging from 0.25 vCPU/0.5 GB to 16 vCPU/120 GB. Fargate tasks use awsvpc networking mode, giving each task its own elastic network interface with a private IP address. Fargate Spot runs tasks on spare capacity at up to 70% discount with the possibility of interruption. Platform versions (e.g., 1.4.0 for Linux) determine the runtime environment features. Fargate supports ephemeral storage from 20 GB to 200 GB, EFS for persistent storage, and environment variables from Secrets Manager and SSM Parameter Store.

  - name: aws-ecs-capacity-providers
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-capacity-providers.html"
    content: |
      Capacity providers manage the infrastructure that tasks run on. There are three types: Fargate, Fargate Spot, and Auto Scaling group capacity providers. Auto Scaling group capacity providers use managed scaling to automatically adjust the ASG size based on task demand. Managed termination protection prevents instances with running tasks from being terminated during scale-in. A capacity provider strategy determines how tasks are distributed across providers using base (guaranteed minimum count) and weight (relative proportion). The default capacity provider strategy is used when no strategy is specified in RunTask or CreateService. Multiple capacity providers can be combined in a strategy for cost optimization, mixing Fargate and Fargate Spot. Managed scaling uses target tracking to maintain a target capacity percentage, adjusting the ASG to keep instances utilized at the desired level.

  - name: aws-ecs-service-discovery
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html"
    content: |
      Service discovery enables ECS services to discover and connect with each other using DNS names. ECS integrates with AWS Cloud Map for service discovery. When service discovery is configured, ECS automatically registers and deregisters task IP addresses as tasks start and stop. Services are discoverable through DNS queries within the VPC. DNS records (A or SRV) are created in a private DNS namespace. Health checks can be configured to only return healthy instances. Service Connect builds on Cloud Map to provide a service mesh with client-side load balancing, automatic retries, and circuit breaking. Service Connect uses an Envoy proxy sidecar injected into tasks. Service Connect namespaces define the scope of discovery. Port mappings in Service Connect can alias internal container ports to standard ports, simplifying service configuration.

  - name: aws-ecs-load-balancing
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html"
    content: |
      ECS services can be configured with Elastic Load Balancing to distribute traffic across tasks. Application Load Balancers (ALB) are recommended for HTTP/HTTPS workloads and support path-based routing, host-based routing, and dynamic port mapping. Network Load Balancers (NLB) support TCP/UDP with ultra-low latency and static IP addresses. With awsvpc network mode, each task has its own IP address and the load balancer routes directly to task IPs. Dynamic port mapping (bridge mode) allows multiple tasks on the same container instance using random host ports. Target groups perform health checks and automatically register/deregister tasks. Multiple target groups can be associated with a single service for routing to different paths or ports. ALB supports gRPC, WebSockets, and HTTP/2. Slow start mode gradually increases the share of requests sent to newly registered targets.

  - name: aws-ecs-auto-scaling
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html"
    content: |
      ECS Service Auto Scaling adjusts the desired task count based on CloudWatch metrics or schedules. Target tracking scaling policies maintain a target value for a specific metric such as average CPU utilization, average memory utilization, or ALB request count per target. Step scaling policies adjust the task count based on CloudWatch alarm thresholds with configurable step adjustments. Scheduled scaling sets the desired count at specific dates and times for predictable demand patterns. Cooldown periods prevent rapid scaling fluctuations. Service auto scaling works independently from infrastructure scaling (capacity providers): service auto scaling adjusts the number of tasks, while capacity provider managed scaling adjusts the number of instances. Scale-in protection can be enabled on specific tasks to prevent them from being terminated during scale-in operations.

  - name: aws-ecs-logging
    project: smoke-data
    priority: 3
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_awslogs.html"
    content: |
      ECS supports multiple logging drivers to collect and route container logs. The awslogs driver sends container logs to Amazon CloudWatch Logs, creating a log group and log stream for each container. FireLens (based on Fluent Bit or Fluentd) provides advanced log routing to CloudWatch, S3, Kinesis Data Firehose, and third-party destinations like Splunk and Datadog. The awsfirelens log driver routes logs through a FireLens sidecar container. Configuration options include log group name, Region, stream prefix, date/time format, and multiline pattern handling. For Fargate tasks, the awslogs or awsfirelens log driver must be used. The task execution role requires logs:CreateLogStream and logs:PutLogEvents permissions. Container Insights provides aggregated cluster and service metrics including CPU, memory, network, and storage utilization with optional enhanced observability using CloudWatch agent.

  # ── Amazon SNS (10 prompts) ──

  - name: aws-sns-overview
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/sns/"
    content: |
      Amazon Simple Notification Service (Amazon SNS) is a fully managed messaging service for both application-to-application (A2A) and application-to-person (A2P) communication. SNS enables you to decouple microservices, distributed systems, and serverless applications using the publish/subscribe (pub/sub) pattern. Publishers send messages to SNS topics, and subscribers receive messages from topics they are subscribed to. SNS supports multiple subscriber types: Amazon SQS queues, AWS Lambda functions, HTTP/HTTPS endpoints, email, SMS, and mobile push notifications. SNS provides features including message filtering, message fanout, message ordering (FIFO topics), message deduplication, and message archiving. SNS integrates with over 60 AWS services as event sources. Messages can be up to 256 KB in size, with the Extended Client Library supporting messages up to 2 GB via S3.

  - name: aws-sns-topics
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/sns/latest/dg/sns-create-topic.html"
    content: |
      An SNS topic is a logical access point and communication channel. Topics come in two types: Standard and FIFO. Standard topics provide maximum throughput, best-effort ordering, and at-least-once delivery. FIFO topics guarantee strict message ordering and exactly-once delivery with up to 300 publishes per second (3000 with batching). Topic names must be unique within an account and Region. Standard topic names can be up to 256 characters; FIFO topic names must end with .fifo suffix. Topics can have access policies controlling who can publish and subscribe. Topic attributes include display name (used for SMS), delivery policy (retry configuration), encryption (using KMS), and logging. Data protection policies can detect and protect sensitive data like PII in messages. Each account can create up to 100,000 standard topics and 1,000 FIFO topics.

  - name: aws-sns-subscriptions
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/sns/latest/dg/sns-create-subscribe-endpoint-to-topic.html"
    content: |
      A subscription connects a topic to an endpoint where messages are delivered. Supported protocols include SQS (queue ARN), Lambda (function ARN), HTTP/HTTPS (URL), email, email-JSON, SMS, and application (mobile push). Subscriptions require confirmation from the endpoint owner before becoming active (except SQS and Lambda in the same account). Subscription attributes include filter policy, delivery policy (retry configuration), raw message delivery (skip JSON wrapping), and redrive policy (dead-letter queue). Cross-account subscriptions allow an account to subscribe to topics in another account. Subscriptions can be suspended by setting the subscription's status to inactive. Each topic supports up to 12.5 million subscriptions (standard) or 100 subscriptions (FIFO). The subscription confirmation token expires after 3 days.

  - name: aws-sns-filtering
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/sns/latest/dg/sns-subscription-filter-policies.html"
    content: |
      SNS message filtering enables subscribers to receive only a subset of messages published to a topic. Filter policies are JSON objects attached to subscriptions that define matching criteria. Filters can be applied to message attributes (metadata) or message body content. Filter policy scope determines which part of the message is evaluated: MessageAttributes or MessageBody. Filter operators include exact string match, exact numeric match, prefix match, suffix match, anything-but (exclusion), numeric range, IP address match, and exists (attribute presence). Multiple conditions within a filter policy are combined with AND logic. Multiple values for a single attribute are combined with OR logic. When a message doesn't match any subscription's filter, it is not delivered to that subscriber but is still successfully published. Filter policies reduce the need for separate topics and custom filtering logic in subscribers.

  - name: aws-sns-fanout
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/sns/latest/dg/sns-common-scenarios.html"
    content: |
      Fanout is a messaging pattern where a single SNS message is delivered to multiple subscribers simultaneously. The SNS-to-SQS fanout pattern publishes messages to an SNS topic with multiple SQS queues subscribed, enabling parallel processing by different consumers. This pattern decouples message production from consumption and allows adding new consumers without modifying the publisher. Common fanout architectures include: order processing where a new order triggers inventory update, payment processing, and notification services simultaneously; event-driven architectures where a single event triggers multiple microservices; and analytics pipelines where data flows to multiple processing systems. SNS-to-Lambda fanout triggers multiple Lambda functions for parallel processing. Combined with message filtering, fanout enables selective message routing to specific subscribers based on message content.

  - name: aws-sns-mobile-push
    project: smoke-data
    priority: 3
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-application-as-subscriber.html"
    content: |
      SNS Mobile Push enables sending push notifications to mobile devices and desktop applications. Supported platforms include Apple Push Notification Service (APNs) for iOS and macOS, Firebase Cloud Messaging (FCM) for Android, Amazon Device Messaging (ADM) for Kindle, and Windows Push Notification Service (WNS). Platform applications represent your app on a specific push service. Platform endpoints represent individual devices registered with a platform application. Messages can be sent to individual endpoints (direct push) or to all endpoints subscribed to a topic (topic-based push). Message structure allows platform-specific customization using the MessageStructure parameter. Token-based authentication (APNs) or API keys (FCM) authenticate with push services. TTL (Time to Live) controls how long push services attempt delivery if the device is offline.

  - name: aws-sns-sms
    project: smoke-data
    priority: 3
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-phone-number-as-subscriber.html"
    content: |
      SNS can send SMS text messages to mobile phone numbers worldwide. SMS messages can be sent directly to phone numbers or published to topics with SMS subscriptions. Message types include Transactional (critical messages like OTPs with higher delivery reliability) and Promotional (non-critical messages at lower cost). SMS sandbox mode restricts sending to verified phone numbers only until production access is requested. Origination identities include short codes, long codes, toll-free numbers, 10DLC (US only), and sender IDs. Spending limits can be configured at the account level. Opt-out management allows recipients to reply STOP to unsubscribe. SMS delivery status logging tracks success and failure. Country-specific regulations may require registration of sender IDs or origination numbers. Monthly spend threshold alarms help monitor costs. Each SMS message can be up to 140 bytes.

  - name: aws-sns-fifo
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/sns/latest/dg/sns-fifo-topics.html"
    content: |
      FIFO (First-In-First-Out) topics provide strict message ordering and exactly-once message delivery. Messages published with the same message group ID are delivered in order. Deduplication prevents duplicate messages using deduplication IDs or content-based deduplication. FIFO topics support up to 300 messages per second (or 10 MB/s) with batching increasing throughput to 3,000 messages per second. FIFO topics can only have FIFO SQS queues as subscribers. Message group IDs enable parallel processing while maintaining order within each group. Use cases include financial transactions, inventory management, and any workflow requiring sequential processing. FIFO topic names must end with the .fifo suffix. Content-based deduplication uses SHA-256 hash of the message body as the deduplication ID. The deduplication interval is 5 minutes.

  - name: aws-sns-encryption
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/sns/latest/dg/sns-server-side-encryption.html"
    content: |
      SNS supports server-side encryption (SSE) to protect the contents of messages in topics using AWS KMS keys. When SSE is enabled, SNS encrypts messages as soon as they are received and decrypts them just before delivery to subscribed endpoints. SSE uses envelope encryption with a data encryption key generated by KMS. You can use the AWS managed key (aws/sns) or a customer managed key (CMK). Customer managed keys allow key rotation, access control through key policies, and audit trails. SSE encrypts the message body but not message metadata (attributes, topic ARN, etc.). When subscribing an encrypted SQS queue to an encrypted SNS topic, the SQS queue's KMS key policy must grant SNS permission to use the key. In-transit encryption is provided by HTTPS endpoints. Data protection policies complement encryption by detecting and masking sensitive data patterns in messages.

  - name: aws-sns-dead-letter
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html"
    content: |
      Dead-letter queues (DLQs) capture messages that SNS cannot successfully deliver to subscribed endpoints. A redrive policy attached to a subscription specifies the SQS queue to use as the DLQ. Messages are sent to the DLQ after exhausting the delivery retry policy. Client-side errors (4xx) are not retried and go directly to the DLQ. Server-side errors (5xx) are retried according to the delivery policy before being sent to the DLQ. The DLQ must be in the same AWS account and Region as the subscription. DLQ messages include metadata about the original delivery attempt including the topic ARN, subscription ARN, and error information. DLQs help debug delivery failures, analyze message patterns, and recover undelivered messages. The SNS topic must have permission to send messages to the DLQ. Best practice is to set up CloudWatch alarms on DLQ depth to detect delivery issues promptly.

  # ── Amazon SQS (10 prompts) ──

  - name: aws-sqs-overview
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/sqs/"
    content: |
      Amazon Simple Queue Service (Amazon SQS) is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. SQS eliminates the complexity of managing message-oriented middleware. SQS offers two types of queues: Standard queues (maximum throughput, best-effort ordering, at-least-once delivery) and FIFO queues (exactly-once processing, first-in-first-out delivery). Messages can be up to 256 KB in size, with the Extended Client Library supporting up to 2 GB via S3. SQS integrates with Lambda for serverless processing, CloudWatch for monitoring, and IAM for access control. Key features include message retention (1 minute to 14 days, default 4 days), dead-letter queues, visibility timeout, long polling, and server-side encryption. SQS automatically scales to handle virtually unlimited throughput.

  - name: aws-sqs-queues
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-creating-deleting-queue.html"
    content: |
      SQS queues are the fundamental resource for message storage and retrieval. Standard queues offer unlimited throughput and guarantee at-least-once delivery with best-effort ordering. FIFO queues support up to 3,000 messages per second with batching (300 without) and provide exactly-once processing and strict ordering. Queue names must be unique within an account and Region; FIFO queue names must end with .fifo. Queue attributes include visibility timeout, message retention period, maximum message size, delivery delay, receive message wait time, and content-based deduplication (FIFO). Queue policies control access using IAM-style JSON policies. Queues can be tagged for cost allocation and organization. Temporary queues use the Temporary Queue Client to create lightweight queues for request-response patterns. Purging a queue deletes all messages without deleting the queue.

  - name: aws-sqs-messages
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-messages.html"
    content: |
      SQS messages contain a body (up to 256 KB), optional message attributes (up to 10, typed metadata), and system attributes (managed by SQS). SendMessage adds a message to a queue and returns a message ID and MD5 digest. ReceiveMessage retrieves messages and makes them invisible to other consumers for the visibility timeout duration. DeleteMessage permanently removes a message after successful processing. SendMessageBatch and DeleteMessageBatch process up to 10 messages per API call for efficiency. Message attributes support String, Number, and Binary data types with optional custom type labels. System attributes include ApproximateReceiveCount, SentTimestamp, and SenderId. The message group ID (FIFO) determines message ordering within a group. The message deduplication ID (FIFO) prevents duplicate messages within the 5-minute deduplication interval. Message timers set a per-message delay overriding the queue-level delay.

  - name: aws-sqs-visibility
    project: smoke-data
    priority: 6
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html"
    content: |
      The visibility timeout is the period during which SQS prevents other consumers from receiving and processing a message after it has been received. The default visibility timeout is 30 seconds, with a range of 0 seconds to 12 hours. When a consumer receives a message, the message remains in the queue but is hidden from other consumers for the duration of the visibility timeout. If the consumer successfully processes and deletes the message before the timeout expires, the message is permanently removed. If the consumer fails to process the message, it becomes visible again after the timeout. ChangeMessageVisibility extends or shortens the visibility timeout for a specific message while it is being processed. Best practice is to set the visibility timeout to at least 6 times the expected processing time. The visibility timeout clock starts when ReceiveMessage returns, not when the message was sent.

  - name: aws-sqs-dead-letter
    project: smoke-data
    priority: 7
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html"
    content: |
      A dead-letter queue (DLQ) receives messages that cannot be processed successfully from the source queue. The redrive policy on the source queue specifies the DLQ ARN and the maximum receive count (maxReceiveCount). When a message's receive count exceeds maxReceiveCount, SQS moves it to the DLQ. Standard queues must use standard DLQs; FIFO queues must use FIFO DLQs. The DLQ must be in the same AWS account and Region as the source queue. DLQ redrive enables moving messages from the DLQ back to the source queue or a custom destination after fixing the processing issue. Best practices include setting DLQ message retention to the maximum (14 days), configuring CloudWatch alarms on ApproximateNumberOfMessagesVisible, and ensuring maxReceiveCount is high enough to allow normal retry behavior. DLQs help isolate problematic messages, debug processing failures, and prevent message loss.

  - name: aws-sqs-fifo
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html"
    content: |
      FIFO (First-In-First-Out) queues guarantee that messages are processed exactly once and in the exact order they are sent. FIFO queue names must end with .fifo suffix. Message group IDs enable ordered processing within independent message groups, allowing parallel processing across groups while maintaining order within each group. Deduplication IDs or content-based deduplication prevent duplicate messages within the 5-minute deduplication window. FIFO queues support up to 300 API calls per second per action (Send, Receive, Delete) without batching, or 3,000 messages per second with batching. High throughput FIFO queues support up to 9,000 send API calls per second per message group. FIFO queues are ideal for financial transactions, order processing, inventory updates, and any workflow where message order matters. Messages within the same group are delivered in order and processed one at a time.

  - name: aws-sqs-delay
    project: smoke-data
    priority: 3
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-delay-queues.html"
    content: |
      Delay queues postpone the delivery of new messages to a queue for a specified number of seconds. Messages sent to a delay queue remain invisible to consumers for the duration of the delay period. The queue-level delay can be set from 0 to 900 seconds (15 minutes). Per-message timers override the queue-level delay for individual messages on standard queues. FIFO queues do not support per-message timers; the queue-level delay applies to all messages. Delay queues are useful for introducing a waiting period before processing, such as waiting for a related operation to complete, rate limiting downstream processing, or implementing retry delays. The delay period is separate from and precedes the visibility timeout. A message in a delay queue cannot be received until the delay period expires, after which it enters the visibility timeout cycle. Delay queue configuration is set using the DelaySeconds queue attribute.

  - name: aws-sqs-long-polling
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-long-polling.html"
    content: |
      Long polling helps reduce the cost of using SQS by eliminating empty responses when no messages are available and reducing false empty responses. With short polling (default), ReceiveMessage queries only a subset of servers and returns immediately even if no messages are found. Long polling queries all servers and waits up to the specified WaitTimeSeconds (1-20 seconds) for a message to become available before returning. Long polling reduces the number of empty ReceiveMessage responses, lowering costs. Configure long polling by setting the ReceiveMessageWaitTimeSeconds queue attribute or the WaitTimeSeconds parameter on individual ReceiveMessage calls. Per-request settings override queue-level settings. A WaitTimeSeconds value of 0 on a request overrides queue-level long polling with short polling. Long polling is recommended for most use cases as it reduces cost and latency for message delivery.

  - name: aws-sqs-encryption
    project: smoke-data
    priority: 4
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-server-side-encryption.html"
    content: |
      SQS supports server-side encryption (SSE) to protect message contents using AWS KMS keys. SSE encrypts the body of messages in the queue; message metadata (ID, timestamp, attributes) is not encrypted. You can use the SQS-owned encryption key (SSE-SQS, no additional cost), the AWS managed key for SQS (aws/sqs), or a customer managed key (CMK). Customer managed keys provide additional control through key policies, automatic rotation, and CloudTrail audit logging. SSE encryption is applied when messages are sent to the queue and decrypted when messages are received. The data key reuse period (1 minute to 24 hours, default 5 minutes) determines how long SQS reuses a data encryption key before calling KMS again, balancing cost and security. When SNS publishes to an SSE-encrypted SQS queue, the SNS service must have permission to use the SQS queue's KMS key. In-transit encryption is provided by using HTTPS endpoints.

  - name: aws-sqs-access-policy
    project: smoke-data
    priority: 5
    link: "smoke-data/smoke-aws-docs:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-creating-custom-policies-access-policy-examples.html"
    content: |
      SQS queue policies are resource-based policies that control who can access the queue and what actions they can perform. Policies use the same JSON format as IAM policies with Principal, Action, Resource, Effect, and Condition elements. Common scenarios include granting cross-account access, allowing SNS topics to send messages, allowing S3 buckets to send event notifications, and restricting access to specific VPC endpoints. The Principal can specify AWS account IDs, IAM users, IAM roles, or AWS services. Condition keys include aws:SourceAccount, aws:SourceArn, and aws:SourceVpce for restricting access. Best practices include using least privilege, combining queue policies with IAM policies, restricting to specific accounts and services, and using condition keys to verify the sender. Queue policies and IAM policies are evaluated together using the standard IAM policy evaluation logic where an explicit deny always takes precedence.
