DVA-C02 Development with AWS Services Practice Question
A developer is deploying a web application on Amazon EKS. The application needs to read configuration data from an Amazon S3 bucket at startup. The developer wants to ensure that the configuration is securely accessed without embedding AWS credentials in the application code. Which solution should the developer use?
⚠ Common exam trap
Candidates often confuse IRSA with IAM instance profiles, thinking that assigning a role to the node is sufficient, but IRSA is the correct method for pod-level IAM permissions in EKS.
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
✓
Use IAM roles for service accounts (IRSA) to assign an IAM role to the pod.
IAM roles for service accounts (IRSA) allows you to associate an IAM role with a Kubernetes service account, which the pod can assume to obtain temporary AWS credentials via the AWS STS endpoint. This eliminates the need to embed long-term credentials in the application code or environment variables, and the credentials are automatically rotated by the AWS SDK. The pod retrieves the configuration from S3 using the assumed role's permissions, ensuring secure access.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use IAM roles for service accounts (IRSA) to assign an IAM role to the pod.
Why this is correct
IAM roles for service accounts (IRSA) is the recommended and most secure method for granting AWS permissions to applications running in EKS pods. It leverages an OpenID Connect (OIDC) provider associated with the EKS cluster to allow Kubernetes service accounts to assume specific IAM roles. This mechanism provides fine-grained, pod-level permissions, ensuring that each pod receives only the necessary temporary AWS credentials, thereby adhering strictly to the principle of least privilege and enhancing overall security.
- ✗
Store the AWS credentials in AWS Secrets Manager and retrieve them at startup.
Why it's wrong here
While AWS Secrets Manager is excellent for securely storing sensitive data, retrieving static AWS credentials from it for a pod still presents a security challenge. The pod would first need some initial permissions to access Secrets Manager, creating a bootstrapping problem. Furthermore, once retrieved, these static credentials reside in the pod's memory or file system, increasing the risk of exposure if the pod is compromised, and they lack automatic rotation, requiring manual management.
- ✗
Assign an IAM instance profile to the EC2 instances running the EKS nodes.
Why it's wrong here
Assigning an IAM instance profile to the underlying EC2 instances running the EKS nodes grants the same set of AWS permissions to *all* pods scheduled on that particular node. This approach severely compromises the principle of least privilege, as a single pod requiring specific access would inadvertently provide that same elevated access to every other pod on the node. Consequently, if one pod is compromised, an attacker could exploit these broad permissions to access AWS resources not intended for that specific application, significantly expanding the security blast radius.
- ✗
Embed the AWS access key and secret key in a Kubernetes ConfigMap.
Why it's wrong here
Embedding AWS access keys and secret keys directly into a Kubernetes ConfigMap is highly insecure and a critical anti-pattern for managing credentials. ConfigMaps are designed for non-confidential configuration data and are stored unencrypted in the cluster's etcd database, making their contents easily readable by anyone with access to the cluster's API or underlying storage. This method exposes sensitive AWS credentials to potential compromise, lacks any form of credential rotation, and violates fundamental security best practices, making it unsuitable for production environments.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
One of 724 original DVA-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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DVA-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 DVA-C02 exam.