Lesson 4.3: Debugging common DVA-C02 scenarios
In AWS development, failures are rarely random. They almost always result from a boundary violation: identity, networking, capacity, or deployment configuration. Scenario-based questions often describe symptoms such as AccessDenied, timeouts, throttling, or failed builds.
Your task as a developer or architect is to identify which architectural boundary is failing and address it. Recognizing patterns quickly is key for both exams and real-world debugging.
IAM failures and AccessDenied
An AccessDenied error indicates that IAM policy evaluation rejected the request. The service is reachable, the identity is authenticated, but authorization failed.
Diagnostic steps
- Identify the calling principal: In most architectures, this is not a human user, but a role assumed by:
- Lambda execution role
- EC2 instance profile
- ECS task role
- Cross-account assumed role via STS
- Evaluate the relevant policies:
- Identity-based policies attached to the role
- Resource-based policies (e.g., S3 bucket policy)
- Explicit deny statements
- Cross-account trust relationships
Remember: explicit deny overrides allow. Even a role with broad permissions can be blocked by a resource policy.
Cross-account scenarios: Both of these must be true:
- Source principal has sts:AssumeRole permission
- Target role’s trust policy allows the source principal
If either is missing, role assumption fails.
Scenario example:
A Lambda trying to write to an S3 bucket in another account fails with AccessDenied. The likely solution is updating the bucket policy or Lambda execution role rather than network or scaling changes.
Lambda timeouts
A Lambda timeout occurs when the function does not complete within its configured execution time. Often, the root cause is environmental, not computational.
Common causes
- Lambda attached to a VPC without proper outbound routing
- Security group blocking database or API access
- Missing NAT Gateway for internet-bound calls
- Downstream service latency exceeding the timeout
When a Lambda is VPC-attached, it loses default internet access. Any attempt to call an external API without a NAT Gateway causes the function to hang until the timeout.
Other causes:
- Database connection exhaustion: Multiple concurrent Lambda invocations can overwhelm RDS connections.
- Cold starts: Memory-constrained functions or VPC-attached functions may initialize slowly.
Debugging steps
- Check CloudWatch Logs to find the last executed statement
- Verify subnet routing and NAT configuration
- Confirm security group rules
- Validate downstream service health
- Ensure the timeout setting aligns with expected execution time
Exam tip: Timeouts combined with VPC changes usually indicate networking misconfiguration, not a code defect.
CodeBuild failures
AWS CodeBuild runs builds in ephemeral containers with an associated IAM role. Failures usually stem from permission issues, dependency problems, or networking misconfigurations.
Common failure categories
- IAM permission issues
- Example: CodeBuild cannot access S3 artifacts or push to ECR. Ensure the role has s3:GetObject or ecr:PutImage.
- Buildspec misconfiguration
- Missing commands or incorrect artifact paths lead to predictable failures.
- Environment and secret issues
- Missing environment variables or inaccessible secrets (from Secrets Manager or Parameter Store) cause runtime errors.
- VPC configuration issues
- When CodeBuild runs inside a VPC, it requires a NAT Gateway or VPC endpoints for outbound access. Without them, dependency downloads fail.
Scenario example:
A build fails while fetching dependencies. Likely cause: CodeBuild is VPC-attached without NAT or endpoints.
Concurrency limits and throttling
Concurrency issues manifest as throttling errors, delayed processing, or partial system failures.
- Lambda: Enforces regional concurrency limits. Excess invocations are throttled. SQS-triggered Lambdas leave messages in the queue for retry. API Gateway clients may receive 429 errors.
- DynamoDB: Exceeding provisioned throughput returns ProvisionedThroughputExceededException. Immediate retries amplify load.
- API Gateway: Exceeding request rate or burst limits triggers throttling responses.
Common causes
- Sudden traffic spikes
- Unbounded parallel processing
- Missing reserved concurrency controls
- Retry amplification from upstream services
Mitigation strategies
- Reserved concurrency to protect downstream services
- Exponential backoff with jitter
- Increase provisioned throughput when necessary
- Introduce buffering layers to absorb spikes
Scenario example:
SQS retries trigger multiple concurrent Lambda executions, overwhelming DynamoDB. Correct solution: implement backoff, throttling, or reserved concurrency.
Diagnostic mindset
Effectively debugging AWS failures requires mapping symptoms to boundaries:
| Boundary | Symptoms | Likely cause |
|---|---|---|
| Authorization | AccessDenied | IAM misconfiguration, role trust, resource policy |
| Network | Timeouts, connectivity errors | VPC routing, NAT, security groups |
| Capacity | Throttling, delayed processing | Concurrency limits, provisioned throughput |
| Deployment | Build failures, artifact errors | CodeBuild misconfiguration, missing artifacts, secret access |
AWS services are loosely coupled and independently scalable, each enforcing its own policies and limits. Understanding these boundaries allows developers to design resilient applications and quickly identify the root cause of failures.
My name is Naeem ul Haq. I’ve been working with AWS since its early days and have deep expertise across its evolving ecosystem.
