I recently became a AWS Certified Cloud Practitioner! The exam was relatively simple, it primarily involved understanding what all of AWS’s services do at a very high level. However, it doesn’t really prepare you to use the services, so I am continuing down the Solutions Architect Path with the Solutions Architect Associate certification!

I found a highly rated course on Udemy called “Ultimate AWS Certified Solutions Architect Associate 2026” produced by Stéphane Maarek. In an effort to show my competency, retain the information myself, and perhaps even teach you a thing or two, I’ll be producing some journal-style blog posts showcasing what I have learned.

Side note: anyone in the U.S. Air Force gets access to a bunch (all?) of Udemy courses for free through Digital University.

IAM

In our modern world, an “account” is typically tied to an “identity”. So your Facebook or Google account are tied to your Facebook and Google identies respectively. No other account can access your identity. In the world of cloud computing, this coupling falls apart, for an AWS “account” is not an identity, but moreso a bin that can house various resources. This bin can then be accessed by various user identities, which themselves are resources housed within the AWS account bin.

The service which manages these user identities is IAM, the first section of Stéphane’s course.

IAM or Identity and Access Management, is the AWS service that manages Users, Groups, permissions, and all the access policies used to access, add, remove, or modify the resorces in your AWS account.

An IAM User is an idividual identity used to access account resorces. This user can be a human user, or a progomatic user, such as one used in a script or program. For example, in my homelab I currently have a progromatic user that backs up my photos to an S3 bucket. The S3 bucket is a resorce, as are an EC2 virtual machine, a Lambda function, or Route 53 DNS entry (we’ll cover all these later on, stay tuned).

An IAM user can be part of any number of groups, includng zero. A group can only contain users, not other groups.

Policies

Both groups and users can have policies assigned to them. A policy is an Allow/Deny statement regarding a users level of access to a resource. A user or group can have any number of policies associated to it. In general, the most restrictive policy wins, though I haven’t tested this or researched too deeply to know exact policy execution order. Policies are represented as JSON objects and look like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AdminAllowAll",
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

The Version field will always be 2012-10-17. I couldn’t find references to any other version except 2008-10-17, so presumably those represent dates, but I am not sure.

The Statement section is then a list of objects, each of which Allow or Deny certain access to certain resources. This example is very simple, you could get much more complecated.

Each object includes a sid (I assume this stands for Security Identifier) which is an optional name for this object, it can be any name you want. Here, I have AdminAlowAll as an easily understandable name.

Under the sid is the Effect, which can be either Allow or Deny. This obviously controls whether the actions listed will be allowed or denied.

The Action section is a list of API actions that are being referenced. You can see here that I use a star (or asterisk) to represent all actions. Everything from access-analyzer:ListAnalyzers to xray:UntagResource and all the others in between (s3:ListAllBuckets, ec2:CopySnapshot and iotevents:DescribeAlarmModel to name but a few). These actions are all of the things that a user can do when interacting with a resource.

Lastly is the Resource section which specifies which resource these actions should apply to. Again, I have all resources selected here, by using the star. If you wanted to specifiy a specific resource, you would include its ARN or Amazon Resource Name. Some examples of ARNs are:

  • An S3 bucket: arn:aws:s3:::backup-photos
  • A IAM Policy: arn:aws:iam::102381579309:policy/test-policy-name
  • A VPC Subnet: arn:aws:ec2:us-east-2:122312579368:subnet/subnet-1f7cf9f1d81704b00
  • An SES Identity arn:aws:ses:us-east-2:881271468296:identity/mckay.one

Virtually everything you create on AWS will have an ARN associated with it, and each service has many, many granular API actions so these policy definitions can grow to be long and convveluted. Best practice of course would be to break them up into smaller modular chunks, but sometimes that is not an option.

I know I barely touched on actions and ARNs in this post, if you are interested in learning more, I suggest you do some more research, perhaps check out Amazon’s documentation!

Authentication Methods

Moving away from policies, actually authenicating as a user (whether human or otherwise) has a few different options:

  • The web console has a username and password, with optional (though recomended) MFA. The password requiremnets are customizable at the AWS account level from 6 digits and no special character requirments all the way up to 128 digits minimum and full upper/lower/number/special character requirements.
  • AWS has a CLI client that can be installed on Windows, macOS or any distro of Linux. This CLI requires an Access Key and Secret Access Key, which are basically a username and password, but randomly generated by AWS. These keys can be created in the web console, and are unique for each account, so don’t go sharing your access keys with your colleages!
  • Lastly, AWS has an SDK for JavaScript, Python, PHP, Node.js, Java, .NET, Go, Ruby, Arduino, C++, Embeded C, Android, and iOS. An SDK is a library of code that can be used while building a script or application. This also uses the same type of access keys as the CLI.

Fun Fact: The AWS CLI is written purely in Python, and so uses the Python SDK to interact with your AWS Account.

There is a bunch more to cover in IAM, but that is all for this post. I hope you enjoyed it, and learned something useful!