AWS DVA-C02 Drill: Secure Token Storage - Cross-Account Access with Minimal Management

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 choosing the right secure storage service that balances encryption, cross-account accessibility, and developer convenience. In production, this is about knowing exactly which AWS managed service handles secret rotation, encryption, and multi-account access with the least overhead. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

GammaSoft, a software company, is deploying a microservices application on Amazon EC2 instances. One microservice processes incoming user transactions. When it detects an invalid transaction, it needs to notify the customer support team through a third-party chat service API. The application requires an access token to authenticate with this chat API. This access token must be stored securely—encrypted at rest and in transit—and must be accessible by EC2 instances from multiple AWS accounts owned by GammaSoft. The development team wants to implement this with the least management overhead possible.

The Requirement:

#

Design a solution to store and retrieve the chat API access token that guarantees encryption at rest and in transit, supports cross-account access, and minimizes management effort.

The Options

#

• A) Use an AWS Systems Manager Parameter Store SecureString parameter encrypted with an AWS managed KMS key. Attach a resource-based policy on the parameter allowing access from other accounts. Update the EC2 instances’ IAM roles with permission to use Parameter Store. Retrieve the token with decryption enabled and use it to authenticate with the chat API.

• B) Encrypt the access token using a customer-managed AWS KMS key. Store the encrypted token in an Amazon DynamoDB table. Grant the EC2 instances IAM permissions to access DynamoDB and KMS. Retrieve the encrypted token from DynamoDB, then decrypt it locally using KMS before sending the chat message.

• C) Use AWS Secrets Manager with a customer-managed AWS KMS key to store the access token. Apply a resource-based policy on the secret granting access from other AWS accounts. Update EC2 IAM roles to allow Secrets Manager access. Retrieve the decrypted token directly from Secrets Manager and use it for authentication.

• D) Encrypt the access token using an AWS managed KMS key and store it as an object in an Amazon S3 bucket. Set a bucket policy to allow cross-account access. Assign EC2 instances permissions for S3 and KMS. Retrieve and decrypt the token locally before sending the message.

Google adsense

#

leave a comment:

Correct Answer

#

C.

Quick Insight: The Developer Imperative

#

AWS Secrets Manager natively supports secret encryption, automatic decryption on retrieval, secret rotation features, and fine-grained resource policies—ideal for cross-account secret sharing with minimal developer overhead.
Parameter Store SecureString (Option A) is simpler but less feature-rich and not optimized for secrets that must be accessed cross-account at scale.
Options B and D involve additional code complexity for encryption/decryption and managing storage formats, increasing error risk and maintenance.

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 C

The Winning Logic

#

Secrets Manager is designed specifically for the secure management of secrets such as API tokens. Its integration with KMS customer-managed keys ensures encryption at rest. Additionally, Secrets Manager handles decryption transparently when your application retrieves the secret, minimizing application complexity. It supports resource-based policies that can grant cross-account access effectively. Secrets Manager also provides built-in rotation capabilities—though rotation isn’t explicitly requested here, this shows its flexibility.

The Trap (Distractor Analysis):

#

• Why not Option A (Parameter Store)?
  While Parameter Store SecureString parameters can be encrypted and support resource-based policies for cross-account access, Parameter Store is generally recommended for less sensitive configuration data. It lacks native rotation, versioning, and monitoring features present in Secrets Manager. If simplicity is key, Parameter Store can be sufficient, but for secret management with cross-account requirements, Secrets Manager is best practice.

• Why not Option B (DynamoDB + KMS)?
  This requires manually encrypting tokens before storing and decrypting after retrieval in the application. It increases management and developer effort, does not natively support cross-account resource policies at the data level, and complicates the secret lifecycle.

• Why not Option D (S3 + KMS)?
  Storing secrets in S3 requires handling encryption/decryption client-side and managing object permissions carefully. While cross-account bucket policies can grant access, this approach leads to higher overhead and complexity when accessing secrets compared to Secrets Manager.

The Technical Blueprint

#

# Example IAM policy snippet for EC2 role to access Secrets Manager cross-account:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": "arn:aws:secretsmanager:region:account-id:secret:chat-api-token-123"
        }
    ]
}

# Example AWS CLI command to retrieve secret and automatically decrypt:
aws secretsmanager get-secret-value --secret-id chat-api-token-123

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For the exam, always pick Secrets Manager when you see API tokens/secret management with cross-account access.

Real World

#

In production, teams might use Parameter Store for internal config values but shift to Secrets Manager when secrets need lifecycle management, auditing, and multi-account sharing.

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

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