Select Two (Multi-Select) 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.

Email server logs.

Why it fails: Email server logs are unstructured operational records, not a supported Bedrock Knowledge Base source; ingestion expects Amazon S3 objects or connector-managed repositories. It tempts because logs are text and searchable, but knowledge bases index curated documents, not raw server telemetry.

Social media live streams.

Why it fails: Live streams are transient, unindexed media, not a supported ingestion source; Bedrock Knowledge Bases require stored documents in Amazon S3 or supported connectors. It tempts because streaming data feeds analytics pipelines, yet knowledge bases need durable, chunkable content rather than real-time broadcast streams.

Local hard drive files.

Why it fails: Local hard drive files are not directly ingestible; Bedrock Knowledge Bases require data staged in Amazon S3 or a supported connector. It tempts because uploading local documents feels natural, but the service has no direct local-filesystem data source.

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.

Amazon Bedrock API Gateway integration

Why it fails: API Gateway integration concerns exposing Bedrock models through REST endpoints; it delivers access control and throttling, not governance features such as model invocation logging, CloudWatch metrics or Guardrails. It is tempting when designing secure API front ends. Bedrock's governance capabilities are the native logging, metrics and Guardrails features.

Amazon Bedrock Model Pre-training

Why it fails: Pre-training builds or customises a foundation model from training data; it is a model-development capability, not a governance control. It would be correct when creating a tailored model, yet it provides no access policies, guardrail enforcement or audit evidence, so it cannot satisfy the governance requirement.

Amazon Bedrock Auto-scaling

Why it fails: Auto-scaling adjusts provisioned throughput capacity in response to demand; it governs performance and cost, not model access, data handling or audit trails. It would be the right choice when sizing inference capacity for variable traffic, but it contributes no policy enforcement, logging or compliance controls to the governance question.

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.

Verifying the S3 bucket encryption.

Why it fails: S3 bucket encryption is a storage security control, not an agent test component. Agent test plans verify orchestration: action group invocation, knowledge base retrieval, guardrails and prompt handling. It tempts because agents can use S3-backed knowledge bases, so encryption checks belong in a separate security review.

Measuring model training time.

Why it fails: Training time belongs to model development, not agent testing. A Bedrock Agent test plan covers action group invocation, knowledge base retrieval, guardrail responses and prompt handling; the foundation model is consumed, not trained. It tempts because teams do track training duration when fine-tuning custom models, where that metric would be valid.

Use a larger, more generic embedding model.

Why it fails: A larger generic embedding model dilutes domain-specific semantics, so vectors for specialised terminology cluster less tightly and retrieval precision drops. It tempts teams because bigger models usually score higher on public benchmarks, yet a fine-tuned domain model would be the right choice when vocabulary is niche and general-purpose embeddings miss relevant chunks.

Increase the number of retrieved chunks to 1000.

Why it fails: Retrieving 1000 chunks floods the context window with loosely related passages, lowering precision and burying the genuinely relevant content. It tempts teams because recall rises superficially, yet reranking or hybrid search is the right choice when precision matters; large top-k suits only broad exploratory recall.

Delete all indices and recreate them every hour.

Why it fails: Rebuilding indices hourly adds no relevance signal and disrupts retrieval while re-embedding runs, so queries hit incomplete or inconsistent vectors. It tempts teams seeking freshness, but incremental upserts of changed documents achieve that; full periodic rebuilds suit only bulk schema or embedding-model migrations.

VectorEmbeddingAccuracy

Why it fails: VectorEmbeddingAccuracy is not a native CloudWatch metric for Bedrock; accuracy is evaluated through model evaluation jobs, not emitted per invocation. It would be relevant when assessing retrieval quality in a RAG pipeline, whereas invocation monitoring uses latency, throttling and error metrics.

GPUUtilization

Why it fails: GPUUtilization is an Amazon EC2 and SageMaker metric, not published natively by Bedrock; Bedrock exposes invocation metrics such as Invocations, Latency and InvocationThrottles. It is tempting because GPU utilisation is a genuine CloudWatch metric for self-managed inference infrastructure.

ModelTrainingLoss

Why it fails: ModelTrainingLoss is not emitted by Bedrock invocation; CloudWatch publishes invocation metrics such as InvocationLatency, InvocationCount and InvocationClientErrors. Training loss belongs to model-training frameworks like SageMaker, so it would be the right metric when monitoring a custom training job, not inference performance.

Disable all encryption to increase performance

Why it fails: Disabling encryption removes at-rest and in-transit protection of indexed data, violating the security requirement outright; performance gains are negligible since Bedrock encrypts transparently. Encryption would be disabled only in isolated test environments where no sensitive content is stored and compliance obligations are absent.

Place the Knowledge Base in a public subnet

Why it fails: A public subnet exposes the knowledge base's underlying resources to the internet, contradicting the isolation that private subnets with VPC endpoints provide. Public subnets suit internet-facing load balancers or bastion hosts, not data stores holding proprietary embeddings that must remain unreachable from outside the VPC.

Grant public read access to the S3 bucket

Why it fails: Public read access exposes the corpus to anyone, defeating the encryption and access controls the knowledge base relies on. It is tempting because Bedrock must read the bucket, so a bucket policy granting the Bedrock service role scoped GetObject access would be the correct configuration instead of opening it publicly.

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.

Delete all data in S3

Why it fails: Deleting S3 data destroys training and inference artefacts rather than identifying savings, and S3 storage is a minor line item beside compute. It is tempting because storage cleanup genuinely reduces spend, so lifecycle policies or Intelligent-Tiering on stale buckets would be the correct action when storage is the dominant cost.

Increase the number of IAM roles

Why it fails: Adding IAM roles creates no cost signal; roles are free and unrelated to resource consumption. It is tempting because IAM roles govern SageMaker access control, so they would be the correct focus when auditing permissions or least-privilege, not when hunting idle endpoints, over-provisioned instances or unused training jobs.

Deploy models to every region

Why it fails: Deploying models to every region multiplies endpoint hosting and storage charges instead of reducing them. It is tempting because multi-region deployment does cut inference latency for global users, so it is the correct action when the requirement is latency reduction rather than cost optimisation.

Exclude all logging to protect privacy

Why it fails: Removing logging entirely destroys the audit trail and traceability that responsible AI governance depends on, so incidents and model drift become undetectable. It is tempting because privacy regulation genuinely restricts what may be recorded, but the correct approach is scoped, redacted or anonymised logging rather than none at all.

Allow users to train the model directly

Why it fails: Granting users direct training access bypasses change control, validation and bias review, so unvetted data can silently alter production model behaviour. It appeals because domain experts often hold the best training data, yet their contribution belongs in a governed retraining pipeline with approval gates, not direct write access to the live model.

IAMUserLoginCount

Why it fails: IAMUserLoginCount tracks console or API authentication events, not inference request volume, so it cannot drive endpoint capacity. It is tempting because identity activity can correlate with workload, and would be the correct metric for detecting anomalous sign-in behaviour or triggering security alerts, not for autoscaling a SageMaker endpoint.

S3RequestLatency

Why it fails: S3RequestLatency measures Amazon S3 request response times, which do not reflect endpoint invocation concurrency or load, so scaling on it cannot relieve inference demand. It is tempting because storage latency can bottleneck model loading, and would be the correct metric when autoscaling storage-throughput-bound preprocessing rather than a SageMaker endpoint.

Provide all users with AdministratorAccess

Why it fails: Granting AdministratorAccess to every user removes least-privilege separation, so any compromised account can alter models, data and logging. It is tempting for rapid onboarding, but governance assigns scoped IAM roles per function, reserving administrative rights for a small audited group.

Publicly host the model endpoint

Why it fails: A public endpoint exposes model inference to unauthenticated callers, bypassing IAM authorisation and audit logging that governance requires. It is tempting when demonstrating a model externally, but governance demands private endpoints or authenticated API access with usage monitoring.

CloudTrail log retention period

Why it fails: CloudTrail log retention governs audit record storage, not endpoint capacity or invocation volume, so it cannot reduce inference spend. It is tempting because CloudTrail costs do scale with retained events, making retention a genuine cost lever in logging-governance scenarios — but that is unrelated to endpoint tuning.

Number of S3 buckets used

Why it fails: This is not a primary driver of inference cost.

Use a single shared user for all data source connections

Why it fails: A single shared connection identity removes per-user access control, so every query retrieves documents the shared account can reach, defeating document-level security. It is tempting because one credential simplifies connector configuration, and a dedicated least-privilege service account is legitimate — but shared human access is not.

Make all documents globally readable

Why it fails: Security violation.

Disable indexing of sensitive documents

Why it fails: Disabling indexing removes documents from retrieval entirely, so the RAG application cannot cite them at all — that is data loss, not security. It is tempting because excluding content from a search index does prevent leakage, and it would be correct if the requirement were to keep certain documents permanently out of scope.

Model evaluation dataset.

Why it fails: Model evaluation datasets assess model quality after deployment; Knowledge Base creation requires a data source, embedding model, vector store and IAM role, not an evaluation dataset. It is tempting because evaluation datasets are configured for Bedrock model evaluation jobs, where measuring accuracy against ground truth is the actual purpose.

External firewall rules.

Why it fails: Knowledge Bases call Bedrock models and OpenSearch Serverless over AWS-internal networking; no external firewall configuration exists in the setup workflow. It is tempting because firewall rules genuinely gate access for self-managed vector stores or on-premises retrieval endpoints, which is when they would need configuring.

Keeping training clusters running

Why it fails: Keeping clusters running bills for idle instance hours, directly increasing training cost rather than reducing it. It is tempting because persistent clusters avoid repeated startup overhead, making them the right choice when latency between iterative jobs matters more than the hourly spend on unused capacity.

Increasing the number of instances

Why it fails: Adding instances multiplies the hourly rate across nodes, raising total training cost unless runtime falls proportionally. It is tempting because horizontal scaling shortens wall-clock training time, making it the right choice when a deadline demands faster completion and the larger bill is acceptable.

Enabling detailed logging for every epoch

Why it fails: Detailed per-epoch logging writes metrics to CloudWatch and storage, adding cost rather than reducing it. It is tempting because logging aids debugging convergence failures, and would suit troubleshooting runs where visibility matters more than spend, but here it directly opposes the cost-reduction goal.

Maintaining the physical security of the data center.

Why it fails: Physical data centre security sits with AWS under the shared responsibility model, not the customer. It is tempting because customers remain responsible for their own on-premises hardware, but in the cloud AWS secures the facilities, while the customer handles patching guest operating systems, IAM and data classification.

Patching the underlying foundation model code.

Why it fails: Patching foundation model code belongs to AWS, which manages the model infrastructure and its updates. It is tempting because customers patch their own applications and operating systems, but the underlying model is provider-managed; customer duties cover data, access management, configuration and application-layer security instead.

Restart the Bedrock service.

Why it fails: Restarting the Bedrock service is not a customer action; Bedrock is a managed AWS service with no restart control, and transient service faults would be checked via AWS Health or Service Quotas instead. It is tempting because restarting a self-managed endpoint or server genuinely clears stuck state.

Increase the model's temperature to 1.0.

Why it fails: Raising temperature to 1.0 increases output randomness, adding variability that obscures the error source instead of isolating it. It is tempting because temperature tuning legitimately helps when responses are too repetitive or deterministic, but diagnosis requires holding parameters constant while testing one variable at a time.

Re-train the underlying base model.

Why it fails: Retraining the base model alters model weights and cannot isolate an agent error caused by configuration, action groups, or prompt handling; Bedrock agents do not expose base-model retraining anyway. It is tempting because retraining addresses poor model quality, which would be the right fix for consistently inaccurate outputs rather than runtime errors.