Service Confusion — AWS AI Practitioner (AIF-C01)

When the dominant constraint is augmenting FM output with proprietary data while avoiding weight modification and ML operational burden, Amazon Bedrock with RAG satisfies the deployment requirement; Amazon SageMaker does not because it is scoped to model training and custom deployment pipelines.

Whether to access pre-trained foundation models through a fully managed inference API (Amazon Bedrock) or deploy and operate model endpoints through an ML platform (Amazon SageMaker AI), when the decisive constraint is elimination of model-infrastructure management.

Which deployment layer provides a provider-agnostic, unified FM access API so that model substitution is a runtime configuration change rather than an application refactor or infrastructure redeployment?

When training data consists of labeled prompt-completion pairs and the goal is task or style alignment, instruction tuning is the correct fine-tuning method; continued pre-training requires an unlabeled corpus and mismatches the data format, while routing the job through SageMaker custom training over-scopes the infrastructure footprint for a managed fine-tuning task.

When the requirement is to produce audit-ready, framework-mapped compliance evidence for external regulators, AWS Audit Manager is the correct choice; AWS Config addresses configuration drift monitoring but does not produce structured attestation reports tied to a regulatory framework.

Whether AWS Audit Manager or AWS Config is the correct service when the requirement is to continuously collect framework-mapped evidence and produce regulator-facing audit reports, rather than to detect resource configuration drift.

Choose AWS Audit Manager over AWS Config when the requirement is to produce continuously collected, framework-mapped audit evidence for regulatory attestation — not to evaluate whether individual resource configurations conform to rules.

Choose AWS Audit Manager over AWS Config when the requirement is to produce framework-mapped, regulator-ready audit evidence reports rather than to detect resource configuration drift against individual rules.

When the task is a well-defined NLP inference operation with a structured output type (entities, sentiment, key phrases), select the purpose-built NLP service over a generative-AI platform that requires additional prompt engineering and introduces unnecessary complexity.

When the stated use case domain (image content moderation) maps exactly to a purpose-built managed AI service capability, prefer that service over building a custom model in a general-purpose ML platform.

When the requirement is real-time text-sentiment classification via a managed, purpose-built AI service that requires no model training, the correct match is the NLP-native service (Amazon Comprehend), not the computer-vision service (Amazon Rekognition) whose data-type domain is images and video.

When the output-quality symptom is weak or inconsistent step-by-step reasoning and the constraint forbids training or data ingestion, the correct intervention is a prompt engineering technique — specifically chain-of-thought — applied directly in the Amazon Bedrock prompt, not a service-level data or model intervention.

Whether to address inconsistent multi-step reasoning by applying an in-prompt technique (chain-of-thought) within Amazon Bedrock, or by invoking a model-customization or retrieval service that violates the no-training, no-ingestion constraint.

Whether to apply SageMaker Clarify (training- and evaluation-stage bias analysis) or Bedrock Guardrails (inference-stage content filtering) when the stated requirement is automated fairness-metric detection integrated into the ML lifecycle.

Whether the responsible-AI requirement — continuously evaluating fairness metrics integrated into the ML lifecycle — maps to a training/evaluation-stage bias detection tool (SageMaker Clarify) or an inference-time content filter (Bedrock Guardrails).

Whether to apply training-time and evaluation-time bias analysis (SageMaker Clarify) versus inference-time content guardrails (Bedrock Guardrails) when the explicit requirement is automated, continuous fairness metric computation across demographic groups within the ML lifecycle.

Whether to apply automated bias metric computation at the model training and evaluation stage using SageMaker Clarify, or to apply inference-time content filtering using Amazon Bedrock Guardrails — where the correct choice depends on which lifecycle stage the fairness requirement targets.

Whether to use SageMaker Model Monitor—which operates at the ML pipeline monitoring stage and compares live inference data against a trained baseline—versus a general-purpose infrastructure monitoring service that cannot perform statistical drift comparison against an ML baseline.

Select RAG via Amazon Bedrock over fine-tuning via Amazon SageMaker AI when the scenario combines a sub-second latency constraint with a daily data-freshness requirement that retraining cycles cannot satisfy.

Whether to apply ROUGE (recall-oriented, measures coverage of reference content) or BLEU (precision-oriented, measures n-gram overlap with reference) as the evaluation metric for a summarisation task, where capturing key source content is the business objective.

Whether to ground the FM in fresh domain data at inference time via RAG (Amazon Bedrock) versus baking knowledge into model weights via fine-tuning (Amazon SageMaker AI), when the knowledge source updates daily and retraining overhead would violate cost and latency constraints.

Whether the explainability requirement demands automated per-prediction feature attribution (SageMaker Clarify / SHAP) versus human-in-the-loop review routing (A2I) — the 'automated' and 'feature-level' constraints together disqualify A2I.

Whether to apply automated feature attribution tooling (SageMaker Clarify) or route predictions through a human review workflow (Amazon A2I) when the constraint requires machine-generated, prediction-level explainability delivered to auditors at inference time.

Whether the explainability requirement demands automated, prediction-level feature attribution at inference time (SageMaker Clarify) or a human-in-the-loop review routing workflow (Amazon A2I); the deciding cue is 'feature-level explanations to auditors' generated automatically, not manual human inspection.

Whether the explainability requirement is satisfied by automated machine-generated feature attribution (SageMaker Clarify / SHAP) or by a human review workflow (A2I), given the auditor constraint that demands quantitative, per-prediction justification without a human in the loop.

When a regulated GenAI deployment requires output-level human validation with a documented decision trail, choose the service that intercepts model outputs and manages human review workflows rather than one that captures operational metrics or aggregates infrastructure-level evidence.

Which AWS service provides customer-managed encryption key control at the infrastructure layer for a Bedrock-based GenAI application, distinct from model-level content safety controls?

Whether the stated auditability mandate is satisfied by a human-in-the-loop review mechanism that produces a durable audit trail (Amazon A2I) versus a model-level content control that filters outputs but generates no human-review record (Amazon Bedrock Guardrails or prompt engineering).

Determine whether PII prevention belongs at the AI inference output layer (Bedrock Guardrails) or the data-storage discovery layer (Macie), and select the service that enforces the policy at the correct layer.

Select the control layer — application-layer AI content filtering versus infrastructure-layer network isolation — that directly enforces policy on model inputs and outputs rather than on network traffic routing.

Apply an AI application-layer control (Amazon Bedrock Guardrails) rather than an infrastructure-layer control when the threat is prompt injection — a semantic content-manipulation risk that network routing, encryption, and IAM policy documents cannot intercept.

Select the control that operates at the AI application output layer to filter PII from live inference responses, not a storage-layer detection service that acts on data at rest.