Service-linked roles (SLRs) in AWS are specialized roles created for specific services to manage permissions and access to resources on behalf of the user. They’re generated using the `aws iam create-service-linked-role` command and can’t be created or deleted through the standard role commands. These roles are owned by AWS, meaning users can't modify or delete them without specific conditions being met. The naming conventions are distinct, starting with "AWSServiceRoleFor" and having a path of `/aws-service-role/`. Their primary purpose is to bootstrap AWS services that depend on other services, allowing for a more streamlined management of permissions. The article highlights some quirks of SLRs, such as their inability to be edited by the user, and how AWS maintains control over them. There’s a notable difference between service-linked roles and standard service roles, which users create and manage. AWS documentation may not always reflect the most current information about SLRs, leading to potential confusion. A hidden API call allows users to retrieve the trust and resource policies associated with these roles, providing valuable insights into their use. To check for SLRs in different accounts, users can exploit a feature in AWS policy validation that reveals whether a role exists when an invalid principal is provided. This insight allows for some estimation of service usage across accounts. The article also provides a method to programmatically create all possible SLRs in an account, which can mislead attackers into thinking a wider range of services is being actively utilized. Finally, it emphasizes a unique IAM policy scenario where a user can attempt to manage service-linked roles despite restrictions on listing resources, illustrating the complex security dynamics within AWS.