Select Two (Multi-Select) Questions

Amazon SageMaker Pipelines

Why it fails: Pipelines orchestrates training workflows and CI/CD steps, not model cards or deployment history records. It is tempting because pipelines do automate model building and versioning artefacts, but the stem asks for documented intended use, performance and limitations shared with stakeholders, which SageMaker Model Cards and Model Registry provide.

Amazon SageMaker Clarify

Why it fails: Clarify detects bias and explains feature attributions; it does not produce model cards or version histories. It is tempting because documenting intended use and limitations sounds like explainability, but Clarify's output is statistical analysis, not the governance documentation and deployment tracking the stem requires.

Amazon SageMaker Studio

Why it fails: Studio is an integrated development environment for building and running notebooks; it stores no model documentation or deployment lineage. It is tempting because teams work in Studio daily, but the stem requires model cards and a registry tracking versions and deployments, not an IDE.

Amazon Translate

Why it fails: Amazon Translate performs machine translation between languages; it does not expose general NLP capabilities such as sentiment analysis, entity recognition or key phrase extraction. It is tempting because it processes natural language text, and it would be the correct choice when the requirement is specifically translating content from one language into another.

Amazon Rekognition

Why it fails: Rekognition analyses images and video — face detection, object labelling, content moderation — not text. It is tempting because it is a prominent pre-trained AI service, and it would be correct for extracting labels or faces from a photo library, but it cannot tokenise, classify or extract entities from natural language.

Amazon Polly

Why it fails: Polly converts written text into synthetic speech, a text-to-speech service; it does not analyse or interpret language semantics. It is tempting because it consumes text input, and it would be correct for adding voice output to an application, but NLP tasks such as sentiment analysis, entity extraction or translation require Comprehend or Translate.

Enable Amazon CloudWatch Logs to capture model output and manually review.

Why it fails: CloudWatch Logs records invocations and outputs after generation, enabling retrospective review rather than preventing non-compliant content. Tempting because logging underpins auditing and monitoring, and it would be correct for observability or post-hoc investigation, not for blocking prohibited keywords and tones before the response reaches the application.

Use AWS IAM policies to restrict the model's output to only approved words.

Why it fails: IAM policies govern which AWS principals may call Bedrock APIs and which models or regions they can invoke; they cannot inspect or filter generated token content. Tempting because IAM is the standard access-control mechanism, and it would be correct for restricting who can invoke a model, not what the model outputs.

Encrypt the model responses using AWS KMS to prevent unauthorized viewing.

Why it fails: KMS encryption protects model responses at rest or in transit from unauthorised viewing; it does not evaluate wording or tone against brand rules. Tempting because encryption is a common compliance control, and it would be correct where the requirement is protecting response confidentiality, not enforcing prohibited keywords.

Configure Macie to automatically grant access to the SageMaker execution role

Why it fails: Macie is a discovery and classification service; it holds no IAM permission to grant roles access to S3 objects, so it cannot authorise the SageMaker execution role. Macie is correctly used to identify sensitive data for labelling, not to manage bucket access.

Create a VPC endpoint for S3 and associate it with the SageMaker VPC

Why it fails: A VPC endpoint changes the network path from the SageMaker VPC to S3; it does not alter the bucket policy that denies external accounts, so the cross-account request is still refused. Endpoints are the right choice when traffic must stay off the public internet, not when authorising a foreign account.

Remove the bucket policy that prohibits external access

Why it fails: Removing the bucket policy strips the guardrail entirely, exposing the training data to every principal rather than the SageMaker execution role alone. Bucket policies are removed when decommissioning a bucket or deliberately making data public, not when granting scoped cross-account access.

Apply chain-of-thought prompting to encourage reasoning

Why it fails: Chain-of-thought prompting improves multi-step reasoning accuracy but supplies no brand guidelines or product facts, so off-brand wording and factual errors persist. It is tempting because it genuinely helps arithmetic and logic tasks, where reasoning transparency rather than grounding in source material is the actual problem.

Use zero-shot prompting without any examples

Why it fails: Zero-shot prompting provides no examples or reference material, leaving the model to invent brand voice and product details, which is precisely what causes the errors. It is tempting for speed on simple, well-specified tasks, but here the model needs grounding in approved content.

Decrease the temperature to 0.0 to eliminate randomness

Why it fails: Lowering temperature reduces randomness in word selection but does not inject brand guidelines or correct product facts; a confident wrong statement remains wrong. Temperature tuning is the right control when output variety or creativity is the problem, not when accuracy and brand alignment are.

Deploy the model without any content filters to maximize creativity

Why it fails: Removing content filters lets the model emit harmful, unsafe or non-compliant output, directly violating responsible AI requirements. Filters are tempting to disable when they block legitimate creative prompts, yet they are the correct choice precisely for open-ended creative tools where misuse and harmful generation must be constrained.

Increase model size to improve accuracy at the expense of interpretability

Why it fails: Scaling parameters trades transparency for marginal accuracy, and interpretability is a responsible AI requirement, not an optional sacrifice. Larger models are the right choice when raw predictive accuracy on a benchmark is the sole objective and explainability is not mandated by regulation or stakeholder need.

Use only synthetic data for training to avoid privacy issues

Why it fails: Synthetic-only training discards real-world distribution, producing models that generalise poorly and still risk leakage if generation is flawed. Synthetic data is genuinely useful for augmenting scarce or sensitive datasets, but responsible deployment requires provenance controls, consent and evaluation on representative real data.

AWS CloudTrail

Why it fails: CloudTrail records API activity for audit and compliance, but it does not version models, detect data or model drift, or retire them. It is the correct service when the requirement is capturing account-level API calls and event history, not managing the model lifecycle itself.

SageMaker Role Manager

Why it fails: SageMaker Role Manager builds IAM roles and permissions for users, so it grants access rather than versioning, monitoring or decommissioning models. It is the correct feature when defining persona-based permissions for SageMaker domain users, not for governing model artefacts and drift.

Use Amazon Forecast to predict ticket volume

Why it fails: Forecast predicts time-series data, not text classification.

Use Amazon Comprehend for topic modeling and entity detection

Why it fails: Comprehend topic modelling clusters ticket text into emergent themes and entity detection extracts key terms, allowing routing categories to be discovered from data rather than fixed labels. This satisfies the requirement to handle new categories without retraining a custom model.

Use Amazon Rekognition to analyze ticket images

Why it fails: Rekognition is for image/video analysis; tickets are text-based.

Amazon DynamoDB table

Why it fails: DynamoDB stores data but cannot be invoked as an action; Bedrock Agents call external services through action groups backed by Lambda functions. DynamoDB is tempting because agents may persist session state, and would be right for storing booking records, but it provides no callable service interface.

Amazon SageMaker endpoint

Why it fails: A SageMaker endpoint hosts a separately trained model; Bedrock Agents invoke external services through action groups backed by Lambda functions, not SageMaker. SageMaker is tempting because it also serves models, and would be correct for custom inference, but it provides no action-group integration for the agent.

Bedrock Knowledge Base

Why it fails: A Bedrock Knowledge Base provides a repository of static documents for retrieval-augmented generation (RAG), not the ability to execute live API calls to external services. It is tempting because it can store travel policy documents, which an agent might query for answers, but it lacks the action groups or Lambda functions required to invoke external flight or hotel booking systems. It would be correct only if the agent needed to answer policy questions from a fixed corpus, not to perform transactional operations.

Measure inference latency under load

Why it fails: Inference latency measures serving performance, not output quality, so it cannot assess generated text. It is tempting because latency matters when deploying models, and benchmarking under load is the right choice for a throughput or scalability question rather than an evaluation-quality one.

Compute perplexity on the generated text

Why it fails: Perplexity measures how well a model predicts a token sequence, requiring reference text and token probabilities; it does not assess the fluency, relevance or factual accuracy of generated output. It suits comparing language models on held-out corpora, not judging generation quality.

High bias typically leads to overfitting

Why it fails: High bias means the model is too rigid to capture the underlying pattern, producing underfitting with poor accuracy on both training and test data. Overfitting arises from high variance, where the model memorises training noise. High bias is the correct diagnosis when a linear model is fitted to clearly non-linear data.

High variance models are insensitive to changes in training data

Why it fails: High variance means the model fits training noise, so small changes in the training set alter the learned parameters and predictions substantially. Insensitivity to training data changes is characteristic of high bias, where the model ignores the data's structure, as with a linear fit to curved data.

Increasing model complexity typically decreases variance

Why it fails: Raising model complexity increases variance, because the model has more parameters to fit training noise, so predictions shift sharply with different samples. Variance falls when complexity is reduced, for example constraining a deep tree with pruning or limiting polynomial degree.

Enable AWS CloudTrail to log all endpoint invocations

Why it fails: CloudTrail logs are for auditing, not encryption or access control.

Disable root access on the SageMaker notebook instances

Why it fails: Notebook instances are not directly relevant to endpoint security.

Minimize the number of features to reduce cost

Why it fails: Feature count is a cost and performance lever, not a responsible-AI control; dropping attributes can strip fairness-relevant signals and entrench bias. It is tempting because leaner models are cheaper and faster, which suits latency- or budget-constrained deployments, but the stem asks about responsible AI for employee predictions.

Publish the model's predictions publicly for transparency

Why it fails: Publishing individual performance predictions exposes personal data, breaching privacy and confidentiality obligations rather than advancing responsible AI. Transparency is tempting because it sounds ethical, and it fits aggregate model documentation, such as model cards or published accuracy metrics, not per-employee outputs.

Set an ECR lifecycle policy to delete untagged images older than 30 days.

Why it fails: Lifecycle policies manage image retention, not enforcement of approved images in pipelines.

Enable AWS Config rules to check for public ECR repositories.

Why it fails: Config rules are detective, not preventive; they do not enforce encryption in the pipeline.

Automatic model fine-tuning

Why it fails: Bedrock offers fine-tuning for selected models, but it is not automatic and not available for every model; you supply labelled data and configure a tuning job. It is tempting because customisation improves task accuracy, which suits domain-specific use cases requiring tailored model behaviour.

Free tier for all models

Why it fails: Bedrock charges per input and output token for each model; there is no blanket free tier across all foundation models. It is tempting because some models offer limited free trials, which suits experimentation, but that is not a general platform benefit.

Built-in image generation capability

Why it fails: Bedrock provides access to foundation models for text, chat and embeddings, but image generation is offered by Amazon Titan Image Generator and Nova Canvas as separate model choices, not as a platform-wide built-in benefit. It is tempting because Bedrock does host image models, which suits teams specifically needing generative imagery.

Use AWS Identity and Access Management (IAM) policies to restrict model access.

Why it fails: IAM policies govern who may invoke which models and actions; they cannot inspect prompt or response content, so generated PII passes through unchanged. IAM restriction is correct for least-privilege access control, not for content-level PII prevention, which needs guardrails or output filtering.

Enable Amazon CloudWatch Logs to capture and audit model outputs.

Why it fails: CloudWatch Logs records outputs after generation, providing audit evidence but no prevention; PII has already been emitted. Logging is the right control for compliance traceability and incident review, whereas blocking PII requires guardrails or filters applied before the response is returned.

Place the Bedrock model endpoint within a private VPC.

Why it fails: A private VPC endpoint secures network path and access to the model, but does nothing to filter generated text; PII can still appear in outputs. Private networking is correct for data-residency or traffic-isolation requirements, not for detecting or blocking PII in model responses.

Disable logging to reduce latency

Why it fails: Disabling logging removes the prediction and feature records that drift detection, data capture and CloudWatch metrics depend on, so degradation becomes invisible. Logging is deliberately reduced only where latency budgets are tight and monitoring is handled out-of-band, which contradicts the monitoring requirement here.

Use only CPU instances

Why it fails: Restricting inference to CPU instances removes GPU capacity needed for throughput and says nothing about capturing model quality signals. CPU-only fleets suit small models or cost-sensitive batch scoring, not production monitoring, which requires metrics, logging and drift detection regardless of instance type.

Retrain model daily

Why it fails: Retraining daily is costly and can propagate bad data or unstable weights; monitoring should trigger retraining when drift or performance thresholds are breached. Scheduled frequent retraining suits rapidly shifting domains with cheap pipelines, not a general monitoring best practice.

Use a high temperature parameter to increase creativity.

Why it fails: Higher temperature flattens the probability distribution, increasing randomness and hallucination risk in a task demanding faithful extraction. It is tempting because temperature legitimately governs creativity, and would be correct for brainstorming or generating varied marketing copy, not for grounded summarisation of factual documents.

Use a low frequency penalty to reduce repetition.

Why it fails: Frequency penalty adjusts token repetition during decoding; it does not improve factual coverage or fidelity, and a low value barely alters output. It belongs in creative or conversational generation where looping phrases must be suppressed. Summarisation quality improves through prompt engineering, retrieval of source context, or fine-tuning, not repetition control.

Use a longer context length by increasing the max tokens parameter.

Why it fails: Raising max tokens only lets the model emit longer output; it does not extend the input window, so the document is still truncated before summarisation. It is tempting because max tokens genuinely controls generation length, and would be correct when summaries are being cut off mid-sentence rather than when source text is being dropped.

Deploy the model immediately without additional training

Why it fails: Fine-tuning requires further training on task-specific data; deploying straight away skips that step entirely. Immediate deployment suits a pre-trained model used as-is via prompting or an API, where no weight updates are needed, but it cannot satisfy a scenario demanding adaptation to a specialised dataset.

Choose a model architecture with more parameters than the base model

Why it fails: Fine-tuning adapts an existing pre-trained model's weights; it never swaps in a larger architecture, since parameter count is fixed at selection time. Enlarging the architecture is a pre-training design decision, so it addresses no fine-tuning step such as dataset preparation, hyperparameter configuration or evaluation.

Define a Lambda function for post-processing

Why it fails: Post-processing via Lambda runs after retrieval, not during ingestion; ingestion covers parsing, chunking, embedding and vector storage. It tempts because Lambda customisation is genuinely useful for transforming retrieved chunks or responses in a RAG pipeline, but that belongs to the query or orchestration stage, not the ingestion workflow the question asks about.

Perform a similarity search on the vector store

Why it fails: Similarity search queries the vector store at retrieval time, after ingestion has already embedded and stored the chunks. It tempts because retrieval is the visible purpose of the pipeline, yet the question asks only for ingestion steps; searching presupposes the embeddings already exist, so it cannot be part of building the index.

Augment the user prompt with retrieved chunks

Why it fails: Augmentation happens at query time, after retrieval, when the user prompt is combined with the chunks returned from the knowledge base. Ingestion covers parsing, chunking, embedding and storage only. Augmentation is the correct step when discussing the retrieval-and-generation half of the pipeline.