๐Ÿ”ด Domain 3 โ€” AI Safety, Security & Governance

Subdomains 3.1โ€“3.4 ยท You scored 0% on ALL subdomains in Set 1 โ€” highest priority domain

3.1 โ€” Input & Output Safety Controls (Guardrails)

Guardrails Component Map โ€” Know What Each Part Does

ComponentWhat It CatchesKey Exam Trigger
Content filtersHarmful content: violence, hate speech, sexual content, insults โ€” by category and severity level"Block toxic or offensive AI responses"
Denied topicsSpecific off-topic subjects you define (e.g., competitors, cryptocurrencies, politics)"Prevent discussion of [specific topic]"
Word filtersSpecific words or phrases you blocklist"Block profanity" or custom forbidden terms
Sensitive info / PIICredit cards, SSNs, phone numbers, emails โ€” detect and/or redact in I/O"Prevent PII exposure in AI responses"
Contextual groundingHallucinations โ€” responses not supported by retrieved context"Ensure RAG responses are grounded in retrieved docs"
Prompt attack filterPrompt injection, jailbreaks, instruction override attempts"Prevent users from overriding the system prompt" or "SQL injection via prompt"
The most common trap: using "denied topics" to block injection attacks. Denied topics = content restrictions (what the model talks about). Prompt attack filter = security (preventing manipulation of the model). These are completely different things.

Guardrails Monitoring โ€” The Right Metric Dimension

To monitor which guardrail policies are triggering, use the InvocationsIntervened metric filtered by the GuardrailPolicyType dimension.
GuardrailPolicyType dimension values: ContentPolicy ยท TopicPolicy ยท SensitiveInformationPolicy ยท WordPolicy ยท GroundingPolicy
GuardrailContentSource = filters by whether the intervention was on INPUT or OUTPUT โ€” a different dimension. The exam will swap these two dimensions on you.
Always enable tracing first: set {"trace": "enabled"} in guardrailConfig on your API call. Without this, you get no per-policy intervention details.

Enforcing Guardrails โ€” IAM Condition Key (Not Lambda Proxy)

To enforce that ALL calls to Bedrock use a specific guardrail, add this IAM condition to the policies of every role that accesses Bedrock:
bedrock:GuardrailIdentifier condition key on InvokeModel and Converse API actions. This makes it impossible for any caller to skip the guardrail.
Lambda proxy approach (all Bedrock calls go through a validation Lambda) adds latency, creates a single point of failure, and still requires additional enforcement to prevent direct Bedrock access. IAM conditions enforce at the API level โ€” no bypass possible.
Scenario: "ensure ALL FM interactions are secured with guardrails, no exceptions" โ†’ IAM condition key bedrock:GuardrailIdentifier applied to all roles accessing Bedrock.

Guardrails for Non-Bedrock Models (SageMaker)

Even if your FM is deployed on SageMaker (not Bedrock), you can still apply Bedrock Guardrails to its I/O by calling the Guardrails API separately and applying the filter to the model's input/output.
Pattern: SageMaker inference โ†’ Lambda post-processor โ†’ EventBridge event โ†’ Lambda applies Bedrock Guardrails to the output.
SageMaker Clarify = bias detection and explainability for ML training. It is not a runtime content safety tool. Using SageMaker Clarify + Model Monitor to enforce usage policies is the wrong architecture.
Bedrock Guardrails = runtime content safety for any FM (Bedrock or SageMaker). SageMaker Clarify = training-time fairness analysis.

WAF vs Guardrails โ€” Two Different Attack Surfaces

Bedrock Guardrails Handles

  • Harmful AI content (toxic, violent, offensive)
  • Prompt injection / jailbreaks
  • PII in AI I/O
  • Off-topic AI responses
  • RAG hallucinations (contextual grounding)
  • โœ“ AI-layer safety and control
  • AWS WAF Handles

  • HTTP-layer attacks (SQLi, XSS, path traversal)
  • DDoS protection at CloudFront/ALB layer
  • Bot protection, rate limiting
  • IP reputation blocking
  • โœ— Does NOT understand AI content
  • โœ— Does NOT prevent prompt injection
  • WAF protects your web application's HTTP layer. Guardrails protect your AI model's I/O. A prompt injection attack passes through WAF as valid HTTP โ€” WAF has no concept of "this text is trying to jailbreak an LLM." Only Guardrails understands that.

    Contextual Grounding for RAG Quality

    Contextual grounding checks compare the model's response against the retrieved context. If the model says something that isn't supported by the retrieved documents, the grounding check intervenes.
    Scenario: "RAG application, need to ensure responses are based only on retrieved documents, prevent hallucination" โ†’ enable contextual grounding checks in Bedrock Guardrails. Not SageMaker Clarify, not custom Lambda validation.
    Two thresholds: groundedness (response supported by context) and relevance (response addresses the query). Both configurable.
    3.2 โ€” Data Security & Privacy Controls

    IAM Identity Center โ€” The Enterprise Identity Answer

    AWS IAM Identity Center is the right answer whenever the scenario involves enterprise employees needing access to AWS services, especially when a corporate directory (Active Directory, Microsoft Entra ID, Okta) is already in use.
    Pattern: Corporate IdP (Entra ID / AD) โ†’ IAM Identity Center โ†’ Permission Sets (define what access each role gets) โ†’ assigned to AWS accounts. Permission sets can include Bedrock model-specific access conditions.
    Creating IAM users that mirror Active Directory usernames is an anti-pattern. You end up managing two identity systems, credentials can drift, and there's no single source of truth. IAM Identity Center federates to AD โ€” users sign in with their AD credentials.
    Scenario mentions: "corporate Active Directory," "Microsoft Entra ID," "employees need access," "consistent permissions across accounts" โ†’ IAM Identity Center + permission sets. Every time.

    OIDC + Cognito for App Authentication (Not IAM Users)

    For third-party apps or web/mobile apps that need to access AWS resources (including Bedrock), use: existing IdP โ†’ Amazon Cognito via OIDC โ†’ Cognito exchanges IdP tokens for temporary AWS credentials via STS.
    Temporary credentials from STS expire automatically โ€” no long-lived secrets to rotate, no Secrets Manager needed for this purpose. That's the security advantage.
    Creating IAM users + Secrets Manager rotation is operationally heavy and still uses long-lived credentials. OIDC + Cognito = federated, temporary, auditable. IAM users = static credentials, rotation risk.
    Cognito user pools = user directory for authentication. Cognito identity pools = exchange third-party tokens for AWS credentials. The latter is what you need for Bedrock access.

    VPC Endpoint Type for Amazon Bedrock

    Amazon Bedrock uses a VPC Interface endpoint (PrivateLink). Traffic stays on the AWS private network โ€” never traverses the public internet.
    VPC Gateway endpoints only work with Amazon S3 and Amazon DynamoDB. Everything else โ€” Bedrock, SageMaker, SSM, Secrets Manager, Kinesis โ€” uses Interface endpoints.
    Scenario: "application in private subnet must call Bedrock without internet access" โ†’ VPC Interface endpoint for the Bedrock Runtime service + update subnet route tables.
    Interface endpoint creates an Elastic Network Interface (ENI) in your subnet. Your app resolves the Bedrock endpoint to this private IP, keeping all traffic inside AWS.

    PII Detection Toolkit โ€” Right Tool for Right Job

    ToolUse ForHow It Works
    Amazon ComprehendDetect + redact PII in text (emails, transcripts, documents)NLP API โ€” real-time or batch. Returns entity types with offsets. Can redact in place.
    Amazon MacieDiscover sensitive data (PII) across S3 buckets at scaleManaged service โ€” scans S3 continuously. Custom classifiers for specific data types.
    Amazon TextractExtract text from scanned documents, images, PDFsOCR + form extraction. Extracts the text โ€” does not analyze it for PII.
    Bedrock Guardrails PIIBlock/redact PII in LLM I/O at inference timeIntercepts prompts and responses, redacts configured entity types
    The exam uses Textract + Macie together as a distractor for email PII scenarios. Textract is OCR (for scanned images). Macie is for S3 bucket discovery, not active redaction. For text PII โ†’ Comprehend.
    Real-time stream PII = Comprehend real-time API. Batch historical data = Comprehend batch. S3 bucket-level discovery = Macie with custom classifiers. Runtime AI I/O = Guardrails.
    3.3 โ€” AI Governance & Compliance

    Bedrock Prompt Management โ€” Governance Features

    Prompt Management provides: versioning (track every change to a template), review workflows (approve before activating), parameterized templates (reusable with variables), and role definitions (system/user/assistant roles embedded in template).
    Auto-activating new versions as they save bypasses the review workflow entirely โ€” that's the anti-pattern. The exam distinguishes between "versioning with review" vs "versioning with auto-activation." Review = governance. Auto-activate = no governance.
    Scenario: "governance requirement, all prompt changes must be approved before deployment" โ†’ Prompt Management with review workflow + versioning. Not auto-activation.

    Compliance Stack โ€” What Belongs Where

    The correct governance + compliance stack:

    Bedrock Prompt Management โ†’ manage parameterized templates, versioning, review workflows
    Bedrock Guardrails โ†’ enforce content safety policies (not RBAC, not compliance logging)
    AWS CloudTrail โ†’ audit log of API calls (who called what Bedrock API, with which template, when) โ€” this is your compliance record
    IAM + permission sets โ†’ role-based access control (who can invoke which models)
    CloudWatch Logs = operational monitoring (errors, latency). CloudTrail = compliance audit trail (API activity). For "compliance" and "audit trail" questions โ†’ CloudTrail. Never CloudWatch.
    Avoid: "use Guardrails for RBAC." Guardrails filter content โ€” they don't control who can invoke which model. RBAC = IAM.

    Prompt Lineage โ€” Tracking Template History

    Prompt lineage = tracking which version of a template was used for which invocation, and what changed between versions.
    Implementation: Bedrock Prompt Management stores template versions โ†’ AWS CloudTrail records the specific template version ARN used in each Bedrock API call โ†’ you can reconstruct exactly what prompt was sent and when.
    CloudWatch Logs stores the text of invocations but not the template version management. S3 object tags are a manual approach with no native versioning integration. Prompt Management + CloudTrail is the AWS-native lineage solution.

    Output Source Traceability

    When you want to know "which document from the knowledge base influenced this response?", the pattern is: tag FM outputs with metadata from the data source at generation time โ€” include source document ID, title, chunk reference in the response metadata.
    Model invocation logs tell you what went in and came out of the LLM, but not which retrieved KB chunk was the source of truth. Tagging the output explicitly at generation time is how you get end-to-end traceability.

    IAM Identity Center โ€” Permission Sets vs IAM Roles Directly

    Permission sets in IAM Identity Center define what access a role has across multiple AWS accounts. They're defined once and assigned to accounts โ€” no need to replicate roles manually across accounts.
    For Bedrock model access control: permission sets can include condition keys like bedrock:ModelArn to restrict which models a department can invoke.
    IAM Identity Center + permission sets = single definition, multi-account consistency. IAM roles created per-account = drift, inconsistency, management overhead. The exam always prefers Identity Center for enterprise multi-account scenarios.
    3.4 โ€” Responsible AI Principles

    Bias Detection in Text Generation โ€” BOLD Dataset

    For detecting demographic bias in text generation models (loan decisions, customer communications), the correct approach is Amazon Bedrock model evaluation jobs using the BOLD dataset (Bias in Open-Ended Language Generation).
    BOLD = designed specifically for demographic bias assessment in language generation. It tests whether the model generates biased text about different demographic groups.
    SageMaker Clarify uses the RealToxicityPrompts dataset which focuses on toxicity, not demographic bias. It also lacks a secondary model validation methodology. Wrong tool for demographic bias in text gen.
    Scenario: "text generation model for loan processing, must evaluate for demographic bias" โ†’ Bedrock model evaluation + BOLD dataset + secondary evaluator model. Not SageMaker Clarify.

    Responsible AI Tools Summary

    NeedRight ToolWrong Tool
    Demographic bias in text generationBedrock eval + BOLD datasetSageMaker Clarify
    Toxicity in model outputsBedrock Guardrails content filtersSageMaker Clarify
    ML model fairness (classification, regression)SageMaker ClarifyBedrock eval (wrong use)
    Explainability for ML predictionsSageMaker ClarifyBedrock Guardrails (wrong use)
    Grounding / hallucination in RAGBedrock Guardrails contextual groundingSageMaker Clarify
    SageMaker Clarify = ML model fairness + explainability (training time, feature importance). Bedrock = LLM evaluation, content safety, bias in text generation. They operate at different layers.