DOP-C02 Security and Compliance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use Amazon Cognito user pools with SAML federation and integrate with ALB

  Why it's wrong here

  Using Cognito user pools with SAML federation and integrating the ALB would create an unnecessary intermediary, because the ALB already has first-class support for external SAML IdPs. In this architecture you would configure the ALB to use Cognito's OIDC endpoint, then map Cognito's federation to the upstream SAML IdP, adding an extra hop, extra token transformation logic, and another failure domain. ALB can instead consume the SAML IdP directly at the listener, eliminating the need to manage Cognito's domain, app clients, and federation mappings for this use case.

• ✗

  Use AWS CloudFront with Lambda@Edge to validate SAML tokens

  Why it's wrong here

  CloudFront with Lambda@Edge can inspect and validate SAML assertions at the edge, but it cannot natively integrate with the ALB’s authentication flow; the ALB requires a built-in SAML IdP configuration to offload token validation at the listener level, not a separate edge function. This option is tempting because Lambda@Edge is often used for custom authentication logic, such as validating JWTs or redirecting to an IdP for CloudFront distributions, and would be correct if the requirement were to authenticate users at the CDN layer rather than at the ALB.

• ✗

  Install a SAML service provider library on each EC2 instance

  Why it's wrong here

  Installing an SAML service provider library on each EC2 instance means every instance must implement the SP side of the SAML protocol, including parsing assertions, validating signatures, and maintaining session state in application code. This forces application-level changes, complicates horizontal scaling because session state may not be shared across instances, and requires rotating certificates at the application layer. The ALB is designed to offload exactly this authentication burden, so pushing it back into the instances is an anti-pattern.

• ✓

  Configure the ALB to use an SAML identity provider for authentication

  Why this is correct

  Configuring the ALB to use an SAML identity provider lets the load balancer act as the relying party, terminating the SAML exchange at the edge of the AWS network. When an unauthenticated user requests a protected target group, the ALB redirects to the IdP, validates the returned assertion, sets an encrypted session cookie, and forwards the authenticated session details to the backend as HTTP headers. This makes authentication transparent to the EC2 instances, so no code changes are required and security is centralized at one access point.

Go deeper

Related to this question