AWS Developer Associate Exam Domains
The current AWS Developer Associate outline has four domains: Development with AWS Services (32%), Security (26%), Deployment (24%), and Troubleshooting and Optimization (18%).
- The weights show relative blueprint emphasis, not an exact raw-question quota.
- The exam focuses on implementing and maintaining cloud applications, not broad architecture design or administering server operating systems.
On this page7 sections
The four-domain map
The AWS Certified Developer - Associate guide organizes the current exam into four domains. Development with AWS Services accounts for 32%; Security, 26%; Deployment, 24%; and Troubleshooting and Optimization, 18%. These weights help candidates distribute practice, but AWS does not publish them as a guarantee that a particular form will contain a fixed number of questions per domain. The tested task is usually a developer decision in context.
| Domain | Weight | Core question |
|---|---|---|
| Development with AWS Services | 32% | How should an application use AWS services and SDKs to meet behavior and data requirements? |
| Security | 26% | How should identity, permissions, secrets, and protection be applied to application code and resources? |
| Deployment | 24% | How should an application package, configuration, and release be deployed and validated? |
| Troubleshooting and Optimization | 18% | How can logs, metrics, errors, and performance symptoms be turned into a safe fix? |
1. Development with AWS Services
This largest domain concerns building and integrating applications with AWS services. Candidates should understand how code interacts with AWS APIs and SDKs, how data is read and written, how asynchronous events affect control flow, and how to choose service features that satisfy a requirement. A prompt may ask which approach keeps data durable, limits latency, handles retries, or supports a stated access pattern.
Consider a worker that receives the same queue message after a timeout. A robust application uses idempotent processing so a retry does not repeat an irreversible action. It distinguishes a delivery mechanism from the business guarantee the application needs. Another scenario might involve a DynamoDB lookup by a non-key attribute: candidates should reason about an index or data-model change rather than scan a large table on every request.
Development questions can combine code-level concepts with managed services, but preparation should remain aligned to the tasks and services in the guide. The objective is not memorizing every API operation. Learn to recognize when an SDK request, event trigger, database pattern, cache, or messaging service fits, and which failure mode to consider.
2. Security
Security represents more than a quarter of the outline. Identity and permissions are central in a developer context. Know the difference between the identity running a workload and the human who deploys it. Prefer temporary role credentials and least-privilege policies over access keys embedded in code, images, or environment files. Reason about identity policies, resource policies, explicit denies, and the scope of each action and resource.
A function can read from one bucket but must write only to a particular prefix in another. The sound approach is to grant its execution role only the required write action and resource scope, then account for any bucket policy or encryption-key authorization. Making the bucket public, granting administrator access, or storing a personal key in the function does not solve the problem safely.
Security also includes protecting data and secrets. Avoid putting database passwords in source control. Retrieve secrets through an appropriate managed mechanism and design rotation or failure handling around application needs. Understand encryption at rest and in transit in terms of service configuration and the key permissions that enable it. The exam tests secure implementation judgment, not abstract slogans.
3. Deployment
Deployment covers putting application changes into a repeatable operating environment. Candidates should understand artifacts, configuration, versioning, rollout behavior, and ways to detect or recover from a bad release. A package that works locally but fails in a managed runtime may have an incompatible dependency, missing environment setting, or incorrect execution permission.
For a release that must minimize user impact, compare deployment strategies through their consequences. A gradual traffic shift can expose a new version to a small portion of requests and allow monitoring before full rollout. A blue/green pattern supports switching between environments but requires attention to data compatibility and cost. The right answer depends on constraints, not on choosing the most complex pattern.
The current guide distinguishes developer tasks from broad CI/CD pipeline design and creation, which are outside the stated exam scope. Candidates should know deployment services and application release behavior identified by the guide, while avoiding time spent designing an entire enterprise pipeline unless another objective requires it.
4. Troubleshooting and Optimization
This domain asks candidates to move from symptoms to evidence. Reproduce the failure, identify the affected request or deployment, inspect relevant logs and metrics, check recent configuration changes, and test one safe hypothesis. The exam may present an AccessDenied response, timeout, elevated error rate, or unexpected latency. Each symptom points to different evidence.
A rising function duration might come from an external dependency, repeated database calls, cold starts, memory pressure, or a retry loop. Increasing memory or timeout without checking evidence can hide a symptom while leaving the cause intact. An authorization failure is better investigated by evaluating the execution role and relevant resource or key policy than by broadening every permission.
Optimization is tied to a goal: lower latency, fewer errors, reduced unnecessary work, or controlled cost. Caching can reduce repeated reads but introduces staleness and invalidation questions. Batching can improve throughput but affect latency or retry granularity. A good answer balances the requirement instead of treating one metric as the only concern.
How to prioritize study time
Use weights as an initial allocation, then adjust based on diagnostic performance. With 10 hours for domain review, a rough split is 3.2 hours on Development, 2.6 on Security, 2.4 on Deployment, and 1.8 on Troubleshooting. Those are planning proportions, not official exam quotas. A learner new to IAM may sensibly spend more time on Security and reduce that allocation only after explaining policy scenarios consistently.
- Read the task statements in the current guide and mark each familiar, uncertain, or unfamiliar.
- For each unfamiliar task, study service behavior in official documentation, then explain it without looking.
- Solve a scenario with a constraint such as least privilege, duplicate delivery, rollback safety, or latency.
- Record why tempting alternatives fail, especially answers that broaden permissions or add operations without addressing the cause.
- Revisit the blueprint before the exam version changes; do not mix current and replacement outlines.
What the outline excludes
The current guide marks broad solution architecture, distributed-system and microservice architecture design, CI/CD pipeline design and creation, IAM user and group administration, server and operating-system administration, and AWS networking infrastructure design as outside the core exam task scope. Developers may encounter these subjects at work, and another exam may cover them, but they should not displace the four domains in a focused study plan.
AWS lists October 27, 2026 as the opening date for registration for an updated Developer Associate exam and December 1, 2026 as the last test date for the current version. On October 6, the detailed accessible guide describes the current version. Use the replacement guide when available rather than assuming this domain map will remain unchanged.
The domain boundaries are useful for navigation, but real scenarios can test more than one. An event-processing question may sit in Development because it asks how the application uses a service, Security because it concerns the role, and Troubleshooting because it describes a duplicate or denied request. Do not force every practice question into one isolated box. Instead, identify the primary task and note the adjacent skills needed to answer it correctly.
The 32%, 26%, 24%, and 18% weights add up to the full outline, but they do not mean that the exam has exactly 16, 13, 12, and 9 scored questions per domain. The test has 50 scored items and score reporting is scaled. Forms can differ, and AWS does not publish a raw count quota. Use weights to allocate study attention, not to predict which questions can be ignored.
When mapping a third-party course, compare task verbs as well as domain names. 'Understand security' is too vague to prove coverage. Look for whether it teaches the specific developer actions in the official guide, such as securing application access, protecting sensitive data, or troubleshooting permissions. A course may use different module labels and still align, but the learner should be able to connect each lesson back to an official task statement.
If a blueprint task is not familiar, translate it into a developer action. For a security task, that may mean selecting an application identity, protecting a secret, or explaining a denied service call. For a deployment task, it may mean packaging dependencies, managing configuration, or deciding what to do after a failed rollout. This action-oriented translation keeps study concrete and helps distinguish the Developer Associate objectives from general cloud-architecture material.
Common questions
What are the current domain weights?
Development with AWS Services 32%, Security 26%, Deployment 24%, and Troubleshooting and Optimization 18%.
Are those exact question quotas?
No. The percentages show blueprint emphasis, not a guaranteed raw item count.
Is CI/CD pipeline design in scope?
Broad pipeline design and creation are outside the current guide's stated developer task scope.