Skip to content
DevOps Madnessa blog by Ioannis Moustakis

AWS Certified Generative AI Developer - Professional: Cheat Sheet

· 28 min read

AWS Certified Generative AI Developer - Professional exam study notes, exam pointers, and cheat sheet.

This material was gathered during my preparation for the AWS Certified Generative AI Developer - Professional exam (here’s my badge). I created and curated this cheat sheet with useful information that will be handy to review before taking the exam.

To pass this exam you need a solid working understanding of Amazon Bedrock, SageMaker AI, RAG architectures, and the surrounding AWS services used to build generative AI applications. Use these notes as complementary material, not as complete study material for the exam.

AWS frequently changes information, configuration, and options of different services, so some of this content might become outdated at some point. Cross-check anything you get from online sources with the official AWS documentation and FAQs before your exam.

OK, enough with the disclaimers, let’s get to it.

General concepts

  • The temperature parameter controls the randomness of the model’s output. A lower temperature value (e.g., 0.1) makes the model’s responses more deterministic and consistent. The top_k parameter limits the number of most probable tokens the model considers at each step, leading to more focused outputs. By lowering both temperature and top_k, similar inputs yield more consistent and reliable responses.

  • Transfer learning enables a model to leverage pretrained knowledge learned from a large corpus rather than starting from zero. When applied correctly, the pretrained representation layers are preserved. Only the final classifier layer should be adjusted to reflect the specific prediction task.

  • Overfitting occurs when a model learns the noise or irrelevant details in the training data rather than generalizable patterns, leading to high accuracy on the training set but poor performance on unseen data. It happens when a model is too complex for the available data. Techniques to address it:

    • L1 and L2 regularization penalize large weights, with L1 promoting sparsity and L2 preventing excessively large weight values. The model focuses on generalizable features and avoids fitting noise. SageMaker AI allows easy integration of these techniques during training.
    • Dropout randomly deactivates neurons during training, so the model doesn’t rely too heavily on any specific neuron or feature. Easily implemented in SageMaker AI with frameworks like TensorFlow, Keras, and PyTorch.
    • Reducing the number of layers simplifies the model and reduces its capacity to overfit.
  • Quantization: techniques for reducing the precision of model parameters, decreasing the memory footprint and computational requirements.

  • SMOTE (Synthetic Minority Oversampling Technique) addresses class imbalance by generating synthetic examples for the minority class. It interpolates new samples based on existing ones from the underrepresented category.

  • Chain-of-thought prompting guides the model to reason step by step before providing a final answer.

  • A comprehensive evaluation system for GenAI outputs typically combines automated scoring (to scale across many prompts and releases) with human feedback (to capture real-world usefulness and UX).

  • Cost optimization patterns worth knowing:

    • Prompt compression: use a smaller FM to summarize older conversation history into a short running summary. Include only the summary plus the most recent turns in each request.
    • Intelligent prompt routing: a tiered model selection strategy so that routine requests (like basic summaries) use a cheaper model while complex requests use a higher-capability model.

Model customization

Choose continued pre-training or fine-tuning when:

  • You have a specific task or use case that requires improved performance
  • You have labeled data relevant to your task
  • You need the model to understand domain-specific language (for example, medical or legal terminology)
  • You want to enhance the model’s accuracy for your application

Build a custom foundation model (typically the highest option in resources and cost) when:

  • None of the available pre-trained models meet your specific requirements
  • You have a vast amount of proprietary data to train on
  • You need complete control over the model architecture and training process

Low-Rank Adaptation (LoRA) is a cost-effective fine-tuning method. Only a small portion of a large foundation model needs to be updated to adapt it for new tasks or domains. A LoRA adapter enhances inference from a base foundation model by adding just a few additional adapter layers. SageMaker AI supports adapter inference components, which let you attach LoRA adapters to a hosted foundation model at inference time. This enables dynamic selection of region-specific adapters without redeploying the model or creating multiple endpoints.

RAG: chunking strategies

The document chunking strategy determines how effectively the system can locate and retrieve relevant information from unstructured content. It directly impacts response accuracy, processing costs, and user experience. Unlike embedding models, which can be optimized through dimensional adjustments, chunking fundamentally alters how information is segmented and retrieved.

  • Fixed-size chunking: divides documents into uniform token-based segments (typically 1000 tokens with 200-token overlap) regardless of content structure or logical boundaries. Predictable processing costs, consistent retrieval performance, and reliable implementation across diverse document types. Works well for varied content formats, FAQ systems, and scenarios prioritizing operational consistency. It may fragment related concepts across chunk boundaries.

  • Semantic chunking: breaks content at natural boundaries (section headers, topic transitions, paragraph breaks) to preserve logical units of information. Improves retrieval relevance for well-structured documents such as policy documents, procedures, and structured business reports. Requires 30-50% higher processing costs due to boundary detection complexity, and creates variable chunk sizes that can affect retrieval consistency.

  • Hierarchical chunking: creates multiple representation levels from document summaries down to detailed paragraphs, enabling retrieval at different granularities based on the query. Supports both executive-level summaries and detailed analysis from the same content. Superior query adaptability, but storage costs increase by 200-400% and it requires more sophisticated retrieval logic. Hierarchical chunking is purpose-built for RAG document segmentation when answers depend on small, specific passages but still require surrounding context.

  • For semantic similarity search in a vector store, the Amazon Titan multimodal embeddings model embeds images, text, or both into vector representations that can be stored and queried in a vector database.

  • Smaller embedding dimensionality reduces storage and indexing costs for large corpora, but should be validated to ensure it still captures the semantic detail needed for the domain. Use an Amazon Titan embedding model and configure a smaller embedding vector dimension. Titan Text Embeddings V2 supports 256 / 512 / 1024 dimensions and normalization; smaller dimensions mean cheaper storage and faster search.

  • The embedding model must match between indexing and querying. A mismatch (or a dimension change) silently degrades retrieval; changing the embedding model or dimensions requires a full re-index. Embedding drift occurs when query embeddings are generated with a different model than the one used to index documents, causing a mismatch in vector space that makes retrieval ineffective.

  • ANN search algorithms: when selecting an approximate nearest neighbor algorithm, consider the trade-offs between accuracy, speed, memory usage, and scalability. Common options: locality-sensitive hashing (LSH) for fast indexing, hierarchical navigable small world (HNSW) for high accuracy, inverted file index (IVF) for balance, and product quantization (PQ) for compact storage. Benchmark multiple algorithms with your dataset.

  • Vector search can be slowed by coordinating many shard-level searches and merging results. Reindexing to use fewer, larger shards reduces fan-out and coordination overhead, improving retrieval latency without changing the FM or the document set.

Vector store and retrieval decision map

Vector stores a Bedrock knowledge base can use: OpenSearch Serverless (default, auto-created), Aurora PostgreSQL (pgvector), Pinecone, Redis Enterprise Cloud, MongoDB Atlas, Neptune Analytics (managed GraphRAG), Kendra GenAI index.

  • Managed end-to-end RAG with least ops → Bedrock Knowledge Base on OpenSearch Serverless.
  • Existing relational data, want SQL joins next to vectors → Aurora pgvector (HNSW / IVFFlat indexes).
  • Full control of index, hybrid search, very large scale → OpenSearch Service.
  • Enterprise search with connectors plus per-user document ACLs honored → Kendra (the Retrieve API returns semantically ranked passages; the GenAI index plugs into both Bedrock KB and Q Business).
  • Relationship-heavy / multi-hop corpora → Neptune GraphRAG. GraphRAG (Neptune Analytics) builds an entity/relationship graph over the corpus; choose it when answers require connecting facts across documents.
  • Ultra-low-latency lookups or a semantic-cache layer → in-memory vector search (MemoryDB / ElastiCache-based patterns).
  • Infrequent searches at low cost → S3 Vectors: scalable, cost-effective vector search that automatically optimizes vector data for low-cost performance as datasets scale.
  • Pinecone is a fully managed vector database service designed for high-performance similarity search and retrieval of high-dimensional embeddings at scale.

Amazon Bedrock

  • Custom models trained in Bedrock (fine-tuning / continued pre-training) can only be invoked via Provisioned Throughput.

  • Bedrock supports regional endpoints for low-latency, region-aware inference workflows.

  • Amazon Bedrock Data Automation (BDA) is a fully managed service that automates transforming unstructured media content (text, images, audio, video) into structured insights.

  • Amazon Titan Image Generator creates high-quality images from natural-language text prompts or reference visuals. Its outputs carry invisible watermarks, and Bedrock provides watermark detection.

  • With the Jamba model from AI21 Labs, users can efficiently summarize large volumes of text. Jamba is optimized for generating coherent, concise summaries.

  • For model selection based on business logic: centralize model selection behind API Gateway and route based on request content. Start a Step Functions workflow, run a lightweight classification step, use Choice states for routing, and invoke the selected Bedrock model from a Lambda task.

  • To improve throughput: set task-specific maxTokens ceilings for short JSON responses, and trim oversized prompt context before invocation.

Runtime APIs

  • Converse API: a consistent interface that works with all models that support messages. Write code once and use it with different models. Model-specific inference parameters can still be passed.
  • ConverseStream: sends messages to the specified model and returns the response in a stream, with the same consistent cross-model interface.
  • InvokeModelWithBidirectionalStream: runs inference using a bidirectional stream. The response stream remains open for 8 minutes.
  • CountTokens API: returns the token count for a given inference request without invoking the model. Use it to estimate token usage and enforce token budget checks; CloudWatch metrics provide ongoing visibility into latency and token consumption.
  • Stop sequences: stop the model after it generates certain key phrases.
  • Tool use: toolConfig carries tool specs (JSON schema) plus toolChoice: auto (model decides), any (must call some tool), tool (force one specific tool). The loop: model returns a toolUse block → app executes → send back toolResult → repeat until end_turn. Forcing a specific tool is the reliable structured-output pattern: schema-conformant JSON without prompt pleading. Combine with schema validation and a single retry on failure.
  • Converse also carries guardrailConfig (id/version/trace), additionalModelRequestFields (model-specific params like top_k), and document/image content blocks for multimodal input.

Throughput, quotas, and cost

  • Quotas are per-model, per-Region RPM + TPM. Throttling answer ladder: exponential backoff + jitter (SDK adaptive retry mode) → cross-Region inference → SQS buffering → Provisioned Throughput → quota increase.

  • Cross-Region inference (CRIS): with a geographic cross-region inference profile, data movement remains within the Regions of that geography. Input and output data may be transmitted to a different Region within the geography for processing, but the data is stored in the source Region and encrypted in transit. CRIS also increases burst throughput (~2x quotas) by spreading traffic across Regions in the geography, so it’s an answer to throttling, not only resilience.

  • Application inference profiles: create a profile wrapping a base or CRIS profile and attach cost-allocation tags → per-team/tenant/app spend in Cost Explorer plus per-profile CloudWatch metrics. The answer to “attribute Bedrock cost by application”.

  • Prompt caching: cachePoint markers on a stable prefix; ~5-minute sliding TTL (resets on hit); cache-read tokens billed at a steep discount (~90%); model-specific minimum prefix token counts.

  • CloudWatch Bedrock runtime metrics worth recognizing by name: Invocations, InvocationLatency, InputTokenCount, OutputTokenCount, InvocationThrottles, InvocationClientErrors, InvocationServerErrors.

  • With Bedrock invocation logging, you can capture the complete request data, response data, and metadata for all calls made in your account within a Region. Supported destinations: CloudWatch Logs and S3.

Guardrails

  • Six policy types:

    1. Content filters (hate, insults, sexual, violence, misconduct, prompt attack) with per-category strength NONE→HIGH, configured independently for input vs output.
    2. Denied topics: natural-language topic definitions, up to ~30.
    3. Word filters: managed profanity plus custom words/phrases.
    4. Sensitive information filters: managed PII entity types with per-entity action Block or Mask (masked output uses {NAME}-style placeholders), plus custom regex.
    5. Contextual grounding checks: grounding score and relevance score thresholds; requires source content passed with the request. Provides an automated way to assess whether the response is supported by the retrieved context.
    6. Automated reasoning checks: apply structured policy logic derived from a policy document.
  • Guardrails can filter or mask PII in both incoming prompts and outgoing responses. Note: guardrail PII masking does not mask model invocation logs.

  • Guardrail profiles allow configurations to be applied across multiple Regions for consistent safety controls and cross-Region inference failover. Detailed guardrail actions (blocked content, modified responses, rejected prompts) can be captured in CloudWatch Logs for monitoring and auditing.

  • Configure guardrail tracing with {"trace": "enabled"} in guardrailConfig. Monitor InvocationsIntervened metrics filtered by the GuardrailPolicyType dimensions: ContentPolicy, TopicPolicy, and SensitiveInformationPolicy.

  • ApplyGuardrail API: evaluate any text against a guardrail standalone, with no Bedrock model invocation. Works for SageMaker-hosted, third-party, or self-hosted models. The answer to “consistent safety controls across models running anywhere”.

  • Guardrails add latency and are billed per text unit; expect cost/latency trade-off questions about applying them selectively.

  • You can enforce the use of a specific guardrail for model inference by including the bedrock:GuardrailIdentifier condition key in your IAM policy.

Knowledge Bases

  • Knowledge bases support built-in logging you can send to CloudWatch Logs. The logs track the status of files during data ingestion jobs: successfully ingested, ignored, or failed.

  • Chunking options at ingestion: default (~300 tokens), fixed-size, semantic, hierarchical (parent-child: match on the child chunk, return the parent for context), none (use when documents are pre-chunked upstream), or custom chunking via a Lambda transformation during ingestion.

  • Grounding ensures the foundation model produces evidence-supported content rather than relying solely on internal model parameters.

  • The Retrieve API queries a knowledge base and returns retrievalResults that include content, location, metadata, and a relevance score. Calling Retrieve for each focused subquery improves coverage for multi-intent questions, because each part can retrieve its own relevant evidence before the application performs synthesis.

  • RetrieveAndGenerate can generate a response and return citations that connect response spans to retrieved source references.

  • Reranking: Knowledge Bases can reorder retrieved chunks using a Bedrock reranking model, which addresses the ranking problem without a custom retriever. Bedrock reranker models are specifically designed to improve the relevance of retrieved results. The Rerank API also exists standalone (Amazon and Cohere rerankers), usable in a custom RAG stack outside Knowledge Bases.

  • Metadata filtering: a sidecar <file>.metadata.json per document enables query-time filters (equals / in / greater-than, etc.). The fix for “restrict retrieval by department/date/tenant”. Implicit filtering can derive filters from the natural-language query.

  • Data sources beyond S3: Confluence, SharePoint, Salesforce, Web Crawler, custom. Knowledge Bases connect directly to enterprise knowledge sources such as Confluence and SharePoint, providing a managed path from source documents to semantic retrieval. Ingestion enforces per-file size limits (~50 MB) and file-count quotas. Skipped or failed files appear in the sync (ingestion job) history and statistics, the first place to look when retrieval “misses” documents.

  • Keeping documents up to date: send S3 event notifications for object create, overwrite, and delete events to EventBridge. An EventBridge rule invokes a Lambda function that calls StartIngestionJob for the knowledge base whenever relevant S3 changes occur.

  • Structured data retrieval: a knowledge base can target Redshift and generate SQL (text-to-SQL), giving grounded answers over warehouse data without moving it into a vector store.

Model evaluation

  • Bedrock Model Evaluations provides a systematic way to compare models and inference settings on the same prompt dataset. When you create an evaluation job you specify the model, the type of task, and the prompt dataset. You can create a custom prompt dataset for automatic evaluation jobs.

  • Steps for evaluating chatbot accuracy in text generation: start the automatic model evaluation in Bedrock, use the TREX dataset for general text generation, and assess performance using the Real World Knowledge (RWK) score.

  • Evaluation results can be centrally stored in S3, then made queryable through the Glue Data Catalog and Athena.

  • Managed RAG evaluation jobs can score retrieval-and-generation behavior with LLM-as-a-judge techniques against a prompt dataset in S3, including faithfulness/groundedness and citation-oriented metrics.

Prompt management and flows

  • Bedrock Flows orchestrates multistep prompts and prompt chains. It enables graceful failure and recovery for long prompt chains, and has nodes for controlling flow logic, including iterator nodes and condition nodes.

  • Bedrock Prompt Management provides centralized prompt storage, parameterization (template variables), and version governance, including controlled promotion of prompt versions through an approval process. It can enforce a consistent response format (such as a required JSON structure). Prompt Management variants and Prompt Flows support systematic A/B testing without building custom orchestration.

  • Advanced Prompt Optimization supports up to five models per job and allows 1 to 100 evaluation samples per template.

Bedrock agents and AgentCore

Every response from a Bedrock agent includes a trace that outlines the steps the agent is taking:

  • PreProcessingTrace: the pre-processing step, where the agent contextualizes and categorizes user input and determines if it is valid.
  • OrchestrationTrace: the orchestration step, where the agent interprets the input, invokes action groups, and queries knowledge bases, then returns output to continue orchestration or respond to the user.
  • PostProcessingTrace: the post-processing step, where the agent handles the final output of the orchestration and determines how to return the response.
  • CustomOrchestrationTrace: details about the custom orchestration step, where the agent determines the order in which actions are executed.
  • RoutingClassifierTrace: the input and output of the routing classifier.
  • FailureTrace: the reason a step failed.
  • GuardrailTrace: the actions of the guardrail.

AgentCore capabilities:

  • AgentCore Evaluations: for a CI pipeline that submits one session and needs an immediate result, the Evaluate API is the right fit: the on-demand, synchronous scoring API for agent traces. It requires a specified evaluatorId, accepts traces in OpenTelemetry format, and returns evaluationResults that can pass or fail the pipeline.

  • Identity: workload identities and a token vault for agents; OAuth 2LO/3LO flows and API keys. An agent acts on a user’s behalf across services without hardcoded credentials.

  • Gateway: turns existing capabilities into MCP tools. Targets are Lambda functions, OpenAPI specs, and Smithy models. Handles inbound authorization (OAuth) and outbound credential injection, and provides semantic tool search so an agent can find the right tool among hundreds.

  • Observability: built-in deep visibility into applications that rely on foundation models. Captures structured invocation data, including request and response metadata, input validation information, model interaction traces, and FM-level error patterns.

  • Runtime: when configured for the MCP protocol, the container must expose the MCP endpoint at 0.0.0.0:8000/mcp. Stateless HTTP is the default and fits simple, independent tool calls. Tools that need multi-turn elicitation, LLM sampling, or progress notifications need retained MCP session state, so they should use stateful mode. For portable client integration, AWS documents using the official mcp package.

Orchestration positioning: Step Functions = deterministic, auditable orchestration; Bedrock Agents / AgentCore = managed agentic runtime; Strands / Agent Squad = code-first AWS-native frameworks.

Amazon SageMaker

Inference options

  • Real-time endpoints: auto scaling on InvocationsPerInstance. Real-time endpoints also support streaming via InvokeEndpointWithResponseStream.
  • Serverless Inference: spiky or intermittent traffic; cold starts; no GPUs.
  • Asynchronous Inference: a managed, scalable approach for large or variable workloads where requests can be queued and processed later rather than needing real-time responses. Supports payloads up to 1 GB and automatically stores both input data and prediction results in S3. Can be configured with an automatic scaling policy based on request volume.
  • Batch Transform: can send multiple records in each request when the container supports batched input and output. Increasing concurrent transforms and tuning payload size can raise per-instance utilization and throughput.
  • Multi-Model Endpoints: many models behind one endpoint, lazily loaded. The cost play for many small models.
  • Inference Recommender: automated load testing to choose instance type and endpoint config.
  • Large Model Inference (LMI): the best fit when the deployment challenge is specific to LLMs rather than ordinary model hosting. Specialized containers, libraries, and tooling for large model inference, including optimizations such as quantization, tensor parallelism, and continuous batching.
  • Inferentia2 (Inf2) / Trainium: purpose-built silicon via the Neuron SDK. The price-performance answer for self-hosted LLM inference and training (LMI containers support it).

Training, tuning, and algorithms

  • DeepAR: a supervised learning algorithm for forecasting scalar (one-dimensional) time series using recurrent neural networks (RNN). When your dataset contains hundreds of related time series, DeepAR is the answer.
  • The Hyperband tuning strategy makes hyperparameter tuning more efficient by intelligently allocating computational resources: it automatically stops poorly performing training jobs early while allocating more resources to promising configurations.
  • max_depth controls the maximum depth of individual trees in a tree-based model. Reducing tree depth simplifies the model, prevents it from fitting noise or overly complex relationships, and helps it generalize.
  • For object detection, SageMaker’s built-in algorithms both classify and localize multiple objects within an image by generating bounding boxes and corresponding class labels.
  • SageMaker Processing fits tabular preparation steps: it runs a supplied processing container as a managed job and writes curated outputs to S3.
  • Ground truth data (a golden dataset) is a curated set of prompts and responses that describe the ideal workflow with a model. Use SageMaker Ground Truth or similar to scale the curation of this dataset.

Tooling and governance

  • JumpStart: ready-to-use, one-click solutions tailored to common use cases.
  • Clarify: assess model fairness and interpretability. Set up a Clarify processing job to calculate bias metrics, generate feature attribution scores, and produce explainability reports.
  • Autopilot: automates building and deploying ML models (AutoML). Primarily optimized for tabular data and classification/regression tasks, not time series forecasting.
  • Canvas: a no-code ML interface for business analysts and domain experts who want accurate predictions without writing code or managing infrastructure. Used together, AWS Glue DataBrew and SageMaker Canvas form a robust, no-code data-to-insight pipeline.
  • Model Monitor has four monitor types: data quality, model quality, bias drift, feature attribution drift.
  • Model cards document model intent, limitations, and versioning. Maintaining a model card addresses governance needs by documenting intended use, limitations, and constraints in a standardized way.
  • Network isolation: set EnableNetworkIsolation to True when calling CreateTrainingJob, CreateHyperParameterTuningJob, or CreateModel if you don’t want SageMaker AI to provide external network access to training or inference containers.
  • To secure SageMaker notebook instances so only authorized users within the VPC can access them, create an IAM policy with a condition that restricts access to the VPC interface endpoint.

Other AI services

  • Amazon Comprehend: toxicity detection is a safety classifier that automatically identifies harmful or abusive language in text. The PII detection feature enables automated identification and redaction of PII in plain-text documents (the DetectPiiEntities API operation). Custom Entity Recognition (CER) identifies and labels domain-specific terms or entities within text. Pre-processing with Comprehend can detect common PII types and mask them before the request reaches the FM.

  • Amazon Textract: provides structured outputs and confidence scores for each extracted element, indicating the reliability of the detected text or data.

  • Amazon Transcribe: converts audio speech into text, with real-time and batch transcription for many languages and audio formats. Custom vocabularies fine-tune transcription for domain-specific terminology such as technical terms, proper names, or specialized phrases. Its Toxicity Detection capability applies to voice data.

  • Amazon Translate: custom terminology lets you create specialized word lists for accurate and consistent translations of domain-specific terms, acronyms, or technical phrases.

  • Amazon Lex: a fully managed service for conversational interfaces using automatic speech recognition (ASR) and natural language understanding (NLU) to convert speech and text into structured intents and slot values. Custom slot types define lists of acceptable input values for a slot, which helps the chatbot handle linguistic variety without additional backend logic or retraining.

  • Amazon Rekognition: image/video moderation labels. Screen user-uploaded images before they reach a multimodal FM.

Amazon OpenSearch

  • For large-scale deployments, sharding strategies are key to performance and scalability. Sharding distributes the vector index across multiple nodes, enabling parallel similarity search and horizontal scaling. By partitioning embeddings into logical shards, OpenSearch can handle millions or billions of vectors while maintaining low-latency queries.

  • The Neural plugin allows OpenSearch to generate embeddings during ingestion and at query time by invoking an embedding model in Bedrock.

  • Topic-based segmentation (separate indices per topic): separating domains into dedicated indexes enables domain-specific tuning, including embedding approaches and index settings.

  • A hierarchical (summary-to-detail) index pattern reduces the search space and improves routing, while fewer, larger shards reduce coordination overhead and improve vector search performance and cluster stability at scale.

  • For managed OpenSearch Service vector search, the retrieval architecture has two separate design concerns: how the corpus is partitioned, and how each vector index is configured and queried.

  • Shard planning: AWS guidance is workload-dependent. 10-30 GiB shards are commonly recommended when search latency is the key objective, 30-50 GiB shards suit write-heavy workloads, and too many small shards create CPU, memory, and out-of-memory pressure.

  • Hybrid search improves relevance by rewarding exact keyword matches (for identifiers) while still leveraging semantic similarity for natural-language queries.

  • Search latency: reindexing into fewer, larger shards reduces cross-shard fan-out and coordination work during vector and hybrid queries, improving latency.

Data and storage services

  • AWS Glue DataBrew: a visual data preparation service to clean and normalize raw datasets at scale without complex coding or manual data wrangling.
  • AWS Glue enables lineage and systematic data source attribution through cataloging and metadata tagging.
  • AWS Glue Data Quality: automated, rule-based validation that can be embedded directly into Glue jobs. Rulesets can enforce completeness and basic validity checks (required fields, non-empty strings).
  • The Detect PII transform in Glue identifies PII within your data source. You specify which PII entities to detect, how the data is scanned, and the actions to take on identified entities.
  • Glue ETL jobs can use S3, VPC data stores, or on-premises JDBC data sources as input.
  • S3 encryption: SSE-KMS encrypts model artifacts at rest with a customer-managed KMS key, allowing fine-grained access control and auditability. SSE-S3 encrypts at rest but does not offer the same level of fine-grained access control and auditability.
  • S3 Access Points are primarily designed for managing access to shared datasets at scale, especially in multi-tenant environments.
  • A metadata framework that separates content from metadata (timestamps, authorship, domain tags) improves precision and context awareness without changing the core RAG architecture → define a standardized metadata schema stored as S3 object metadata.
  • FSx for Lustre: a high-performance file system for workloads that need fast, parallel access to large datasets (ML training, HPC, analytics). When linked to an S3 bucket, it presents S3 objects as files, so SageMaker training jobs read data at file system speeds while S3 remains the source of truth. Data written back to FSx can be automatically exported to S3, with no data duplication or complex migration.
  • DynamoDB works great for storing reviewer inputs. A DynamoDB-backed circuit breaker persists across executions and can implement a cooldown period using TTL.
  • Amazon Data Firehose: fully managed streaming of real-time data into storage services such as S3. Ideal for continuous data ingestion. Know the split: Kinesis Data Streams (custom real-time consumers) vs Firehose (managed delivery) vs MSK (Kafka-compatible).
  • AppFlow: SaaS → S3 sync without custom code (e.g., Salesforce exports feeding a knowledge base pipeline).
  • DataSync / Transfer Family: move on-prem file shares into S3 to feed knowledge bases.
  • EventBridge Scheduler: cron for scheduled knowledge base syncs and batch evaluation runs.
  • Service Catalog: publish vetted GenAI stack templates org-wide.
  • QuickSight ML Insights: built-in anomaly detection using ML to automatically identify data outliers or trends.

Application integration and serverless patterns

API Gateway

  • A WebSocket API provides a straightforward way to push incremental updates to the browser in near real time.
  • API Gateway provides a simple, controlled interface for collecting human feedback and decisions. An API Gateway + Lambda + DynamoDB pattern captures explicit user ratings and annotations at scale.
  • A centralized GenAI gateway is best implemented with API Gateway in front of a Lambda layer that invokes Bedrock, so the organization can standardize request validation, throttling, and access patterns.
  • REST API response streaming: configured with response transfer mode STREAM. AWS documents server-sent events and generative AI chatbot time-to-first-byte reduction as use cases. With Lambda proxy integration, API Gateway uses the Lambda streaming invocation path ending in /response-streaming-invocations.
  • AWS positions REST APIs as more customizable and feature-rich, while HTTP APIs are the lower-latency, lightweight option.
  • Integration timeout: 29 s default (raisable via quota for Regional REST APIs). The classic cause of “long generations fail behind API Gateway”. Fixes: response streaming, WebSockets, or go async (SQS + status polling / callback).

Step Functions

  • Provides a managed orchestration layer for review and approval workflows, including waiting for human actions. The .waitForTaskToken callback pattern pauses the workflow until SendTaskSuccess / SendTaskFailure is called: THE managed human-approval / external-callback pattern.
  • Can enforce explicit stopping conditions by tracking failure counts in state input and branching with a Choice state.
  • Can implement ReAct-style patterns by combining Bedrock model invocations with tool invocations, conditional branching, and termination logic.
  • Use a Parallel state to invoke two different Bedrock models at the same time.
  • Express Workflows are limited to 5 minutes.
  • Map state (inline vs distributed; distributed = massive parallel fan-out over S3 items) for parallel document/chunk processing.

Lambda

  • A Lambda pre-processing layer enables targeted detection and sanitization of adversarial prompt patterns (common prompt-injection and jailbreak patterns, e.g. with pattern matching and named entity recognition) before the request reaches the model or tools.
  • A lightweight Lambda pre/post-processing layer can enforce deterministic checks (such as ensuring a required disclaimer is present and blocking noncompliant outputs) before returning content to users.
  • Reusing clients keeps connections open across invocations, reducing repeated TLS handshakes and connection setup time.
  • Invocation payload limits: 6 MB each for request and response (synchronous).

Other integration services

  • SQS event source mappings process records at least once. Use the interaction ID as an idempotency key if needed.
  • AWS AppConfig: retrieve externalized configuration dynamically at runtime. For Lambda, use the AppConfig Agent Lambda extension to fetch configuration updates without custom polling logic. Designed for dynamic configuration changes independent of code deployments; supports validation and progressive deployments with rollback based on CloudWatch alarms.
  • Secrets Manager: for API token rotation, it natively automates secret rotation through its integration with Lambda.
  • CloudWatch Synthetics: continuous, automated checks that simulate end-to-end usage. Alarms on the resulting metrics create ongoing regression detection with minimal custom infrastructure.
  • X-Ray: trace API Gateway → Lambda → Bedrock spans; find tail latency and per-dependency errors.
  • AWS Outposts: run AWS compute and storage on premises for local data integration and residency. De-identifying on Outposts ensures only approved data is sent to the FM.

Human-in-the-loop flows

  • SageMaker Ground Truth Plus: a managed data labeling service for human-in-the-loop workflows. Domain experts, such as healthcare professionals, can review and correct AI-generated summaries before they are used in production. Ideal for regulated industries.
  • Amazon Augmented AI (A2I): a managed framework for incorporating human review into ML workflows. Typically used for specific human review tasks during inference, such as document classification or moderation, rather than full-scale data labeling and retraining workflows.
  • Amazon Nova Canvas: primarily intended for real-time, human-in-the-loop creative processes, such as brainstorming or refining visuals in a shared workspace.
  • Step Functions with .waitForTaskToken for managed review and approval workflows (see above).

Caching

  • Prompt caching is most effective for a stable, reusable prompt prefix (for example, instructions and few-shot examples). It reduces token cost and improves latency by reusing a cached prefix, but it still invokes the FM for every request. It does not avoid unnecessary FM invocations when users ask the exact same question repeatedly.
  • Edge caching with CloudFront can avoid unnecessary FM invocations entirely for repeated requests by serving cached responses at edge locations. This directly reduces Bedrock invocation volume and improves latency for global users.
  • Caching decision ladder: identical repeated requests → CloudFront edge cache or exact-match cache (ElastiCache); similar but not identical questions → semantic cache (embed the query → similarity lookup over cached answers → serve above a threshold); long shared prompt prefix → prompt caching; expensive retrieval → cache retrieved contexts.

Deployments

  • A canary deployment provides controlled exposure of the new configuration to live traffic and a straightforward rollback mechanism. Use it to expose only a limited production cohort or for gradual rollout.
  • AppConfig for gradual rollout and automatic rollbacks.
  • CodePipeline: for automatic rollback, the stage must already have had a successful execution after the rollback configuration exists. A successful baseline deployment matters before relying on automatic recovery.

Security and governance

  • Data poisoning happens during pre-training, domain adaptation, and fine-tuning, where poisoned data is introduced, intentionally or by mistake, into a model. It is considered successful if the model has learned from poisoned data. Protect models by isolating the training environment, infrastructure, and data. For voice data, consider Amazon Transcribe’s Toxicity Detection; for text data, consider the Bedrock Guardrails API to filter data.
  • PrivateLink: Bedrock interface endpoints are service-specific (bedrock, bedrock-runtime, bedrock-agent, bedrock-agent-runtime) for private access without the internet. Combine with endpoint policies and aws:SourceVpce-style IAM conditions.
  • Data privacy commitments: customer prompts and outputs are not used to train base models and are not shared with model providers; content stays in-Region.
  • KMS customer-managed keys encrypt custom models, knowledge bases, agents, and guardrails: fine-grained control plus CloudTrail auditability.
  • SCPs / IAM conditions pin usage org-wide: allow bedrock:InvokeModel only on approved model or inference-profile ARNs, or only in approved Regions.
  • Macie: automated discovery of sensitive data at rest in S3. Scan corpora and log buckets before they feed RAG or fine-tuning; complements Comprehend (in-flight detection).
  • AWS WAF in front of API Gateway / CloudFront: rate-based rules against token-flooding abuse and scraping of GenAI endpoints.
  • Cognito for end-user auth, plus API Gateway usage plans / API keys for per-tenant throttling.
  • CloudTrail = API activity (who called what, control plane).
  • VPC endpoints: interface VPC endpoints are not used to connect to S3; S3 typically requires gateway VPC endpoints for private access. An endpoint policy is a resource-based policy attached to a VPC endpoint, controlling which AWS principals can access a service through the endpoint.

Errors, quotas, and troubleshooting

  • ThrottlingException → RPM/TPM quota hit: backoff + jitter (SDK adaptive retry mode) → CRIS → SQS smoothing → Provisioned Throughput → quota increase.
  • ValidationException → malformed request or input exceeds the model’s context window → truncate / summarize (prompt compression) / re-chunk; also check the model-specific request schema.
  • ModelTimeoutException or a stream cut mid-response → reduce maxTokens, stream output, retry idempotently.
  • AccessDeniedException → model access not enabled in that Region/account, or an IAM / VPC endpoint policy block. Check the Model access page first.
  • Retrieval-quality debugging order: (1) ingestion/sync job status and statistics (skipped or failed files), (2) same embedding model and dimension for index and query, (3) chunk size vs question granularity, (4) top-K and score thresholds, (5) metadata filters too strict, (6) add a reranker.
  • Hallucination mitigation ladder: ground with a knowledge base → contextual grounding threshold → lower temperature/top_p → require citations (RetrieveAndGenerate) → human review for high-stakes outputs.
  • Truncated outputmaxTokens too low or a stop-sequence collision. Repetitive output → temperature/top_p tuning.
  • JSON format drift → forced tool use / stricter schema plus a validate-and-retry Lambda.

Evaluation metrics map

  • Classic NLP metrics by task: ROUGE = summarization overlap, BLEU / METEOR = translation, BERTScore = semantic similarity, F1 / exact match = extractive QA, perplexity = language-model fit.
  • Bedrock automatic model evaluation built-in metric dimensions: accuracy, robustness, toxicity (task types: text generation, summarization, QA, classification). Human-based jobs = custom metrics with your own workforce.
  • LLM-as-a-judge job metrics: correctness, completeness, faithfulness, coherence, helpfulness, plus responsible-AI checks such as harmfulness and refusal.
  • RAG evaluation splits in two: retrieve-only → context relevance / coverage; retrieve-and-generate → faithfulness/groundedness, correctness, citation precision and coverage.
  • Shadow testing (SageMaker shadow variants): mirror live traffic to a new model/config and compare offline with zero user impact; precedes canary. Production variants with traffic weights = managed A/B testing.
  • Golden-dataset regression: run on every model/prompt change, score with semantic similarity or an LLM judge, alarm on score drops via CloudWatch. The deployment quality gate pattern.

Good luck with your exam.

Ioannis

Cloud infrastructure architect and technical writer — IaC × AI agents. About