AWS DVA-C02 Drill: AWS STS API Operations - MFA-Enabled Cross-Account S3 Access

Jeff’s Note

#

Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.

For DVA-C02 candidates, the confusion often lies in which AWS STS API operation supports MFA authentication when accessing cross-account resources. In production, this is about knowing exactly which AssumeRole variant can incorporate MFA device token requirements properly to securely access resources in another AWS account. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

BrightByte Apps is developing a serverless application that needs to access sensitive data stored in an Amazon S3 bucket owned by a partner account. For strict security compliance, BrightByte requires that developers use multi-factor authentication (MFA) every time they request temporary credentials to access this bucket. The developers must programmatically obtain temporary credentials with MFA validation before accessing the bucket.

The Requirement:

#

Identify the correct AWS Security Token Service (AWS STS) API operation that BrightByte’s developers should use, supplying the MFA code, to securely assume a role in the partner account and access the S3 bucket.

The Options

#

• A) AssumeRoleWithWebIdentity
• B) GetFederationToken
• C) AssumeRoleWithSAML
• D) AssumeRole

Google adsense

#

leave a comment:

Correct Answer

#

D) AssumeRole

Quick Insight: The Developer’s Imperative

#

When programmatically obtaining temporary credentials for cross-account role assumption with MFA enforcement, AssumeRole is the correct AWS STS API because it explicitly supports passing MFA serial number and token code parameters. Other API calls either don’t support MFA validation or are designed for specific identity federation scenarios outside this scope.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answer

#

Option D) AssumeRole

The Winning Logic

#

• The AssumeRole API supports an optional parameter called SerialNumber and TokenCode which can be used to pass the MFA device’s ARN and the current MFA token code. This enforces MFA upon role assumption.
• It is the standard method used to assume an IAM role in another AWS account, enabling cross-account access with temporary credentials.
• The temporary credentials returned can directly access S3 or any other service resources governed by the assumed role’s permissions.
• This aligns perfectly with BrightByte’s requirement to enforce MFA every time credentials are assumed to access the sensitive bucket.

The Trap (Distractor Analysis):

#

• Why not A) AssumeRoleWithWebIdentity?
  This is designed for federating via OIDC providers and JWT tokens from web identities (like Cognito or Google) and does not support MFA token parameters.

• Why not B) GetFederationToken?
  This issues temporary credentials for a federated user within the same account, not for cross-account role assumption. It can enforce MFA on the session but is not intended for assuming roles in other accounts.

• Why not C) AssumeRoleWithSAML?
  This is specific for federated sign-in using SAML authentication and does not handle MFA tokens directly in the call. It’s for enterprise federation scenarios, not ad-hoc developer MFA token usage for role assumption.

The Technical Blueprint

#

For Developer / SysOps (Code/CLI Snippet):

Here is an example CLI call showing how to pass MFA info when assuming a role:

aws sts assume-role \
    --role-arn arn:aws:iam::123456789012:role/PartnerS3AccessRole \
    --role-session-name developer-session \
    --serial-number arn:aws:iam::111122223333:mfa/developer-device \
    --token-code 123456 \
    --duration-seconds 3600

This call requests temporary credentials from the STS service assuming the specified role, validates the MFA token, and returns short-lived credentials to access the partner account’s S3 bucket.

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For the exam, always pick AssumeRole when you see MFA + cross-account role assumption.

Real World

#

In production, developers integrate the AssumeRole call with their CI/CD pipelines and SDK code, passing in the current MFA token obtained via a hardware or virtual MFA device. This ensures compliance and security while accessing cross-account resources securely and temporarily.

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the AWS DVA-C02 exam.