Foundation Model Integration Data And Compliance practice questions

Manually encrypt all files using AWS KMS before uploading to S3.

Why it fails: While good practice, it does not address PII redaction requirements.

Enable Amazon Bedrock Data Protection policies to automatically strip PII during vectorization.

Why it fails: Bedrock does not have an automatic PII-stripping feature for source documents.

Configure the Bedrock Knowledge Base to use a custom encryption key for PII filtering.

Why it fails: Encryption keys protect data at rest but do not provide logical redaction or masking of PII.

Enable Amazon Macie on the S3 bucket and configure Bedrock to ignore flagged objects.

Why it fails: Macie identifies PII but does not perform redaction as part of an automated ingestion pipeline.

Use Amazon Bedrock Guardrails to mask PII during the inference request.

Why it fails: Guardrails filter content post-generation or pre-processing but do not redact PII from the vector database ingestion pipeline.

Semantic chunking based on paragraph breaks.

Why it fails: Semantic chunking is effective but often less precise for highly technical documents than hierarchical approaches.

Fixed-size chunking with 100 token overlap.

Why it fails: Fixed-size often leads to loss of context in technical legal documents.

Default chunking strategy.

Why it fails: The default strategy is often too simplistic for dense domain-specific content.

Store all data in-memory only to avoid persistent storage risks.

Why it fails: This does not provide durability or meet the auditability requirements of HIPAA.

Use public S3 buckets with ACLs enabled.

Why it fails: Public buckets are a security risk and violate HIPAA compliance.

Disable logging to prevent sensitive data from appearing in logs.

Why it fails: Auditing and logging are mandatory for HIPAA compliance.

AWS Glue DataBrew

Why it fails: Glue DataBrew profiles and transforms tabular data for analytics pipelines; it has no model training or hosting capability. It would be correct for cleaning and normalising datasets before analysis, but it cannot fine-tune a foundation model on domain-specific language.

Amazon SageMaker JumpStart

Why it fails: While JumpStart helps deploy models, Bedrock Custom Models is the specific pathway for fine-tuning within the Bedrock service family.

Amazon Kendra

Why it fails: Amazon Kendra is an enterprise search service that indexes documents and returns relevance-ranked answers; it neither hosts foundation models nor runs fine-tuning jobs. It would be the right choice for semantic search over internal content, but not for adapting a model to domain language.

The embedding model is too small.

Why it fails: Small models are usually faster, not slower.

The source documents are too short.

Why it fails: Short documents actually improve retrieval speed.

The Bedrock service is overloaded.

Why it fails: While possible, the vector index configuration is the primary driver of retrieval speed.

Use AWS Config to monitor bucket changes.

Why it fails: Config is for compliance and tracking, not triggering data workflows.

Set the knowledge base to 'Auto-Refresh' mode.

Why it fails: There is no 'Auto-Refresh' mode; synchronization must be triggered.

Enable S3 Versioning.

Why it fails: Versioning is for data safety, not index triggering.

Amazon EFS

Why it fails: EFS is for file-system access, not integration with Knowledge Bases.

AWS Backup

Why it fails: Backup is for data protection, not ingestion.

Amazon DynamoDB

Why it fails: DynamoDB is for metadata, not document storage.

Prompt Template.

Why it fails: The template instructs the model, it does not structure the data source.

Vector Database index settings.

Why it fails: These settings manage search, not the input structure.

IAM Policy.

Why it fails: IAM manages permissions.

Serverless architecture.

Why it fails: This is a key benefit.

Access to multiple FM providers via a single API.

Why it fails: This is a key benefit.

Data privacy and security controls.

Why it fails: This is a key benefit.

Use public S3 endpoints with read-only access.

Why it fails: Public S3 endpoints expose the RAG data corpus to the internet, so read-only access still permits unauthenticated retrieval of sensitive content. It is tempting because read-only sounds restrictive, but security requires private endpoints via VPC endpoints or Gateway endpoints with bucket policies restricting access to the pipeline's roles.

Use default AWS managed public keys.

Why it fails: AWS managed default keys are shared across accounts and offer no customer-controlled rotation or audit trail, so they cannot satisfy data security requirements for a RAG corpus. It is tempting because they require no key management effort, but customer managed KMS keys with defined rotation and access policies are needed here.

S3 bucket storage size.

Why it fails: Not a model performance metric.

Number of active IAM roles.

Why it fails: Not a model performance metric.

Use an S3 bucket in every region.

Why it fails: S3 stores data and model artefacts; it does not serve Bedrock inference, so replicating buckets leaves no endpoint to invoke during an outage. This is tempting because S3 Cross-Region Replication genuinely provides regional data durability, which would satisfy a data-resilience requirement rather than model availability.

Request a cross-region Bedrock endpoint from AWS Support.

Why it fails: Cross-region inference profiles are configured by the customer, not provisioned by AWS Support, and they route requests rather than create a failover endpoint. Requesting one is tempting because cross-region inference does address regional model availability, so it would fit if the requirement were model throughput rather than outage survival.

Enable global AWS region auto-scaling.

Why it fails: AWS has no global auto-scaling service that spans regions; scaling is configured per service within a region, so it cannot restore Bedrock inference after a regional failure. It is tempting because auto-scaling does improve availability within one region, which would be correct for handling demand spikes rather than regional outages.

By prepending the metadata to the prompt.

Why it fails: This is inefficient and does not work for filtering.

It is done automatically by the model.

Why it fails: The developer must define the metadata ingestion.

It is not possible to use metadata in Bedrock RAG.

Why it fails: It is a supported and common feature.

AWS PrivateLink

Why it fails: PrivateLink handles network isolation, not model training policies.

AWS KMS Customer Managed Keys

Why it fails: KMS manages encryption, not the data usage policy of the model provider.

Amazon Bedrock Provisioned Throughput

Why it fails: Provisioned Throughput is for performance scaling, not data policy control.

Converting all text to images before embedding

Why it fails: Converting text to images discards extractable textual content, degrading text-query retrieval and inflating storage and embedding cost. Retaining text chunks alongside image embeddings preserves both modalities. Image-only conversion suits purely visual corpora, not PDFs where text queries dominate.

Using a fixed-size character count of 500 without overlap

Why it fails: A fixed 500-character split ignores sentence and section boundaries, severing tables from captions and splitting figures across chunks, which harms multi-modal retrieval accuracy. Semantic or layout-aware chunking with overlap preserves context. Fixed-size splitting suits homogeneous plain text, not structured multi-modal PDFs.

Concatenating all chunks into one large vector

Why it fails: Concatenating every chunk into a single vector averages away distinct visual and textual signals, so multi-modal queries cannot match specific figures or tables. Separate embeddings per modality and chunk preserve retrievable granularity. One combined vector suits coarse document-level similarity, not fine-grained multi-modal retrieval.

Using AWS Glue for data preparation only

Why it fails: Glue is for ETL, it does not secure the transit of data to Bedrock.

Deploying the model in an on-premises data center

Why it fails: Bedrock is a managed service; it cannot be deployed on-premises.

Encrypting the dataset with AWS CloudHSM

Why it fails: Encryption protects the data at rest but does not establish a private path for training.

AWS Secrets Manager for S3 credentials

Why it fails: Secrets Manager is for API keys, not for data encryption at rest.

Amazon Bedrock Model invocation logs

Why it fails: Invocation logs track usage and do not perform encryption.

S3 Bucket policies only

Why it fails: Bucket policies control access, but they do not manage the encryption of the vector index itself.

Create a Glue Data Catalog for the S3 bucket

Why it fails: A Glue Catalog is for structured data analysis, not needed for native Bedrock Knowledge Base RAG.

Enable AWS WAF on the S3 bucket

Why it fails: WAF is for web traffic and cannot be applied to S3 buckets.

Create a Lambda function to split PDFs manually

Why it fails: Bedrock Knowledge Bases handle chunking automatically.

Disable all CloudWatch logging to prevent data leakage

Why it fails: Logging is usually required for compliance audits; disabling it hinders tracking.

Store all prompts in plain text in S3 for auditing

Why it fails: Storing prompts in plain text is a security risk if not properly managed.