Refer to the Exhibit Practice Questions

{"Effect":"Allow","Action":"bedrock:GetFoundationModel","Resource":"*"}

Why it fails: GetFoundationModel only retrieves model metadata; invoking Claude Instant requires the InvokeModel action on the model's ARN. It is tempting because discovering which foundation models exist is a genuine prerequisite task, and this statement would be correct for a role that only lists available models.

{"Effect":"Allow","Action":"bedrock:InvokeModel","Resource":"arn:aws:bedrock:us-east-1::foundation-model/*"}

Why it fails: The resource ARN omits the region-specific inference profile or model identifier required for Claude Instant invocation, so the call still fails authorisation. It is tempting because InvokeModel is the right action, and this statement would work for models addressable directly by foundation-model ARN.

{"Effect":"Allow","Action":"bedrock:*","Resource":"*"}

Why it fails: Granting bedrock:* on * violates least privilege and still may not match the inference-profile ARN the invocation targets. It is tempting because wildcards resolve many permission errors quickly, and this would be acceptable for a temporary administrative role rather than a scoped application role.

Change the prompt to include 'Write a long summary'

Why it fails: Prompt wording cannot exceed the max_tokens parameter, which caps generated output length; Claude stops once that budget is reached. It is tempting because prompt engineering shapes verbosity, and this would be correct when the model's response is truncated by an instruction implying brevity rather than a token limit.

Set 'stop_reason' to 'none'

Why it fails: stop_reason is a read-only response field reporting why generation halted; it is not an input parameter and cannot be set to 'none'. It is tempting because it appears in the CLI output alongside truncation, and inspecting it would be correct when diagnosing whether max_tokens or a stop sequence ended the response.

Use a different region like us-west-2

Why it fails: Region selection affects latency, data residency and model availability, not the max_tokens ceiling governing output length. It is tempting because some models or inference profiles are only offered in certain regions, and changing region would be correct when the desired model or capacity is unavailable in the current one.

No models

Why it fails: Reading the attached policy, its Allow statement is scoped by a condition or resource that no model in the account satisfies, so none are invocable. It is tempting to assume any attached policy grants access, but an explicit Deny or an unmet condition overrides the Allow, leaving zero permitted models.

Claude v2 and any model with a name containing 'claude'

Why it fails: The policy grants invocation of Claude v2 only, not every model whose name contains 'claude'; the wildcard condition is absent, so other Claude variants are denied. It tempts because name-prefix matching is a real IAM pattern for scoping families of models, and would be right if the statement used a wildcard such as 'claude*'.

Any model in the account

Why it fails: The policy's Allow does not extend to every model in the account; its resource or condition restricts invocation to a specific subset, so a blanket claim is wrong. It is tempting because a broad Allow statement looks unrestricted, but IAM evaluates the resource ARN and conditions, which narrow the permitted set.

The S3 input path is incorrect

Why it fails: SageMaker validates the S3 URI and fails fast with a validation error before the job starts when a bucket or prefix is malformed; a job that launched and then failed points to a runtime cause such as missing permissions or absent objects. An incorrect path suits pre-flight validation failures, not mid-execution errors.

The IAM role does not have permission to access S3

Why it fails: The exhibit's error is a client-side Python exception from the training script, not an S3 AccessDenied or ClientError, so IAM permissions are irrelevant here. An IAM role lacking S3 permissions is tempting because SageMaker training jobs commonly fail that way, and it would be correct if the log showed an access-denied message when reading the input channel.

The training code has a syntax error

Why it fails: A syntax error would surface as a Python SyntaxError during script parsing, before any training loop or dataset access; the exhibit's error occurs later, so the code parsed successfully. Syntax errors are tempting because training scripts do fail on them, and this would be correct if the log showed a traceback at import or compile time.

Proceed with deployment because the model is already in production

Why it fails: Deploying despite a high bias metric ignores the finding and perpetuates disparate impact on the gender facet. Responsible AI practise requires investigating and mitigating the bias, for example by rebalancing training data or adjusting thresholds, before releasing the model.

Remove the gender attribute from the training data and retrain

Why it fails: Dropping the gender attribute does not remove bias, since correlated proxies such as postcode or occupation still encode it, and the Clarify job would simply report a different facet. It is tempting because removing a protected attribute feels like anonymisation, and it would be reasonable where the attribute is genuinely irrelevant to the target and no proxy correlation exists.

Increase the acceptance threshold for the model

Why it fails: Raising the acceptance threshold shifts the decision boundary to cut approvals, altering error rates without addressing the disparate impact measured across the gender facet. It is tempting because threshold tuning is a legitimate lever for balancing precision and recall, and would be correct if the goal were purely to reduce false positives rather than mitigate bias.

It specifies a character sequence for the model to include in its response

Why it fails: Stop_sequences are strings that terminate generation when produced, not content the model is instructed to include. Specifying text to appear in the response is achieved through the prompt itself, which is the correct mechanism when you require particular wording in the output.

It limits the number of tokens in the response

Why it fails: Token count is governed by max_tokens, not stop_sequences. Stop_sequences halts generation when the model emits a specified string. Limiting response length via token count would be the right control when you need a hard cap on output size regardless of content.

It controls the randomness of the response

Why it fails: Randomness is controlled by temperature and top_p, which shape the sampling distribution. Stop_sequences instead define strings that end generation. Adjusting temperature would be correct when you need to tune output variability, from deterministic to creative responses.

The upload succeeds because S3 automatically encrypts objects at rest

Why it fails: Automatic encryption does not satisfy the condition requiring the header.

The upload fails because the policy does not allow PutObject without encryption

Why it fails: The policy allows PutObject with a condition; the failure is due to missing condition, not because encryption is required.

The upload succeeds because the bucket has default encryption enabled

Why it fails: The policy condition checks the request header, not the bucket's default encryption.

Increase the chunk size in FIXED_SIZE chunking

Why it fails: Larger fixed-size chunks dilute the embedding with unrelated text, so the retriever's similarity score for a specific detail drops and it is missed. Fixed-size chunking suits uniform, short passages where boundary loss is tolerable, not long documents needing precise detail retrieval.

Add more documents to the S3 bucket

Why it fails: Adding more documents increases corpus size without improving chunking or embedding quality, so long-document details remain poorly retrieved. It is tempting because a larger knowledge base appears richer, but the actual fix is adjusting chunk size or overlap so relevant passages are indexed and matched.

Change the embedding model to a larger one

Why it fails: Embedding models map text to vectors; swapping to a larger one does not alter how source documents are split, so details spanning chunk boundaries stay unretrieved. Larger embeddings suit semantic similarity tuning, not the chunking configuration the stem asks about.

Use a CPU instance

Why it fails: CPU instances lack the matrix-multiply throughput and high-bandwidth memory that transformer decoding depends on, so per-token latency rises sharply. CPU inference is the right pick for small models, sporadic traffic or cost-sensitive endpoints where GPU acceleration is unnecessary.

Switch to a larger instance type

Why it fails: A larger instance adds vCPU and memory, which does not raise the GPU's token-generation throughput; per-token latency is bound by accelerator compute and memory bandwidth. Larger instances suit memory-bound models or bigger batch workloads, not the sequential decode path that governs inter-token latency.

Increase batch size to 10

Why it fails: Batching ten requests raises aggregate throughput but each token still waits for the whole batch, so individual per-token latency grows. Larger batches suit offline or high-volume throughput scenarios, not the interactive single-stream latency the exhibit targets.

Insufficient training data

Why it fails: Training data volume is unrelated to an IAM policy's permissions; the exhibit concerns which AWS services and resources the SageMaker execution role can reach, so the concern is excessive privilege or unauthorised access. Data sufficiency would be the issue if the question described model accuracy problems or unrepresentative datasets.

Violation of data residency requirements

Why it fails: Data residency concerns where personal data is physically stored or processed, not which API actions an IAM role may invoke. An IAM policy governs permissions, so the exhibit raises excessive privilege or unauthorised access. Residency would be the answer if the stem showed data replicated to an unapproved AWS Region.

Absence of model monitoring

Why it fails: CloudTrail records the IAM policy creation itself, which concerns permissions and least privilege, not runtime model behaviour. Absence of model monitoring is a separate concern detectable through CloudWatch or SageMaker Model Monitor, not through an IAM policy creation event.

Titan Embed Text

Why it fails: Titan Embed Text produces vector embeddings only and cannot generate text, so it fails the generation requirement regardless of price. Embedding models are the correct choice for semantic search, retrieval or clustering, where converting text into vectors is the goal rather than producing new text.

Titan Text Express

Why it fails: Titan Text Express generates text but is not the lowest-cost text-generation model in the exhibit; another listed model undercuts its price. Titan Text Express suits general-purpose text generation where throughput and quality matter more than minimising spend, not the cheapest-option requirement stated here.

Need more information

Why it fails: The exhibit lists model capabilities and prices, so the cheapest text-generating model can be identified directly; requesting more information is unnecessary. This answer would be correct only if the exhibit omitted pricing or generation capability, leaving the comparison impossible to complete from the data provided.

It requires human approval before deploying any model

Why it fails: The policy governs endpoint creation permissions, not model deployment approval gates, so it cannot enforce human sign-off on models. It is tempting because approval workflows do support responsible AI, but that requires a deployment-stage control, not an IAM policy scoped to endpoint provisioning.

It prevents the use of GPU instances to reduce cost

Why it fails: The policy governs endpoint creation permissions, not instance selection, so GPU cost control is not its mechanism; responsible AI here concerns controlled deployment. Restricting instance types would be correct for budget governance, but cost reduction is a financial aim, not the accountability the policy demonstrates.

It restricts endpoints to only use models built in SageMaker

Why it fails: Limiting endpoints to SageMaker-built models constrains provenance, not the approval or oversight the policy enforces; models from other sources can still be responsible. Such a restriction would be correct when governance demands vetted model origins, but the policy's control point is endpoint creation authorisation.

Variant weight is 1.0

Why it fails: Variant weight 1.0 simply routes all traffic to that single variant; it does not prevent scaling. It is tempting because weights matter in multi-variant A/B deployments, where they would be the correct focus if the config defined several production variants.

Instance type is too small

Why it fails: An undersized instance slows individual inferences but does not stop the endpoint from adding instances as load rises. It is tempting because instance sizing genuinely governs latency and throughput per replica, and it would be the right answer if the endpoint scaled but still timed out.

InitialInstanceCount is 1

Why it fails: InitialInstanceCount 1 is the starting replica count; autoscaling provisions additional instances beyond it, so it does not block scaling. It is tempting because a single instance looks like an obvious bottleneck, and it would be correct if autoscaling were absent from the configuration.

Use a single model for all customers without segmenting by region

Why it fails: A single unsegmented model pools heterogeneous regional behaviour, so it can learn majority-region patterns and disadvantage minority segments, worsening bias. It is tempting because one model is cheaper to train, deploy and maintain. Robust, unbiased fraud detection typically requires segment-aware features, per-region evaluation and stratified sampling to expose subgroup performance gaps.

Deploy the model with a high confidence threshold to reduce false positives

Why it fails: A confidence threshold only tunes precision versus recall; it neither improves robustness to distribution shift nor removes bias encoded in features or training data. It is tempting because raising the threshold cuts false positives, which matters operationally. Bias mitigation requires representative data, fairness metrics and reweighting or resampling, not threshold tuning.

Encrypt all transaction data at rest and in transit

Why it fails: Encryption at rest and in transit protects data confidentiality against interception or theft; it does nothing about model bias or robustness to adversarial or drifting inputs. It is tempting because encryption is a standard financial-services control and appears security-relevant. Bias and robustness are addressed through data quality, fairness testing and validation, not cryptographic protection.

The model is overfitting to the training data.

Why it fails: Non-deterministic outputs for identical inputs indicate inconsistent or non-reproducible inference, not overfitting, which shows as poor generalisation to unseen data. Overfitting is tempting because it also degrades reliability, but the symptom here is run-to-run variance. Reproducibility and output stability are the actual concern.

The model is exhibiting bias against a demographic group.

Why it fails: Varying probabilities for the same input indicate non-deterministic inference, not demographic bias, which requires comparing outcomes across protected groups. Bias is tempting because responsible AI often concerns fairness, but no group attribute appears in the logs. The concern is reproducibility and consistent model behaviour.

The input data is drifting from the training distribution.

Why it fails: Repeated inputs yielding varying probabilities indicates non-determinism or inconsistent model outputs, not data drift, which concerns changes in input distribution over time. Drift detection is tempting because CloudWatch Logs can surface distribution shifts, but the pattern here is output variance for identical inputs.