That's enough about the exam's internals.  What content appears on the AWS Certified Developer exam?

Looking at the exam guide, there are five content domains and each one is given a weight measured by a percentage.

Domain 1 is Deployment and is 22 percent of the exam.

Domain 2, Security, is 26 percent of the exam.

Domain 3 is Development with AWS Services  is 30 percent of the exam.  This makes it the largest single component.

Domain 4 is Refactoring and is 10 percent.

Finally, domain 5 is Monitoring and Troubleshooting and is 12 percent of the exam.

I am going to go over each domain and outline the services and features you will want to know and understand in order to pass the exam.

Overall, my opinion of the exam is that it is less about software development and more about supporting--or maybe sustaining--the development experience inside the AWS cloud.

There are no programming tasks in the exam.  The closest I came to programming is analyzing and understanding some pseudocode.  This makes sense because AWS supports multiple programming languages.  Even though each language has its own syntax, the general flow of the logic is the same.

I do not think of myself as a programmer.  I do write bits of code to get work done.  However, most of the time it's out of a sense of efficiency.  It only looks like laziness.  It's different, I promise.

Instead, this exam is about understanding the nature of software development in the cloud.  It's about understanding distributed systems, using available features to avoid wasting time and energy, all while being cost-effective, scalable, elastic, and secure.

Domain 1, Deployment, is 22 percent of the exam.  This equates to about 14 questions.

These 14 questions directly relate to 4 topics that are outlined in the exam guide.

1. Deploy written code in AWS using existing CI/CD pipelines, processes, and patterns. 
2. Deploy applications using Elastic Beanstalk. 
3. Prepare the application deployment package to be deployed to AWS.
4. Deploy serverless applications.

The first topic, Deploy written code in AWS using existing CI/CD pipelines, processes, and patterns means that you need to understand, conceptually, three topics and the related AWS tooling.  They are: 

1. Continuous Integration.
2. Continuous Delivery.
3. Continuous Deployment.

Primarily, this means you need to understand the services AWS CodeCommit, AWS CodeBuild, AWS CodeDeploy, and AWS CodePipeline.

The second topic, Deploy applications using Elastic Beanstalk, is unique because it calls out a specific AWS service.

No other service is called out by name on the exam guide.  

It is important to know how to create an application using Elastic Beanstalk, how to manage its deployment, how to upgrade the deployment, and how to remove it when it is no longer needed.  

Be sure, as you learn about Elastic Beanstalk, to pay attention to its best practices.  For example, learn about database deployments and how to ensure they survive moving to a new version.

Topic 3, Prepare the application deployment package to be deployed to AWS, mea  ns you need to have an understanding of how the .ebextensions folder works and how to manage various types of deployments.  Elastic Beanstalk has five deployment policies.  It's important to know what they are and generally when to use them.  If you need a hint, one of the most common deployments types is Blue/Green.  Find out what this type of deployment does and then figure out the other ones.

The last topic in this domain, Deploy serverless applications, can be challenging for people new to serverless applications.  In AWS, a serverless application is a combination of Lambda functions, event sources, and other resources that work together to perform tasks. 

It's important to note that a serverless application is more than just a Lambda function—it can include additional resources such as APIs, databases, and event source mappings.  

One of the best ways to learn about serverless application deployment is by using the AWS Serverless Application Model, SAM.  AWS SAM can be used to define, test, and deploy a serverless application.  

This topic of the domain includes aspects of the API Gateway.  This means knowing how to use the API Gateway to manage different versions of your application.  Keep in mind that the API Gateway is not limited to domain 1.  It figures, prominently, in domain 3, Development with AWS Services.  I'll get to that shortly.  The next thing I want to talk about is domain 2, Security.

In this domain questions covering security take up 26% of the exam.  This makes it the second-largest domain with 17 questions, give or take.  

There are three topics inside this domain.

1. Make authenticated calls to AWS services.
2. Implement encryption using AWS services.
3. Implement application authentication, and authorization.

The first topic is Make authenticated calls to AWS services. The second is Implement encryption using AWS Services. Finally, the third is Implement application authentication, and authorization.

Individually, these three topics can seem overwhelming.  Especially if you're new to some of the security best practices.

Though, in modern environments, thoughts of security should be included in every stage of development.  This might be what domain 2 is truly trying to evaluate.  Do you understand data stewardship and how to protect the data as it moves through the cloud using your applications?

Thankfully, the services covered are fairly connected and related.  It's about knowing which services and features are appropriate for the given use cases.

The primary AWS services covered include AWS IAM, Identity & Access Management, Amazon Cognito, AWS KMS, and AWS Secrets Manager.

Also included in the exam are subjects such as identity federation, identity providers, and SAML.

Many people equate security with encryption.  However, the services and features covered in this domain move past encryption and require you to know how to secure the access to data, limit access to those people and applications that need it, and how to scale access as needed.

If you're new to developing on AWS, here's a spoiler.  IAM as user management for applications does not scale.  Be sure to know effective methods for user management before taking the exam.

The third domain, Development with AWS Services, is the largest one at 30%.  

There are about 20 questions on the exam related to development spread across four different topics.

1. Write code for serverless applications.
2. Translate functional requirements into application design.
3. Implement application design into application code.
4. Write code that interacts with AWS services by using APIs, SDKs, and AWS CLI.

The first and last topic both start with the words write code.

The second topic is about application design and the third topic expects you to be able to turn your design into application code.

However, as I mentioned earlier, there's not one question about programming or programming languages.  There's no coding, at all.  

Instead, what's expected of you is that you need to know the steps required in order to design and implement code using the AWS cloud.

When writing code for the AWS cloud, you will be well-served knowing the differences between writing code on a monolithic platform and one that is serverless.

One common theme, I think, is microservices.  The challenge with serverless architectures is that data doesn't persist, internally, between functions.  This means you need to use some sort of external storage system for data like Amazon S3 or DynamoDB.

While there is no coding on the exam, there can be questions that test your understanding of programming logic.  The ones that I've seen use pseudocode to describe a Lambda function.  

The syntax is relatively simple but you're expected to understand the logic path and recognize how it could be made more efficient or secure.

Along the lines of understanding AWS Lambda, be sure to understand how resource allocation works.  By this, I mean look past how much memory has been allocated to a function.  How do you incorporate custom libraries, effectively use connection strings to databases, and manage external dependencies?

For example, if you're shown a loop that iterates over data and saves that data to a database, you might have to make it more performant by making it run faster.    You'll need to know how to manage the code's dependencies, the connection to the database, and security.  

One way to manage Lambda dependencies is using the relatively new feature called Lambda Layers.  A layer is an archive that contains additional code such as libraries, dependencies, or even custom runtimes.

Another thing that's important to know about serverless development is that Lambda functions are asynchronous.  They run when they're called and it is difficult to string them together.  This can create a challenge if you have a transaction that has multiple parts that must all succeed and rollback if one or more fails.

Spoiler alert: Using a Lambda function to call another Lambda function has never been a good idea.  As ideas go, it's up there with starting a land war in Asia or going against a Sicicilan when death is on the line.

Instead, AWS Step Functions was designed to address this type of problem and allows you to create and manage workflows.  Essentially, it is an event-driven orchestrator for serviceless code.

The second topic of this domain, Translate functional requirements into application design is, to coin a phrase, the process of AWS-ifying a problem.

If a question asks for MySQL, you need Amazon RDS.

If the problem requires web servers, think Amazon EC2.

Though, if both MySQL and web servers are needed, the answer could also be Elastic Beanstalk.  

Essentially, it's understanding what's available to you as a developer inside the AWS ecosystem and being able to create a solution using those AWS services and features without having to create it yourself.

The last topic in this domain, Write code that interacts with AWS services by using APIs, SDKs, and AWS CLI, can be tricky.

AWS treats their APIs as if they are contracts.  Understanding this idea will serve you well on the exam.  Breaking an API is the equivalent of violating trust.  Since the world runs on trust, it is important to protect it.  

One way to do this while creating solutions in the AWS Cloud is to use the API Gateway.  If you have several versions of an API, you can use the API gateway to ensure different versions of an API can coexist without interfering with each other.

This means being aware of and understanding how stage variables can be configured to interact with different endpoints.  

To me, this domain was mostly about taking advantage of existing AWS solutions, serverless architectures, distributed systems, asynchronous workflows, and microservices.

Moving to Domain 4, Refactoring; it is 10% of the exam.  This means you'll see 6 or 7 questions based on two topics.

1. Optimize applications to best use AWS services and features.
2. Migrate existing application code to run on AWS.

Optimize applications to best use AWS services and features is closely related to Domain 3.  What makes it different is the perspective.  Domain 3 is more about creating cloud-native applications.  Domain 4 is focused more on moving existing applications into the cloud.

Very often, this is a two-step process.  The first step is migration and the second step is optimization.

Moving workloads into the cloud might save some money at first but, in general, the lift-and-shift approach where an application moves as-is from an on-premises environment to the cloud often has limited savings.

The savings is realized when the application is refactored to be cloud-native.  If there was a mantra around this domain it is to think "Services not servers."  Always-on servers cost money.  When you're not using something, you should turn it off.  

Some things require a virtual machine.  For this, EC2 is the answer.  However, the sooner you can stop using EC2 instances, the quicker you'll see savings.

Services and features in this domain include AWS Lambda, Amazon Cognito, Amazon SQS, Amazon SNS, Amazon S3, AWS Single Sign-On, DynamoDB, and Amazon ElastiCache.

There could be questions about containers and containerization.  However, those questions are more about understanding how containers work.  More complex issues, like orchestration, are found in the Solutions Architect and SysOps exams.

Instead, questions about containers will be focused on integration with other AWS services.  If you're unaware, containers have no built-in storage.  This means that you'll need to know how to interact with services like DynamoDB and S3.  This includes use cases, security, and cost optimization.

Again, think services, not servers and be prepared to answer questions about replacing server-based applications with their AWS counterparts.  

An example of this that comes to mind is about user authentication.  If you've got a custom application that authenticates users, this is a candidate for replacing it with Amazon Cognito.

The fifth, and final domain, is Monitoring and Troubleshooting.  It is 12% of the exam and this translates to between 7 and 8 questions.

The two topics covered are:

1. Write code that can be monitored.
2. Perform root cause analysis on faults found in testing or production.

This domain is a little easier than it sounds.  Unlike the SysOps exam and, to an extent, the Solutions Architect exam, these two topics are focused on your application.  It makes sense as this is, after all, a developer-focused exam.

The three services you have to be the most familiar with are Amazon CloudWatch, Amazon CloudTrail, and AWS X-Ray.

Each one has very specific use cases. 

Amazon CloudWatch is a kitchen-sink type of service.  It is a monitoring and observability service from AWS that looks at infrastructure.  Infrastructure is the keyword here.

When you need to know what happened to a Lambda function and how it is performing, you'll use Amazon CloudWatch.

If you need to see what a Lambda function did, that's not infrastructure, that's an API call.  Those are monitored using Amazon CloudTrail.

There can be some overlap between them.  For example, I could write a Lambda function that writes to a log file.  This is a great use case for CloudWatch Logs.  However, if I write a generic print statement, this is making an API call to standard out and I would configure CloudTrail to catch it.

The third service that is featured inside this domain of the exam is AWS X-Ray.  This is a service that lets you follow code through a distributed system.   X-Ray collects and records trace data to create a service map that reveals latencies, HTTP statuses, and metadata that can be used for analysis.  

While there are no guarantees in life, this is another service you can expect to see inside the AWS Developer - Associate exam.

That covers everything that I wanted to talk about.

I've addressed the exam, what it evaluates, how it's built, and its contents.  The next steps are now yours.  

As a final thought, while you're studying, you can safely ignore services and features that are six months old or newer.  

It takes the exam writers some time to create questions based on new features and workflows.  If you recall, I mentioned some questions on the exam are not scored.  Often, these are newer services and features that are being considered.  It can take some time to find the correct wording for a situation.  So, don't stress about the really new services.  It's shiny and new but not relevant enough for evaluation.

It's been great fun walking through the developer exam with you.  I'm excited for you as you take your next steps on your cloud journey.

For Cloud Academy, I'm Stephen Cole.  Best of luck and we're cheering for you.