Free MLS-C01 practice test

Converting to Parquet (Option C) enables columnar projection pushdown so Spark reads only the two needed columns from each file, drastically reducing I/O. Partitioning by event_date (Option F) enables partition pruning when queries filter by time range, which is the most common pattern for time-series IoT data. Option A (S3 Transfer Acceleration) speeds up uploads/downloads over the internet but does not reduce the amount of data scanned. Option E (partitioning by device_id) is a high-cardinality key that would create millions of tiny partitions, causing excessive metadata overhead and small-file problems without meaningful scan reduction. Option D (gzip compression) reduces bytes transferred but gzip is not splittable—Spark cannot read compressed blocks in parallel, which can worsen performance. Option B (larger master node) does not affect data scanning; the master node manages job coordination, not data reads.

A rising IteratorAgeMilliseconds metric indicates the consumer is falling behind the producer. Since each Kinesis shard supports up to 2 MB/s read throughput and a Glue streaming job's parallelism is governed by the number of DPUs, increasing DPUs adds more parallel workers that can read from shards concurrently, directly addressing consumer-side lag. — Resharding the stream to 40 shards would be needed only if write throughput (1 MB/s or 1,000 records/s per shard) were exceeded; 10 shards support up to 10,000 records/s write and 80,000 records/second at an assumed small record size likely fits within the shard write limit. The bottleneck here is described as the consumer job, not the stream capacity. — Enabling S3 multipart upload improves write performance to S3 but is not the primary bottleneck described; the metric points to the processing job falling behind the stream, not write latency. — Extending the retention period prevents records from expiring but does not address the root cause of consumer lag; it only buys more time before records are lost, not faster processing.

Amazon Kinesis Data Analytics (now Amazon Managed Service for Apache Flink) provides a fully managed Flink environment that natively supports stateful stream processing required for 7-day rolling window aggregations, stream-to-stream and stream-to-batch (S3 reference data) joins, and low-latency output. Writing to SageMaker Feature Store simultaneously populates the online store (backed by DynamoDB for low-latency reads) and offline store (backed by S3), meeting all requirements with no server management. AWS Glue Streaming ETL supports simple transformations but has limited support for complex stateful windowed aggregations like 7-day rolling counts and lacks native SageMaker Feature Store sink connectors, requiring custom code. Using Kinesis Firehose and daily batch Glue jobs converts the problem to batch processing, eliminating the ability to compute up-to-date rolling features and missing the low-latency online store update requirement. A self-managed Kafka cluster on EC2 with custom Kafka Streams logic has the highest operational overhead (cluster management, patching, scaling) and requires building custom integrations with Redis and Redshift.

Lake Formation supports fine-grained column-level access control directly on Data Catalog tables. By revoking SELECT permission on the 'customer_ssn' column for the Finance unit's principals, the team enforces the policy without duplicating data or maintaining separate ETL jobs. Option D creates data duplication and adds maintenance burden every time the schema changes. Option A (Glue ETL redaction job) also duplicates data and adds pipeline complexity; any schema change requires updating the job. Option B (S3 Block Public Access + bucket policy) operates at the S3 object level and cannot filter individual columns within a file—it is also unrelated to column-level security.

Dropping or carefully handling features with >40% missingness is standard EDA practice — high missingness often means the feature is unreliable or its imputation would introduce substantial noise; domain knowledge should guide whether to impute or discard. Dropping near-zero variance features is well-established — a feature where 99.5% of values are identical adds almost no discriminative signal and can even hurt model performance by adding noise. Converting free-text to TF-IDF vectors or dense embeddings (e.g., via pre-trained models) is the correct way to make unstructured text usable in structured ML models. Option D (one-hot encoding free text) is incorrect — free text cannot be meaningfully one-hot encoded character by character or word by word at scale without extreme dimensionality explosion. Option E is incorrect — imputing near-zero variance features with their mode will further reinforce the dominant value, not increase variance; these features should be removed. Option F is incorrect — SageMaker algorithms do not universally handle missing values automatically; algorithms like Linear Learner require complete input, and relying on automatic handling is not a substitute for proper EDA-based feature treatment.

AWS Glue DataBrew is a visual, no-code data preparation service that provides 250+ built-in transformations, automated data profiling, and the ability to define data quality rules (such as value range checks and regex pattern matching) — all without writing code. — SageMaker Data Wrangler also offers no-code transforms and quality reports but is specifically positioned within the SageMaker ML workflow and does not advertise 250+ transforms or the same breadth of data quality rule authoring as DataBrew. — SageMaker Processing with scikit-learn requires writing Python code, which contradicts the no-code requirement. — Athena with UDFs requires writing SQL and Lambda functions for UDFs, which is not a no-code solution.

A logarithmic transform compresses large values and expands small values, making a right-skewed distribution more symmetric — a standard technique for features like income or house prices. A Min-Max Scaler rescales the range but does not change the shape of the distribution; skewness remains. A Standard Scaler normalizes to zero mean and unit variance but also preserves the shape of the distribution without correcting skewness. Ordinal encoding is a categorical encoding technique and is not applicable to continuous numeric features.

Capping (winsorizing) at the 99th percentile is a standard robust outlier handling technique that retains all records while reducing the influence of extreme values — appropriate for a linear model sensitive to outliers. Replacing outlier values with the column median is another valid imputation strategy that substitutes implausible values with a robust central tendency estimate. Removing records where the value exceeds a clinical threshold is a reasonable domain-driven approach, but it risks data loss and is listed as option D here as a distractor because it is less universally preferred than imputation for a continuous medical feature when data is limited. One-hot encoding is for categorical variables; applying it to a continuous numeric feature like blood pressure is incorrect and would destroy the feature's numeric information. Increasing the learning rate is a hyperparameter tuning action that does not address the underlying data quality issue and would not make the model more robust to outliers.

B) Correct: One-hot encoding is the appropriate choice for a nominal categorical variable like US state abbreviations, where there is no meaningful ordinal relationship between states. K-Means uses Euclidean distance, so representing states as equidistant binary vectors avoids imposing a false ordering. A) Incorrect: Label/ordinal encoding assigns arbitrary integer values (e.g., Alabama=0, Wyoming=49), which would cause the distance-based K-Means algorithm to treat states numerically and incorrectly infer that Wyoming is '49 units away' from Alabama. C) Incorrect: Target encoding uses the target variable's mean, which is appropriate for supervised models but not for unsupervised clustering where there is no target variable. D) Incorrect: Binary encoding is a dimensionality-reducing alternative but still introduces a pseudo-ordinal structure (e.g., states sharing binary digit patterns), which can introduce misleading distances in K-Means.

Narrowing search ranges around top-performing configurations focuses the Bayesian optimizer on the most promising region of the hyperparameter space, improving efficiency when the plateau suggests the global region has been identified but not fully exploited. Enabling warm starting with 'IDENTICAL_DATA_AND_ALGORITHM' transfers the surrogate model's learned knowledge from previous tuning jobs to a new job, allowing Bayesian optimization to continue refining rather than starting from scratch. Switching to random search discards all the probabilistic knowledge Bayesian optimization has accumulated; random search is less efficient than Bayesian optimization after many trials. Adding more hyperparameters increases the dimensionality of the search space, making it harder (not easier) to find optima. Increasing parallel jobs only affects throughput/speed; it does not improve the quality of exploration and may actually reduce Bayesian optimization's effectiveness since parallel jobs cannot incorporate each other's results sequentially.

BlazingText in Word2Vec mode (unsupervised) generates high-quality word embeddings that can be used as features for downstream NLP tasks like NER. While BlazingText also has a supervised text classification mode, the Word2Vec mode produces word-level vector representations as explicitly requested. Sequence-to-Sequence is designed for sequence transformation tasks like machine translation and text summarization, not for producing word embeddings or performing NER. Neural Topic Model (NTM) is a topic modeling algorithm that discovers abstract topics in a document corpus; it does not produce word-level embeddings suitable for NER. Latent Dirichlet Allocation (LDA) is also a topic modeling algorithm focused on document-level topic distributions, not word-level representations for sequence labeling tasks.

SageMaker Clarify provides explainability analysis using SHAP (SHapley Additive exPlanations) values, which quantify the contribution of each feature to a model's prediction. This directly addresses the need to understand which parts of the input are driving outputs. SageMaker Model Monitor detects data drift and model quality degradation in deployed models; it does not generate feature attributions for individual predictions. SageMaker Experiments tracks and compares training runs (metrics, parameters, artifacts) but does not perform explainability analysis. SageMaker Debugger monitors training jobs for issues like vanishing gradients or overfitting via built-in rules, but it does not produce post-training SHAP-based feature importance for predictions.

Normalizing features ensures that features on different scales contribute equally to distance calculations, preventing high-magnitude features from dominating cluster assignments. Using kmeans++ initialization selects initial centroids that are spread far apart, dramatically reducing the chance of poor initialization that leads to degenerate (very small or very large) clusters. — Simply increasing K adds more clusters but does not fix underlying imbalance caused by feature scale differences or poor initialization. — mini_batch_size affects the speed of the web-scale K-Means algorithm but is not a primary driver of cluster quality imbalance. — L1 regularization is a technique for supervised learning and has no meaning in the unsupervised K-Means context.

Random Cut Forest (RCF) is SageMaker's purpose-built unsupervised anomaly detection algorithm. It assigns an anomaly score to each data point based on how much the tree structure changes when the point is added, making it ideal for detecting outliers without labeled data. — XGBoost requires labeled data for supervised binary classification, which is not available here. — Linear Learner also requires labeled data and is a supervised algorithm. — K-Means is an unsupervised clustering algorithm that groups data into clusters but does not inherently produce anomaly scores or identify individual anomalous records.

Setting use_pretrained_model to 1 is correct. The SageMaker built-in Image Classification algorithm supports transfer learning via the 'use_pretrained_model' hyperparameter. When set to 1, the algorithm initializes the network with ImageNet pre-trained weights and fine-tunes it on the provided dataset — ideal for small labeled datasets. Option D is incorrect: 'transfer_learning_mode' is not a valid hyperparameter in the SageMaker Image Classification algorithm; this is a fabricated option. Option C is incorrect: 'augmentation_type' controls data augmentation (e.g., flipping, cropping) and helps with regularization, but it does not enable transfer learning with pre-trained weights. Option A is incorrect: Specifying num_layers=50 and optimizer=sgd simply configures the architecture and optimizer but does not activate pre-trained weight initialization.

When a model is too large to fit in the memory of a single GPU, model parallelism is required. The SageMaker Model Parallel (SMP) library partitions the model's layers (and optionally tensors) across multiple GPUs so that each GPU holds only a shard of the model, enabling training of models with billions of parameters. Option D is incorrect because data parallelism requires each GPU to maintain a full copy of the model; with 10 billion parameters this would cause an out-of-memory error on each GPU — SageMaker does not automatically shard the model when only data parallelism is enabled. Option C conflates SageMaker Pipelines (an MLOps workflow orchestration service) with pipeline model parallelism; SageMaker Pipelines is not used to split model layers across instances for distributed deep learning. Option A is incorrect; EC2 Spot Instances do not provide fundamentally different (higher-memory) GPU hardware compared to On-Demand — they use the same instance types at a lower cost; a single GPU on any instance type cannot hold a 10 billion parameter model in full precision.

Retraining on only recent post-pandemic data is correct because when the underlying data distribution has permanently shifted (concept drift), training on historical pre-pandemic data would introduce noise and bias — the model needs to learn from data representative of the new regime. Re-evaluating and re-engineering features is correct because a fundamental change in consumer behavior may mean existing features no longer have predictive power; feature engineering aligned with new patterns is a necessary part of adapting to concept drift. Establishing a new Model Monitor baseline is correct because the original baseline reflects the old data distribution — monitoring against a stale baseline will generate irrelevant alerts or miss new issues; a fresh baseline from recent data is required for meaningful ongoing monitoring. Increasing auto scaling capacity is wrong because the problem is model accuracy (concept drift), not insufficient compute capacity — adding more instances will not improve predictions. Scheduling retraining every 24 hours on all historical data is wrong because including pre-pandemic data dilutes the training signal from the new distribution and does not address concept drift; it would perpetuate the problem. Switching to a multi-model endpoint for both old and new versions is wrong because the old model is known to be inaccurate under the new distribution — hosting it alongside the new model adds no value and could confuse A/B testing results.

Data Quality Monitor is correct because it compares the statistical properties (distributions, missing values, data types) of live inference input data against a baseline computed from training data, which is exactly the scenario described. Model Quality Monitor is wrong because it measures prediction quality metrics (e.g., accuracy, F1) against ground-truth labels — it requires actual labels to be available after inference. Bias Drift Monitor is wrong because it tracks changes in bias metrics (e.g., disparate impact across demographic groups), not general feature distribution shift. Feature Attribution Drift Monitor is wrong because it uses SHAP values to detect changes in feature importance over time, not raw feature distribution statistics.

Enable VPC configuration (SubnetIds and SecurityGroupIds) is correct because placing the training job inside a VPC with no internet gateway routes ensures training instances cannot reach the internet, and when combined with an S3 VPC endpoint, S3 traffic stays within the AWS network and is encrypted in transit via HTTPS. EnableInterContainerTrafficEncryption is correct because it explicitly encrypts the inter-node communication channel between distributed training instances, satisfying the third requirement. EnableNetworkIsolation is wrong because while it prevents outbound network access, it also blocks the training container from reaching S3, which means training data cannot be fetched — VPC configuration is the correct mechanism for internet isolation while retaining S3 access via VPC endpoints. Configuring an S3 VPC endpoint and enabling SSE on S3 alone is wrong because it addresses data-at-rest encryption and S3 routing but does not prevent internet access from the training instances by itself — VPC configuration is still required. Attaching an IAM policy that denies outbound internet access is wrong because IAM controls API-level permissions, not network-level traffic; it cannot enforce network isolation for training instance traffic.

Multi-model endpoint (MME) is correct because it is specifically designed to host hundreds to thousands of models on a shared set of instances, dynamically loading and unloading models into memory on demand. This dramatically reduces cost and management overhead when models share the same framework. Deploying 200 separate endpoints is wrong because it multiplies infrastructure costs and operational complexity with no benefit over MME. Multi-container endpoints are wrong because they are designed to host a small number of different containers (up to 15) in a sequential or ensemble pipeline on a single endpoint, not for hosting hundreds of independent models. Serverless inference with one function per model is wrong because deploying 200 separate serverless endpoints still creates 200 separate resources, and serverless inference does not natively support multi-model hosting at this scale.