Hard Difficulty Questions

Use AWS Trusted Advisor to review the Bedrock model for ethical AI compliance.

Why it fails: AWS Trusted Advisor provides recommendations across cost optimization, security, fault tolerance, performance, and service quotas. It does not evaluate foundation models for ethical AI compliance or content bias. Trusted Advisor checks are infrastructure-oriented and have no capability to inspect generative AI outputs, making it unsuitable for this compliance requirement.

Enable Amazon Macie to automatically redact biased statements from Bedrock responses.

Why it fails: Amazon Macie is a data security service that discovers and classifies sensitive data in Amazon S3. It does not analyze natural language for bias or harmful content, nor does it operate inline on Bedrock responses. Macie's findings are about data classification, not content moderation, so it cannot satisfy the requirement to detect biased or harmful output from the generative AI assistant.

Configure AWS WAF to inspect the generative AI responses for biased language.

Why it fails: AWS WAF is a web application firewall that protects against common web exploits such as SQL injection and cross-site scripting at the HTTP layer. It does not understand natural language semantics and cannot evaluate model outputs for bias or harmful content. While WAF can protect the application endpoint, it does not fulfill the content moderation requirement for generative AI responses.

Caching agent responses

Why it fails: Caching returns stored responses for identical inputs; agents with changing context still re-invoke and loop. It tempts because caching reduces latency and token spend, and it would be correct if the question asked how to cut repeated identical model calls or lower cost in a high-volume pipeline.

Increasing the model temperature

Why it fails: Raising temperature increases output randomness, which makes repeated or divergent agent turns more likely, not less. It tempts because temperature tuning is a familiar knob for controlling model behaviour, and it would be correct if the question asked how to make agent responses more varied or creative.

Using a smaller model

Why it fails: A smaller model changes capability and cost, not coordination logic; agents still loop if the orchestration permits it. It tempts because smaller models are cheaper and faster, and it would be correct if the question asked how to reduce inference latency or cost per agent call.

The number of concurrent IAM users.

Why it fails: IAM user count does not drive Bedrock Knowledge Base charges; billing accrues from vector store storage, embedding generation and retrieval queries. It is tempting because IAM is integral to AWS access control, but identity management is free, and concurrent users only matter where per-seat licensing applies, which Bedrock does not use.

The frequency of S3 bucket scans.

Why it fails: S3 bucket scans are not a billed dimension; the knowledge base syncs on demand or schedule, and you pay for embeddings, vector storage and retrieval. It is tempting because S3 ingestion is part of setup, but scanning frequency itself incurs no Bedrock charge — only the API calls and storage it triggers.

Increase the vector dimension size.

Why it fails: Vector dimension changes embedding granularity, not retrieval selectivity; it cannot filter millions of documents to the most relevant. It is tempting because higher dimensions can capture finer semantic detail, and it would be the right lever when the embedding model's representational capacity is the bottleneck rather than the search stage.

Use a larger model for embedding.

Why it fails: A larger embedding model improves semantic quality per vector but still scores every document, so it does not narrow retrieval across millions of files. It is tempting because better embeddings raise relevance generally, and it would be correct when poor semantic representation, not the search mechanism, causes irrelevant matches.

Reduce the chunk size.

Why it fails: Smaller chunks change what each vector represents, not how the index is searched, so millions of candidates are still compared. It is tempting because finer chunks sharpen local semantics, and it would be correct when passages are too coarse and dilute the embedding's meaning.

Increasing the vector dimension size to maximum

Why it fails: Maximum vector dimensions increase index size and latency without improving semantic relevance; embedding models emit fixed dimensions, so padding adds noise. It is tempting because higher dimensionality can capture more features, and would suit training a custom embedding model, not retrieval tuning.

Using only fixed-size overlap chunking

Why it fails: Fixed-size overlap chunking alone splits text arbitrarily, severing semantic units and diluting embeddings. It is tempting for its simplicity and predictable token counts, and would be adequate for uniform, unstructured logs, but relevance needs semantic or recursive chunking that respects content boundaries.

Map the old embeddings to new dimensions using a linear function.

Why it fails: Linear dimension mapping distorts the vector space, so cosine and dot-product similarity no longer reflect semantic distance, degrading retrieval. It tempts because dimensionality reduction is a real technique, but it applies when training a projection on representative data, not when porting embeddings between incompatible models.

Use the Bedrock Import Vector API.

Why it fails: No such Bedrock Import Vector API exists; embeddings must be written to the vector store via its own ingestion path. It tempts because Bedrock offers model import and batch inference jobs, so a vector-import endpoint sounds plausible, but those features move models or inference data, not pre-computed embeddings.

Import existing vectors directly into the OpenSearch index.

Why it fails: Writing vectors straight into OpenSearch bypasses the embedding-model alignment: query embeddings must come from the same model and dimension as the stored vectors, and Aurora pgvector or Bedrock Knowledge Bases expect their own schema. Direct index import suits reusing an existing OpenSearch cluster whose embedding pipeline is unchanged.

Amazon RDS

Why it fails: SageMaker Data Capture writes its JSONL records to an Amazon S3 bucket you specify, not to a relational database. RDS is the right choice when captured payloads must be queried relationally alongside application data, which is not how Data Capture is architected.

Amazon CloudWatch Logs

Why it fails: Data Capture stores records in the Amazon S3 location configured on the endpoint, not in CloudWatch Logs. CloudWatch Logs is correct for capturing inference container logs and metrics, whereas the input and output payloads themselves land in S3 for later monitoring and evaluation.

Amazon ElastiCache

Why it fails: Data Capture persists records as objects in Amazon S3; ElastiCache provides in-memory caching, which is neither durable nor the configured destination. ElastiCache would be correct for low-latency session or feature caching in front of a model endpoint, not for storing capture output.

Directly modifying a database table without an API

Why it fails: Agents must use defined actions/APIs.

Running a local Docker container

Why it fails: Agents cannot run local containers.

Write a Lambda function to strip logs before writing to S3

Why it fails: This adds unnecessary complexity and latency compared to native service features.

Use IAM policies to prevent logs from being written

Why it fails: This violates the enterprise requirement to have logs for compliance.

Use AWS CloudTrail to log API calls and enable redaction in CloudWatch

Why it fails: CloudTrail logs metadata, not the prompt/response content itself.

Use a custom system prompt to tell the model not to use URLs

Why it fails: System prompts are suggestions and cannot be relied upon for strict compliance/safety requirements.

Disable model streaming

Why it fails: Streaming is a performance feature; it does not filter content.

Use IAM to block internet access for the application

Why it fails: The model generates text internally; blocking the application's internet access does not stop the model from generating URL strings.

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.

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.

Reduce the index replication factor

Why it fails: This affects availability, not ingestion performance.

Disable vector search

Why it fails: This defeats the purpose of the application.

Increase the number of replica shards

Why it fails: Replica shards add overhead to index writes.

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.

Model's popularity

Why it fails: Popularity reflects community adoption, not retrieval accuracy on your corpus; a widely used model may embed domain jargon poorly. It is tempting as a shortcut when benchmarking is hard, yet the deciding factors are task fit, vector dimensionality, context length and evaluation against your own queries.

Model training cost

Why it fails: Training cost applies to fine-tuning or pre-training a model, whereas embedding models are typically consumed via API or downloaded pre-trained, so cost is inference and storage. It is tempting when budgeting GPU spend, but selection hinges on retrieval quality, dimensionality, latency and domain vocabulary coverage.

Amazon SageMaker Model Monitor.

Why it fails: SageMaker Model Monitor is for tabular/ML models, not specifically for LLM text toxicity evaluation.

A

Why it fails: A

AWS Glue to sanitize data.

Why it fails: Glue is for data transformation, not model output evaluation.

AWS Lambda to call the model and manually inspect outputs.

Why it fails: Manual inspection is not automated validation.

Moving model artifacts to S3 Standard

Why it fails: Storage location does not impact latency once deployed.

Increasing the number of replicas

Why it fails: Replicas improve throughput, not individual request latency.

A

Why it fails: A

Disable the Guardrail and re-run the test to see if performance improves.

Why it fails: This would expose more PII, not help troubleshoot.

Route all traffic through a WAF to block PII patterns.

Why it fails: WAF is for HTTP/HTTPS filtering, not internal PII content within an LLM inference payload.

Increase the PII sensitivity threshold in the IAM policy.

Why it fails: Guardrail settings are configured in the Guardrail resource, not IAM.

IAM role permissions

Why it fails: IAM issues typically cause 403 Forbidden.

Input JSON schema validation

Why it fails: Schema issues cause 400 Bad Request.

Disable filters for non-English languages

Why it fails: This is a major security risk.

Translate all inputs to English first

Why it fails: Adding an extra translation step adds latency and potential for translation errors.

Use a regex-based filter only

Why it fails: Regex is not sufficient for multilingual semantic content filtering.