text: A loose analogy for IAM roles are that of professional uniforms: a surgeon's scrubs, a ﬁreﬁghter's 
  
  hardhat, or a startup CTO's favorite hoodie. Many people can*assume the role*of a surgeon, 
  
  ﬁreﬁghter, and startup CTO, which identiﬁes them with a certain job function. 
  
  One of the most useful things about IAM roles is they can be associated not only with human 
  
  entities, but also with AWS services. These types of roles are known as*service roles*. This means you 
  
  can assign an IAM role directly to a service. With an IAM role assigned to the service instance, you 
  can then associate speciﬁc IAM policies with the instance role, so that the service instance itself can 
  
  access other AWS services. This is extremely useful for automation. 
  
  **Authorization - PARC**
  
  So far we've been talking about principals. Principals represent the**authentication**component. For 
  authorization, you will attach JSON documents called*IAM policies*to principals. 
  
  **Principals**
  
  As mentioned,*principals*are the entities that are allowed or denied access. 
  
  **Actions**
  
  *Actions*are the type of access that is allowed or denied. Actions are commonly AWS service API 
  
  calls that represent create, read, describe, list, update, and delete semantics. 