Courseiva
← DOP-C02
Full test
Incident and Event Response →hardMultiple ChoiceObjective-mapped

DOP-C02 Incident and Event Response Practice Question

Exhibit

Refer to the exhibit.

Error log from an application instance:

2023-10-01T12:34:56Z ERROR Failed to assume role: AccessDenied
User: arn:aws:sts::123456789012:assumed-role/EC2-AppRole/i-0a1b2c3d4e5f
is not authorized to perform: sts:AssumeRole on resource:
arn:aws:iam::123456789012:role/DatabaseAccessRole

A DevOps engineer is troubleshooting an application running on an EC2 instance. The application needs to access an Amazon RDS database using IAM database authentication. The EC2 instance is associated with an IAM role 'EC2-AppRole', and the RDS instance has a resource-based policy that allows 'DatabaseAccessRole' to connect. The engineer sees the error in the exhibit. What is the most likely cause?

⚠ Common exam trap

Test-takers frequently assume the error is due to missing resource-based policies or network connectivity, but the core issue is the missing trust relationship between the EC2 instance role and the database access role, which is a common misconfiguration in cross-account or cross-role IAM authentication setups.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The trust policy of the IAM role 'DatabaseAccessRole' does not allow the EC2 instance role 'EC2-AppRole' to assume it.

The error indicates that the EC2 instance's IAM role 'EC2-AppRole' cannot authenticate to the RDS instance. IAM database authentication requires the EC2 instance to assume a database authentication token, which is generated by calling the RDS API with the 'EC2-AppRole' credentials. However, the RDS instance's resource-based policy only allows 'DatabaseAccessRole' to connect. For 'EC2-AppRole' to successfully authenticate, it must first assume 'DatabaseAccessRole' via a trust policy that permits the EC2 instance role to assume it. Without this trust relationship, the authentication token request fails, causing the error.

Answer analysis

Option-by-option breakdown

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

  • ✗

    The RDS instance does not have a resource-based policy that grants access to 'DatabaseAccessRole'.

    Why it's wrong here

    The RDS instance already has a resource-based policy that explicitly grants access to 'DatabaseAccessRole', but more importantly, IAM database authentication on RDS does not rely on resource-based policies for token generation. The permission to generate an authentication token is governed by an identity-based policy attached to the calling IAM principal (e.g., 'DatabaseAccessRole' or 'EC2-AppRole') that allows the 'rds-db:connect' action, not by a policy on the RDS resource. Therefore, even if this policy were missing, the symptom would be an authorization failure rather than a trust-policy error, and the scenario states it is present, making this option incorrect.

  • ✗

    The security group for the EC2 instance does not allow outbound traffic to the RDS instance.

    Why it's wrong here

    The security group configuration governs network connectivity at the TCP layer; a mismatch would cause connection timeouts or 'Connection refused' errors when trying to reach RDS on port 3306, not IAM authentication failures. The token generation itself is a signed request to AWS STS and does not traverse the RDS security group, and after the token is presented, RDS performs an IAM authorization check that fails regardless of network reachability. Since the error is specifically about an unauthorized or invalid token, outbound-traffic restrictions are not responsible, making this option incorrect.

  • ✗

    The EC2 instance does not have the correct IAM instance profile attached.

    Why it's wrong here

    The EC2 instance has the IAM role 'EC2-AppRole' attached, so the instance profile is correctly serving credentials from the instance metadata service. If the instance had no profile, the application would fail to load AWS credentials at all, typically raising a 'NoCredentialsError' or failing to sign the authentication request entirely, rather than producing an IAM error tied to role assumption. Because the failure is about the trust policy of 'DatabaseAccessRole', the instance profile is functioning; the issue lies later in the STS AssumeRole flow, not at the metadata layer where the instance profile operates.

  • ✓

    The trust policy of the IAM role 'DatabaseAccessRole' does not allow the EC2 instance role 'EC2-AppRole' to assume it.

    Why this is correct

    For IAM database authentication, the application must first assume the IAM role 'DatabaseAccessRole' to obtain credentials authorized to generate the RDS token; the trust policy on 'DatabaseAccessRole' must explicitly list 'EC2-AppRole' as a trusted principal. When this trust policy does not allow the EC2 instance's role to assume it, the STS AssumeRole call returns 'AccessDenied', so the application cannot acquire the token required for authentication to RDS. This exactly matches the observed error, confirming the trust policy of 'DatabaseAccessRole' is the root cause.

About these practice questions

One of 251 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.