Implementation And Integration practice questions

Embedding the prompt in a Knowledge Base

Why it fails: This is an integration, not a prompting technique.

Few-shot prompting

Why it fails: This is not zero-shot.

Increasing temperature to 1.0

Why it fails: Higher temperature increases randomness, not reasoning quality.

GetFoundationModel

Why it fails: This is for retrieving model metadata.

ListFoundationModels

Why it fails: This lists models, it does not perform inference.

InvokeModel

Why it fails: InvokeModel is model-specific and less consistent across providers.

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.

Spot Instance Configuration

Why it fails: Optional, not mandatory.

Auto-scaling policy

Why it fails: Optional, not mandatory for deployment.

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.

Directly editing the Bedrock service binary

Why it fails: Users do not have access to service binaries.

Configuring them inside the model's training script

Why it fails: Inference parameters are for inference, not training.

It caches the model responses

Why it fails: System prompts provide behavioural instructions and context to the model; response caching is a separate inference or infrastructure feature, not a prompt function. It is tempting because prompts are reused across calls, but caching is configured at the API or application layer. System prompts are chosen to enforce consistent persona, tone, and task constraints.

It automatically formats the output as JSON

Why it fails: A system prompt supplies instructions and context that steer the model's behaviour and tone; it does not enforce a structured output schema. JSON formatting requires tool use, structured output configuration, or explicit prompt engineering with validation. Teams reach for system prompts when they want consistent persona, guardrails, or task framing across invocations.

It overrides the model's training data

Why it fails: A system prompt conditions the model at inference time through instructions; it cannot alter the weights or knowledge baked in during pre-training. It is tempting because system prompts do strongly shape responses, but they only guide behaviour within the model's existing capabilities. Overriding training data would require fine-tuning or continued pre-training instead.

InvokeModel

Why it fails: For model inference.

ListKnowledgeBases

Why it fails: For discovery, not ingestion.

Retrieve

Why it fails: Retrieve is for querying.

SSH private key

Why it fails: Never include credentials in a model package.

Training dataset

Why it fails: Training data is not needed for inference.

Schedule a daily batch cron job

Why it fails: Not real-time.

Use AWS Glue to ETL the data directly to the vector store

Why it fails: Glue is for ETL, but it bypasses the managed Knowledge Base ingestion service.

Manually update the Knowledge Base via the console

Why it fails: Not automated.

model_owner

Why it fails: Not an inference parameter.

S3_output_path

Why it fails: Used for batch transform, not real-time inference.

AWS CloudTrail

Why it fails: Good for auditing, but simulator is for testing.

Amazon CloudWatch

Why it fails: CloudWatch logs are for application errors.

AWS Config

Why it fails: For compliance.

Vector distance

Why it fails: Used for ranking, not a filter field.

Token count

Why it fails: Not used for filtering.

Model ID

Why it fails: Not used for filtering.

Max_tokens

Why it fails: Controls length.

Temperature

Why it fails: Controls randomness, not diversity directly via probability distribution.

Top_k

Why it fails: Also controls diversity, but Top_p is more standard in Bedrock documentation.

Use AWS CloudTrail to log all Bedrock API calls, and configure CloudTrail to include request and response bodies. CloudTrail will automatically mask PII fields.

Why it fails: CloudTrail logs API activity but does not capture the full request and response payloads for Bedrock InvokeModel or Converse calls by default. Even if data events are enabled, CloudTrail does not perform PII redaction. This approach would not provide the required prompt and response logging with PII removal, and would miss the actual content.

Implement a custom Lambda function that intercepts every Converse API call, redacts PII using Amazon Comprehend, and then writes the sanitized logs to CloudWatch Logs.

Why it fails: While this could work, it requires significant custom development and adds latency and operational overhead. The question asks for the least operational overhead. A managed guardrail with built-in PII detection and redaction, combined with native model invocation logging, is simpler and more maintainable than a custom interception layer.

Enable model invocation logging in Amazon Bedrock and configure it to send logs to CloudWatch Logs, then use a CloudWatch Logs subscription filter with a Lambda function to redact PII before storing the logs.

Why it fails: Model invocation logging captures full request and response data, but it does not natively redact PII. Adding a subscription filter and Lambda function introduces custom code and operational overhead. The requirement is to avoid PII in logs with least overhead; this approach requires building and maintaining a redaction pipeline, which is more complex than using a managed guardrail.

Use Amazon Bedrock's automatic synchronization feature, which continuously monitors S3 and updates the knowledge base in real time.

Why it fails: Amazon Bedrock Knowledge Bases does not provide a real-time continuous synchronization feature. You must configure and trigger sync jobs, either on a schedule or via event-driven automation. This option describes a non-existent feature, so it is incorrect.

Manually trigger a full sync of the knowledge base after each document update.

Why it fails: A full sync re-ingests all documents, which is time-consuming and costly, especially for large datasets. While it would eventually reflect the latest versions, it is not efficient and does not meet the requirement of ensuring timely updates. Incremental sync is the preferred method for updates.

Enable versioning on the S3 bucket and configure the knowledge base to use the latest object version.

Why it fails: S3 versioning retains multiple versions of an object, but the Bedrock knowledge base data source connector reads the current version of each object. Versioning alone does not trigger re-ingestion of updated documents, nor does it automatically update the vector store. It is useful for recovery but not for keeping the knowledge base in sync.

inferenceConfig

Why it fails: inferenceConfig manages parameters like temperature.

system

Why it fails: System messages set the behavior, not the tools.

additionalModelRequestFields

Why it fails: This is for model-specific overrides, not tool definitions.

Set the IAM role to 'AdministratorAccess'

Why it fails: AdministratorAccess grants broad API permissions but does not attach the inference container to subnets or security groups, so it cannot reach private VPC resources. It tempts because IAM roles are genuinely required for SageMaker execution, yet the correct configuration is the VPC subnets and security groups on the model.

Update the JumpStart model Dockerfile

Why it fails: Editing the Dockerfile changes the image contents, not the network placement of the inference container, so private VPC reachability remains unconfigured. It tempts because custom containers are legitimately built via Dockerfiles, but JumpStart supplies its own image; VPC subnets and security groups are what attach the endpoint.

Enable AWS PrivateLink on the S3 bucket

Why it fails: PrivateLink exposes AWS services to your VPC via interface endpoints; it does not place the SageMaker inference container inside your VPC subnets. It tempts because PrivateLink genuinely provides private connectivity to S3, but the requirement is endpoint VPC configuration, not bucket-level networking.

Knowledge Base

Why it fails: A knowledge base supplies retrieval-augmented context from indexed documents; it does not define the API schema, operation or authentication that let an agent invoke an external endpoint. It is tempting because knowledge bases are central to many Bedrock Agents designs, but they serve grounding, not action-group API integration.

Guardrail

Why it fails: Guardrails filter and constrain model inputs and outputs for safety and policy compliance; they do not define the OpenAPI schema, Lambda handler or permissions an agent needs to call an external API. It is tempting because guardrails accompany most agent deployments, but they govern content, not action-group connectivity.

Amazon DynamoDB

Why it fails: DynamoDB is a key-value and document database without native vector indexing or similarity search, so it cannot serve as the vector store for Bedrock Knowledge Bases. It is tempting as a familiar serverless data store, but managed RAG requires a vector-capable backend such as OpenSearch Serverless.

Amazon ElastiCache

Why it fails: ElastiCache provides in-memory caching (Redis or Memcached), not vector storage with similarity search, so Bedrock Knowledge Bases cannot use it as a native vector store. It is tempting because Redis supports vector search, but the managed integration targets OpenSearch Serverless, Aurora PostgreSQL and Neptune Analytics.

Amazon RDS for PostgreSQL

Why it fails: RDS for PostgreSQL is not a native Bedrock Knowledge Base vector store; the managed integration targets Amazon OpenSearch Serverless, Aurora PostgreSQL with pgvector, or Neptune Analytics. It is tempting because Aurora PostgreSQL is supported, and RDS would be correct for a self-managed pgvector deployment outside Knowledge Bases.