How to Authenticate Entra ID Users to Amazon Bedrock Privately with Per-Department Model Access?

Implement data security and privacy controls. Design and implement enterprise integration architectures. Implement monitoring systems for GenAI applications.
Answer Correct answer: A — SAML-federate Entra ID to IAM, scope department roles by ModelId, use bedrock-runtime PrivateLink endpoints, and enable CloudTrail with model invocation logging.

A company is creating a generative AI (GenAI) application that uses Amazon Bedrock foundation models (FMs). The application must use Microsoft Entra ID to authenticate. All FM API calls must stay on private network paths. Access to the application must be limited by department to specific model families. The company also needs a comprehensive audit trail of model interactions. Which solution will meet these requirements?

  1. Configure SAML federation between Microsoft Entra ID and IAM. Create department-specific IAM roles that allow only the required ModelId values. Create AWS PrivateLink interface VPC endpoints for Amazon Bedrock runtime services. Enable AWS CloudTrail to capture Amazon Bedrock API calls. Configure Amazon Bedrock model invocation logging to record detailed model interactions. Correct Answer
  2. Create an identity provider (IdP) connection in IAM to authenticate by using Microsoft Entra ID. Assign department permission sets to control access to specific model families. Deploy AWS Lambda functions in private subnets with a NAT gateway for egress to Amazon Bedrock public endpoints. Enable CloudWatch Logs to capture model interactions for auditing purposes.
  3. Create a SAML identity provider (IdP) in IAM to authenticate by using Microsoft Entra ID. Use IAM permissions boundaries to limit department roles’ access to specific model families. Configure public Amazon Bedrock API endpoints with VPC routing to maintain private network connectivity. Set up AWS CloudTrail with Amazon S3 Lifecycle rules to manage audit logs of model interactions.
  4. Configure OpenID Connect (OIDC) federation between Microsoft Entra ID and IAM. Use attribute-based access control to map department attributes to specific model access permissions. Apply SCP policies to restrict access to Amazon Bedrock FM families based on department. Use Microsoft Entra ID’s built-in logging capabilities to maintain an audit trail of model interactions.

Community Insight

The question tests whether you can map each stated requirement to a distinct AWS control — federation for identity, PrivateLink for network path, IAM resource scoping for model families, and two complementary logs for audit — rather than picking one mechanism that claims to do everything.

This scenario combines four Bedrock requirements: Microsoft Entra ID authentication, private-only FM API traffic, department-level model-family restriction, and a full audit trail. Option A satisfies all four with SAML federation to IAM, ModelId-scoped roles, bedrock-runtime PrivateLink interface endpoints, CloudTrail and model invocation logging.

Choosing option B because it mentions Microsoft Entra ID and private subnets; a NAT gateway still sends Bedrock inference traffic to the public bedrock-runtime endpoint, and CloudWatch Logs alone does not provide the model-interaction audit trail.

Community Discussion (1 comments)

Nowax 👍 1 Selected: A
SAML 2.0 is the standard Entra ID->IAM enterprise SSO pattern; department IAM roles scoped to model ARNs enforce family-level access; 'bedrock-runtime' PrivateLink endpoints keep inference off the internet; and CloudTrail (API activity) plus model invocation logging (prompt/response bodies) together give the complete trail. Not B - NAT gateway egress reaches the public Bedrock endpoint, so traffic leaves the private path, and CloudWatch Logs captures nothing unless invocation logging is enabled. Not C - "public endpoints with VPC routing" is not a private path, permissions boundaries cap rather than grant, and CloudTrail alone omits prompt/response content. And not D - Entra ID has no visibility into Bedrock invocations, so it cannot be the audit trail, and SCPs are account-wide guardrails, not per-department grants.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

Option A covers every stated requirement with a purpose-built control. Microsoft Entra ID federates to AWS through a SAML identity provider in IAM, so users assume department-specific roles instead of holding long-lived keys. Those roles restrict access by resource, allowing only the required ModelId ARNs, which enforces model-family limits per department at the IAM policy layer. Amazon Bedrock runtime traffic is kept private through AWS PrivateLink interface VPC endpoints (com.amazonaws.<region>.bedrock-runtime), eliminating internet egress. Auditing is layered: AWS CloudTrail records the Bedrock API activity (who called what, when), while Bedrock model invocation logging captures the request and response payloads needed for a comprehensive trail of model interactions.

Why the Other Options Are Wrong

Option B places Lambda in private subnets but routes to Amazon Bedrock through a NAT gateway, which traverses the public endpoint — the private-path requirement fails — and CloudWatch Logs captured from the function is not a substitute for CloudTrail plus invocation logging. Option C claims private connectivity while explicitly using public Bedrock API endpoints, and permission boundaries only cap the maximum permissions of a role; they do not grant or define department-level model-family access. Option D uses SCPs, which apply at the account/organization level rather than to individual departments, and relies on Microsoft Entra ID's own sign-in logs, which cannot record Bedrock model invocations. In both C and D the audit requirement is effectively unaddressed at the model-interaction level.

Community Comment Notes

Nowax argues the same reasoning, noting that "SAML 2.0 is the standard Entra ID->IAM enterprise SSO pattern" and that department IAM roles scoped to model ARNs enforce family-level access. The comment also correctly separates the two logging layers — CloudTrail for API activity and model invocation logging for prompt/response bodies — which is the distinction most candidates miss. It dismisses option B on the grounds that NAT gateway egress reaches the public Bedrock endpoint, so traffic is not private. That consensus matches the independent analysis here.

Official Reference

Exam Strategy

Treat each clause in the stem as a checklist and cross off options that break any single clause — here, 'private network paths' instantly eliminates NAT gateway and public-endpoint designs. Remember that permission boundaries and SCPs are guardrails that limit, not grant, permissions, so they rarely satisfy a 'limit by department' access requirement.

Frequently Asked Questions

Why is a NAT gateway to Amazon Bedrock not considered a private network path?

A NAT gateway only masks private IPs while traffic still exits to the public bedrock-runtime endpoint over the internet, so it fails the PrivateLink/private-connectivity requirement.

Why can't IAM permissions boundaries alone limit departments to specific model families?

A permissions boundary only sets the maximum permissions an identity can have; access still requires an identity policy that allows the specific ModelId ARNs.

More AIP-C01 FAQ →

Related Analysis

Practice All AIP-C01 Questions

Access 110 questions with complete answers and detailed explanations.

View Full AIP-C01 Practice Test →

← Back to AIP-C01 Study Guide