Security, Compliance, and Governance for AI Solutions practice questions

Use AWS Lake Formation to grant cross-account access to the bucket

Why it fails: Lake Formation governs data lakes in the same account or via Resource Access Manager, but direct S3 bucket access for Bedrock is not managed by Lake Formation.

Copy the S3 bucket to the same account as Bedrock

Why it fails: Copying data is inefficient and may violate data residency requirements; cross-account access can be secured with policies.

Make the S3 bucket public and use a pre-signed URL

Why it fails: Making the bucket public violates security best practices; pre-signed URLs are for temporary access, not for ongoing model access.

Cell-level security

Why it fails: Lake Formation offers no cell-level security feature; row-level and column-level filters are the granular controls, so this names a capability that does not exist. It tempts because it sounds like the finest-grained option, and would be right only if individual cell values could be masked.

Column-level security

Why it fails: Column-level security restricts which columns a principal can read, not which rows, so it cannot filter records by project. It tempts because it is the other fine-grained Lake Formation filter, and would be correct when specific fields, such as salary, must be hidden from some teams.

Tag-based access control

Why it fails: Tag-based access control grants or denies permissions according to LF-Tags on resources, not according to row values, so it cannot filter records by project. It tempts because it scales governance across many tables, and would be correct when permissions should follow data classification tags.

Use Bedrock's content filters to block sensitive data

Why it fails: Content filters detect and block harmful or sensitive content in prompts and responses; they do not alter the provider's contractual data-handling or training practices. It is tempting because filters do address sensitive data, and they would be the right control when the requirement is preventing harmful or policy-violating content.

Encrypt all data with KMS before sending to Bedrock

Why it fails: KMS encryption protects data in transit and at rest but does not govern whether the provider may use decrypted prompts for training. It is tempting because encryption is a standard data-protection control, and it would be correct when the requirement is confidentiality of stored data rather than training exclusion.

Use a custom model hosted on SageMaker instead

Why it fails: Hosting a custom model on SageMaker sidesteps Bedrock entirely, so it does not satisfy the requirement to use a third-party foundation model in Bedrock. It is tempting because self-hosting gives full control over training data, and it would be correct when no Bedrock model meets the workload's needs.

Use AWS KMS multi-Region keys to encrypt data

Why it fails: Multi-Region keys allow decryption in multiple regions, violating data residency.

Enable cross-region replication for the S3 bucket

Why it fails: Cross-region replication would copy data to another region, violating data residency.

Use AWS Certificate Manager (ACM) to issue a certificate for the training job and enable network isolation

Why it fails: ACM is for SSL/TLS certificates, not for encrypting training data at rest. Network isolation alone doesn't encrypt data.

Enable SageMaker data capture and use a private VPC with an internet gateway

Why it fails: Data capture is for inference logging, not encryption; an internet gateway would expose the training job to the internet, violating the no-internet requirement.

Store training data in an encrypted S3 bucket and use a SageMaker notebook instance inside a VPC

Why it fails: Encrypting S3 data is good but does not encrypt the SageMaker storage volumes. A notebook instance is not the same as a training job configuration.

Add an AWS KMS key policy to allow cross-account decryption

Why it fails: The issue is access denied, not encryption. If KMS is used, the key policy would also need cross-account access, but that is not the primary issue described.

Create a new VPC peering connection between the two accounts

Why it fails: VPC peering is not required for S3 access; S3 is accessed over the internet or via VPC endpoints.

Use AWS Lake Formation to grant cross-account permissions on the S3 data

Why it fails: Lake Formation is for data lake permissions but requires additional setup; it's not the typical fix for this common cross-account S3 access issue.

SageMaker Role Manager

Why it fails: Role Manager creates roles with permissions, but does not restrict which specific models can be used.

AWS Config rules to detect non-compliant models

Why it fails: AWS Config can detect non-compliant resources after the fact, but does not prevent the use of unauthorized models.

SageMaker Model Registry

Why it fails: Model Registry manages model versions, but does not enforce which base models are allowed.

Set up an S3 bucket for model invocation logs in a different Region for disaster recovery

Why it fails: Storing logs in a different Region would violate data residency requirements.

Use AWS Global Accelerator to route traffic to Bedrock across regions for better performance

Why it fails: Global Accelerator would route traffic to the nearest region, but that could move data outside the desired Region.

Modify the trust policy of the IAM role

Why it fails: Trust policies are used for cross-account access, not for restricting API calls to a specific role within the same account.

Place the notebook instance in a private VPC subnet

Why it fails: Placing the notebook in a private VPC subnet controls network access but does not restrict which IAM role can invoke the API.

Use a resource-based policy on the notebook instance

Why it fails: Incorrect. Amazon SageMaker notebook instances do not support resource-based policies.

Configure a topic restriction to block 'PII' topics

Why it fails: Topic restrictions filter based on topic categories, not sensitive data patterns like SSNs.

Enable model invocation logging and manually review all inputs

Why it fails: Manual review does not meet the real-time blocking requirement.

Add a word filter with a list of common SSN patterns

Why it fails: Word filters match exact strings or regex, but PII detection is better handled by managed PII filters that understand context and format.

Enable Network Isolation and use an S3 VPC Endpoint

Why it fails: Network Isolation blocks all network access including S3, so the job cannot read data from S3 even with a VPC endpoint.

Enable Network Isolation and use a VPC with a NAT gateway

Why it fails: Network Isolation prevents all network access, so even a NAT gateway cannot be used. Also, NAT gateway provides internet access.

Disable Network Isolation and use a public VPC subnet

Why it fails: A public subnet has internet access via an internet gateway, violating the no-internet policy.

The guardrail's sensitivity threshold is set too low

Why it fails: A low sensitivity threshold makes the guardrail less likely to flag borderline content, so harmful prompts pass through unfiltered. It is tempting because sensitivity tuning is a real guardrail setting, but the stem describes plainly harmful fraud instructions, which a correctly configured deny filter should catch regardless of threshold.

The prompt was sent to a different Bedrock model that does not support guardrails

Why it fails: Bedrock guardrails apply per model invocation, so a call routed to a model or endpoint outside the guardrail's configuration bypasses filtering entirely. It is tempting because guardrails genuinely are model-scoped, but the stem states a guardrail was configured and invoked; a misspelled bucket or wrong password would not produce this specific error.

The guardrail was configured with a word filter but not a content filter

Why it fails: A word filter matches literal terms, so paraphrased harmful requests such as 'commit fraud' evade it, whereas content filters classify intent. It is tempting because word filters are a real guardrail component, but the stem's prompt contains no blocked keyword, so the filter type is the actual gap.

Deploy the endpoint in a public subnet and use a security group to restrict source IPs

Why it fails: Even with security group restrictions, the endpoint has a public DNS and is potentially exposed to the internet.

Enable network isolation on the endpoint

Why it fails: Network isolation prevents the endpoint from accessing the internet but does not restrict inbound access; the endpoint remains publicly accessible.

Use an AWS Lambda function to proxy requests and restrict access via IAM

Why it fails: Lambda adds complexity and still requires the endpoint to be accessible; it does not inherently restrict network access.

Grant DESCRIBE on the table

Why it fails: DESCRIBE allows viewing metadata but not querying data.

Grant INSERT on the table

Why it fails: INSERT permission allows adding data, not querying.

Create a view with only the allowed columns and grant SELECT on the view

Why it fails: While this would work, it is not a direct Lake Formation permission; the question asks which permission should be granted to the role, and Lake Formation supports column-level grants directly.

Contact the model provider directly via email

Why it fails: This is not the standard AWS process; information is available in the documentation.

Use Amazon Macie to analyze the model provider's privacy policy

Why it fails: Macie is for discovering sensitive data, not for reading privacy policies.

In the AWS Artifact reports

Why it fails: AWS Artifact provides compliance reports for AWS services, not third-party model provider data handling.

Configure a Bedrock Guardrail to log all invocations to a CloudWatch Logs group in the required region

Why it fails: Guardrails do not log full invocation content; they log only guardrail evaluations.

Use AWS CloudTrail to log all API calls and store them in the required region

Why it fails: CloudTrail logs API calls, not model invocation content (prompts/responses). The requirement is for inference logs.

Use AWS Global Accelerator to route traffic to the required region

Why it fails: Global Accelerator improves performance but does not control log storage location.

Use AWS Lake Formation to share the notebook

Why it fails: Use AWS Lake Formation to share the notebook — Lake Formation is for data lake permissions and not designed for sharing SageMaker notebooks directly. Incorrect.

Attach a resource-based policy to the notebook instance that grants the colleague's IAM role permissions to open and run, and deny delete

Why it fails: Attach a resource-based policy to the notebook instance — SageMaker notebook instances do not support resource-based policies. Incorrect.

Create an IAM role in the colleague's account with permissions to create and manage SageMaker notebooks

Why it fails: Create an IAM role in the colleague's account with permissions to create and manage SageMaker notebooks — This would allow creation/deletion, not limited to opening and running. Incorrect.

Topic restriction to limit topics

Why it fails: Topic restriction limits the model to certain conversation topics but does not directly remove sensitive information from responses.

Word filter to block specific words

Why it fails: Word filter blocks specific predefined words, but it is not comprehensive enough to reliably prevent all sensitive data from appearing.

Grounding check to verify responses are grounded in source documents

Why it fails: Grounding check verifies that responses are grounded in source documents but does not filter out sensitive information.

Content policy to filter out harmful content

Why it fails: Content policy filters outputs based on harmful content categories such as hate speech or violence, not for sensitive data like PII. It does not address the requirement to prevent sensitive information in responses.

Amazon Macie

Why it fails: Macie discovers sensitive data but does not provide encryption.

AWS Certificate Manager (ACM)

Why it fails: ACM manages SSL/TLS certificates, not encryption keys for data at rest.

AWS CloudHSM

Why it fails: CloudHSM provides hardware security modules but is not directly integrated with S3 or SageMaker for encryption; KMS is the recommended service.

Attach an S3 bucket policy to the model artifacts

Why it fails: S3 bucket policies control access to data, not Bedrock model invocation.

Configure a VPC endpoint for Bedrock

Why it fails: VPC endpoints control network access, not IAM authorization for model invocation.

Use AWS Organizations service control policies to deny all model access

Why it fails: SCPs provide governance guardrails but do not grant granular invoke permissions to specific roles.