DVA-C02 Exam Dumps : AWS Certified Developer - Associate

The requirements call for (1) standardized templates to define serverless infrastructure, (2) the ability to test locally before deployment, and (3) integrating deployment and infrastructure changes into an existing AWS CodePipeline workflow. AWS Serverless Application Model (AWS SAM) is designed specifically for serverless applications and extends CloudFormation with serverless-specific resources (such as AWS::Serverless::Function, APIs, event sources). SAM also provides the SAM CLI , which includes local testing capabilities (for example, sam local invoke and sam local start-api) that emulate Lambda and API Gateway behavior for rapid iteration before deployment.

Option A fits all requirements: create an AWS SAM template as the infrastructure definition and add pipeline stages that execute the necessary SAM CLI commands (commonly sam build and sam deploy, and optionally test commands) as part of the CI/CD process. This makes deployments repeatable and automated, ensures infrastructure changes are deployed in lockstep with application changes, and keeps everything governed by the existing CodePipeline.

Option D uses SAM but relies on a standalone script outside the pipeline, which conflicts with the requirement to incorporate infrastructure changes into the existing pipeline. Option C (plain CloudFormation) can define infrastructure, but it does not inherently provide the same streamlined local testing workflow that SAM CLI provides for serverless event sources and APIs. Option B is unrelated: Step Functions is an orchestration service and its definition language is not a general infrastructure templating and local-testing solution for serverless deployments.

Therefore, A is the correct strategy: use AWS SAM templates and integrate SAM CLI build/deploy steps into CodePipeline to automate deployments and support local testing while managing infrastructure as code.

This is a cross-account access pattern using STS AssumeRole. Account A owns the DynamoDB table and has created an IAM role (AccessPII) with permissions to access the table. Account A also configured a trust policy that allows principals from Account B to assume the role. That trust policy alone is not enough; the caller in Account B must also be allowed to call sts:AssumeRole.

Therefore, in Account B, the EC2 instance profile role (the role attached to the EC2 instances running the app) must have permission to assume the role in Account A. That is Option A.

Next, the application must actually obtain temporary credentials for the Account A role. The standard way is to call STS AssumeRole in the application logic (or use an SDK credential provider that assumes a role). This yields temporary credentials that have the permissions of the AccessPII role, allowing DynamoDB access in Account A. That is Option D.

Option B is not correct because granting direct DynamoDB table permissions in Account B does not grant access to a table owned by Account A unless Account A also grants access via a resource policy (DynamoDB resource policies exist but the scenario already sets up role assumption; the intended solution is AssumeRole).

Option C is incomplete/wrong: getting temporary credentials from the EC2 role alone gives permissions of the EC2 role in Account B, not the permissions in Account A. You must assume the cross-account role.

Option E is for IAM user MFA session tokens, not cross-account role assumption for an EC2 role.

Therefore, grant sts:AssumeRole to the EC2 role and call AssumeRole in code.