AWS AIP-C01: FM Integration and Data

Topic snapshot

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Foundation Model Integration, Data Management, and Compliance

A company is building a customer support GenAI API with Amazon API Gateway and AWS Lambda. The API must route requests by tenant and use case to either an Amazon Bedrock foundation model or a SageMaker AI endpoint. Operations must be able to switch providers, canary the routing change, and roll back on CloudWatch alarms without redeploying API Gateway or Lambda. Which implementation best meets these requirements?

Options:

• A. Use Lambda environment variables for model IDs and endpoint names

• B. Use separate Step Functions workflows with hardcoded model ARNs

• C. Use API Gateway stage variables to call each provider directly

• D. Use AWS AppConfig for routing rules consumed by Lambda adapters

Best answer: D

Explanation: The key pattern is externalized model routing plus a provider abstraction. AWS AppConfig can store tenant and use-case rules, deploy changes gradually, validate configuration, and roll back based on CloudWatch alarms while Lambda continues using the same code path.

Dynamic model selection should separate runtime configuration from application code. In this design, Lambda implements a stable request/response contract and provider-specific adapters for Bedrock and SageMaker AI. AWS AppConfig stores the active routing rules, model IDs, inference profiles, or endpoint names by tenant and use case. AppConfig deployment strategies, validators, and CloudWatch alarm integration let operations canary and roll back routing changes without redeploying Lambda or API Gateway. The application can cache AppConfig data to avoid adding unnecessary latency while still refreshing configuration on a controlled interval.

The closest alternatives either require deployment changes or hardcode provider choices, which prevents safe operational switching.

• Environment variables require updating Lambda configuration and typically publishing or redeploying infrastructure, so they are not ideal for controlled runtime switching.
• Stage variables do not provide provider-specific request adaptation, validation, or AppConfig-style rollout and rollback controls.
• Hardcoded workflows move the routing decision into deployed orchestration definitions, so provider changes still require workflow updates.

Question 2

Topic: Foundation Model Integration, Data Management, and Compliance

A claims-processing application invokes Anthropic Claude 3 Sonnet through Amazon Bedrock InvokeModel to summarize uploaded claim notes. After a model migration, every request fails before inference.

Exhibit: CloudWatch log excerpt

ValidationException: Malformed input request
#: required key [anthropic_version] not found
#: required key [messages] not found
#: extraneous key [inputText] is not permitted
Request body:
{"inputText":"Summarize this claim note...","textGenerationConfig":{"maxTokenCount":512}}

Which change fixes the root cause with the smallest safe change?

Options:

• A. Increase the Lambda function memory allocation.

• B. Reduce the prompt length below the model context window.

• C. Recreate the Bedrock model access permission.

• D. Serialize requests using Claude’s Messages JSON schema.

Best answer: D

Explanation: The symptom is a Bedrock validation error before inference starts. The root cause is a model-specific payload mismatch: the application is sending a Titan-style inputText request to a Claude Messages model. The smallest safe fix is to change only the request serializer for that model family.

Bedrock InvokeModel payloads are model-specific. A request that works for one model family, such as a Titan text payload with inputText and textGenerationConfig, is not automatically valid for Anthropic Claude 3. Claude 3 expects a Messages-style JSON body that includes fields such as anthropic_version, messages, and max_tokens, with user content represented in the conversational message structure. The failure occurs during request validation, so compute capacity, permissions, and prompt length are not the root issue. The key takeaway is to route each model invocation through a serializer that emits the schema required by the selected foundation model.

• Compute tuning does not address a request rejected as malformed before model execution.
• Model access would cause an authorization or access error, not an extraneous-key schema validation error.
• Prompt shortening helps context overflow, but the log shows missing required JSON fields instead.

Question 3

Topic: Foundation Model Integration, Data Management, and Compliance

A platform team is standardizing retrieval augmentation for several FM applications. The applications should not connect directly to vector indexes. They need one IAM-protected AWS interface that accepts natural-language queries, applies knowledge-base metadata filters, and returns relevant source chunks and scores so each application can build its own prompt. Which AWS capability best fits this role?

Options:

• A. AWS Glue Data Catalog table APIs

• B. Amazon OpenSearch Service k-NN queries

• C. Amazon Bedrock Knowledge Bases Retrieve API

• D. Amazon Bedrock InvokeModel API

Best answer: C

Explanation: Amazon Bedrock Knowledge Bases can expose retrieval through the Retrieve API, which returns relevant chunks and scores for RAG workflows. This fits applications that want to construct prompts themselves while using a consistent, IAM-controlled retrieval layer.

The core concept is separating retrieval access from direct vector-store implementation. Amazon Bedrock Knowledge Bases manages the connection to supported vector stores and exposes retrieval operations such as semantic search, metadata filtering, and returned source chunks. Using the Retrieve API lets multiple FM applications use a consistent contract while avoiding direct coupling to OpenSearch, Aurora pgvector, or other backing stores. It also supports normal AWS access control patterns through IAM. Use Retrieve when the application wants retrieval results for its own prompt construction; use RetrieveAndGenerate when Bedrock should also call a model to generate the answer.

• Model invocation calls an FM but does not provide a standardized retrieval interface over indexed knowledge sources.
• Direct k-NN queries can perform vector search, but they couple each application to the vector store and its query/security model.
• Catalog APIs describe datasets and schemas; they do not execute semantic retrieval for RAG prompts.

Question 4

Topic: Foundation Model Integration, Data Management, and Compliance

An insurance company is moving a claims-assistant prototype to production on Amazon Bedrock. The assistant must use a Bedrock Knowledge Base for policy citations, return a fixed JSON object consumed by an existing Step Functions workflow, reuse and version approved tone/safety/legal instructions across several assistants, and show only a concise justification—not hidden chain-of-thought—to users or logs. Which architecture best fits these requirements?

Options:

• A. Use Bedrock Prompt Management, Prompt Flows, JSON output validation, and citation logging.

• B. Use Bedrock Guardrails as the prompt repository and allow team-specific output formats.

• C. Call RetrieveAndGenerate with Lambda-stored prompts and parse free-form answers.

• D. Fine-tune a SageMaker model to emit JSON and full reasoning traces.

Best answer: A

Explanation: The best fit is a prompt-operations architecture, not a model-training or safety-filter-only approach. Bedrock Prompt Management supports reusable, versioned prompt assets, while Prompt Flows can orchestrate retrieval and model invocation. JSON validation and concise rationale instructions meet the downstream workflow and reasoning-disclosure constraints.

The core concept is prompt governance with structured output and controlled reasoning disclosure. Bedrock Prompt Management provides a governed place for reusable prompt templates and approved instruction blocks with versioning. Prompt Flows can compose the Bedrock Knowledge Base retrieval and model invocation into a controlled workflow. The prompt should define the required JSON fields, include citations, and request only a concise rationale_summary rather than chain-of-thought. The application should validate the JSON before Step Functions and log prompt version, citations, and validation outcomes for auditability. A safety filter alone does not manage prompt lifecycle or output contracts, and fine-tuning is unnecessary for a prompt-governance requirement.

• Hard-coded prompts fail because they do not provide reusable versioned governance or reliable structured output control.
• Fine-tuning approach overbuilds the solution and conflicts with the requirement to avoid exposing full reasoning traces.
• Guardrails-only design confuses safety filtering with prompt operations and permits inconsistent output formats.

Question 5

Topic: Foundation Model Integration, Data Management, and Compliance

An insurance company is building a claims assistant in one AWS account in us-east-1. Source objects in Amazon S3 include PDF claim packets with forms and tables, JPEG damage photos, MP3 adjuster calls, and daily CSV policy extracts. Requirements: prepare inputs for an Amazon Bedrock multimodal FM, make new data searchable for RAG within 15 minutes, enforce claim/customer metadata filters with source citations, keep raw content in-Region, and avoid custom model training. Which architecture is the best fit?

Options:

• A. Use same-Region S3 events to start Step Functions with SQS retries; validate and quarantine files; use Bedrock Data Automation for PDFs/images, Transcribe for audio, and Glue Data Quality for CSVs; normalize artifacts with metadata, embed with Titan, and index in Bedrock Knowledge Bases backed by OpenSearch Serverless.

• B. Fine-tune a custom multimodal model in SageMaker AI on all historical claims files, deploy an endpoint, and refresh the model weights daily as new claims arrive.

• C. Use Lambda to base64-encode every S3 object and include all PDFs, images, audio files, and CSVs directly in each Bedrock InvokeModel request.

• D. Use Glue crawlers and Athena over the S3 bucket for all files, expose SQL views to the application, and pass retrieved rows and object URIs to a text-only Bedrock model.

Best answer: A

Explanation: The best design uses a governed, event-driven multimodal preprocessing pipeline before retrieval and FM invocation. It converts PDFs, images, audio, and CSVs into normalized text or structured artifacts with metadata, then indexes embeddings for fresh, filterable RAG with citations.

The core concept is modality-specific preparation for FM consumption. S3 event ingestion with Step Functions and SQS provides resilient orchestration within the Region. Validation and quarantine prevent corrupt or unsupported inputs from reaching the FM. Bedrock Data Automation can extract useful content from documents and images, Transcribe converts audio to text, and Glue Data Quality validates tabular extracts. The workflow then normalizes chunks, captions, transcripts, and table rows with claim/customer/source metadata, creates embeddings with an Amazon Bedrock embedding model such as Titan, and indexes them in Bedrock Knowledge Bases with OpenSearch Serverless for retrieval, filtering, and citations. Same-Region storage and encryption support the data locality requirement. The key takeaway is to prepare and index multimodal artifacts, not send raw files or retrain a model for every ingestion cycle.

• Raw prompting fails because unprocessed files can exceed context and latency limits and do not provide searchable metadata or citations.
• SQL-only cataloging is insufficient because Glue and Athena do not transcribe audio or extract image/document semantics for a multimodal RAG workflow.
• Custom training is overbuilt and does not satisfy the 15-minute searchable ingestion and citation requirement for new claim content.

Question 6

Topic: Foundation Model Integration, Data Management, and Compliance

A company is building a synchronous customer-support API with API Gateway and Amazon Bedrock. Incoming messages contain inconsistent date formats, product nicknames, and free-text incident descriptions. The FM must receive a canonical JSON payload with event_time_utc, product_id, issue_summary, and detected_entities. Raw account numbers must not be sent to Bedrock. The preprocessing step must run before each FM invocation and publish rejection/error metrics to CloudWatch. Which implementation should the developer choose?

Options:

• A. Add a Lambda preprocessor that validates input, normalizes fields, uses Amazon Comprehend for entity and PII detection, enriches product IDs from DynamoDB, then invokes Bedrock with canonical JSON.

• B. Send raw messages to SQS and run an asynchronous Step Functions workflow that normalizes data after the Bedrock response is generated.

• C. Use Bedrock Prompt Management to instruct the FM to normalize dates, infer products, and ignore account numbers in its response.

• D. Store raw messages in an Amazon Bedrock Knowledge Base and rely on retrieval results to infer product IDs and account-number handling.

Best answer: A

Explanation: The required behavior is preprocessing for FM input quality before invocation. A Lambda layer can deterministically validate and reformat the request, call Amazon Comprehend for entity and PII detection, enrich fields from DynamoDB, and emit CloudWatch metrics before sending a clean payload to Bedrock.

For production FM consumption, normalize and enrich the input before the model call instead of asking the FM to clean unsafe or inconsistent source text. Lambda is a good synchronous integration point behind API Gateway because it can validate schema, standardize timestamps, map product nicknames to canonical IDs, call Amazon Comprehend for entity and PII detection, redact account numbers, and format the final prompt variables or JSON payload for Amazon Bedrock. CloudWatch metrics and logs from the preprocessing layer provide operational evidence for rejected inputs and transformation failures. Retrieval, prompt instructions, or post-response processing do not reliably prevent raw sensitive values from reaching the FM.

• Retrieval misuse fails because a Knowledge Base improves context retrieval, not deterministic input normalization or PII removal before invocation.
• Prompt-only cleanup fails because raw account numbers would still be sent to the FM and output instructions are not validation controls.
• Post-response workflow fails because the requirement is synchronous preprocessing before the Bedrock invocation.

Question 7

Topic: Foundation Model Integration, Data Management, and Compliance

A fintech team is building an internal loan-policy assistant. A Bedrock Knowledge Base and Prompt Management already provide grounded answers, but compliance reviewers need the model to consistently use the company’s domain terminology in generated summaries. The team has a small labeled dataset, limited GPU budget, and must avoid maintaining a fully retrained model. Which implementation best meets these constraints?

Options:

• A. Increase Knowledge Base chunk size and rebuild the OpenSearch vector index.

• B. Fine-tune with LoRA/adapters in SageMaker AI and deploy the adapted endpoint.

• C. Retrain a new foundation model from scratch on SageMaker AI.

• D. Move the prompts into Step Functions and add Lambda retries.

Best answer: B

Explanation: Parameter-efficient adaptation is appropriate when a team needs domain-specific model behavior but has limited data, compute, or operational capacity for full fine-tuning. LoRA or adapters update a small set of additional parameters while preserving the base model.

The core implementation mechanism is parameter-efficient fine-tuning with LoRA or adapters. In this scenario, retrieval and prompt management already handle grounding, but the model’s generated language needs consistent domain-specific behavior. A SageMaker AI customization workflow can train small adapter weights for the chosen base model, register the artifact, and deploy an adapted endpoint without owning a fully retrained foundation model. This fits the constraints of small labeled data, lower GPU usage, and simpler lifecycle management. Changing retrieval chunking helps search relevance, not model style adaptation; orchestration retries improve reliability, not domain behavior.

• Full retraining is excessive because the team does not need to build or maintain a new foundation model.
• Vector index changes address retrieval quality, not the model’s learned terminology or writing behavior.
• Workflow retries improve execution resilience but do not customize the model output style.

Question 8

Topic: Foundation Model Integration, Data Management, and Compliance

In a RAG application on AWS, which statement best defines a hybrid search design that uses keyword search, vector search, and an Amazon Bedrock reranker model to improve context relevance?

Options:

• A. Retrieve keyword and vector candidates, then use Bedrock reranking before prompting.

• B. Apply guardrails to redact unsafe retrieved passages before generation.

• C. Embed documents only, then select nearest vectors without keyword retrieval.

• D. Store prompt templates and versions to standardize retrieval behavior.

Best answer: A

Explanation: Hybrid search uses both lexical matching and semantic similarity to create a broader candidate set for RAG. An Amazon Bedrock reranker model then scores and reorders those candidates so the most relevant passages are added to the model context.

The core concept is retrieval-stage relevance improvement. Keyword search is strong for exact terms, product names, IDs, and compliance vocabulary, while vector search is strong for semantic similarity. A hybrid design runs both retrieval methods, merges or deduplicates the candidate passages, and uses an Amazon Bedrock reranker model to assign relevance scores for the user query. The application then includes the top-ranked passages in the prompt or knowledge-base response. This is different from safety filtering or prompt versioning, which are useful controls but do not define hybrid retrieval with reranking.

• Vector-only retrieval misses the keyword component and can underperform for exact-match terms or identifiers.
• Guardrail redaction addresses safety and policy enforcement, not ranking retrieved context by relevance.
• Prompt versioning helps manage prompt changes but does not combine lexical retrieval, semantic retrieval, and reranking.

Question 9

Topic: Foundation Model Integration, Data Management, and Compliance

A customer support assistant runs in a European AWS Region and uses Amazon Bedrock. The selected foundation model is not available for direct on-demand invocation in the application’s home Region, but it is supported by a European Bedrock inference profile. Governance requires requests to remain in approved European Regions, and operations wants continuity without custom routing logic. Which pattern best fits this requirement?

Options:

• A. Create Route 53 endpoint failover

• B. Invoke a Bedrock inference profile

• C. Configure Provisioned Throughput locally

• D. Replicate Bedrock prompt versions

Best answer: B

Explanation: The requirement is regional model availability and continuity for an Amazon Bedrock foundation model. Bedrock Cross-Region Inference uses inference profiles to route requests to supported Regions, so the application avoids custom failover while honoring regional governance constraints.

Bedrock Cross-Region Inference is the pattern for invoking supported Bedrock models when direct regional availability or continuity is the main design driver. The application sends requests to an inference profile instead of hard-coding multiple regional model endpoints or implementing its own failover. The profile defines the supported destination Regions, such as a European profile for approved European routing, and Bedrock handles routing for supported models. This differs from capacity reservation, prompt replication, or DNS failover because those patterns do not make an unavailable direct model available through Bedrock-aware routing. The key mapping is: model Region constraint plus continuity requirement means use an inference profile.

• Local throughput can reserve capacity for supported models, but it does not solve direct model unavailability in the home Region.
• DNS failover adds custom routing and is not the Bedrock-native mechanism for model-aware cross-Region inference.
• Prompt replication helps lifecycle consistency, but it does not route inference traffic across Regions.

Question 10

Topic: Foundation Model Integration, Data Management, and Compliance

A financial services company is standardizing GenAI applications on Amazon Bedrock. Product teams must reuse approved prompt templates, retrieval connectors, API invocation settings, structured logging fields, and safety policies. The platform team wants consistent delivery without forcing every app to reimplement Bedrock calls or governance controls. Which principle or pattern best fits this requirement?

Options:

• A. Model customization per product

• B. Offline governance review queue

• C. Direct service calls in each app

• D. Shared GenAI access layer

Best answer: D

Explanation: The core pattern is a reusable GenAI platform abstraction, often implemented as a gateway, SDK, or shared service. It provides approved components for prompts, retrieval, API access, logging, and safety so teams build consistently without duplicating controls.

A shared GenAI access layer creates a standard “paved road” for application teams. In an AWS implementation, the layer can wrap Amazon Bedrock model invocation, Bedrock Prompt Management assets, Knowledge Bases or retrieval adapters, Bedrock Guardrails, IAM-scoped access, and common CloudWatch or audit logging fields. This keeps governance and operational behavior consistent while still allowing product teams to own business-specific application logic. The key is reuse at invocation time, not just documentation or after-the-fact review. Direct integrations tend to drift across teams, while model customization does not solve API, logging, retrieval, or safety-control standardization.

• Direct integration creates inconsistent prompts, logging schemas, IAM policies, and guardrail usage across applications.
• Model customization can adapt behavior but does not standardize retrieval, API access, or audit controls.
• Offline review may find issues later but does not enforce approved controls during GenAI requests.

Continue with full practice

Use the AWS AIP-C01 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try AWS AIP-C01 on Web View AWS AIP-C01 Practice Test

Related focused pages

• Free AWS AIP-C01 Full-Length Practice Exam
• Implementation and Integration
• AI Safety, Security, and Governance
• Genai Operations
• Testing, Validation, and Troubleshooting

Free review resource

Read the AWS AIP-C01 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.