Securing AI Systems

Security foundations: shared responsibility, IAM, KMS

The most common exam trap in Domain 5 is the belief that "it's managed, so AWS secures my data and access for me." It does not, and that one misread sinks more security questions than any other. Securing an AI system on AWS is not one product you turn on. It is a layered discipline, and every layer answers a different question. Before any AI-specific control, three foundations apply to every workload: who owns which part of security, who is allowed to act, and is the data encrypted.

The AWS shared responsibility model: know where the line is. Under the AWS shared responsibility model^[1], AWS is responsible for security OF the cloud: the physical data centers, the hypervisor, the hardware, and the managed AI services themselves such as Amazon Bedrock and Amazon SageMaker AI. You, the customer, are responsible for security IN the cloud: your IAM permissions, the data you classify and encrypt, the prompts and fine-tuning datasets you supply, and your network configuration. For a managed model service this split is concrete: AWS keeps Bedrock patched, isolated, and operationally secure, but it does not decide who in your organization may call the model, nor does it classify or protect the data you choose to send it. The single most common exam trap in Domain 5 is assuming "it's managed, so AWS secures my data and access for me." It does not. That side of the line is always yours. The figure below lays the two halves side by side: AWS owns security OF the cloud on the left, you own security IN the cloud on the right. The blueprint lists the shared responsibility model itself as an in-scope security concept, so expect a question that hinges on placing a specific task on the correct side of the boundary.

AWS IAM and least privilege: the access foundation. AWS Identity and Access Management (IAM)^[2] controls who can do what through identities (users, roles^[3]) and the policies attached to them. The governing principle is least privilege^[4]: grant each identity only the specific permissions it genuinely needs, and nothing more. Applied to AI, an application role might be allowed to invoke one particular Amazon Bedrock model but be denied the ability to read the raw training data in Amazon S3, or denied access to a different, higher-cost model. Prefer IAM roles (temporary, automatically-rotated credentials assumed by a service or application) over long-lived access keys embedded in code. Least privilege limits the blast radius: if a credential leaks or an application is compromised, the attacker inherits only that one narrow permission set rather than broad access to your models and data.

AWS KMS encryption: the data-protection foundation. AWS Key Management Service (AWS KMS)^[5] creates and controls the cryptographic keys that encrypt your data, and it integrates with the storage and AI services so encryption is enforced consistently. Two ideas you must keep separate on the exam: encryption at rest protects stored data (model artifacts, training datasets, S3 objects) while encryption in transit (TLS) protects data moving over the network. For Amazon S3, server-side encryption with S3-managed keys (SSE-S3) is the default applied to all new objects^[6], and you can step up to customer-managed KMS keys (SSE-KMS)^[7] when you need control over key policy, rotation, and access auditing. Crucially, encryption and access control are not substitutes: KMS protects the bytes at rest, but it is the key policy plus IAM that decides who is allowed to decrypt them. A bucket can be perfectly encrypted and still be exposed if the permissions are wrong. Amazon Bedrock follows the same posture: it encrypts data at rest and in transit^[8] and lets you supply your own KMS keys for resources such as custom models and fine-tuning jobs.

AWS shared responsibility model: AWS secures OF the cloud (infrastructure, managed AI services); you secure IN the cloud (IAM, encryption, data, network).

Data & network security across the ML lifecycle

AI security risk does not live at a single point: it spans the whole pipeline: collecting data, training or fine-tuning on it, storing it, and serving inference. Protection has to follow the data the entire way, and AWS supplies a specific control for each stage. The figure below maps the four canonical ML lifecycle stages to the AWS control that guards each one. The blueprint groups these under "identify AWS services to secure AI systems," "secure data engineering," and "security and privacy considerations."

Discover sensitive data before it enters the pipeline: Amazon Macie. Amazon Macie^[9] is a managed data-security service that uses machine learning and pattern matching to automatically discover and classify sensitive data (such as personally identifiable information (PII), financial data, and credentials) in Amazon S3. The exam-relevant use case is finding PII in source or training data before it is used to train or fine-tune a model, so you do not unknowingly bake personal data into a model or a derived dataset. A precise distinction to remember: Macie classifies and flags; it does not remediate. It tells you where the sensitive data is, but it will not move, delete, redact, or encrypt it for you. You act on its findings with other controls (IAM, KMS, deletion, masking). Treating Macie as if it cleans the data for you is a classic distractor.

Keep traffic off the public internet: Amazon VPC and AWS PrivateLink. Network isolation shrinks the attack surface. AWS PrivateLink^[10] provides private connectivity between your Amazon VPC and AWS services through interface VPC endpoints, so traffic to a service such as Amazon Bedrock stays on the AWS private network^[11] and never traverses the public internet. For sensitive AI workloads (confidential prompts, regulated training data) this means model calls are not exposed to the open internet at all. When a stem says "keep model traffic private," "do not go over the public internet," or "connect privately to Bedrock," the answer is VPC + PrivateLink (interface endpoints).

Audit who did what: AWS CloudTrail (with CloudWatch). You cannot secure what you cannot see. AWS CloudTrail^[12] records account API activity as an event history (including model-invocation API calls) answering who invoked which model, when, and from where, which is exactly the audit trail required for threat detection, compliance, and incident investigation. Amazon CloudWatch complements it by capturing operational logs and metrics for monitoring and alerting. The mental shortcut: CloudTrail = the API action trail (an audit/forensic record); CloudWatch = operational logs, metrics, and alarms.

Document data origin: lineage, cataloging, and Model Cards. Source citation and documenting data origins are explicit Task 5.1 objectives. Data lineage records where a dataset came from and how it was transformed along the way; data cataloging keeps a central registry of datasets and their metadata so their origin is discoverable. The AWS Glue Data Catalog^[13] is the AWS service for this. For the model itself, Amazon SageMaker Model Cards^[14] document a model's intended use, training data, evaluation results, and risk considerations in one auditable record, the standard answer when a question asks how to document a model's details and provenance.

Secure data engineering: quality, privacy, access, integrity. The blueprint calls out four best practices, and they are as much a security concern as a quality one. Assess data quality: poisoned, mislabeled, or low-quality training data is itself a security and reliability risk, because a model is only as trustworthy as the data it learned from. Implement privacy-enhancing technologies: anonymize, pseudonymize, mask, or tokenize PII so models train on the signal without exposing individuals. Enforce data access control: scope IAM and key policies so only authorized identities and pipelines can read each dataset. Protect data integrity: ensure data is not tampered with in transit or at rest, backed by encryption and the audit trail above. Together these protect data across collection, storage, training, and inference rather than at a single checkpoint.

Application-layer safety: Amazon Bedrock Guardrails. Amazon Bedrock Guardrails^[15] is a configurable control that filters harmful content and can detect and redact sensitive information (including PII) in model inputs and outputs, and block disallowed topics. It is the application-layer complement to the infrastructure controls above. Be careful with the boundary the overview draws: filtering prompt/response content with Guardrails is not the same as infrastructure security (IAM, KMS, network isolation), and defending specifically against prompt injection and jailbreaking is treated as a prompt-engineering concern (Task 3.2), not part of system/data/network hardening.

AWS controls mapped to the four ML lifecycle stages: Macie at collection, KMS/TLS for training and storage, VPC+PrivateLink at inference; IAM and CloudTrail span all stages.

Exam-pattern recognition: concern → control, and the traps

Task 5.1 questions are almost always a security concern dressed as a scenario. Read the concern keyword in the stem and let it select the service; the distractors are nearly always the right tool for a different concern. Below are the high-frequency mappings, then the traps that catch people.

Concern → AWS control (the core mapping):

"Control who can invoke the model / access the data," "grant only the permissions needed," "least privilege," "give an app temporary credentials" → AWS IAM (roles and policies).
"Encrypt data at rest," "protect model artifacts / training data on disk," "manage and rotate encryption keys," "customer-managed keys" → AWS KMS (with S3, SageMaker AI, Bedrock). "Protect data in transit" → TLS / encryption in transit.
"Find / discover / classify PII or sensitive data in S3 before training" → Amazon Macie.
"Keep model traffic off the public internet," "connect privately to Bedrock," "private connectivity from my VPC" → Amazon VPC + AWS PrivateLink (interface endpoints).
"Record who invoked the model / API, when, and from where," "audit trail," "investigate an incident" → AWS CloudTrail (CloudWatch for operational logs/metrics).
"Filter harmful content, block topics, redact sensitive info in prompts/responses" → Amazon Bedrock Guardrails.
"Document where the data came from / how it was transformed" → data lineage + cataloging (AWS Glue Data Catalog); "document the model's intended use, training data, and risks" → Amazon SageMaker Model Cards.

Distractor traps to recognize:

"AWS secures my data and access automatically because it's managed." False. The shared responsibility model puts data classification, encryption choices, IAM, and network config on you. Any option implying AWS handles your in-the-cloud security for you is wrong.
Encryption ≠ access control. If the scenario is "who is allowed to read this," the answer is IAM / key policy, not "encrypt it with KMS." KMS protects the bytes; it does not decide who may decrypt them. Watch for a stem that is solved by encryption and a stem solved by access control. They are different answers.
Macie discovers, it does not remediate. If the requirement is to move, delete, mask, or encrypt the sensitive data, Macie alone is not the answer. It only finds and classifies; you act on its findings with other services.
CloudTrail vs CloudWatch. "Who made which API call" → CloudTrail (the action/audit trail). "Operational logs, metrics, alarms, dashboards" → CloudWatch. Mixing these is a frequent trap.
Securing the system (Task 5.1) vs proving compliance (Task 5.2). IAM, KMS, PrivateLink, and Macie harden the system; AWS Audit Manager, AWS Artifact, AWS Config, and AWS Trusted Advisor evidence governance and compliance. If the ask is "download AWS's SOC 2 report" or "map my workload to a compliance framework," that is the governance task, not securing. Do not reach for the security tools.
Prompt injection / jailbreaking is not infrastructure security. Those are prompt-engineering risks (Task 3.2). On a 5.1 question, the infrastructure-security answer is IAM / KMS / network isolation / Guardrails for content filtering, not a prompt-design fix.
Network isolation vs encryption. "Don't traverse the public internet" → PrivateLink/VPC (a network control). "Protect the data itself" → KMS/TLS (an encryption control). A scenario emphasizing connectivity wants the network answer, not the crypto answer.

AWS security controls for AI systems by concern

Security concern	AWS service or control	Purpose
Access	AWS IAM roles and policies	Grant least-privilege permissions so identities can only perform the actions they need
Encryption	AWS KMS (with S3, SageMaker AI)	Encrypt data and model artifacts at rest; TLS protects data in transit
Network isolation	Amazon VPC with AWS PrivateLink	Keep service traffic on the AWS private network, off the public internet
Sensitive-data discovery	Amazon Macie	Automatically find and classify PII and other sensitive data in Amazon S3
Auditing	AWS CloudTrail and Amazon CloudWatch	Record API calls (who invoked the model) and operational logs for investigation

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Shared responsibility splits AI security between AWS and you

The AWS shared responsibility model makes AWS responsible for security of the cloud (physical infrastructure, the hypervisor, and the managed AI services such as Amazon Bedrock and Amazon SageMaker AI themselves) while you are responsible for security in the cloud: IAM permissions, data classification and encryption, the prompts and fine-tuning datasets you supply, and network configuration. AWS does not decide who may call your model or protect the content you send it; that side of the line is always yours.

Trap Assuming AWS secures your data and access because the AI service is fully managed. Managed covers the infrastructure, not your in-the-cloud configuration.

2 questions test this

A managed AI service still leaves your data and access to you

A managed service like Amazon Bedrock being patched, isolated, and operated by AWS does not make your data or access secure on its own. Classifying data, choosing encryption, scoping IAM, and configuring network access all stay on the customer side of the shared responsibility line. "Fully managed" describes who runs the infrastructure, not who controls who can reach your data, which is a recurring Domain 5 distractor.

Trap Picking "fully managed, so no extra security configuration is needed" for a Bedrock workload, when IAM scoping and network controls are still the customer's job.

Scope IAM to least privilege for AI workloads

AWS Identity and Access Management (IAM) controls who can do what through identities and policies, and least privilege means granting each identity only the permissions it genuinely needs. For example, an application role allowed to invoke one specific Amazon Bedrock model but denied access to the raw training data in Amazon S3. AWS frames this as "grant only the permissions required to perform a task," which limits the blast radius if a credential leaks.

Trap Attaching a broad managed policy like a full-access policy to a model-invocation role because it is convenient, instead of narrowing to the specific action and resource.

9 questions test this

Give workloads temporary credentials via IAM roles, not access keys

AWS recommends that workloads use temporary credentials with IAM roles rather than long-lived access keys embedded in code: a role supplies short-term, automatically rotated credentials that a service or application assumes, so there is no static secret to leak. When a scenario asks how to let an application call a model with temporary credentials, the answer is an IAM role; long-term access keys are reserved for the narrow cases that genuinely cannot use a role.

Trap Hard-coding an IAM user's long-lived access key in the application to call the model, when an assumed IAM role would supply rotating temporary credentials instead.

8 questions test this

Use AWS KMS to encrypt data and model artifacts at rest

AWS Key Management Service (AWS KMS) creates and controls the cryptographic keys that encrypt data at rest (Amazon S3 objects, training datasets, and model artifacts) and integrates with services such as Amazon S3, Amazon SageMaker AI, and Amazon Bedrock so encryption is applied consistently. When a stem asks how to protect data or model artifacts on disk, manage and rotate keys, or use customer-managed keys, the answer is AWS KMS.

Trap Reaching for AWS KMS to protect data while it travels between client and service, when KMS encrypts data at rest and TLS is what protects data in transit.

5 questions test this

Encryption in transit protects data on the wire with TLS

Encryption at rest and encryption in transit are distinct controls: at-rest encryption (AWS KMS) protects stored bytes, while in-transit encryption protects data moving over the network using TLS (AWS requires TLS 1.2 and recommends TLS 1.3). A scenario about protecting data as it travels between client and service wants the in-transit / TLS answer, not at-rest key management.

Trap Choosing AWS KMS key management for a requirement about protecting data as it moves over the network, when in-transit protection comes from TLS.

4 questions test this

Encryption protects bytes; IAM and key policy decide access

Encrypting data with AWS KMS protects the bytes at rest but does not by itself decide who may decrypt them. That is governed by the KMS key policy together with IAM, which AWS describes as "ensuring that only trusted users have access to KMS keys." A bucket can be fully encrypted and still exposed if permissions are wrong, so a "who is allowed to read this" requirement is solved by IAM and key policy, not by adding more encryption.

Trap Adding encryption to a bucket to fix an over-permissive access problem, when the exposure comes from IAM and bucket/key policy rather than from unencrypted data.

S3 encrypts every new object by default with SSE-S3

Amazon S3 applies server-side encryption with S3-managed keys (SSE-S3) as the base level of encryption for every bucket, so all new object uploads are encrypted at rest automatically, at no cost and with no configuration. Step up to server-side encryption with customer-managed KMS keys (SSE-KMS) when you need control over key policy, rotation, and access auditing.

Trap Claiming S3 training data sits unencrypted until you turn encryption on. SSE-S3 is the automatic default for all new objects.

Bedrock encrypts at rest and in transit, and accepts your KMS keys

Amazon Bedrock encrypts data both at rest and in transit, and lets you supply your own AWS KMS keys for resources such as model customization (fine-tuning) jobs, the resulting custom models, agents, and knowledge-base ingestion jobs. This reflects the shared responsibility split: AWS provides the encryption capability, while choosing and managing customer-managed keys remains your option.

Trap Assuming Bedrock data is unencrypted unless you configure your own KMS keys, when Bedrock encrypts at rest and in transit by default and customer-managed keys are an added option.

Use Amazon Macie to discover PII in S3 before training

Amazon Macie is a managed data-security service that uses machine learning and pattern matching to automatically discover and classify sensitive data (PII, financial information, and credentials) in Amazon S3. Its exam use case is finding sensitive data such as PII in source or training data before that data is used to train or fine-tune a model.

Trap Reaching for Amazon Comprehend to scan S3 datasets for sensitive data, when Macie is the service that discovers and classifies PII directly in S3.

7 questions test this

Macie reports findings but does not remediate the data

Amazon Macie flags and classifies sensitive data and generates findings, but it does not move, delete, redact, or encrypt the data for you. AWS frames the findings as something to "review and remediate as necessary." If the requirement is to remediate (mask, delete, or encrypt), Macie alone is not the answer; you act on its findings with other controls such as IAM, KMS, or downstream automation via EventBridge.

Trap Choosing Macie to automatically mask or delete the PII it finds. Macie only detects and reports, leaving remediation to other controls.

Use VPC interface endpoints with PrivateLink to keep traffic private

An Amazon VPC interface endpoint with AWS PrivateLink establishes a private connection to a service such as Amazon Bedrock, so model traffic stays on the AWS private network and your data "isn't available over the internet." When a stem asks how to connect privately to Bedrock or keep model traffic off the public internet, the answer is a VPC interface endpoint via PrivateLink.

Trap Selecting a public endpoint secured with TLS to keep Bedrock traffic off the internet, when only a VPC interface endpoint with PrivateLink keeps the traffic on the AWS private network.

14 questions test this

Data lineage and cataloging document where data came from

Documenting data origins is a secure-AI governance practice: data lineage records where a dataset came from and how it was transformed across the pipeline, while a data catalog keeps a central, searchable registry of datasets and their metadata so their origin and ownership are discoverable. Together they establish provenance across the ML lifecycle rather than capturing it at a single checkpoint.

2 questions test this

SageMaker Model Cards document a model's provenance and risk

Amazon SageMaker Model Cards document a model's intended use, training details and metrics, evaluation results and observations, and a risk rating (Unknown, Low, Medium, or High) in a single record, and any edit other than an approval-status change creates a new version for an immutable audit trail. When a question asks how to document a model's details, provenance, and risk for governance, Model Cards is the standard answer.

Trap Reaching for an AWS AI Service Card to document a model you built. Service Cards are authored by AWS for AWS-managed services you consume, while you write a Model Card for your own model.

15 questions test this

Secure data engineering applies controls across the lifecycle

Secure data engineering bundles several best practices (assess data quality, apply privacy-enhancing technologies, enforce data access control, and protect data integrity) so that data is safeguarded across collection, storage, training, and inference rather than only at one stage. Treat it as a lifecycle discipline, not a single gate at ingestion.

Poor data quality is a security risk, not just a reliability one

Assessing data quality is a security concern as well as a reliability one: poisoned, mislabeled, or low-quality training data undermines a model because it is only as trustworthy as the data it learned from, and tampered data is an integrity attack. Protecting data integrity ensures data is not altered in transit or at rest, closing the gap that data-poisoning relies on.

Trap Treating data poisoning as solved by encrypting the dataset, when encryption protects confidentiality but it is integrity checks and data-quality assessment that catch tampered or poisoned training data.

Use privacy-enhancing technologies to train without exposing PII

Privacy-enhancing technologies (anonymization, pseudonymization, masking, and tokenization of PII) let a model train on the useful signal while individuals stay unidentifiable. Apply them as a secure-data-engineering step before sensitive data enters or moves through the training pipeline, rather than trying to scrub a trained model after the fact.

Trap Planning to remove PII from the model after training, when privacy-enhancing technologies have to be applied to the data before it enters the training pipeline.

Bedrock Guardrails is the application-layer safety control

Amazon Bedrock Guardrails filters harmful content, blocks denied topics, and can detect and block or mask sensitive information including PII in both the user's input prompt and the model's response. It is the application-layer complement to infrastructure controls such as IAM, KMS, and network isolation. It governs what the model is asked and what it returns, not who can reach the service, so it works alongside those controls, not as a substitute.

Trap Treating Guardrails as a replacement for IAM and network isolation. It filters prompts and responses but does not control who can invoke the model.

2 questions test this

Use Secrets Manager to keep credentials out of code

AWS Secrets Manager stores, manages, and rotates secrets such as database credentials, API keys, and OAuth tokens, so applications and notebooks retrieve them at runtime instead of hard-coding them in source. AWS positions it as the way to "replace hard-coded credentials with a runtime call," supporting the least-privilege and infrastructure-protection goals of securing an AI system. For your AWS encryption keys use KMS, and for AWS access prefer IAM roles. Secrets Manager is for the other credentials your app must hold.

Trap Storing AWS access keys in Secrets Manager so an application can call a model, when an assumed IAM role removes the static AWS credential entirely.

Use GuardDuty to detect threats against your AWS workloads

Amazon GuardDuty is a managed threat-detection service that continuously analyzes foundational sources (AWS CloudTrail management events, VPC flow logs, and DNS logs) with machine learning and threat intelligence to flag suspicious activity such as compromised or exfiltrated credentials and anomalous API calls, including against generative-AI workloads. It is the automated detection layer for these scenarios, generating findings with no manual log analysis required, and it pairs with services like Amazon Detective for investigation.

Trap Reaching for Amazon Macie to catch a compromised-credential or anomalous-API-access threat. Macie classifies sensitive data in S3, whereas GuardDuty is the threat detector.

9 questions test this

Security foundations: shared responsibility, IAM, KMS

Data & network security across the ML lifecycle

Exam-pattern recognition: concern → control, and the traps

AWS security controls for AI systems by concern

Decision tree

Cheat sheet

Also tested in

References