AWS Certified AI Practitioner (AIF-C01)

Few-shot prompting provides a small set of examples (input-output pairs) to teach the model the desired pattern. It can help the LLM format incident analyses consistently and may improve accuracy by demonstrating how to compute deltas/ratios. However, the requirement is specifically to produce an explicit step-by-step reasoning trace with intermediate calculations, which is more directly addressed by chain-of-thought prompting than by merely providing examples.

Zero-shot prompting relies only on instructions without examples. While you could ask for numbered steps and calculations, zero-shot is generally less reliable for complex, multi-evidence reasoning across sequential logs and metrics. It often increases variability in structure and completeness, making it a weaker choice when the output must consistently include intermediate computations and a justified root cause/remediation trace.

Directional stimulus prompting steers the model by emphasizing specific signals, constraints, or hints (e.g., “focus on latency spikes after deployment,” “prioritize 5xx errors”). This can improve relevance and reduce distraction from noisy logs, but it does not inherently cause the model to expose a full reasoning chain with intermediate calculations. It is more about guiding attention than eliciting explicit step-by-step reasoning.

Batch learning is too generic for this scenario and does not specifically describe the continued training of a foundation model from an existing checkpoint. Many training jobs process data in batches, but that alone does not address the requirement to keep the FM current with newly arriving text while preserving prior knowledge. The question is asking for a lifecycle strategy for updating a pretrained model, not merely a data ingestion style. In exam terms, batch learning is not the precise label for warm-started ongoing FM refreshes.

Static training means training the model once on a fixed dataset and then leaving the weights unchanged until a future full retraining cycle. That conflicts with the requirement to reflect breaking developments within 24 hours and to perform daily refreshes. A static model would quickly become outdated in a financial news setting where new events materially change the information landscape every day. It also does not align with the stated plan to warm-start from the latest checkpoint on a rolling corpus.

Latent training is not a standard training strategy term used for foundation model maintenance in AWS certification contexts or mainstream ML practice. Although the word 'latent' appears in discussions of latent representations or latent spaces, it does not describe a recognized method for incrementally updating an FM with new corpora. The option therefore does not match the operational pattern of daily checkpoint-based updates over a rolling dataset. It is essentially a distractor rather than a valid answer choice for this use case.

Incorrect. Mathematical vector representations are embeddings, not tokens. Embeddings are continuous-valued vectors used to represent meaning for tasks like semantic search or retrieval-augmented generation (RAG). Token counts used for billing refer to the number of discrete token IDs processed by the model, not the dimensionality or number of embedding vectors.

Incorrect. Pre-trained weights are the model parameters learned during training (often billions of parameters). They determine the model’s behavior and are not counted per request. Token billing is about runtime usage (how much text is processed/generated), whereas weights relate to the model’s size and training, not per-inference metering.

Incorrect. Prompts are the instructions and context you provide, but a prompt is composed of tokens after tokenization. Bedrock bills based on the number of tokens in the prompt (plus any included context/system messages) and the number of tokens in the generated completion. Tokens are the units inside the prompt, not the prompt itself.

Speech recognition converts audio to text (ASR) and is used for call transcription, voice assistants, and media captioning. The problem here involves structured request attributes (client IP and user agent) and detecting suspicious sources, not interpreting audio signals. Even if the platform is “video streaming,” the security requirement is about API traffic analysis, so speech recognition is not applicable.

NLP named entity recognition (NER) extracts entities (people, organizations, locations, etc.) from unstructured text. The inputs in this scenario are client IP addresses and user-agent strings used for request fingerprinting and behavioral analysis. While user-agent is a string, the task is not entity extraction; it is identifying deviations from normal traffic patterns. Therefore, NER is the wrong ML approach.

Fraud forecasting focuses on predicting future fraud rates or volumes over time (time-series forecasting), not evaluating each incoming request for abnormality relative to a learned baseline. The requirement is to score individual requests and flag unusual sources immediately, which is anomaly detection/classification. Forecasting could complement capacity planning or trend analysis, but it does not satisfy per-request, low-latency suspicious-source detection.

Customizing/fine-tuning a model can sometimes reduce the need for long few-shot prompts, but it adds extra cost and operational overhead (training, evaluation, and potentially higher ongoing charges). Given the model runs only once per day and quality is already satisfactory, fine-tuning is unlikely to be the most cost-effective way to reduce monthly spend while maintaining current performance.

Increasing the number of tokens in the prompt (for example, adding more examples or longer instructions) will increase input token usage and therefore increase cost. While it might improve quality in some cases, the question states output quality is already satisfactory and the goal is to lower monthly cost, making this the opposite of what is needed.

Provisioned Throughput on Amazon Bedrock is intended for workloads that need guaranteed capacity, predictable latency, and sustained throughput. For a single invocation per day, provisioned capacity would typically be more expensive than on-demand token-based usage. It does not reduce token charges and is not aligned with the low-frequency usage pattern described.

Native integration with Amazon S3 is useful for snapshots, backups, and data lifecycle patterns (e.g., storing index snapshots in S3). However, S3 is object storage and does not provide the low-latency, high-dimensional similarity search required for RAG. S3 integration helps durability and cost management, but it does not enable k-NN retrieval of embeddings within 100 ms.

Geospatial indexing and queries support location-based use cases such as finding points within a radius, bounding box searches, and geo-distance sorting. While it is a specialized indexing capability, it is unrelated to semantic similarity over 768-dimensional embedding vectors. Geospatial features won’t help retrieve the top 20 nearest embeddings for a RAG workload.

Real-time analysis on streaming data refers to ingesting and querying continuously arriving events (logs, metrics, clickstreams) with low indexing latency. Although OpenSearch is commonly used for near-real-time analytics, streaming support does not address the core requirement here: fast similarity search over high-dimensional embeddings. Vector retrieval performance depends on k-NN/ANN indexing, not streaming analytics.

Amazon EBS is block storage designed to be attached to an EC2 instance (or certain managed compute services) as a volume. It is not an object storage service and does not provide a direct “read from object storage” integration point for Bedrock evaluation. Using EBS would require provisioning compute to host and expose the data, adding unnecessary complexity and not meeting the stated requirement.

Amazon EFS is a managed network file system (NFS) used primarily with EC2, containers, and some AWS compute services that can mount file systems. While it can store files, it is not object storage and is not the standard direct input source for Bedrock evaluation datasets. It would also require a mounted environment and network configuration rather than a simple S3 object reference.

AWS Snowcone is a small edge device used for offline/edge compute and data transfer to AWS, typically when connectivity is limited or for rugged environments. It is not a regional object storage service that Bedrock can directly read from for an evaluation job. Snowcone might help move data into AWS, but the dataset would still ultimately need to land in S3 for direct Bedrock access.

Incorrect. Temperature controls randomness/creativity in generation, affecting determinism and sometimes indirectly influencing response length. However, Bedrock does not bill “per temperature setting.” Billing is metered by usage (primarily tokens). Even if temperature changes the style of output, the charge is still driven by how many tokens are generated and processed.

Incorrect. The scenario explicitly states no custom training or fine-tuning is performed. Training data volume would matter only if the solution included model customization (fine-tuning) or separate training workflows. For managed FM inference in Bedrock, you pay for inference usage (tokens), not for the provider’s original pre-training data.

Incorrect. Training time is irrelevant here because the model is not being trained by the customer. Bedrock provides managed foundation models where customers typically consume inference APIs. Charges based on training duration would apply to training jobs in services like Amazon SageMaker training or certain customization workflows, not standard Bedrock inference.

AWS Config is a service for assessing, auditing, and evaluating the configurations of AWS resources. It helps with compliance monitoring and governance, such as checking whether resources conform to desired rules or policies. It does not provide code generation, step-by-step development help, or PySpark authoring assistance for AWS Glue jobs. Therefore, it does not meet the requirement for guided ETL job creation.

Amazon Personalize is a managed machine learning service used to build recommendation systems and personalized user experiences. Its purpose is to generate recommendations based on user behavior and item metadata, not to help developers write ETL code or learn AWS Glue. Although ETL pipelines may prepare data for Personalize, the service itself does not provide development guidance for Glue. That makes it unrelated to the need described in the question.

Amazon Comprehend is a natural language processing service that extracts insights such as entities, sentiment, key phrases, and PII from text. It is useful for text analytics workloads, but it is not a developer assistant and does not help users build AWS Glue ETL jobs. It cannot provide step-by-step coding guidance or generate PySpark scripts for Glue. As a result, it does not satisfy the stated requirement.

Intrusion detection and anomaly flagging is a security analytics/ML classification use case, typically using services like Amazon GuardDuty, Amazon Detective, or custom anomaly detection. It focuses on identifying suspicious patterns, not generating new content. It also often relies on historical telemetry and baselines rather than prompt-driven creation, so it does not match the requirement to generate marketing assets from short text briefs.

Optimizing indexing strategies is a database engineering/performance tuning activity (e.g., Amazon RDS, Aurora, DynamoDB design patterns). It is not an AI/ML task and does not involve generating new content. While it can improve query latency and throughput, it does not address the requirement to create marketing assets from text briefs, so it is not a generative AI use case.

Forecasting financial time-series data is a predictive analytics/ML use case (e.g., Amazon Forecast or custom models in SageMaker). It produces predictions (future values) rather than creative assets like images. It also commonly benefits from historical labeled/structured time-series data. Therefore, it does not match the prompt-based, content-generation requirement described in the question.

Licensing a third-party enterprise SaaS with embedded GenAI places most security responsibilities on the SaaS provider (application security, model operations, patching, availability). The customer mainly manages identity/access, configuration, and data governance decisions (what data is uploaded, retention, user permissions). In the scoping matrix, this is typically the lowest customer ownership model.

Using a third-party FM via API increases customer responsibility compared to SaaS (you secure your app, prompts, connectors, and any stored outputs). However, the FM provider still owns core model training, model-layer security controls, and much of the inference platform. You must focus on secure integration, data minimization, encryption in transit, and preventing sensitive data leakage in prompts.

Fine-tuning a third-party FM shifts more responsibility to the customer than simple API usage because you manage training data preparation, privacy controls, and evaluation for harmful outputs. Still, the underlying base model and often the managed training/inference environment are controlled by the provider/service. Customer ownership is high, but not as high as building and training a model entirely from scratch.

Incorrect. Increasing temperature generally increases output variability, which can reduce reproducibility but does not reduce vulnerability. In many cases it can worsen safety by making the model more likely to produce unexpected or policy-violating content. Security controls should be deterministic and enforceable (guardrails, filtering, access control), not based on randomness.

Incorrect. Choosing models from SageMaker listings (or any catalog) does not inherently prevent prompt injection or jailbreaks. Prompt injection is largely an application-layer and interaction-pattern problem, not solely a model provenance problem. Even well-vetted models can be coerced without strong system instructions, guardrails, and data minimization.

Incorrect. Trimming user input to 200 tokens may slightly reduce the space for elaborate attacks, but many jailbreaks are short and still effective. It also degrades user experience and may break legitimate complex queries. Effective mitigation focuses on policy enforcement (system prompts/guardrails), output filtering, and preventing sensitive data from being available to the model.

AWS Audit Manager helps continuously collect evidence from AWS services and map it to compliance frameworks (e.g., HIPAA, SOC) to simplify audits. It is not a subscription platform for third-party ISVs to publish quarterly reports, and it does not natively provide a “new report published by an external vendor” notification workflow. It’s about assessing your AWS environment’s controls, not distributing partner content.

AWS Artifact provides on-demand access to AWS compliance reports (e.g., SOC reports, ISO certifications) and allows acceptance of certain agreements. It is limited to AWS-provided artifacts, not third-party medical device ISV reports. While Artifact is central to compliance documentation, it does not support subscribing to external data products or notifying you when an ISV publishes a new quarterly report.

AWS Trusted Advisor delivers best-practice recommendations and checks across cost optimization, performance, security, fault tolerance, and service limits. It can generate alerts for certain account-related findings, but it is unrelated to third-party data product subscriptions or publication events. Trusted Advisor won’t notify you when an external ISV publishes a compliance report; it focuses on your AWS account posture.

Amazon Inspector focuses on automated vulnerability management for workloads (e.g., EC2 instances, container images in ECR, and certain Lambda package scanning). It helps with security posture and finding CVEs, not ML transparency. Inspector does not compute fairness/bias metrics across demographic groups and does not generate per-inference feature attributions like SHAP, so it cannot satisfy regulator explainability requirements.

Amazon Macie discovers and classifies sensitive data (like PII) in Amazon S3 and helps with data security and privacy governance. While important for a bank’s compliance program, Macie does not provide model bias evaluation, fairness metrics, or prediction-level explainability. It addresses “what sensitive data exists and where,” not “why the model made this decision” or “whether outcomes are biased.”

Amazon Rekognition is a computer vision service for analyzing images and videos (labels, faces, text in images, custom labels). The use case here is loan underwriting using applicant text summaries and structured financial features, not image classification. Adding Rekognition labels does not produce bias metrics or SHAP explanations and does not meet the regulator’s audit-ready transparency requirements.

Incorrect. Retraining may reduce the probability of unsafe outputs but does not guarantee that explicit content will never appear, and it does not satisfy the requirement to block based on a 90% moderation confidence at inference time. It also violates the constraint “without retraining the base model.” In regulated or policy-driven environments, runtime enforcement is required even if the model is improved.

Incorrect. A one-time validation on a held-out test set is a pre-release quality step, not a runtime control. Generative systems can produce novel outputs depending on prompts and context, so pre-release testing cannot ensure ongoing compliance. It also does not implement the required threshold-based blocking and logging for each inference request.

Incorrect. Incorporating user feedback can help identify issues and improve future behavior, but it is reactive and non-deterministic. It does not prevent unsafe images from being displayed in the moment, and it does not guarantee blocking when confidence is ≥90%. Feedback mechanisms are complementary to, not a substitute for, automated inference-time moderation and governance logging.

Compute cost and runtime are operational metrics (efficiency), not predictive performance metrics (effectiveness). They help with budgeting, scaling, and latency/throughput planning, but they cannot confirm whether the model meets the required 92% top-1 accuracy. A model can be cheap and fast yet inaccurate, or expensive and slow yet accurate. This option does not evaluate correctness against labeled ground truth.

Counting layers or parameters describes model capacity/complexity, not actual accuracy on the task. Parameter count is sometimes correlated with capability, but it is not a substitute for empirical evaluation on a representative labeled benchmark. Two models with similar size can have very different accuracy due to training data, fine-tuning, preprocessing, or domain shift. This option fails to validate the 92% requirement.

Color fidelity checks can be useful for validating image preprocessing pipelines (e.g., ensuring no unintended transformations), but they do not measure classification accuracy against labeled categories. A model could receive perfectly color-accurate images and still misclassify them. The requirement is explicitly top-1 accuracy on a labeled benchmark, which must be computed from predictions versus ground truth labels.

AWS CloudTrail records AWS API calls and events for auditing, governance, and security investigations (for example, who launched an instance or changed an IAM policy). It is not intended for performance monitoring such as P95 latency, HTTP 5xx rates, or GPU/CPU utilization, and it does not provide metric-based alarming for application SLOs.

AWS Trusted Advisor provides periodic checks and recommendations across cost optimization, performance, security, fault tolerance, and service limits. While it can flag issues like approaching quotas or underutilized resources, it does not provide real-time, per-request latency percentiles, 5xx error monitoring, or container-level GPU/CPU telemetry with alerting.

AWS Config tracks configuration state and changes of AWS resources and evaluates them against compliance rules (for example, whether S3 buckets are public or security groups allow 0.0.0.0/0). It is not a metrics/observability service and cannot natively compute P95 latency, monitor 5xx error rates, or track runtime GPU/CPU utilization for containers.

Amazon Q Developer is a generative AI assistant focused on software development workflows (code generation, explanations, debugging, IDE integration, and AWS console assistance). It is not intended as a general managed service to access multiple third-party foundation models for building custom multilingual chatbots or content generators. It also does not represent the primary AWS service for serverless FM inference with configurable guardrails and RAG knowledge base integrations.

Amazon Kendra is an enterprise search service that indexes and retrieves information from multiple data sources using connectors and relevance tuning. While it can be used as part of a RAG architecture (retrieving documents to ground responses), it does not provide managed access to multiple foundation models for text generation. Kendra solves search and retrieval, not serverless multi-model FM inference with built-in guardrails.

Amazon Comprehend is a managed natural language processing service for tasks like entity recognition, key phrase extraction, sentiment analysis, topic modeling, and PII detection. It is not a foundation-model platform and does not provide generative capabilities for building chatbots or product-description generators. Comprehend may complement a solution (e.g., PII detection), but it does not meet the requirement for managed multi-provider FM access and RAG/guardrails.

Incorrect. Agents for Amazon Bedrock are used to orchestrate multi-step tasks at inference time (tool use, function calling, retrieval, and workflow execution). They do not “supervise the model’s training process,” and they do not directly reduce hallucinations by changing how the foundation model was trained. While agents can improve factuality by grounding responses with tools or knowledge bases, the option’s premise about training supervision is wrong.

Incorrect. Data pre-processing to remove problematic training examples implies you have access to and can modify the model’s training dataset, followed by retraining or fine-tuning. The question explicitly prohibits retraining and requires improvement within 24 hours. In managed foundation models on Bedrock, customers generally cannot edit the original training corpus. This approach is not feasible under the stated constraints.

Incorrect. Switching to a different foundation model could reduce hallucinations, but the question explicitly says the team cannot change the foundation model. Even if allowed, model switching often requires re-validation, prompt adjustments, and regression testing—unlikely to be the fastest compliant fix within 24 hours. The best answer must respect the constraint and use inference-time controls.