Amazon MLA-C01: Security, Governance and Compliance — Study Guide
Part of the AWS Machine Learning Engineer Associate MLA-C01 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
IAM roles, least privilege, and SageMaker execution contexts
Identity and access management for ML workloads requires explicit, auditable separation of privileges between human users, CI/CD systems, and runtime compute. For SageMaker this means defining a dedicated execution role (an IAM Role with an AssumeRolePolicyDocument that permits the SageMaker service principal sagemaker.amazonaws.com) and scoping that role’s permissions to the minimum set of actions needed: S3 GetObject/PutObject on specific prefixes, kms:Decrypt/kms:Encrypt on one or more customer-managed CMKs, logs:CreateLogStream and logs:PutLogEvents for specific LogGroup ARNs, and sts:AssumeRole only if cross-account access is required. Attach resource-level policy conditions (aws:SourceAccount and aws:SourceArn) so that artifacts created by a particular SageMaker job or pipeline cannot be exfiltrated by other principals. Use separate roles for training, model building, and hosting (RoleArn fields passed to CreateTrainingJob, CreateModel, CreateEndpointConfig) so runtime privileges are compartmentalized; store these role ARNs in code or pipelines as parameters rather than embedding credentials.
For ephemeral developer access and human approvals, prefer IAM roles assumed via AWS STS with short-lived credentials instead of long-lived IAM user keys. Enforcement of multi-person reviews and separation of duties is achieved by combining IAM permission boundaries, AWS Single Sign-On or an OIDC IdP, and resource-level controls on SageMaker Model Registry packages. Where workflows require temporary elevation (for example, to approve a model package), use an approval workflow in SageMaker Model Registry that sets ModelApprovalStatus to “PendingManualApproval” and require an IAM principal with a narrowly scoped sagemaker:ApproveModelPackage permission to flip it to “Approved”.
VPC isolation, network controls, and encryption
Network isolation begins by placing SageMaker training and inference instances inside VPC subnets with explicit VpcConfig (subnet IDs and security group IDs) supplied to CreateTrainingJob, CreateModel, CreateEndpointConfig, and CreateProcessingJob APIs. Combine this with VPC endpoints (Interface endpoints for com.amazonaws.region.sagemaker and com.amazonaws.region.s3 via AWS PrivateLink or Gateway endpoints for S3) so model artifacts and API traffic never traverse the public internet. Enable VPC Flow Logs for the subnet and use Security Group rules to restrict egress to only the addresses and ports required, for example to only the S3 VPC endpoint or to a NAT Gateway if external package downloads are allowed.
Encryption must be applied at rest and in transit. For data at rest, use S3 server-side encryption with AWS KMS (SSE-KMS) and safeguard keys with a customer-managed CMK that has key policies restricting admins and the SageMaker execution role (put the CMK ARN into OutputDataConfig.KmsKeyId or into S3 PutObject SSE-KMS headers for artifacts). For EBS volumes attached to training instances, specify volume encryption via ResourceConfig and ensure the EBS KMS key is set. For container-to-container traffic and network transfers, enable EnableInterContainerTrafficEncryption and EnableNetworkIsolation in CreateTrainingJob/CreateModel to force TLS for inter-container traffic and to block outbound internet access; in addition, all REST and SDK calls to SageMaker and S3 should leverage HTTPS/TLS by default. Rotate CMKs with EnableKeyRotation on the CMK and audit key usage with CloudTrail’s KMS events.
Audit logging, data events, and lineage tracking
A comprehensive audit trail combines management-plane logs and data-plane events. Use AWS CloudTrail to record all SageMaker and IAM API calls; enable data event logging in CloudTrail for S3 buckets (PutEventSelectors with DataResources pointing to the S3 ARN) to capture object-level reads/writes for training datasets and model artifacts. Send container logs and training job system logs to CloudWatch Logs by ensuring execution role permissions for logs:CreateLogStream and logs:PutLogEvents are present; retention policies and subscription filters can stream these logs to a central SIEM. For network-level auditing, enable VPC Flow Logs and for suspicious activity detection subscribe to GuardDuty findings and Amazon Macie for S3 sensitive-data discovery.
Lineage requires capturing artifact provenance across preprocessing, training, evaluation, and deployment. Use SageMaker Pipelines and SageMaker Experiments to create Experiment, Trial, and TrialComponent records automatically; these APIs record parameters, inputs, metrics, and the ModelPackage metadata. Persist metadata in a central metadata store: AWS Glue Data Catalog can serve as the dataset catalog and store table-level metadata and partitioning, while SageMaker’s metadata service links pipeline executions to model artifacts. For cross-account or multi-source ingestion, centralize connections with AWS Glue connections (JDBC for on-prem MySQL) or use AWS Database Migration Service (DMS) to replicate transactional data into S3/Redshift where Glue crawlers can index it, then reference the resulting Glue tables from pipelines to maintain an auditable lineage path.
Model governance: registry, model cards, and monitoring
SageMaker Model Registry (model package groups and ModelPackage objects) provides the canonical central model store with built-in lifecycle states and hooks for CI/CD. Register a trained model into a ModelPackageGroup and set the ModelApprovalStatus to “PendingManualApproval”; automation (CodePipeline, Step Functions) can pause for an authorized principal to call UpdateModelPackage with ModelApprovalStatus=“Approved”. Pair the registry with SageMaker Model Cards to document intended use, datasets, training hyperparameters, lineage references, performance metrics, fairness metrics from SageMaker Clarify, and compliance statements. Model Cards should be authored as structured metadata and stored alongside the ModelPackage so reviews, audit trails, and model cards remain co-located with the binary artifacts.
Operational monitoring is completed using SageMaker Model Monitor for data and model quality drift and SageMaker Clarify for bias and explainability. Enable DataCaptureConfig on CreateEndpoint to capture request and response payloads to a secure S3 prefix (with SSE-KMS), then configure Model Monitor baseline generation jobs (using baseline statistics and constraints) and schedule monitoring jobs or trigger on-demand analysis. For bias drift on deployed real-time endpoints, capture inference and ground-truth (when available), run Clarify bias jobs against the captured dataset, and store Clarify reports in S3 and Model Cards. Alerts and remediation can be tied to CloudWatch Alarms and Step Functions that implement rollback or quarantine patterns.
Design patterns, trade-offs, and common pitfalls
When centralizing multiple data sources, AWS Glue with its JDBC connectors plus AWS Lake Formation for fine-grained access control is the lowest operational overhead pattern; using DMS to replicate transactional sources into S3 gives better isolation for ML pipelines but increases operational complexity. For dataset access latency during repeated training jobs, streaming S3 input with Pipe mode or mounting a shared filesystem such as Amazon FSx for Lustre (exporting a POSIX namespace to training instances) reduces startup time compared with repeatedly copying large datasets into local EBS volumes. The trade-off is that FSx adds cost and management; Pipe mode is simpler but requires your training container to support streaming input (RecordIO, protobuf).
For class imbalance and categorical handling with minimal ops, leverage Data Wrangler or SageMaker Processing to produce consistent transforms and store feature data in SageMaker Feature Store so both offline training and online inference share the same transformation. For imbalance specifically, prefer algorithm-level remedies first (for XGBoost, set scale_pos_weight to num_negative/num_positive) before data-level resampling; algorithmic approaches avoid creating synthetic records and are operationally simpler for pipelines. For anomaly detection and dataset-quality checks, choose between purpose-built services and custom models: Amazon Lookout for Metrics offers automated anomaly detection and visualization with connectors to multiple sources, while SageMaker Random Cut Forest (built-in) integrates directly into pipelines and gives full control for custom thresholds and explainability.
Common pitfalls include over-broad IAM roles (excessive s3:* or kms:* permissions), failure to enable CloudTrail data events for S3 leading to blind spots when model artifacts are exfiltrated, not enabling VPC endpoints and thus unintentionally routing data over the public internet, and skipping Model Approval workflow resulting in unreviewed models being promoted. Another frequent error is storing plaintext sensitive data in S3 without SSE-KMS or not restricting KMS key policies to prevent key use by unauthorized principals.
Practical Problem: Use-Case Scenario
AcmeFin: fraud detection model for a financial web application. Data sources include transaction logs and customer profiles in S3 plus on-premises MySQL tables containing customer risk scores. The goals are secure, auditable pipelines, low training startup latency for frequent retraining, a manual approval gate for production deployment, on-demand bias/drift assessment for deployed endpoints, and automated anomaly detection and visualization of incoming data.
Ingest and centralize data: use AWS DMS to replicate on-prem MySQL into an S3 landing prefix under strict SSE-KMS encryption (bucket policy restricted to AcmeFin accounts). Register the S3 datasets and partitions with AWS Glue Data Catalog via Glue crawlers and enforce access through Lake Formation permissions. Rationale: DMS provides continuous replication for transactional tables, Glue Catalog centralizes metadata and enables lineage across ETL and training.
Secure compute and storage: create dedicated SageMaker execution roles with least privilege (RoleArn used in CreateTrainingJob) and trust policy allowing sagemaker.amazonaws.com; restrict role permissions to specific S3 prefixes and the customer-managed CMK. Put all training and inference into private subnets by supplying VpcConfig.Subnets and VpcConfig.SecurityGroupIds to CreateTrainingJob and CreateEndpointConfig, and create Interface endpoints for com.amazonaws.region.s3 and for the SageMaker API to avoid public internet egress. Rationale: VPC isolation plus VPC endpoints ensures artifacts never traverse public networks and roles with CMK restrictions prevent key misuse.
Minimize training startup latency: store large datasets on Amazon FSx for Lustre exported to the training subnet and use Pipe mode for smaller streaming inputs. Configure CreateTrainingJob with InputDataConfig pointing to the FSx-mounted dataset or S3 with Pipe mode, and reuse warm caches by keeping dataset pointers constant across jobs. Rationale: FSx provides POSIX access and avoids repeated S3 downloads; Pipe mode reduces copy latency for streaming-friendly containers.
Governance and manual approval: register models in SageMaker Model Registry on completion of training; set ModelApprovalStatus=“PendingManualApproval” for new ModelPackage objects. Implement an approval workflow using AWS CodePipeline/Step Functions that requires a principal with sagemaker:UpdateModelPackage permission to call UpdateModelPackage(ModelApprovalStatus=“Approved”) before the CreateEndpoint step runs. Rationale: Model Registry provides lifecycle states and an auditable approval action tied to IAM authorizations.
On-demand bias and drift checks: enable DataCaptureConfig on the endpoint to write requests and responses to an SSE-KMS encrypted S3 prefix. For on-demand bias analysis, run SageMaker Clarify batch jobs referencing captured data and the Model Card baseline; for continuous drift, schedule SageMaker Model Monitor jobs that compare live distributions against baseline statistics. Rationale: Data capture plus Clarify/Model Monitor provides both ad-hoc and scheduled assessments with results stored alongside model metadata.
Anomaly detection and visualization: connect captured metrics and feature time series to Amazon Lookout for Metrics for automated anomaly detection and notifications, and visualize results in Amazon QuickSight. Alternatively, run a Random Cut Forest training job in SageMaker and surface anomalies into a dashboard if custom thresholds are needed. Rationale: Lookout for Metrics reduces operational overhead for anomaly detection and integrates with multiple sources for rapid visualization.
This approach balances security (VPC, SSE-KMS, restricted IAM), governance (Model Registry, Model Cards, approval workflows), low-latency training (FSx + Pipe mode), and operational monitoring (DataCapture, Clarify, Model Monitor, Lookout for Metrics) while maintaining auditable lineage via Glue Catalog and SageMaker Experiments.
← Model Monitoring and Observability · All domains · Generative AI and Foundation Models →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →