Episode 3: AWS IAM Deep Dive: Users, Roles, Policies & Security | SAA-C03 Exam Prep

Hey everyone, Balu here. Welcome to episode 3 of the AWS Solutions Architect Exam Preparation Series on Tech Talk with Balu. Today, we're diving into one of the most fundamental and heavily tested topics on the exam. AWS Identity and Access Management, or IAM, for short. Now I'm going to be completely honest with you. A lot of people think IAM is boring. They want to jump straight into EC2, S3, all that exciting stuff. But here's the truth, if you don't understand IAM, you're going to fail the exam. I'm not exaggerating. IAM is the foundation of everything in AWS. Every single service you interact with uses IAM for permissions. Every architecture question involves IAM somehow. And on the actual exam, you'll see IAM concepts woven into at least 30 to 40% of the questions. So today, we're going to master IAM. We're going to understand users, groups, policies and roles. We're going to talk about MFA, password policies and access keys. And most importantly, I'm going to show you the exam traps, the sneaky questions AWS uses to trip people up. By the end of this episode, you will not only understand IAM as a topic, but you'll be able to spot IAM questions on the exam from a mile away. I promise, let's get started. All right. Let's start with the big picture. What is IAM and why does it exist? IAM stands for identity and access management. At its core, it answers three questions. Who are you? That's authentication. What are you allowed to do? That's authorization. Can I verify your really you? And that's access control. Very critical. So who are you? And can I really verify you are who you claim to be you? Now here's something critical for the exam. IAM is a global service. This is really important. When you create an IAM user or a role, it exists across all AWS regions simultaneously. So it's not like EC2 or S3 where you choose a specific region. IAM is truly global. Let me repeat that because it comes up on the exam. IAM is not region scoped. If you create a user in the AWS console while you're viewing the US East one region, that user exists globally. They can access resources in any region you give them permission for. The root account, your first big security lesson. When you first create an AWS account, you get something called the root account. This is created by default and it has complete unrestricted access to everything. I mean everything. It can close your account, change billing, delete all resources to everything. Here's a golden rule. And this is tested on the exam constantly. Never use the root account for daily tasks. Never do that. Think of the root account like the master key to a building. You don't carry it around every day. You lock it in a safe and only use it for emergencies. So what should you be doing with your root account? So there are three things. First, secure it immediately. Enable MFA, which is multi factor authentication on day one. I'm not kidding. Day one. Just do it. Second, create an IAM user for yourself for daily administrative work. And the third, lock away those root credentials and only use them for a few tasks that actually require root access. Things like changing your account payment methods or closing your account. So real world example. I once consulted for a company where a developer was using the root account to test Lambda functions. One day, they accidentally run a script that deleted their entire S3 bucket with years of customer data. Why did it succeed? Just because the root account has permission to do anything, including catastrophic mistakes. If they had been using an IAM user with limited permissions, that script would have been denied. The data would have been safe after all. For the exam, remember, if a question mentions the root account and daily operations, the same sentence that's wrong. root account is for emergency use only. Now let's talk about IAM users and groups. This is where you actually start managing who has access to what? I am users. And I am user represents a person or an application. It's a digital identity. One person equals one user. That's a rule. Each IAM user has a unique name within your AWS account. Access for accessing AWS, either through a password for console access or access keys for programmatically access or both. They would have permissions that determine what they can do in AWS. Let me give you a real world scenario. You're a company with 50 employees. You create 50 IAM users, one for each person. Alice gets a user called Alice. Bob gets Bob. Each person gets their own unique credentials. Why one user per person? It's for security and auditing. If something goes wrong, you need to know exactly who did what. If five people shared one account, you will never know who made the mistake that cost you tens of thousands of dollars. Let's look at an exam trap question. A company has five developers who all use the same IAM user account to save on costs. This is a good practice. People think sure it saves having multiple users. Wrong. The answer is no. This wireless, the principle of individual accountability. One person equals one user always. IAM groups. Now if you have 50 users, you don't want to be assigning permissions to each one individually. That's where groups come in. Groups are basically a collection of users. You create a group, assign permissions to the group and then add users to that group. The users inherit all the permissions from that group. Now for a real world example. You have 10 developers, five testers and let's say three database administrators. You create three groups. Developer group. They have permissions to access EC2, S3 lambda. The testers group would have really access to the test environments and they would be the DB admins group. They would have full access to RDS and DynamoDB. Add your 10 developers to a developer group. Now all 10 automatically get those permissions. When you hire an 11th developer, just add them to the group done. So critical example point, groups cannot contain other groups. This is a top question you will see. Groups cannot be nested. You cannot have all developers group that contains a senior developers group and a junior developers group. No nesting allowed. Groups contain only users. Another example. Question. Is a member of multiple groups how are permissions handled? The answer is user gets the union of all the permissions from all the groups that he is in. If group A allows S3 access and group B allows EC2 access, the user has both S3 and EC2 access. Now let's look at an important limitation. A user can be a member of multiple groups but they don't have to be in any group at all. You can have users without any group membership, though that's not a best practice. For the exam, memorize this. One person equals to one user. Groups contain users only, no nesting. Users inherited permissions from groups. A user can be in multiple groups or user can be in zero groups. Alright, now we get to the heart of IAM policies. This is where you define what people can and cannot do. So what's a policy? A policy is a JSON document that defines permissions. It's a set of rules that say, allow this action on this resource or deny this action on this resource. Think of it like a contract. The policy spells out exactly what someone is allowed to do. What's the anatomy of a policy? The JSON structure. Every policy has a specific structure. Let me break this down for you because understanding this is critical for the exam. A policy has these elements. There is a version. This is always 2012, 10, 17. That's the current policy language version. Just memorize it. Every policy starts with this. Well, it will have statement. This is an array that contains one or more permission rules. This is where the actual permissions live. And each statement you have effect, which is either allow or deny. This is whether you're grinding or blocking the permission. There is an action field, which is a specific API operation you're allowing or denying. For example, estri-colon-get-object means reading an object from estri-bucket. EC2-colon-describe-instances means listing EC2-instances. Use the format service-colon-action. The asterix function means all actions. So estri-colon-asterix means all estri-actions. Next field would be resource. The specific AWS resource the application applies to. This is an ARN Amazon resource name. Again the asterix star means all resources. Let me take you through a real example. A policy that allows someone to read objects from any estri-bucket. So you would have the version, which would be the date that we talked about. The statement would have the effect, which would be allow. The action would be. s3 call and get object and the resource would be staff to say or asterisk to say I want everything from that s3 bucket. Now a real world scenario you want to give your developers read only access to easy to they need to see what instances are running but they shouldn't be able to start stop or terminate anything so here's the policy start with the version again the statement effect would be allow the action would be easy to call and describe asterisk and the resource would be asterisk. Let's break all of this down. The easy to call and describe with the asterisk means all easy to describe actions like describe instances describe volumes describe security groups everything that starts with the word describe but no start stop terminate or modify actions the least privilege principle let's look at that one here's a golden rule that shows up on the exam again and again the principle of least privilege this means give users the minimum permissions they need to do their job nothing more if a user only needs to read from s3 don't give them full s3 access give them read only access if they only need to access one specific s3 bucket don't give them access to all the buckets give them access to that just one bucket let's look at an exam question pattern now a developer needs to read files from an s3 bucket called company hyphen data which policy is most appropriate let's look at the wrong answers first full s3 access that's wrong read access to all s3 buckets that's wrong too the right answer is that you only provide read access to that company hyphen data bucket the exam loves testing whether you understand the concept of least privilege now let's look at inline policies versus managed policies there are two ways to assign policies number one managed policies these are standalone policies that exist independently you create the policy once then you attach it to multiple users groups or roles there are two types of managed policies AWS managed policies that's created and managed by AWS examples of them are amazon s3 read only access or administrator access these are ready to use then there is customer managed policies you create these yourself you write the JSON you save it as a policy then attach it where needed the second type of policies the inline policies these are policies embedded directly into a single user group of role they can be reused when you delete the user the inline policies deleted too so for the exam here's the rule use managed policies for permissions you will use across multiple users or groups they are reusable and easier to manage that way use inline policies only for one off unique permissions that apply to a single user or role and should never be reused so best practice for the real world what would you do stick with managed policies create customer managed policies for your company specific needs attach them to groups not individual users this makes management much much easier now let's look at policy evaluation logic how AWS decides this is really important for the exam when AWS evaluates whether to allow an action it follows this logic by default everything is denied it starts with the assumption that nothing is allowed then an explicit allow overrides the default deny if a policy says allow s3 hyphen get object then that action is allowed then it looks for any explicit deny overrides anything if any policy say deny s3 hyphen get object then that action is denied even if another policy say allow that's very important so let's look at an exam scenario now a user is in two groups group a has a policy that allows all s3 actions group b has a policy that denies s3 hyphen delete object question can the user delete objects from s3 the answer is no the explicit deny in group b overrides the allow that if specified in group a so remember deny always wins another example policy variables policies can use variables to make them dynamic for example you would have a json file like effect allow action s3 colon asterix and resource resource to a link for bucket now that link in the resource field could have a variable that you can replace with the actual username so if Alice logs in she can only access a particular area within that particular bucket but if Bob logs in he will only have access to his own area this is a really powerful pattern for per user permissions without creating individual policies for the users so for the exam please know that policy variables exist and you can dynamically do these kind of configuration and it's a very powerful pattern now let's talk about iam roles this is where things get really interesting and this is heavily tested on the exam what is a role a role is a set of permissions that can be assumed by an entity a user an application or even an AWS service think of it like this you're an actor you have your normal identity but sometimes you put on a costume and assume a different role while you're in that role you have different abilities and permissions then you take off the costume and go back to being yourself that's exactly how iam roles work so why roles why not just use users well great question let me show you with a real world example let's look at scenario one easy to instance accessing an estri bucket you have an easy to instance running a web application the application needs to read files from the estri bucket what we have a bad approach is to create an iam user generate access keys and hard code those keys in your application on the easy to instance why is it bad first of all those keys are sitting on the easy to instance if someone hacks the instance they steal the keys remember keys don't expire if they're stolen they're valid forever until you manually rotate them you have to manage key rotation manually so what would be a good approach create an iam role with estri read permissions and then attach that role to the easy to instance and why is it better fast for no keys to steal the role uses temporary credentials that AWS automatically retites the credentials are valid for a limited time that's usually 15 minutes to 12 hours and if someone compromises the instance the credential expire quickly this is a massive example topic remember for easy to instances accessing AWS services always use roles never use access keys let's look at the scenario two cross account access if you have two AWS accounts a production account and development account developers work in the dev account but sometimes they need access to the production account to troubleshoot you don't want to create iam users in the production account for every developer that's a management nightmare instead you create a role in the production account that trust the development account developers in the dev account can assume that role to temporarily access protection this is called cross account access and it's tested on the exam scenario three AWS service to AWS service lambda functions need to write logs to cloud watch and read from dynamo DB you create an iam role with permissions for cloud watch logs and dynamo DB you assign that role to the lambda function now lambda can access those services this is called a service role AWS services use roles to interact with other AWS services so how roles work the assumption process when you assume a role here's what happens you request to assume the role by calling the AWS sts which is security token service assume role api AWS checks if you're allowed to assume that role based on the roles trust policy if allowed AWS sts gives you temporary security credentials and access key id a secret access key and a session token now you can use those temporary credentials to make api calls the credentials they expire after certain time you specify this but it's typically 15 minutes to 12 hours now let's look at trust policies versus permission policies this is confusing for a lot of people so pay attention every role has two types of policies trust policies who can assume this role this defines who or what is allowed to assume the role it's like a guest list these entities are allowed to use this role in example is effect allow principle service would be easy to dot amazon aws dot com and the action would be sts calling assume role this trust policy says easy to instances are allowed to assume this role permission policy what can the role do this defines what the role is allowed to do once it is assumed it's like a job description once you're in this role here's what you can do an example would be the effect allow action s3 hyphen get object and resource asterisk this permission policy says this role can read objects from s3 for the exam understand this trust policy equals to who can assume the role and permission policy equals to what the role can do now let's look at common exam scenarios with the role rules. Question one, an application running on EC2 needs to access DynamoDB. What's the most secure way? The answer is create an IAM role with DynamoDB permissions and attach it to the EC2 instance. What you can't do is to create an IAM user and hard-cord the access case. Never do that. Question two, a Lambda function need to write logs to CloudWatch. How do you grant permissions? The answer is create an IAM role with CloudWatch logs permissions and assign it to the Lambda function. Question three, developers in account A need occasional access to the resources in account B. What's the best approach? The answer is create a cross account role in account B that trusts account A. Developers assume the role when they need access. Now, rules for external identity federation. This is advanced, but you might see this on the exam. You can use rules for users who authenticate with external identity providers like Active Directory, Google or Facebook. As an example, your company uses Active Directory for employee authentication, employees sign into AD and AWS maps their AD identity to an IAM role. They get temporary AWS credentials based on their AD group membership. This is called federation and rules make it possible. Right. Let's now talk about first and second lines of defense for your AWS account, password policies and multi-factor authentication. Password policies, the first line of defense. AWS lets you define a password policy for your IAM users. This forces users to create strong passwords. You can configure minimum password lengths. It requires at least 8, 10, 12 or 14 characters. For the exam, know that longer is better. A 14 character password is exponentially harder to crack than an 8 character password. It requires specific character types, so forces users to include uppercase letters, lowercase letters, numbers and symbols. This makes brute force attacks much harder. It allows users to change their own passwords. This is usually a good idea. Users should be able to change their password if they think it's been compromised. Enable password expiration. Forces users to change their password every 30, 60 or 90 days. This is called password rotation. Prevents password reuse. Remember, the last 5 or 10 passwords and don't let the users reuse them. Now, for a real world example, a financial services company sets a policy requiring 14 character passwords with uppercase, lowercase numbers and symbols. Passwords must be changed every 60 days, and the last 10 passwords cannot be reused. This dramatically reduces the risk of password compromise. For the exam, understand that strong password policies improve security. If a question asks about securing, I am users, password policies are part of the answer. Multi-factor authentication. The second line of defense. MFA is a single most important security measure you can implement and the exam tests this constantly. What is MFA? MFA requires two things to log in, something you know which is your password and something you have, a physical device or a virtual device generating a code. So even if someone steals your password, they can't log in without your MFA device. A real world impact. Let's say a hacker steals your I am user password through a phishing attack. Without MFA, they can log into your AWS account and start launching Bitcoin mining instances that cost you thousands of dollars. With MFA enabled, the hacker has your password but not your phone. They can't get past the login screen, your account is totally safe. Now, MFA device options. AWS supports several different types of MFA devices. There is virtual MFA devices. These are apps on your phone or computer. The most common one is Google Authenticator but there is also OTHY Microsoft Authenticator amongst others. The app generates a six digit code that changes every 30 seconds. You enter your password and the current code is the login. The advantages are it's free, it's easy to set up, works on multiple devices. The disadvantages of these are that if you lose your phone, you lose access, though you can use backup codes. The second type of MFA is U2F security keys. These are physical devices like Ubiki. You plug the device into your computer's USB port and tap it to authenticate. The advantages are it's very secure, it can't be fished. The device cryptographically verifies it's stock into a real AWS. One key can work for multiple accounts also. The disadvantages are it costs money, it's around $20-$50 and it can be lost or stolen. It's a physical device. There's also the hardware key fobs. These are standalone devices that display a six digit code. Jamalto is a common brand. The advantages are it doesn't require a phone, it's very secure, but the disadvantages are against much more expensive, costing around $50-$100 and of course a can you can misplace it. For GovCloud or high security environments, there's also ShowPass ID which meets specific government compliance requirements. So a critical example point MFA on root account is Mandatory. The example test this, you must enable MFA on your root account. This is non-negotiable. So question pattern would be, a company wants to secure their AWS account. What should they do first? The answer is enable MFA on the root account. It's not to create an IM user and definitely not to set up CloudWatch alarms. First priority is definitely to enable MFA on the root account. Now MFA for all IM users. The best practice is to enable MFA for all IM users. Not just root, especially for users with administrative permissions. If an IM user can launch easy to instances of deleted strip pockets, they should have MFA enabled. Let's look an exam scenario now. A company's security policy requires all users with admin rights to use MFA. How do you enforce this? The answer is create an IM policy that denies all actions unless MFA is authenticated and then attach this policy to the admin group. This is possible with the policy condition that checks for MFA. The users can't do anything unless they have logged in with MFA. Okay, let's talk about access keys. This is how applications and scripts access AWS programmatically through the CLI or SDK. So what are our access keys? Access keys are long term credentials consisting of two parts. The first part is the access key ID. This is like a username. It's public and it identifies who is making the APA call. It looks like a long string. The second part to it is the secret access key. This is like a password. It's secret and you should never share it. Together, these two components allow you to authenticate to AWS via the CLI, which is the command line interface or the SDK, which is a software development kit. When do you use access keys now? Access keys are for programmatic access. So if you're using AWS CLI from your laptop or an application making AWS APA calls or scripts that automate AWS task, you need access keys for them. Now for a critical security rule, never ever share access keys. This is test on the exam. Access keys are like password. You should never share them. You never put them in your code. You never commit them to GitHub. Now, let me take you through a real world disaster story. A developer accidentally commits their AWS access keys into a public GitHub repository. Within minutes, automated bots found those keys launched hundreds of easy to instances for cryptocurrency mining and racked up a bill of $50,000. This happens constantly. Don't let it happen to you. Best practices for access keys. To what are the best practices for access keys for humans using CLI? Generate access keys for your I am user. Download them once. You can't retrieve the secret key again after that. So remember that. Configure the AWS CLI with those keys. Now for applications running on AWS like EC2, don't use access keys. Use I am rolls instant. I can't stress this enough. Easy to instances. Lambda functions, ECS containers, they should all use rolls not access keys. Why? Because rolls use temporary credentials that rotate automatically. Access keys are long term and don't expire unless you manually rotate them. Now rotating the access keys. What are the best practices? Rotate access keys regularly like say every 90 days as a common interval. And why? If a key is compromised and you don't know it, regular rotation limits the damage. The compromised key becomes invalid after rotation. So how do you rotate your keys? So create a second access key for the user. You can have two at a time. Update your applications to use the new key. Test that everything is working okay with the new key. And then just obsolete or delete the old key. Now for an exam trap question is how many access keys can an I am user half? The answer is maximum of two. This allows for rotation of the keys without downtime. You create the new key while the old key is still active, then switch over and then delete the old key. Let's look now at IAM Credentials report auditing access keys. AWS provides a report that lists all the IAM users and the status of their credentials, passwords, access keys, MFA devices, so and so forth. This report shows when access keys were created, when they were last used, whether MFA is enabled, so and so forth. So for the exam, know that this report exists and it's useful for auditing and enforcing security policies. Now for an exam scenario. How can a security team identify IAM users who haven't used their access keys in over 90 days? The answer is generate an IAM Credentials report and filter for access keys with a last-use date older than 90 days. Now, AWS provides two really important tools for monitoring and improving IAM security. The show up on the exam all the time, so please do pay attention. IAM Credentials report account level audit. This is a report that lists all users in your AWS account and the status of their credentials. What it shows are user name, where they have a password for console access, when the password was last used, whether MFA is enabled, whether they have access keys, when the access keys were created, when the access keys were last used and so forth. Why is this important? You can use this report to enforce security policies, find users who haven't used their access keys in six months, delete those keys, find users without MFA, require them to enable it. So, for a real-world use case scenario, a company runs this report monthly. They find that 20 users out of 200 have been logged in for over 90 days. They delete those users to reduce their attack surface. They also find that 15 users don't have MFA enabled. They send those users an email requiring them to enable MFA within one week or their access will be revoked. So, for the exam, remember, Credentials report is equal to account level, equals to shows all users and their credentials status. Now, let's look at IMAXISAdvisor user level audit. This is a different tool that shows which AWS services a specific user or role has accessed when they last access them. For example, you might see something like, "Estery Last Access" today, "Ec2 Last Access" six months ago, "Adius Last Access" 30 days ago, "Lamda Never Accessed." Why is this important? So, this helps you implement the principle of least privilege. If a user has permission to access Lambda, but they have never used it, you can remove that permission. Let's look at a real-world use case. You have a developer who originally needed to access Adius, DynamoDB, S3, and Lambda. Over time, the role changed. They haven't touched Adius or DynamoDB in a year. Access Advisor shows you this and you remove those permissions. Now, the user only has access to what they actually need. Now, for the exam, remember, "Axis Advisor" equals user level, equals shows which services a specific user has accessed. Now, let's look at an exam comparison question. What's the difference between IAM Credentials report and an IAM Access Advisor? The answer is, "Scredentials report is account level, shows all users, credential status, that's the password, keys, the MFA, so and so forth." Whereas, the Access Advisor is at user level. It shows which services a specific user has accessed. So, both are tools for auditing and enforcing least privilege, but at different levels. Alright, let's talk about IAM Best Practices now. The exam loves to test these and they are framed as scenario questions. Let me walk you through each one with real-world context. Best Practice 1. Don't use root account. We've covered this, but it's so important, I'm repeating it again. The root account should only be used for changing account settings, closing your AWS account, changing AWS support plans and a few other account level tasks. Everything else should be done with IAM users. So, an exam question would be, "What is the AWS Best Practice for the root account?" The answer is, "Secure it with MFA and don't use it for daily tasks." On to Best Practice 2. One physical person equals one IAM user. Never share IAM users. If Alice and Bob both need access, create two users, one for Alice and one for Bob. And why is that? Accountability. If something was wrong, you need to know exactly who did it. A real-world example would be three developers were sharing one IAM user account. One of them accidentally deleted a critical, RDS database. The company had no way to determine which developer was responsible for that. After that incident, they created separate IAM users for each developer and enabled cloud trail logging. Now, every action is traceable to a specific person. On to Best Practice 3. Assign permissions to groups and not users. Don't assign policies directly to individual users. Assign policies to groups, then add users to groups. And why would you do that? It's for manageability. If you have 50 users and you need to change permissions, you don't want to modify 50 users individually. Change the group policy once and all 50 users get the update. Now, for a real-world example, the company with 200 employees organized them into groups. It would be developers, testers, operations, database admins, data scientists. And when they needed to grant cloud watch access to everyone, they attached the cloud watch policy to all the five groups done. 200 people got the permission instantly. Best Practice 4. Use strong password policies. Require complex passwords. Require password rotation. Prevent password reuse. This reduces the risk of password compromise. An exam question would be, how can a company enforce strong passwords for all IAM users? And the answer is configure an IAM password policy with minimum length and complexity requirements. Now, for Best Practice 5. Enable MFA. Multi-factor authentication should be enabled for root account, which is absolutely mandatory. All IAM users with administrative privileges. And ideally, you should be enabling that for all IAM users. This is your best defense against stolen passwords. Now, for an exam scenario. A company wants to reduce the risk of credential theft. What should they implement? The answer is enable MFA for all users, especially those with elevated permissions. Now, for Best Practice 6. Use rules for applications. Applications running on EC2 lambda ECS they should use IAM rules, not access keys. And why? Rules use temporary credentials that rotate automatically. Access keys are long term credentials that don't expire. Now, for an exam question. An application on EC2 needs to access esterry. What's the most secure method? The answer is to attach an IAM role with esterry permissions to the EC2 instance. Definitely don't generate access keys and hard code them in the application. Now, for Best Practice 7. Rotate access keys regularly. For situations where you must use access keys like developers using CLI locally, rotate them every 90 days. Best Practice 8 would be to regularly audit your IAM users with credential report. Remove unused access keys, enforce MFA. Use access advisor to identify and remove any unused permissions and implement the concept of least privileged. An exam question would be how can a security team identify unused permissions to enforce least privileged? The answer is to use IAM access advisor to see which services each user has accessed. Then remove permissions for the services they haven't used. Best Practice 9. Navajo share access keys. Access keys are like your password. Don't put them in code, don't commit them into GitHub, don't email them, don't share them. If you need to give access to a third party, create an IAM role they can assume, don't give them keys. Now, real world disaster, we've all heard the stories. Developer commits code with access keys to GitHub. Borts find the keys within minutes and then they go, it launches hundreds of instances and then you pay the bill. Don't be that developer. Alright now, the most interesting bit, the A-ZAM traps. These are the sneaky questions AWS uses to test you if you really understand the topic of IAM or if you're just memorizing facts. Frapp1. Root account for daily operations. Question. An administrator uses Root account to launch easy to instances and manage S3 buckets daily. Is this acceptable? People think the Root account has all permissions so it's powerful and useful. It's wrong, the Root account should never be used for daily tasks, remember that. So the answer is no. Create an IAM user with administrative permissions for daily operations and then reserve the Root account for account level tasks only. Top number two, sharing I am users. Question. To save on management overhead, five developers share a single IAM user. This is good practice. People think fewer users means less management. It's wrong, one person equals one user always. So the answer is no, each developer should have had their own IAM user for accountability and auditing purposes. Trap number three. Groups within groups. Question. Can you create an IAM group called All Engineers that contains developer group and a Q group? People think groups should be hierarchical like in active directory, but as strong groups cannot contain other groups in AWS IAM. So the answer is no, IAM groups can only contain users, not other groups, no nesting allowed. Trap four. Inline versus managed policies. The question is, you need to assign the same permissions to 20 different users. Should you use inline policies or managed policies? You don't want to use inline policies. So the answer is you want to use managed policies because you want to create at once, attach it to all the 20 users at once. It's much easier to manage. Now let's look at Trap five, explicit deny versus allow. The question is, a user is in group A, which allows all restrictions. And he's also in group B, which denies estri-hyphen delete object. Can the user delete estri-objects? People think they allow in group A, overrides the deny in group B. Wrong. Deny always wins. So the answer is no, an explicit deny overrides all allows. The user cannot delete objects. Onto Trap six. Access keys on easy to. The question is, an application on easy to needs to read from estri. Should you generate access keys and put them on the instance or use an IAM role? People think access keys work fine. Wrong. Access keys are long term credentials that can be compromised. Remember that. So the answer is to use an IAM role. Attach the role to the easy to instance. The role provides temporary credentials that rotate automatically. This is one of the most common exam questions. Trap seven. IAM is regional. The question. You create an IAM user in the US East One region. Can that user access resources in EU West One? So people think IAM users are regional, so they are stuck in one region. No, it is not. So yes, IAM users exist globally and can access resources in any region. You give them permission for. Trap number eight. Password policy details. Question is, a company wants to prevent users from reusing their last five passwords. Can IAM password policies enforce this? The answer is yes. Password policies can prevent password reuse. You can remember the last one to 24 passwords. Trap number nine. Maximum number of access keys. Is how many access keys can an IAM user have? People think as many as needed, but there is a hard limit. So the answer is maximum of two access keys per user. Remember that. This allows for key rotation without downtime. Trap number 10. MFA device per user. Question. Can multiple IAM users share the same MFA device? People think sure it's like sharing a password. But wrong, MFA devices should never be shared. The answer is no. Each user should have their own MFA device, sharing defeats the purpose of multi factor authentication. Trap number 11. IAM role trust policy. Question. What does the trust policy of an IAM role define? People think what the role can do. Wrong. That's the permission policy. So the answer is the trust policy defines who can assume the role. The permission policy defines what the role can do once assumed. Trap number 12. Service control policies. It's an advanced question. Can IAM policies be used to restrict the root account? People think IAM policies control everything. But it's wrong. IAM policies don't affect the root account. The answer is no. IAM policies have no effect on the root account. To restrict the root account, you need AWS organizations with service control policies as CPs. This is an advanced topic, but it can show up on the exam. Alright, we're almost done. Let me give you some rapid fire exam tips for IAM questions. Tip number one. Look for keywords. If you see these keywords in a question, here's what they mean. Most secure. Usually means use IAM roles instead of access keys. IAM.MFA implement the concept of least privilege. List privilege. Give minimum permissions needed. Don't give full access when read only works. Credential theft. The answer involves MFA. Accountability or audit trail. Remember one person equals to one IAM user enable cloud trail. Application on EC2 needs access to S3. Use an IAM role not access keys. Tip number two. Eliminate the wrong answers. If a question mentions root account for daily operations, then the answer is wrong. Sharing IAM users. That's wrong. Access keys hard coded onto EC2 is wrong. No MFA for admin users. That's wrong as well. Eliminate these immediately. Tip number three. Default to the most secure option. Even in doubt pick the most secure option. The exam generally favors security. Remember that. Tip number five. Read the question carefully. The exam might ask which is possible. Pick what technically works at that point. Which is the best practice. Pick what AWS recommends. If they ask which is the most cost effective, different answer than the most secure. That's what you want to pick. Tip number five. Use policy Jason. You will need to write Jason on the exam, but you should be able to read it and understand what it does. Practice looking at policy examples and determining what they allow or deny. On to tip six. Understand roles deeply. Roles are everywhere on the exam. Easy to rolls. Lamp the rolls. Cross account rolls. Service rolls, etc. Make sure you understand when to use roles and how they work. Tip number seven. Know the tools. I am credentials report. That's account level audit. I am access advisor. That's user level audit. Cloud trade that logs all API calls for auditing. Just know when to use each one. Okay. All right, everyone. That's it for I am. Let's recap what we've covered in this session. We started with a big picture. I am a global. The root account should never be used for daily tasks. We covered users and groups. Groups can't be nested. We deep dive into policies. The Jason structure effect action resource. Lease privilege principle. We talked about roles. Temporary identifies for services and applications. Trust policies versus permission policies. We covered password policies and MFA. The first and second line of defense. We discussed access keys for programmatic access, but use roles whenever possible. We looked at I am security tools, credential report and access advisor for auditing. And finally, we went through the best practices and the common exam traps. I am is the foundation of AWS security. Every service you use, every architecture you build, I am is involved. After I am and you're well on your way to passing the solutions architect exam. In our next episode, we're going to dive into more advanced AWS topics and some interesting related exam questions. If you found this episode helpful, make sure you're subscribed to Tech Talk with Ballu. And if you have questions, drop them in the show notes, please. Until next time, keep studying, keep practicing and I will see you in the next one. This is Ballu signing off. Thank you.