Refer to the Exhibit Practice Questions

Delete the existing endpoint and create a new one

Why it fails: Deleting the endpoint removes its hosting configuration and the DNS route callers use, so requests fail until a replacement is provisioned. It is tempting because recreating an endpoint does deploy a new model version, and that is the right approach when the endpoint is disposable and brief interruption is acceptable.

Update the endpoint's model name directly

Why it fails: Editing the model name in place triggers a redeployment of the existing endpoint's production variant, so the old version stops serving before the new one is ready. It appeals because it is the quickest way to point an endpoint at a different model when downtime is tolerable.

Use SageMaker Model Monitor to automatically switch

Why it fails: Model Monitor evaluates incoming data and predictions for drift and quality, publishing findings to CloudWatch; it holds no deployment control and cannot shift traffic between variants. It is tempting because it watches model behaviour, which is the correct tool when the goal is detecting degradation rather than releasing a new version.

sagemaker:ListApps

Why it fails: ListApps enumerates applications in a domain and grants no access to a user profile's file storage. It is tempting because listing resources is a common first permission in IAM policies, and it would be correct when a user must discover which SageMaker applications exist before launching one.

sagemaker:DescribeUserProfile

Why it fails: DescribeUserProfile returns configuration details about a user profile; it does not authorise reading the EFS-backed home directory where Studio files reside. It is tempting because profile metadata is often needed during troubleshooting, and it would be correct when validating that a user profile exists and is configured properly.

kms:Decrypt

Why it fails: kms:Decrypt only unwraps data keys; the missing permission is the sagemaker:DescribeUserProfile or file-system action governing Studio home directory access. It is tempting because encrypted volumes require decrypt rights, and kms:Decrypt would be correct if the user could reach the filesystem but the underlying EBS or EFS data was encrypted with a key they cannot use.

Change the model artifact encryption to SSE-S3.

Why it fails: Switching to SSE-S3 removes the KMS dependency but discards the customer managed key's access control and audit trail that the bucket's security posture requires. SSE-S3 suits buckets with no KMS governance mandate, not one already encrypted under SSE-KMS.

Re-upload the model artifact without encryption.

Why it fails: Re-uploading without encryption strips protection from the model artifact entirely, breaching the encryption requirement rather than granting the role kms:Decrypt. Unencrypted artifacts suit only non-sensitive test data in isolated accounts, never production models under a KMS policy.

Attach the AWS managed policy 'AmazonSageMakerFullAccess' to the role.

Why it fails: AmazonSageMakerFullAccess grants broad SageMaker permissions but does not include kms:Decrypt on the customer managed key protecting the bucket, so the role still cannot read the artifact. It suits general SageMaker administration, not granting access to a specific KMS-encrypted object.

The InputDataConfig specifies ContentType text/csv but the actual file is not CSV.

Why it fails: A ContentType mismatch usually triggers a parsing or deserialisation error when SageMaker reads the channel, not the failure shown. The exhibit's traceback points elsewhere, so the declared MIME type is not implicated. This would be correct if the log showed a CSV parse failure.

The SageMaker training image is outdated and does not support Scikit-learn 1.0.

Why it fails: An outdated image would surface as a package or import error, not the specific exception in the exhibit. The failure stems from the script's code or data handling, so the image version is irrelevant. This would be correct only if the log showed a missing Scikit-learn module or version conflict.

The training data contains missing values that need to be imputed.

Why it fails: Missing values typically raise a ValueError inside the estimator or preprocessing step, producing a traceback naming that function. The exhibit's error does not reference NaN handling, so imputation is not the cause. This would be correct if the log showed NaN or null-related exceptions.

The policy allows s3:PutObject but the job only reads

Why it fails: Allowing only s3:PutObject grants writes, not the s3:GetObject needed to read, but the exhibit shows the policy already includes read actions. Write-only policies suit ingestion pipelines uploading results, not jobs retrieving training data from S3.

The policy does not specify the bucket ARN without /*

Why it fails: Omitting the bucket ARN without /* would deny object-level reads, yet the exhibit's stated policy already scopes resources correctly, so this is not the fault. Bucket-versus-object ARN scoping suits policies granting ListBucket only, not the read failure described.

The Glue job role does not have the required permissions

Why it fails: The Glue job role's missing permissions is the actual fault only if the exhibit shows no S3 allow statements; the scenario's policy document instead governs the failure. Role permission gaps suit newly created jobs never granted S3 access, not misconfigured existing policies.

TargetValue is too high

Why it fails: TargetValue sets the metric threshold that triggers scaling; raising it makes the endpoint tolerate higher load before adding instances, affecting scale-out rather than the slow scale-in. It tempts because a high threshold suggests over-provisioning, yet the delayed decrease is caused by ScaleInCooldown, not TargetValue.

ScaleOutCooldown is too low

Why it fails: ScaleOutCooldown governs how long after a scale-out event before another scaling action; a low value speeds further scale-out, not scale-in. It tempts because cooldown parameters sound responsible for sluggish scaling, but the slow decrease stems from ScaleInCooldown being too high, delaying removal of idle instances.

Wrong predefined metric selected

Why it fails: Wrong predefined metric cannot explain asymmetric scaling: scale-out and scale-in are governed by separate CloudWatch alarms, so slow scale-in points to a long scale-in cooldown or missing scale-in policy. A predefined metric is chosen when built-in metrics such as CPUUtilization or InvocationsPerInstance already match the workload.

The endpoint instance type is insufficient.

Why it fails: An insufficient instance type produces latency or out-of-memory failures, not errors triggered specifically by repointing the endpoint configuration to a new model version. It is tempting because undersized instances genuinely cause endpoint failures, and resizing would be correct if the error appeared under increased inference load rather than after a version change.

The container image for the new model is not compatible.

Why it fails: An incompatible container image fails at model load time, yet the stem attributes the error to the configuration update pointing at a new model version, which leaves the image unchanged. It is tempting because container incompatibility genuinely breaks SageMaker endpoints, and it would be correct if the image itself had been swapped alongside the model.

The IAM role does not have permission to invoke the endpoint.

Why it fails: Invoke permissions govern caller access to the endpoint, so a missing policy yields AccessDenied for clients rather than errors introduced by repointing the configuration to a new model version. It is tempting because IAM misconfiguration genuinely blocks endpoint invocation, and it would be correct if callers, not the model version, had changed.

The new model artifact is not properly uploaded to S3.

Why it fails: A missing S3 artifact causes failure when the endpoint loads the model, but the stem's error follows a configuration update to a new model version, which implies the artifact exists at a new location. It is tempting because absent artifacts genuinely break deployments, and it would be correct if the upload step had been skipped.

The learning rate is too high

Why it fails: A high learning rate causes divergence or NaN loss, which the exhibit would show as oscillating or exploding loss values, not the failure signature displayed. It is tempting because tuning the learning rate is a standard remedy for unstable training, and it would be correct if the loss curve showed divergence rather than the actual symptom.

The instance type does not have SSD storage

Why it fails: Instance storage type affects I/O throughput, not whether the job can start; the exhibit's failure would not reference SSD absence. It is tempting because storage performance matters for data-heavy training, and it would be correct if the logs showed disk read/write bottlenecks or slow data loading rather than the actual error.

The instance type does not have enough memory

Why it fails: Insufficient memory manifests as an out-of-memory error or killed process, which the exhibit does not show. It is tempting because memory exhaustion is a frequent cause of training failures, and it would be the correct choice if the logs contained an OOM kill or memory allocation failure message.

The number of epochs is too low

Why it fails: Too few epochs produces an underfit model with poor accuracy, not a job failure; training completes normally. It is tempting because epoch count is a common hyperparameter to adjust, and it would be the correct choice if the exhibit showed training and validation loss still decreasing when training stopped.

The IAM role 'SageMakerExecutionRole' does not have permission to create the training job.

Why it fails: The role's own permissions govern what it can do after assumption; the 'Unable to assume role' error occurs earlier, when the caller's identity lacks sts:AssumeRole on that role or the trust policy rejects it. It is tempting because missing permissions are a frequent cause of failures, but the failing action is assumption, not job creation.

The training image in ECR does not exist.

Why it fails: A missing ECR image would produce an image-pull or resource-not-found error after the role is assumed and the job is provisioned. It is tempting because container images are a common misconfiguration, but the 'Unable to assume role' message indicates failure at the earlier credential-assumption step.

The S3 bucket 'my-bucket' does not exist.

Why it fails: A missing S3 bucket would surface later as an input-data or validation error once the job starts, not as an immediate 'Unable to assume role' failure at submission. It is tempting because S3 access is commonly misconfigured, but the error names role assumption, which occurs before any bucket is read.

The model is underfitting because the validation accuracy is too low

Why it fails: Underfitting means both training and validation accuracy are low, indicating the model has not learned the underlying pattern. Here 95% training accuracy shows the model fits the data well. The option is tempting because 92% validation accuracy sounds low in absolute terms, but it is close to training performance.

The model needs more epochs to improve validation accuracy

Why it fails: A 95% versus 92% split shows the model already converging, so adding epochs risks overfitting rather than lifting validation accuracy. The option is tempting because more training often helps early in a run. Without a learning curve showing validation accuracy still rising, more epochs are not indicated.

The model is overfitting because the training accuracy is higher than validation accuracy

Why it fails: A three-point gap between training and validation accuracy is normal generalisation loss, not overfitting; overfitting shows a large gap with validation accuracy plateauing or degrading. The option is tempting because any gap superficially suggests memorisation. The stated accuracies indicate the model generalises acceptably.

sagemaker:DescribeEndpoint

Why it fails: DescribeEndpoint returns endpoint metadata and is not required to send InvokeEndpoint requests; the missing action is sagemaker:InvokeEndpoint. It is tempting because describing resources is commonly bundled with using them, and would be needed for tooling that inspects endpoint status before invoking.

sagemaker:CreateEndpoint

Why it fails: CreateEndpoint provisions a new endpoint and does not permit calling an existing one; sagemaker:InvokeEndpoint is the action the user lacks. It is tempting because endpoint-related permissions sound interchangeable, and would be correct for a deployment role that must stand up endpoints.

sagemaker:ListEndpoints

Why it fails: ListEndpoints enumerates endpoints in the account and grants no invocation rights, so adding it leaves InvokeEndpoint absent. It is tempting because listing is often assumed to precede calling a resource, and would be correct for a user who must discover endpoint names rather than invoke them.

The S3 output path is incorrect

Why it fails: An incorrect S3 output path produces a permissions or access-denied error naming that bucket, not the failure shown. SageMaker validates the output location and reports it explicitly, so this would be the cause only when the error text references the S3 URI or an AccessDenied on that prefix.

The training image is not accessible

Why it fails: An inaccessible training image fails before the container starts, with an ImagePull or ResourceNotFound error naming the ECR repository and tag. The exhibit shows the job reaching execution, so the image was pulled successfully; this would be correct only if the error cited the image URI.

The instance type is insufficient

Why it fails: An insufficient instance type surfaces as a resource-limit or OutOfMemory error, or as an instance-type validation failure at job creation. The exhibit's error does not reference memory, CPU or capacity, so this would be the cause only when the message names the instance type or resource exhaustion.

Learning rate too high

Why it fails: A high learning rate causes erratic loss or divergence, not steadily rising training AUC with a plateaued validation curve. That pattern indicates the model is memorising training data. A high learning rate would be the suspect when training loss oscillates or fails to decrease at all.

Underfitting

Why it fails: Underfitting produces low training AUC alongside low validation AUC, since the model cannot capture the underlying pattern. Here training AUC keeps climbing, which is the opposite signature. Underfitting would be the diagnosis when both curves plateau early at a poor value.

Insufficient training data

Why it fails: Insufficient training data typically depresses both training and validation performance, or causes high variance across folds. The stem shows training AUC still increasing, meaning the model fits the data it has. Data scarcity would be indicated by poor training AUC despite adequate model capacity.

The model weights became corrupted due to a disk write error.

Why it fails: Disk write errors corrupting weights would surface as load or checksum failures at endpoint startup, not as NaN predictions from an otherwise running endpoint. Corruption is the right cause when logs show artifact integrity errors, but the exhibit indicates malformed feature values passed at inference time.

The endpoint is overloaded and returning a default NaN response.

Why it fails: Overload produces throttling, timeouts or 5xx responses, not NaN values; SageMaker does not substitute NaN as a default. Overload is the correct diagnosis when logs show latency spikes and capacity errors, whereas NaN output originates from the inference input or model computation itself.

The model artifact failed to load correctly, resulting in NaN weights.

Why it fails: A failed artifact load typically makes the endpoint invocation fail outright or return an error, not silently emit NaN predictions. Artifact loading is the right suspect when logs show container startup or deserialisation errors, but the exhibit points to input data containing nulls reaching the model.

Create two separate endpoint configurations, each with 3 instances, and distribute traffic between them.

Why it fails: Splitting into two configurations still requests six ml.c5.large instances in total, so the same per-instance quota is breached. It tempts because distributing load across multiple endpoints is a legitimate pattern for isolating variants or blue/green deployments, but it does not alter the underlying account limit.

Use a different instance type, such as ml.m5.large, which has a higher limit.

Why it fails: Switching instance type does not raise the account-level quota that the error reports; the limit applies to the ml.c5.large family in that Region, so ml.m5.large may hit its own separate cap. It tempts because moving to a larger or different family is the standard fix when a specific instance type is unavailable in an Availability Zone.

Delete unused endpoints to free up resources.

Why it fails: Deleting unused endpoints frees running endpoint instances, not the service quota governing concurrent ml.c5.large instances for endpoint configuration creation. It tempts because quota exhaustion often stems from orphaned resources, and cleanup is the usual remedy when account limits are genuinely consumed by idle deployments.