AWS DVA-C02 Drill: Cross-Account Parameter Access - Minimal Operational Overhead

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 securely accessing shared resources across AWS accounts without needless parameter duplication or complex credential management. In production, this is about knowing exactly how IAM roles and Systems Manager permissions interplay for cross-account parameter retrieval. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

TechNova Solutions manages multiple AWS accounts for their services. Account X owns an application that stores critical environment variables as parameters in AWS Systems Manager (SSM) Parameter Store. A development team in Account Y is building a new service that requires read access to those parameters from Account X. The team wants to avoid duplicating parameters or maintaining separate copies in Account Y.

The Requirement:

#

Design a solution that enables the application in Account Y to securely access the existing parameters in Account X with the least amount of operational overhead.

The Options

#

• A) Configure the application in Account Y to use IAM user credentials from Account X that have permissions to read the parameters.
• B) Create an IAM role in Account X that can be assumed by Account Y and grant it permissions to access the parameters.
• C) Use AWS Resource Access Manager (RAM) to share the parameters cross-account.
• D) Develop a script to periodically copy parameters into an Amazon S3 bucket accessible by both accounts.

Google adsense

#

leave a comment:

Correct Answer

#

B

Quick Insight: The Developer’s Imperative

#

Security best practice favors role assumption over long-term IAM user credentials for cross-account access.
Leveraging IAM roles simplifies permission management and reduces operational overhead compared to custom replication scripts or resource-sharing services not suited for parameters.

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 B

The Winning Logic

#

Cross-account access to SSM parameters is best achieved by creating an IAM role in the account owning the parameters (Account X) that grants read permissions to Systems Manager Parameter Store. This role is then assumed by entities in the consuming account (Account Y). This approach:

• Avoids long-term credential management tied to IAM users.
• Applies the principle of least privilege with auditability.
• Reduces operational overhead compared to scripts or duplications.
• Uses native identity federation between accounts.

The Trap (Distractor Analysis)

#

• Why not A?
  Using an IAM user from Account X in Account Y requires sharing and managing long-lived credentials, which introduces security risks and higher operational burden.

• Why not C?
  AWS RAM does not support sharing SSM Parameter Store parameters directly, so this option is not feasible.

• Why not D?
  Manually replicating parameters into S3 buckets adds complexity, risk of inconsistency, and extra maintenance overhead.

The Technical Blueprint

#

Relevant IAM Trust Policy to Allow Cross-Account Role Assumption (in Account X)

#

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT_Y_ID:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

Example Inline Policy Attached to the Role (allows read access to parameters)

#

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:GetParameter",
        "ssm:GetParameters",
        "ssm:GetParametersByPath"
      ],
      "Resource": "arn:aws:ssm:REGION:ACCOUNT_X_ID:parameter/YOUR_PARAMETER_PATH/*"
    }
  ]
}

CLI command from Account Y assuming the role to retrieve parameters:

#

aws sts assume-role \
    --role-arn arn:aws:iam::ACCOUNT_X_ID:role/ParameterAccessRole \
    --role-session-name "AccessParametersSession" > temp-creds.json

export AWS_ACCESS_KEY_ID=$(jq -r '.Credentials.AccessKeyId' < temp-creds.json)
export AWS_SECRET_ACCESS_KEY=$(jq -r '.Credentials.SecretAccessKey' < temp-creds.json)
export AWS_SESSION_TOKEN=$(jq -r '.Credentials.SessionToken' < temp-creds.json)

aws ssm get-parameter --name "/app/env/VAR1" --with-decryption

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For the exam, always pick IAM Roles with AssumeRole when you see a cross-account access requirement to SSM Parameter Store or other sensitive resources.

Real World

#

In production, you might combine assumed roles with AWS SDKs and Secrets Manager for more dynamic credential management and enhanced security. But for exam purposes, focus on the IAM role assumption pattern.

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

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