- [Seph] For this third domain, the focus will be on designing secure applications and architectures. As security is one of the most important aspects of any environment, as well as a constant theme throughout the exam, it will be vital that you not only know the various security services available, but also that you understand the security concepts, and how they affect your decisions regarding the services and solutions you will end up evaluating. And because AWS recommends that security be considered at every stage, level, and tier of your applications and architectures, even the exam items that are not solely focused on security will still expect you to consider it as you select solutions. For this domain, the focus will be split into three parts. First, we'll be securing access to AWS services, which we'll discuss in this segment. Second, we'll be designing security into your application tiers. And the last area of focus will be selecting appropriate data-security options. As with the other domains, the solutions you are considering should involve thorough examination of the architecture requirements and needs, and the understanding that none of these topics stand alone. Now, with that out of the way, let's get started. As I said, here we'll focus on securing access to AWS services. What that means, is that one of the biggest and earliest considerations you will make when designing an architecture is how the people, tools, and applications you build will access the necessary AWS services. This could involve determining not only who or what can launch or terminate your resources, but also managing how and when access is given, operational permissions, and almost anything else that would involve calls to the service. When studying this area, you'll definitely be spending a lot of time with AWS Identity and Access Management, or IAM. Look into users, groups, and roles, and what goes into deciding between which to use, and how they might be combined. How do you create them? What are their strengths and limitations? And what scenarios would dictate possibly switching between the various user, group, and role-based permissions? Right along with those identities, make sure you know how IAM and other AWS services enable you to secure the necessary credentials, as well as the best practices for handling those credentials. This goes for the identities that you might create, as well as techniques to secure the root user. Don't forget to look at the best practices around controlling your application's access to the AWS APIs. When should you hardcode credentials into your application? The answer to this is never. What other ways are there to enable API access? You should also know how to write and interpret policy documents. Learn the major parts of a policy statement, what's required, and what are the ways in which the policies provide granularity with permissions? Make sure you also understand IAM's decision logic when evaluating policies, and how that will affect an identity with multiple policies attached. And lastly, understand the methods, services, and tools available that help you to create traceability for access to AWS resources. Just as you need to be aware of the performance and behaviors of your application components, you need to have insight into who and what has access to your account resources. Know how to gain that visibility, how to enforce security standards, and how to alert and automate based off of that data. Learning to design secure access to the resources is an important step in learning how to prioritize security at every step. Take your time when diving into these topics, and get practice with both the designing and implementation whenever possible. Until next time.