The AWS cloud practitioner exam is one of the most popular and well-respected exams in IT today. There are almost as many different paths to prepare for and pass the AWS Certified Cloud Practitioner exam as there are people who have already passed it, but we’ve identified 12 tips that will help you get the best results possible on your AWS certification test. Whether you’re a project manager looking to add more technical skills or an administrator looking for new opportunities in IT, passing this test can be a great step toward advancing your career!

These twelve simple steps can give you all the tools you need to ace any question related to the AWS Cloud Practitioner exam they throw at you:

The AWS Cloud Practitioner certification is an associate-level certification that proves your ability to use AWS services to build secure, cost-effective, fault-tolerant architectures.

  1. You can pass even if you know one service well

This tip may seem obvious but I’m including it because all too often people get lost looking at services they don’t need to know about. This tip does come with a warning though, study all services even those you think will not be tested as this exam tests knowledge across the board.

  1. Know the five services you must know about the cloud.

The five services everyone should know cold are: EC2, S3, RDS, ElastiCache, and CloudFront (this list is not definitive). The tips below assume you already have some familiarity with these services. For new users, this is a good list to start with as it contains all the basic building blocks.

I would also recommend that for each service you learn one thing really well such as IAM roles and policies on EC2, how to build a scalable database on RDS, and so on.

  1. Know your limits and how to monitor them

EC2 has many limits but there are only two you need to understand: hard drive space and instance limits. Every EC2 instance has a root volume size that cannot be increased but the space can be extended by adding EBS volumes.

Note that all data on an EBS volume is lost when an instance restarts or terminates. The number of supported running instances depends on the operating system, for example, Windows supports between 1-16 while Linux supports 2-60.

  1. Know how to use tags

Tagging resources is a great way to categorize resources and make it easier for you to find them later. You can assign a user defined key/value pair label to any resource in AWS (there’s no limit). For example: when launching an EC2 instance you could add the “env” tag with the value “production” so when you have a list of instances in the future and want to show only production instances it’s easy.

In addition, when using AWS Cloudwatch alarms you can add tags to monitor resources by adding them as event triggers. For example, we can add an alarm that triggers when we launch or terminate EC2 instances tagged with “env”: “production” (more tips on that below).

  1. Think like a sysadmin

Before creating any resources think about how you will monitor and manage them and how they will be controlled (including de-provisioning). This should help make decisions around which service to use. For example, do not create EBS volumes without attaching them to an instance. You must attach all volumes before they can be used. This may seem obvious but it’s easy to just create a volume and then forget that you have to attach them later.

Another example is storage: if your application uses a lot of disk space do not just create a large EBS volume as this will affect performance for other resources on the instance, instead, use multiple smaller volumes which can be mounted separately (and even onto separate servers).

  1. You can protect yourself from accidental deletion

In AWS it’s very easy to delete resources so much so that I recommend enabling protection from accidental deletion by selecting “Make this resource protected” when creating any resource which you expect to last longer than a few minutes. The only reason why you would need to remove the protection would be if someone else were managing the resource and you wanted them to be able to delete it.

For example: if someone else is managing your RDS instance they may need the ability to terminate the DB instance while you would not (protecting yourself from accidentally deleting a resource can also be helpful when testing changes in AWS).

  1. Do not use the EC2 AMI sharing feature unless you  know what you are doing

EC2 AMIs can be shared across regions but this is not recommended for two reasons: firstly, permissions cannot be controlled so anyone who has access to any of your AMIs can copy it and launch an instance anywhere (even without permission). Secondly, bandwidth usage could get expensive. It’s simpler just to upload one copy of your image per region and keep them there. If you want to share AMIs across regions use AWS Organizations.

  1. Build your own AMI’s and snapshots then delete them when finished

It is very easy to mess up the root volume of an EC2 instance (it is also possible to completely delete a running instance), we can protect ourselves from this by creating our own AMI and snapshotting it before we finish working with any resources. For example, I could launch a temporary EC2 instance and run my software on it, once I’m done I stop the instance, create an AMI from its snapshot, terminate the temporary instance, and remove its snapshot all at once. This way I know that my root volume will be safe until I choose to reuse it.

  1. Use multiple availability zones (AZ’s)

By default, AWS regions include at least two AZ’s which means that your application will be highly available if an entire AZ were to disappear. But this is not the only reason to use multiple AZ’s: applications deployed in more than one AZ can benefit from higher performance and lower latency while using less compute resources (i.e. smaller instances).

A good rule of thumb for deciding on how many AZ’s you should create your application it is to divide your total number of EC2 instances by 2 and choose this number of AZs within the region. Additionally, it does not hurt to have multiple AZ’s but if you are just running a few small servers then choosing just one might save you some money.

  1. Your cloud network can be a bottleneck but you can avoid creating one

Cloud networking is very easy to use and usually works out of the box, however that does not mean it is always efficient or scalable. I have seen many instances where multiple servers were slow because they all needed to communicate with each other using an inefficient cloud network with too many hops between them (which may be due to inexperienced AWS users who did not understand how NAT works).

This becomes particularly problematic when trying to solve performance problems: if you cannot easily monitor your application’s performance or debug it remotely then this will cause extra stress and frustration, while also adding time and cost to fixing the problem. Additionally, we must consider security: your data center should be as secure as possible and your communication channels should be encrypted so that no one will be able to intercept the data.

  1. Route 53 is your friend – use it for everything DNS related

DNS management is required when creating applications in the cloud: we need a way to map our domain names (like “myawesomeapp.com”) to (EC2) instances and Route 53 has an excellent developer-friendly API for this purpose (it is also very reliable and scalable).

You can easily create CNAMEs, A records, SRV records, etc… but if you want finer control of how you manage those DNS entries then keep in mind that changing them (using another HTTP request without first deleting the old entry) could take some time (Route 52 will cache DNS entries for about an hour) and that sending the wrong HTTP request could result in downtime (for example, deleting a CNAME record instead of simply changing its value).

  1. Backups are easy to create using snapshots but you need to delete them eventually.

If you want your backups to be reliable then keep this in mind: don’t leave old AMIs hanging around because these take up space on EBS volumes. Also, it is not advisable to use your root volume as a backup destination since it contains important data which must be easily accessible within a single AZ (so that if one fails the other(s) can still support your application).

This means that you should avoid mounting an EBS volume as /mnt/backup when creating AMIs from EBS snapshots by using the AWS CLI or API. An alternative to a single backup destination is a multi-destination approach: you could create an AMI in one AZ and then move it to another one where it will be further backed up by other solutions (e.g. S3).

I also recommend scheduling automatic backups so that they happen automatically, on a regular basis, and storing them both in different US regions (for disaster recovery purposes) and at least two other countries (to protect against the risk of your data being seized – yes it can happen).

Do prepare for your interviews as well. Read our more interview question blogs.