AWS Generative AI Developer – Professional (AIP-C01): 6 Practice Questions on FM Integration, Data, and Compliance
Practice FM Integration, Data, and Compliance for the AWS Generative AI Developer – Professional (AIP-C01) exam with the 6 questions below. About 31% of the exam comes from this domain. Every option is explained, so a wrong pick still teaches something.
AWS Generative AI Developer – Professional (AIP-C01) · FM Integration, Data, and Compliance · 6 questions with answers and explanations
📊 This set at a glance
Exam: AIP-C01 · 75 questions · 180 minutes · passing score 750 · the largest of 5 domains
This set: 4 applied, 2 advanced · 5 scenario, 1 trade-off · 2 with more than one answer
Topics: Amazon Bedrock Knowledge Bases, Amazon Titan Text Embeddings V2, Amazon OpenSearch Serverless
🧭 Reading FM Integration, Data, and Compliance questions
Much of this domain concerns the data side of a GenAI system: chunking, embeddings, vector stores, knowledge bases and model selection. Scenarios describe a quality, cost or access requirement and ask which design meets it. Good answers enforce rules in the data layer and keep the index in step with its sources, while weak ones lean on prompt instructions or application code.
Three things to look for
• First decide whether the need is new knowledge or new behavior. Missing facts call for RAG; a consistent tone or format calls for fine-tuning.
• An index drifts unless edits and deletions in the source reach it. A new embedding size means the whole index must be rebuilt, or stored vectors and new queries will no longer line up.
• For multilingual requirements, test candidate models with real questions in every target language before committing to one.
Question 1 of 6
Which TWO actions keep a vector index aligned with its source documents over time? (Select TWO)
Show answer
✅ Answer: B, E
Difficulty: applied · Topic: Amazon Bedrock Knowledge Bases
Why a vector index drifts
Each vector is a snapshot of a document's text at the time it was embedded. The source keeps changing:
• A policy is updated: old vectors still describe the old wording, so retrieval returns outdated rules.
• A document is deleted: its vectors remain and keep being retrieved, even though the content should no longer be used.
Keeping them in sync
• Track each source document with an ID and a change marker (last-modified time or content hash).
• On change, delete the old chunks and re-embed the new version.
• On deletion, remove all vectors that belong to that document.
Amazon Bedrock Knowledge Bases handles this with incremental sync: an ingestion job detects added, modified and deleted files in the data source and updates the vector store to match.
Why each option works or fails
• ✗ A. Keep vectors for deleted documents: retrieval keeps returning content that was withdrawn, and answers can cite documents that no longer exist.
• ✓ B. Delete vectors for removed documents (correct): stale vectors are removed, so content that no longer exists or is no longer approved cannot be retrieved.
• ✗ C. Disable metadata: metadata is what links a chunk to its source and enables filtering; removing it makes stale chunks harder to find and remove, and does nothing to keep content current.
• ✗ D. Embed only the first page: most of each document is never indexed, which makes retrieval incomplete and does not track changes to the rest of the document.
• ✓ E. Re-embed changed documents (correct): the vectors reflect the current wording, so answers use today's content, not an earlier version.
Question 2 of 6
A knowledge base serves 40 departments, and each user should only retrieve documents from their department. Which approach fits?
Show answer
✅ Answer: A
Difficulty: applied · Topic: Amazon Bedrock Knowledge Bases
Access control in retrieval
When one knowledge base holds documents for many groups, the restriction must happen before retrieved text reaches the model. Anything the model sees can end up in an answer.
Metadata filtering in Amazon Bedrock Knowledge Bases
• Each source document gets metadata, for example a department attribute. With an Amazon S3 data source this is a <file>.metadata.json file next to the document.
• Chunks inherit this metadata when they are indexed.
• At query time the application, which knows who the user is from its authentication, adds a filter to the Retrieve or RetrieveAndGenerate request, for example equals: { key: "department", value: "finance" }.
• The vector store returns only matching chunks, so other departments' documents are never retrieved.
The filter must come from the application's identity data, never from text the user types, or a user could ask for another department.
Why each option works or fails
• ✓ A. Department metadata with per-user filters (correct): results are limited to the user's department inside the retrieval query, so documents from the other 39 departments never reach the model at all.
• ✗ B. Ask the model to hide content: the other departments' text is already in the prompt, and a model instruction can be bypassed or ignored, so it is not access control.
• ✗ C. Rotating the knowledge base weekly: all 40 departments need access at the same time, and during a department's week every user would still see that department's documents.
• ✗ D. One unfiltered index: every user can retrieve every department's documents, and relying on users to ignore them provides no protection.
Question 3 of 6
A retailer's assistant must answer product questions in English, Spanish, and Japanese with consistent quality. What should the design include before model selection is final?
Show answer
✅ Answer: D
Difficulty: applied
Multilingual quality is model-specific
Foundation models are trained on different mixes of languages. A model that is excellent in English can be noticeably weaker in Japanese, for example with tokenization, formality or product terminology.
Evaluate in every target language
• Build an evaluation set with representative product questions written natively in English, Spanish and Japanese, including tricky cases such as product names, units and mixed-language queries.
• Run each candidate model against all three sets, scoring with human reviewers or an LLM judge (for example a Bedrock model evaluation job), and compare per language.
• Choose the model only if it meets the quality bar in every language, since the requirement is consistent quality.
Example
Model X scores 93% in English, 91% in Spanish and 78% in Japanese; model Y scores 90%, 89% and 88%. Y is the better fit for consistent quality even though X wins in English.
Why each option works or fails
• ✗ A. English only at launch: restricting users to English fails the stated requirement to answer in Spanish and Japanese.
• ✗ B. Fine-tune on English and hope: cross-lingual transfer is not guaranteed, and a plan without measurement cannot confirm consistent quality in the other languages.
• ✗ C. English test set with translated results: English scores say nothing about how the model actually handles Spanish or Japanese questions, so language-specific weaknesses go unnoticed.
• ✓ D. Evaluation set in all three languages (correct): quality varies by language and model, so testing with representative questions in each language confirms the model meets the bar everywhere before selection is final.
Question 4 of 6
Documents contain natural topic sections of varying length. Fixed-size chunks often split ideas mid-thought. Which chunking strategy fits?
Show answer
✅ Answer: D
Difficulty: applied · Topic: Amazon Bedrock Knowledge Bases
Semantic chunking
Fixed-size chunking splits text every N tokens regardless of content, so a chunk can end in the middle of an explanation and the next one starts without its subject.
Semantic chunking splits where the meaning changes. It embeds sentences (or small groups), compares neighbors, and starts a new chunk where similarity drops sharply, which usually marks a topic change.
• Chunks follow the document's natural sections, even when sections vary in length.
• Each chunk tends to hold one complete idea, which improves retrieval precision.
• In Bedrock Knowledge Bases it is a built-in strategy with settings such as maximum tokens, buffer size and a breakpoint percentile threshold. It adds some ingestion cost because a model is invoked during chunking.
Why each option works or fails
• ✗ A. No chunking: whole-document embeddings mix many topics into one vector, reducing retrieval precision and producing very large contexts.
• ✗ B. Every 100 characters: this is an even smaller fixed split that cuts through words and sentences, making the mid-thought problem worse.
• ✗ C. Larger fixed-size chunks: bigger chunks split less often but still cut at arbitrary points and mix unrelated topics, because size, not meaning, sets the boundary.
• ✓ D. Semantic chunking (correct): boundaries are placed where the topic changes, so chunks match the variable-length sections and ideas are no longer split mid-thought.
Question 5 of 6
A team uses Amazon Titan Text Embeddings V2 at 1,024 dimensions for 300 million chunks and wants to reduce vector storage cost. Which TWO statements are correct? (Select TWO.)
Show answer
✅ Answer: C, D
Difficulty: advanced · Topic: Amazon Titan Text Embeddings V2, Amazon OpenSearch Serverless
Embedding dimensions and storage
Amazon Titan Text Embeddings V2 lets you choose the output size per request: 1,024, 512 or 256 dimensions (set with the dimensions parameter). Smaller vectors keep most of the retrieval accuracy of the full size but lose a little.
Storage scales linearly with dimensions. At 32-bit floats, a 1,024-dimension vector is about 4 KB, so 300 million chunks are about 1.2 TB of raw vectors; at 512 dimensions it is about half, and index memory for HNSW graphs shrinks as well.
Changing dimensions safely
• Query vectors and stored document vectors must come from the same model with the same settings, or similarity scores are meaningless.
• Changing the size therefore means re-embedding every chunk with the new setting and rebuilding the index, then embedding queries with the same setting.
Why each option works or fails
• ✗ A. Truncate stored vectors in place: this is not the documented way to get smaller Titan V2 vectors; the supported path is to request the smaller size from the model, and the index definition also has a fixed dimension.
• ✗ B. No effect on quality: smaller vectors usually lose some accuracy, so the right size should be chosen by measuring retrieval quality, not by always picking the smallest.
• ✓ C. Re-embed and re-index (correct): vectors of different sizes cannot be compared, so the whole corpus must be embedded again at the new dimension and loaded into a new index.
• ✓ D. 512 or 256 dimensions (correct): Titan V2 offers these smaller sizes, which cut storage and memory while typically costing only a small amount of retrieval accuracy.
• ✗ E. Latency only: storage per vector is proportional to the number of dimensions, so dimension directly drives index size and cost.
Question 6 of 6
A company must isolate vector data for several business units with different access policies while sharing one platform. Which design fits?
Show answer
✅ Answer: B
Difficulty: advanced · Topic: Amazon OpenSearch Serverless
Multi-tenant isolation for vector data
When several business units share one platform, each unit's data must be reachable only by its own users. Isolation is strongest when the data store enforces it, not only the application.
• Separate index or collection per unit: for example one Amazon OpenSearch Serverless collection or index per unit, each with its own data access policy, or one Amazon Bedrock knowledge base per unit, with IAM policies naming each resource ARN.
• Shared index with metadata filters: cheaper, but a single bug that forgets the business_unit filter exposes everyone's data.
Example
HR, Legal and Sales each get their own index. The HR application role is allowed only on the HR index, so even a faulty query cannot return Legal documents.
Why each option works or fails
• ✗ A. Single public index for all employees: every employee could retrieve every unit's data, which breaks the different access policies.
• ✓ B. Separate indexes or collections with access policies (correct): each unit's vectors live in their own resource with its own permissions, so isolation is enforced by the data layer while the platform stays shared.
• ✗ C. One file copied to each unit: every unit would receive all vectors, including other units' data, and copies quickly drift out of sync.
• ✗ D. Shared index with no metadata, application logic only: with no metadata, the data cannot even be told apart, and any application bug exposes all units' data.
🎯 Takeaways
• An index stays accurate only if updates are re-embedded and deletions are removed, which is what incremental sync automates.
• Enforce who can see what with metadata filters applied at retrieval time, not with model instructions or trust in users.
• For multilingual requirements, validate candidate models with native test questions in every target language before choosing one.
• For documents with natural sections of varying length, semantic chunking keeps ideas intact where fixed-size chunking cuts them.
• Smaller Titan V2 dimensions trade a little accuracy for lower storage, and switching requires re-embedding and re-indexing so queries and documents match.
• Enforce tenant isolation in the data layer with a separate index or collection and access policy per unit, not only in application code.
🔗 Keep practicing on this blog
• All AIP-C01 practice sets
• Every exam on this blog
📚 Beyond this set
More AIP-C01 questions: https://hyunhp.github.io/cert-bank/#exam=AIP-C01
Study guide: https://hyunhp.github.io/cert-bank/study.html#exam=AIP-C01
These are original practice questions, not real exam questions, and cert-bank is not affiliated with any certification vendor.
Original practice questions written for this blog, not exam dumps.
Comments
Post a Comment