A company requires that all AWS IAM user accounts have specific complexity requirements and minimum password length. How should a Solutions Architect accomplish this? 1. Set a password policy for each IAM user in the AWS account. 2. Set a password policy for the entire AWS account. 3. Create an IAM policy that enforces the requirements and apply it to all users. 4. Use an AWS Config rule to enforce the requirements when creating user accounts.

2. Set a password policy for the entire AWS account. The easiest way to enforce this requirement is to update the password policy that applies to the entire AWS account. When you create or change a password policy, most of the password policy settings are enforced the next time your users change their passwords. However, some of the settings are enforced immediately such as the password expiration period. There’s no need to set an individual password policy for each user, it will be easier to set the policy for everyone. As there is no specific targeting required it is easier to update the account password policy. You cannot use AWS Config to enforce the password requirements at the time of creating a user account. Reference: [Set an account password policy for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) Save time with our [AWS cheat sheets](https://digitalcloud.training/aws-iam/).

A developer created an application that uses Amazon EC2 and an Amazon RDS MySQL database instance. The developer stored the database user name and password in a configuration file on the root EBS volume of the EC2 application instance. A Solutions Architect has been asked to design a more secure solution. What should the Solutions Architect do to achieve this requirement? 1. Move the configuration file to an Amazon S3 bucket. Create an IAM role with permission to the bucket and attach it to the EC2 instance. 2. Attach an additional volume to the EC2 instance with encryption enabled. Move the configuration file to the encrypted volume. 3. Install an Amazon-trusted root certificate on the application instance and use SSL/TLS encrypted connections to the database. 4. Create an IAM role with permission to access the database. Attach this IAM role to the EC2 instance.

4. Create an IAM role with permission to access the database. Attach this IAM role to the EC2 instance. The key problem here is having plain text credentials stored in a file. Even if you encrypt the volume there is still as security risk as the credentials are loaded by the application and passed to RDS. The best way to secure this solution is to get rid of the credentials completely by using an IAM role instead. The IAM role can be assigned permissions to the database instance and can be attached to the EC2 instance. The instance will then obtain temporary security credentials from AWS STS which is much more secure. This just relocates the file; the contents are still unsecured and must be loaded by the application and passed to RDS. This is an insecure process. This will only encrypt the file at rest, it still must be read, and the contents passed to RDS which is insecure. The file is still unsecured on the EBS volume so encrypting the credentials in an encrypted channel between the EC2 instance and RDS does not solve all security issues. Reference: [IAM roles for Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) Save time with our [AWS cheat sheets](https://digitalcloud.training/aws-iam/).

A financial services company stores transaction records in an Amazon S3 bucket. The company runs its analytics application on a cluster of on-premises servers. The application needs temporary, secure access to the S3 bucket to analyze the data files. The company uses AWS IAM Identity Center to manage identities and ensure adherence to the principle of least privilege. The solution must avoid long-term credential storage and provide a secure method for the application to access the S3 bucket. Which solution will meet these requirements? 1. Create an S3 bucket policy to allow access from the public IP address range of the company’s on-premises servers. Configure the application to access the S3 bucket directly. 2. Use IAM Roles Anywhere to issue temporary credentials to the application. Set up a trust relationship with IAM Identity Center and configure the application to assume the role using these credentials. 3. Deploy AWS Storage Gateway File Gateway to the on-premises environment. Configure the application to access the S3 bucket through the gateway by using NFS or SMB. 4. Use AWS Systems Manager to store an access key and secret key for an IAM user with access to the S3 bucket. Configure the application to retrieve the credentials from Systems Manager Parameter Store when needed.

2. Use IAM Roles Anywhere to issue temporary credentials to the application. Set up a trust relationship with IAM Identity Center and configure the application to assume the role using these credentials. IAM Roles Anywhere provides a secure and scalable method for on-premises workloads to obtain temporary AWS credentials. It avoids the use of long-term credentials and integrates with IAM Identity Center to ensure least privilege access to the S3 bucket. Opening access to a public IP address range is less secure and does not align with the principle of least privilege. It exposes the S3 bucket to potential security risks. While File Gateway can provide access to S3, it is designed for file-based workloads and adds unnecessary complexity for this use case. IAM Roles Anywhere is a simpler and more secure option for temporary credentials. Storing long-term credentials in Parameter Store introduces security risks. Temporary credentials from IAM Roles Anywhere are a more secure and compliant solution. References: [What is AWS Identity and Access Management Roles Anywhere?](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) Save time with our [AWS cheat sheets](https://digitalcloud.training/aws-iam/).

A healthcare organization is designing a secure web application in the AWS Cloud for managing patient records. The application must securely retrieve and store multiple patient credentials, including access keys and passwords. The organization wants to use an AWS-managed service to handle these credentials. The solution must minimize operational overhead while ensuring security. Which solution will meet these requirements with the LEAST operational overhead? 1. Store the patient credentials in AWS Systems Manager Parameter Store. Use the GetParametersByPath API to securely retrieve the credentials in the application at runtime. 2. Store the patient credentials in AWS Secrets Manager. Use the GetSecretValue API to securely retrieve the credentials in the application at runtime. 3. Store the patient credentials in an Amazon RDS database table. Encrypt the credentials by using AWS Key Management Service (AWS KMS). Configure the application to query the RDS database to retrieve the credentials. 4. Store the patient credentials in an Amazon S3 bucket. Enable server-side encryption with AWS KMS keys (SSE-KMS). Use pre-signed URLs to retrieve the credentials securely.

2. Store the patient credentials in AWS Secrets Manager. Use the GetSecretValue API to securely retrieve the credentials in the application at runtime. Secrets Manager is designed to securely store and retrieve credentials with minimal operational overhead. It also supports secret rotation and integrates with AWS services for secure runtime access. Although Parameter Store can store credentials, it does not offer native secret rotation, which increases operational overhead. Manually managing credentials in an RDS database introduces significant operational complexity and does not offer built-in secret rotation or retrieval mechanisms. S3 is not designed for storing credentials, and managing access via pre-signed URLs increases complexity while not offering features such as secret rotation. References: [What is AWS Secrets Manager?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) Save time with our [AWS cheat sheets](https://digitalcloud.training/aws-secrets-manager/).

To accelerate experimentation and agility, a company allows developers to apply existing IAM policies to existing IAM roles. Nevertheless, the security operations team is concerned that the developers could attach the existing administrator policy, circumventing any other security policies. How should a solutions architect address this issue? 1. Send an alert every time a developer creates a new policy using an Amazon SNS topic. 2. Disable IAM activity across all organizational accounts using service control policies. 3. Assign all IAM duties to the security operations team and prevent developers from attaching policies. 4. Set a permissions boundary on the developer IAM role that denies attaching administrator access.

4. Set a permissions boundary on the developer IAM role that denies attaching administrator access. Setting a permissions boundary is the easiest and safest way to ensure that any IAM users cannot assume any elevated permissions. A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries. This does not explicitly prevent any developers from attaching the policy, only sending a notification. If all IAM activity was disabled across all accounts within the Organizational unit, each IAM user would not be able to do anything within the account. The easiest way to do this is to use a permissions boundary, to make sure the permissions are being administered appropriately. Reference: [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) Save time with our [AWS cheat sheets](https://digitalcloud.training/aws-iam/).

A global retail company needs to provide its remote IT operations team with secure access to AWS resources across multiple AWS accounts. The company uses an on-premises Microsoft Active Directory for centralized user authentication and authorization. The AWS accounts are managed through AWS Organizations and support various internal teams and projects. The company wants to integrate its existing Active Directory with AWS to centralize identity management, reduce operational overhead, and ensure secure, role-based access to resources across all accounts. Which solution will meet these requirements with the LEAST operational overhead? 1. Deploy AWS Managed Microsoft Active Directory using AWS Directory Service. Establish a one-way trust relationship with the on-premises Active Directory. Use IAM roles mapped to Active Directory groups to provide resource access in each AWS account. 2. Use AWS Identity Center (AWS IAM Identity Center) integrated with AD Connector to link the on-premises Active Directory. Configure permission sets in IAM Identity Center to assign account-level and resource-level permissions based on Active Directory groups. 3. Create individual IAM users for each team member. Assign permissions manually to each IAM user in every AWS account. Use AWS Config to enforce compliance with access policies across accounts. 4. Deploy an OpenID Connect (OIDC)-compatible identity provider and integrate it with the on-premises Active Directory. Use the identity provider to generate tokens for users and configure IAM roles to allow access to AWS resources.

2. Use AWS Identity Center (AWS IAM Identity Center) integrated with AD Connector to link the on-premises Active Directory. Configure permission sets in IAM Identity Center to assign account-level and resource-level permissions based on Active Directory groups. Use AWS Identity Center (AWS IAM Identity Center) integrated with AD Connector to link the on-premises Active Directory. Configure permission sets in IAM Identity Center to assign account-level and resource-level permissions based on Active Directory groups: This is correct because AD Connector allows seamless integration with the on-premises Active Directory without duplicating or synchronizing identities. When combined with IAM Identity Center, permissions can be centrally managed using permission sets mapped to AD groups, minimizing operational effort and ensuring consistent access control across multiple AWS accounts. Setting up AWS Managed Microsoft AD introduces additional overhead compared to using AD Connector. It requires managing a separate AWS-hosted directory and maintaining trust relationships with the on-premises directory. Creating and managing individual IAM users for a globally distributed team across multiple AWS accounts is operationally intensive and prone to errors. Additionally, AWS Config does not reduce the complexity of manually assigning permissions. Setting up an OIDC-compatible identity provider adds unnecessary complexity for a workforce identity management use case. It is more suited for customer-facing applications than for internal employee access to AWS resources. References: [AD Connector](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html) [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) Save time with our [AWS cheat sheets](https://digitalcloud.training/aws-iam/).

A research institute uses an Amazon Elastic Kubernetes Service (Amazon EKS) cluster to run machine learning workloads. The institute must ensure that Kubernetes service accounts within the EKS cluster have secure, fine-grained access to specific AWS resources for model training and data processing. The solution must use IAM roles for service accounts (IRSA) to meet these requirements. Which combination of solutions will meet these requirements? (Select TWO.) 1. Create an IAM policy that defines the necessary permissions for AWS resources. Attach the policy directly to the IAM role of the EKS worker nodes. 2. Define an IAM role that includes the required permissions. Annotate the Kubernetes service accounts with the Amazon Resource Name (ARN) of the IAM role. 3. Configure a trust relationship between the IAM roles for the service accounts and an OpenID Connect (OIDC) identity provider associated with the EKS cluster. 4. Implement pod security policies in the EKS cluster to restrict pods from accessing unauthorized AWS resources. 5. Modify the EKS cluster's worker node IAM role to include permissions for Kubernetes service accounts. Ensure all service accounts map to a single IAM role.

2. Define an IAM role that includes the required permissions. Annotate the Kubernetes service accounts with the Amazon Resource Name (ARN) of the IAM role. 3. Configure a trust relationship between the IAM roles for the service accounts and an OpenID Connect (OIDC) identity provider associated with the EKS cluster. IRSA enables Kubernetes service accounts to securely assume IAM roles with the necessary permissions for accessing specific AWS resources. OIDC integration is required for IRSA to allow the EKS service accounts to assume the associated IAM roles securely. Attaching the policy to the worker node role gives broad permissions to all pods running on those nodes, violating the principle of least privilege. Pod security policies manage pod-level security but do not directly control access to AWS resources via IAM. Mapping all service accounts to a single IAM role does not provide the granularity required for secure access. References: [IAM roles for service accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) [Create an OpenID Connect (OIDC) identity provider in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) Save time with our [AWS cheat sheets](https://digitalcloud.training/aws-iam/).

Security, Identity, & Compliance for AWS Solutions Architect Associate

A company requires that all AWS IAM user accounts have specific complexity requirements and minimum password length.

How should a Solutions Architect accomplish this?

Set a password policy for each IAM user in the AWS account.
Set a password policy for the entire AWS account.
Create an IAM policy that enforces the requirements and apply it to all users.
Use an AWS Config rule to enforce the requirements when creating user accounts.

2. Set a password policy for the entire AWS account.

The easiest way to enforce this requirement is to update the password policy that applies to the entire AWS account. When you create or change a password policy, most of the password policy settings are enforced the next time your users change their passwords. However, some of the settings are enforced immediately such as the password expiration period.

There’s no need to set an individual password policy for each user, it will be easier to set the policy for everyone.
As there is no specific targeting required it is easier to update the account password policy.
You cannot use AWS Config to enforce the password requirements at the time of creating a user account.

Reference:
Set an account password policy for IAM users

Save time with our AWS cheat sheets.

How well did you know this?

Not at all

Perfectly

A developer created an application that uses Amazon EC2 and an Amazon RDS MySQL database instance. The developer stored the database user name and password in a configuration file on the root EBS volume of the EC2 application instance. A Solutions Architect has been asked to design a more secure solution.

What should the Solutions Architect do to achieve this requirement?

Move the configuration file to an Amazon S3 bucket. Create an IAM role with permission to the bucket and attach it to the EC2 instance.
Attach an additional volume to the EC2 instance with encryption enabled. Move the configuration file to the encrypted volume.
Install an Amazon-trusted root certificate on the application instance and use SSL/TLS encrypted connections to the database.
Create an IAM role with permission to access the database. Attach this IAM role to the EC2 instance.

4. Create an IAM role with permission to access the database. Attach this IAM role to the EC2 instance.

The key problem here is having plain text credentials stored in a file. Even if you encrypt the volume there is still as security risk as the credentials are loaded by the application and passed to RDS.

The best way to secure this solution is to get rid of the credentials completely by using an IAM role instead. The IAM role can be assigned permissions to the database instance and can be attached to the EC2 instance. The instance will then obtain temporary security credentials from AWS STS which is much more secure.

This just relocates the file; the contents are still unsecured and must be loaded by the application and passed to RDS. This is an insecure process.
This will only encrypt the file at rest, it still must be read, and the contents passed to RDS which is insecure.
The file is still unsecured on the EBS volume so encrypting the credentials in an encrypted channel between the EC2 instance and RDS does not solve all security issues.

Reference:
IAM roles for Amazon EC2

Save time with our AWS cheat sheets.

How well did you know this?

Not at all

Perfectly

A company runs an application in a private subnet within a VPC. The application is integrated with Amazon Cognito using a user pool for user authentication. The company wants to enable users to securely upload and store their documents in an Amazon S3 bucket.

What combination of steps should the company take to securely integrate the application with Amazon S3?

(Select TWO.)

Configure an Amazon Cognito identity pool to provide temporary credentials for Amazon S3 when users authenticate through the user pool.
Enable Amazon S3 VPC endpoints in the VPC to ensure private connectivity between the application and the S3 bucket.
Add a bucket policy to deny requests that do not include valid Amazon Cognito credentials.
Assign IAM roles directly to the S3 bucket to allow user-level access.
Configure the application to generate Amazon S3 access tokens directly from the Cognito user pool.

1. Configure an Amazon Cognito identity pool to provide temporary credentials for Amazon S3 when users authenticate through the user pool.
2. Enable Amazon S3 VPC endpoints in the VPC to ensure private connectivity between the application and the S3 bucket.

An Amazon Cognito identity pool is required to grant temporary AWS credentials for accessing S3 buckets. The user pool alone does not provide direct access to AWS resources, so the identity pool integrates with the user pool to securely grant users permissions to interact with S3.

The application runs in a private subnet and needs secure connectivity to Amazon S3. A VPC endpoint ensures traffic remains within the AWS network, improving security and reducing reliance on internet gateways or NAT gateways.

Bucket policies can restrict access based on certain conditions, but integrating Amazon Cognito requires granting access through IAM roles tied to identity pools, not bucket policies.
IAM roles are assigned to entities like users or identity pools, not to resources like S3 buckets. The proper method involves attaching policies to the identity pool role to grant temporary credentials.
User pools authenticate users but do not directly provide credentials for AWS services. An identity pool is required to bridge the authentication process with AWS resource access.

References:

Save time with our AWS cheat sheets:

How well did you know this?

Not at all

Perfectly

A financial services company stores transaction records in an Amazon S3 bucket. The company runs its analytics application on a cluster of on-premises servers. The application needs temporary, secure access to the S3 bucket to analyze the data files.
The company uses AWS IAM Identity Center to manage identities and ensure adherence to the principle of least privilege. The solution must avoid long-term credential storage and provide a secure method for the application to access the S3 bucket.

Which solution will meet these requirements?

Create an S3 bucket policy to allow access from the public IP address range of the company’s on-premises servers. Configure the application to access the S3 bucket directly.
Use IAM Roles Anywhere to issue temporary credentials to the application. Set up a trust relationship with IAM Identity Center and configure the application to assume the role using these credentials.
Deploy AWS Storage Gateway File Gateway to the on-premises environment. Configure the application to access the S3 bucket through the gateway by using NFS or SMB.
Use AWS Systems Manager to store an access key and secret key for an IAM user with access to the S3 bucket. Configure the application to retrieve the credentials from Systems Manager Parameter Store when needed.

2. Use IAM Roles Anywhere to issue temporary credentials to the application. Set up a trust relationship with IAM Identity Center and configure the application to assume the role using these credentials.

IAM Roles Anywhere provides a secure and scalable method for on-premises workloads to obtain temporary AWS credentials. It avoids the use of long-term credentials and integrates with IAM Identity Center to ensure least privilege access to the S3 bucket.

Opening access to a public IP address range is less secure and does not align with the principle of least privilege. It exposes the S3 bucket to potential security risks.
While File Gateway can provide access to S3, it is designed for file-based workloads and adds unnecessary complexity for this use case. IAM Roles Anywhere is a simpler and more secure option for temporary credentials.
Storing long-term credentials in Parameter Store introduces security risks. Temporary credentials from IAM Roles Anywhere are a more secure and compliant solution.

References:

Save time with our AWS cheat sheets.

How well did you know this?

Not at all

Perfectly

A healthcare organization is designing a secure web application in the AWS Cloud for managing patient records. The application must securely retrieve and store multiple patient credentials, including access keys and passwords. The organization wants to use an AWS-managed service to handle these credentials. The solution must minimize operational overhead while ensuring security.

Which solution will meet these requirements with the LEAST operational overhead?

Store the patient credentials in AWS Systems Manager Parameter Store. Use the GetParametersByPath API to securely retrieve the credentials in the application at runtime.
Store the patient credentials in AWS Secrets Manager. Use the GetSecretValue API to securely retrieve the credentials in the application at runtime.
Store the patient credentials in an Amazon RDS database table. Encrypt the credentials by using AWS Key Management Service (AWS KMS). Configure the application to query the RDS database to retrieve the credentials.
Store the patient credentials in an Amazon S3 bucket. Enable server-side encryption with AWS KMS keys (SSE-KMS). Use pre-signed URLs to retrieve the credentials securely.

2. Store the patient credentials in AWS Secrets Manager. Use the GetSecretValue API to securely retrieve the credentials in the application at runtime.

Secrets Manager is designed to securely store and retrieve credentials with minimal operational overhead. It also supports secret rotation and integrates with AWS services for secure runtime access.

Although Parameter Store can store credentials, it does not offer native secret rotation, which increases operational overhead.
Manually managing credentials in an RDS database introduces significant operational complexity and does not offer built-in secret rotation or retrieval mechanisms.
S3 is not designed for storing credentials, and managing access via pre-signed URLs increases complexity while not offering features such as secret rotation.

References:

Save time with our AWS cheat sheets.

How well did you know this?

Not at all

Perfectly

A highly sensitive application runs on Amazon EC2 instances using EBS volumes. The application stores data temporarily on Amazon EBS volumes during processing before saving results to an Amazon RDS database. The company’s security team mandate that the sensitive data must be encrypted at rest.

Which solution should a Solutions Srchitect recommend to meet this requirement?

Configure encryption for the Amazon EBS volumes and Amazon RDS database with AWS KMS keys.
Use AWS Certificate Manager to generate certificates that can be used to encrypt the connections between the EC2 instances and RDS.
Use Amazon Data Lifecycle Manager to encrypt all data as it is stored to the EBS volumes and RDS database.
Configure SSL/TLS encryption using AWS KMS customer master keys (CMKs) to encrypt database volumes.

1. Configure encryption for the Amazon EBS volumes and Amazon RDS database with AWS KMS keys.

As the data is stored both in the EBS volumes (temporarily) and the RDS database, both the EBS and RDS volumes must be encrypted at rest. This can be achieved by enabling encryption at creation time of the volume and AWS KMS keys can be used to encrypt the data. This solution meets all requirements.

This would encrypt the data in-transit but not at-rest.
DLM is used for automating the process of taking and managing snapshots for EBS volumes.
You cannot configure SSL/TLS encryption using KMS CMKs or use SSL/TLS to encrypt data at rest.

References:

Save time with our AWS cheat sheets:

How well did you know this?

Not at all

Perfectly

To accelerate experimentation and agility, a company allows developers to apply existing IAM policies to existing IAM roles. Nevertheless, the security operations team is concerned that the developers could attach the existing administrator policy, circumventing any other security policies.

How should a solutions architect address this issue?

Send an alert every time a developer creates a new policy using an Amazon SNS topic.
Disable IAM activity across all organizational accounts using service control policies.
Assign all IAM duties to the security operations team and prevent developers from attaching policies.
Set a permissions boundary on the developer IAM role that denies attaching administrator access.

4. Set a permissions boundary on the developer IAM role that denies attaching administrator access.

Setting a permissions boundary is the easiest and safest way to ensure that any IAM users cannot assume any elevated permissions. A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity’s permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.

This does not explicitly prevent any developers from attaching the policy, only sending a notification.
If all IAM activity was disabled across all accounts within the Organizational unit, each IAM user would not be able to do anything within the account.
The easiest way to do this is to use a permissions boundary, to make sure the permissions are being administered appropriately.

Reference:
Permissions boundaries for IAM entities

Save time with our AWS cheat sheets.

How well did you know this?

Not at all

Perfectly

A global retail company needs to provide its remote IT operations team with secure access to AWS resources across multiple AWS accounts. The company uses an on-premises Microsoft Active Directory for centralized user authentication and authorization. The AWS accounts are managed through AWS Organizations and support various internal teams and projects.

The company wants to integrate its existing Active Directory with AWS to centralize identity management, reduce operational overhead, and ensure secure, role-based access to resources across all accounts.

Which solution will meet these requirements with the LEAST operational overhead?

Deploy AWS Managed Microsoft Active Directory using AWS Directory Service. Establish a one-way trust relationship with the on-premises Active Directory. Use IAM roles mapped to Active Directory groups to provide resource access in each AWS account.
Use AWS Identity Center (AWS IAM Identity Center) integrated with AD Connector to link the on-premises Active Directory. Configure permission sets in IAM Identity Center to assign account-level and resource-level permissions based on Active Directory groups.
Create individual IAM users for each team member. Assign permissions manually to each IAM user in every AWS account. Use AWS Config to enforce compliance with access policies across accounts.
Deploy an OpenID Connect (OIDC)-compatible identity provider and integrate it with the on-premises Active Directory. Use the identity provider to generate tokens for users and configure IAM roles to allow access to AWS resources.

2. Use AWS Identity Center (AWS IAM Identity Center) integrated with AD Connector to link the on-premises Active Directory. Configure permission sets in IAM Identity Center to assign account-level and resource-level permissions based on Active Directory groups.

Use AWS Identity Center (AWS IAM Identity Center) integrated with AD Connector to link the on-premises Active Directory. Configure permission sets in IAM Identity Center to assign account-level and resource-level permissions based on Active Directory groups: This is correct because AD Connector allows seamless integration with the on-premises Active Directory without duplicating or synchronizing identities. When combined with IAM Identity Center, permissions can be centrally managed using permission sets mapped to AD groups, minimizing operational effort and ensuring consistent access control across multiple AWS accounts.

Setting up AWS Managed Microsoft AD introduces additional overhead compared to using AD Connector. It requires managing a separate AWS-hosted directory and maintaining trust relationships with the on-premises directory.
Creating and managing individual IAM users for a globally distributed team across multiple AWS accounts is operationally intensive and prone to errors. Additionally, AWS Config does not reduce the complexity of manually assigning permissions.
Setting up an OIDC-compatible identity provider adds unnecessary complexity for a workforce identity management use case. It is more suited for customer-facing applications than for internal employee access to AWS resources.

References:

Save time with our AWS cheat sheets.

How well did you know this?

Not at all

Perfectly

A gaming company operates a leaderboard application for a popular multiplayer game. The application uses an Amazon Aurora PostgreSQL DB cluster for storage. The game servers, hosted on Amazon EC2 instances, frequently update the leaderboard with player scores.

The company has a strict security policy that requires database credentials to be encrypted and rotated every 30 days. The company wants to minimize operational overhead while ensuring the application can seamlessly retrieve and use updated credentials.

What should a solutions architect do to meet this requirement?

Use AWS Secrets Manager to store the database credentials. Configure Secrets Manager to rotate the credentials automatically every 30 days. Update the game server application to retrieve credentials from Secrets Manager.
Use AWS Systems Manager Parameter Store to store the database credentials as SecureString parameters encrypted with AWS KMS. Implement a custom AWS Lambda function to rotate the credentials every 30 days and update the parameters.
Configure Amazon Cognito to generate temporary database credentials. Use Cognito’s built-in mechanisms to rotate the credentials every 30 days. Update the game server application to request temporary credentials from Cognito.
Store the database credentials in an Amazon DynamoDB table encrypted with AWS KMS. Configure an AWS Lambda function to rotate the credentials in Aurora every 30 days and update the DynamoDB table with the new credentials.

1. Use AWS Secrets Manager to store the database credentials. Configure Secrets Manager to rotate the credentials automatically every 30 days. Update the game server application to retrieve credentials from Secrets Manager.

AWS Secrets Manager integrates seamlessly with Aurora PostgreSQL, providing built-in credential rotation and secure storage. This minimizes operational overhead and meets the security requirements.

While Parameter Store securely stores credentials, it does not natively integrate with Aurora for automatic rotation. Writing a custom Lambda function increases complexity.
Cognito is primarily designed for user identity management and is not intended for database credential management. This approach does not directly address the security requirements.
DynamoDB is not a service designed to securely store or manage database credentials. This approach requires unnecessary custom implementations and adds operational complexity.

References:

Save time with our AWS cheat sheets.

How well did you know this?

Not at all

Perfectly

A research organization wants to move its data analytics application to a serverless solution. The organization stores scientific data in an Amazon S3 bucket and needs the solution to support SQL queries on both existing and new data. The data must be encrypted at rest and replicated to a different AWS Region to ensure durability and compliance.

Which solution will meet these requirements with the LEAST operational overhead?

Create a new S3 bucket that uses server-side encryption with AWS KMS multi-Region keys (SSE-KMS). Configure Cross-Region Replication (CRR). Load the data into the new S3 bucket. Use Amazon Athena to query the data.
Create a new S3 bucket that uses server-side encryption with Amazon S3 managed keys (SSE-S3). Configure Cross-Region Replication (CRR). Load the data into the new S3 bucket. Use Amazon Redshift Spectrum to query the data.
Configure Cross-Region Replication (CRR) on the existing S3 bucket. Use server-side encryption with Amazon S3 managed keys (SSE-S3). Use Amazon Athena to query the data.
Configure S3 Cross-Region Replication (CRR) on the existing S3 bucket. Use server-side encryption with AWS KMS multi-Region keys (SSE-KMS). Use AWS Glue for ETL and Amazon Redshift to query the data.

1. Create a new S3 bucket that uses server-side encryption with AWS KMS multi-Region keys (SSE-KMS). Configure Cross-Region Replication (CRR). Load the data into the new S3 bucket. Use Amazon Athena to query the data.

SSE-KMS provides encryption at rest with multi-Region replication, and Athena offers a serverless SQL querying solution with minimal operational overhead.

Redshift Spectrum is not a fully serverless solution and requires managing the Redshift cluster, increasing operational overhead.
SSE-S3 does not provide the same level of security as SSE-KMS, which is required for compliance in many scenarios.
AWS Glue and Redshift require additional management and are not as cost-efficient as Athena for simple SQL querying tasks.

References:

Save time with our AWS cheat sheets.

How well did you know this?

Not at all

Perfectly

A company runs workloads in the AWS Cloud and wants to consolidate and analyze security-related information to enhance workload protection. The company needs a solution that simplifies the collection and centralization of security data across multiple AWS accounts and Regions with minimal development effort.

Which solution will meet these requirements with the LEAST development effort?

Configure Amazon Security Lake to automatically collect, normalize, and store security data in Amazon S3 for analysis.
Use AWS Glue crawlers to extract and catalog security data into an AWS Lake Formation-managed data lake.
Deploy an Amazon RDS cluster and use AWS Database Migration Service (AWS DMS) to load security data from multiple sources.
Create a custom Lambda function to fetch security data in JSON format and store it in Amazon S3 for further analysis.

1. Configure Amazon Security Lake to automatically collect, normalize, and store security data in Amazon S3 for analysis.

This is the best solution because Amazon Security Lake is purpose-built for centralizing security data. It minimizes development effort by automatically collecting and formatting data into the Open Cybersecurity Schema Framework (OCSF) for analysis.

While this approach helps create a centralized data lake, it requires more development effort to set up the data ingestion pipelines and manage the schema.
DMS is not designed for collecting and normalizing security data. Setting up RDS for this use case introduces unnecessary complexity.
While possible, this solution requires custom development and ongoing maintenance, making it less efficient than using a managed service like Amazon Security Lake.

References:

How well did you know this?

Not at all

Perfectly

A media streaming company stores user activity logs in an Amazon S3 bucket. The logs are accessed frequently for real-time analytics and reporting. The company enforces strict encryption requirements for data stored in S3 and currently uses AWS Key Management Service (AWS KMS) for encryption.

The company wants to reduce costs related to encrypting objects in the S3 bucket while maintaining compliance with its encryption requirements and minimizing the number of AWS KMS calls.

Which solution will meet these requirements?

Use server-side encryption with Amazon S3 managed keys (SSE-S3) to eliminate AWS KMS usage.
Enable S3 Bucket Key for server-side encryption with AWS KMS keys (SSE-KMS) on the objects to reduce the cost of KMS requests.
Use client-side encryption with AWS KMS customer-managed keys to encrypt the data before uploading it to S3.
Use server-side encryption with customer-provided encryption keys (SSE-C) and store the keys in AWS Secrets Manager.

2. Enable S3 Bucket Key for server-side encryption with AWS KMS keys (SSE-KMS) on the objects to reduce the cost of KMS requests.

Enabling S3 Bucket Key reduces the number of AWS KMS calls required for object encryption. S3 Bucket Key caches the encryption keys at the bucket level, significantly lowering the cost of encryption for frequently accessed objects while meeting encryption requirements.

SSE-S3 does not use AWS KMS, but it does not meet the strict encryption requirements specified by the company, which mandate the use of AWS KMS.
Client-side encryption increases operational complexity and does not optimize costs associated with AWS KMS calls.
SSE-C requires the company to manage its own encryption keys, introducing operational overhead. Additionally, this approach does not optimize costs related to AWS KMS.

References:

Save time with our AWS cheat sheets.

How well did you know this?

Not at all

Perfectly

A healthcare startup is building a cloud-based patient management system on AWS. The system processes sensitive health data and uses Amazon RDS for the database, Amazon S3 for storing medical reports, and AWS Lambda for processing event-driven workflows triggered by S3 Event Notifications.

The startup uses AWS IAM Identity Center to manage user authentication. The development, testing, and operations teams need secure access to RDS and S3 while ensuring compliance with healthcare regulations that mandate least privilege access and centralized access control.

Which solution meets these requirements with the LEAST operational overhead?

Use AWS IAM Identity Center integrated with the startup’s existing Active Directory. Create permission sets with fine-grained permissions for RDS and S3. Assign team members to appropriate groups in Active Directory, which map to Identity Center permission sets.
Configure an Amazon Cognito user pool to authenticate team members. Use a custom Lambda function to generate temporary credentials for RDS and S3 access. Implement role-based access controls within the Lambda function to enforce least privilege.
Create separate IAM users for all team members. Assign each user predefined managed policies with RDS and S3 permissions. Use IAM Access Analyzer to review permissions periodically to ensure compliance with least privilege principles.
Use AWS Organizations to create separate accounts for development, testing, and operations teams. Apply Service Control Policies (SCPs) to restrict access at the account level. Use cross-account IAM roles to grant granular permissions for RDS and S3 based on team needs.

1. Use AWS IAM Identity Center integrated with the startup’s existing Active Directory. Create permission sets with fine-grained permissions for RDS and S3. Assign team members to appropriate groups in Active Directory, which map to Identity Center permission sets.

IAM Identity Center enables centralized user management and integrates seamlessly with Active Directory. It allows the creation of permission sets that enforce least privilege while minimizing operational overhead by using existing group structures.

Cognito is primarily designed for managing end-user authentication, not for managing internal team access to AWS resources. Using Cognito and a custom Lambda function would add unnecessary complexity and operational overhead.
Managing individual IAM users introduces significant administrative overhead. IAM Identity Center is a more scalable and centralized solution.
Creating separate accounts and managing cross-account IAM roles adds unnecessary complexity. IAM Identity Center provides a more efficient solution for centralized access control within a single account.

References:

Save time with our AWS cheat sheets.

How well did you know this?

Not at all

Perfectly

A government agency is moving its document management system to AWS. The application will store classified documents in Amazon S3. The agency must encrypt the documents before storing them in S3 to ensure compliance with strict data security regulations.

Which solution will meet these requirements?

Encrypt the documents by using client-side encryption with customer managed keys and upload the encrypted files to S3.
Encrypt the documents by using server-side encryption with AWS KMS keys (SSE-KMS) configured with custom key policies for access control.
Encrypt the documents by using server-side encryption with customer-provided keys (SSE-C).
Encrypt the documents by using client-side encryption with Amazon S3 managed keys and upload the encrypted files to S3.

1. Encrypt the documents by using client-side encryption with customer managed keys and upload the encrypted files to S3.

Client-side encryption means the data is encrypted before it ever leaves the client system, giving maximum control over the encryption process. Using customer managed keys (CMKs) from AWS Key Management Service (KMS), the agency retains full ownership and control over key policies, rotation, and access, which is often a requirement for handling classified or sensitive government data. This approach ensures compliance with strict regulations by minimizing trust in the cloud provider to protect unencrypted data.

While secure and easy to manage, SSE-KMS means AWS handles the encryption after data reaches S3.
While client-side encryption can ensure security before data reaches S3, it increases operational complexity since the customer must manage key creation, storage, and rotation independently.
SSE-C requires the customer to provide the encryption keys for every S3 operation, which can increase operational overhead and risks if key management is not handled correctly.

References:

Save time with our AWS cheat sheets.

How well did you know this?

Not at all

Perfectly

A research institute uses an Amazon Elastic Kubernetes Service (Amazon EKS) cluster to run machine learning workloads. The institute must ensure that Kubernetes service accounts within the EKS cluster have secure, fine-grained access to specific AWS resources for model training and data processing. The solution must use IAM roles for service accounts (IRSA) to meet these requirements.

Which combination of solutions will meet these requirements?

(Select TWO.)

Create an IAM policy that defines the necessary permissions for AWS resources. Attach the policy directly to the IAM role of the EKS worker nodes.
Define an IAM role that includes the required permissions. Annotate the Kubernetes service accounts with the Amazon Resource Name (ARN) of the IAM role.
Configure a trust relationship between the IAM roles for the service accounts and an OpenID Connect (OIDC) identity provider associated with the EKS cluster.
Implement pod security policies in the EKS cluster to restrict pods from accessing unauthorized AWS resources.
Modify the EKS cluster’s worker node IAM role to include permissions for Kubernetes service accounts. Ensure all service accounts map to a single IAM role.

2. Define an IAM role that includes the required permissions. Annotate the Kubernetes service accounts with the Amazon Resource Name (ARN) of the IAM role.
3. Configure a trust relationship between the IAM roles for the service accounts and an OpenID Connect (OIDC) identity provider associated with the EKS cluster.

IRSA enables Kubernetes service accounts to securely assume IAM roles with the necessary permissions for accessing specific AWS resources.

OIDC integration is required for IRSA to allow the EKS service accounts to assume the associated IAM roles securely.

Attaching the policy to the worker node role gives broad permissions to all pods running on those nodes, violating the principle of least privilege.
Pod security policies manage pod-level security but do not directly control access to AWS resources via IAM.
Mapping all service accounts to a single IAM role does not provide the granularity required for secure access.

References:

Save time with our AWS cheat sheets.

How well did you know this?

Not at all

Perfectly

A highly elastic application consists of three tiers. The application tier runs in an Auto Scaling group and processes data and writes it to an Amazon RDS MySQL database. The Solutions Architect wants to restrict access to the database tier to only accept traffic from the instances in the application tier. However, instances in the application tier are being constantly launched and terminated.

How can the Solutions Architect configure secure access to the database tier?

Configure the database security group to allow traffic only from the application security group
Configure the database security group to allow traffic only from port 3306
Configure a Network ACL on the database subnet to deny all traffic to ports other than 3306
Configure a Network ACL on the database subnet to allow all traffic from the application subnet

Study These Flashcards

1. Configure the database security group to allow traffic only from the application security group

The best option is to configure the database security group to only allow traffic that originates from the application security group. You can also define the destination port as the database port. This setup will allow any instance that is launched and attached to this security group to connect to the database.

Port 3306 for MySQL should be the destination port, not the source.
This does not restrict access specifically to the application instances.
This does not restrict access specifically to the application instances.

Reference:
Control traffic to your AWS resources using security groups

Save time with our AWS cheat sheets.

A Solutions Architect for a large banking company is configuring access control within the organization for an Amazon S3 bucket containing thousands of financial records. There are 20 different teams which need to have access to this bucket, however they all need different permissions. These 20 teams correspond to 20 accounts within the banking company who are currently using AWS Organizations.

What is the simplest way to achieve this, whilst adhering to the principle of least privilege?

Create a new AWS Organizations. Assign each team to a different Organizational Unit and apply to appropriate permissions granting access to the appropriate resources in the bucket.
Copy the items from the bucket to create separate versions of each Separate the items in the bucket into new buckets. Administer Bucket policies to allow each account to access the appropriate bucket.
Use S3 Access points to administer different access policies to each team, and control access points using Service Control Policies within AWS Organizations.
Create the S3 Bucket in an individual account. Configure an IAM Role for each user to enable cross account access for the S3 Bucket with a permissions policy to only access the appropriate items within the bucket.

Study These Flashcards

3. Use S3 Access points to administer different access policies to each team, and control access points using Service Control Policies within AWS Organizations.

Amazon S3 Access Points, a feature of S3, simplify data access for any AWS service or customer application that stores data in S3. With S3 Access Points, customers can create unique access control policies for each access point to easily control access to shared datasets. You can also control access point usage using AWS Organizations support for AWS SCPs.

This would not only be incredibly time consuming but totally unnecessary as you can use the preexisting AWS Organizations and the Service Control policies to control access via S3 Access Points.
This involves a lot of operational overhead and would be prone to significant error when administering the correct permissions to each account.
This is an unnecessary complexity as it would be much easier to provision separate policies per team using S3 Access Points.

Reference:
Amazon S3 Access Points

Save time with our AWS cheat sheets.

A website runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB) which serves as an origin for an Amazon CloudFront distribution. An AWS WAF is being used to protect against SQL injection attacks. A review of security logs revealed an external malicious IP that needs to be blocked from accessing the website.

What should a solutions architect do to protect the application?

Modify the network ACL on the CloudFront distribution to add a deny rule for the malicious IP address
Modify the configuration of AWS WAF to add an IP match condition to block the malicious IP address
Modify the network ACL for the EC2 instances in the target groups behind the ALB to deny the malicious IP address
Modify the security groups for the EC2 instances in the target groups behind the ALB to deny the malicious IP address

Study These Flashcards

2. Modify the configuration of AWS WAF to add an IP match condition to block the malicious IP address

A new version of the AWS Web Application Firewall was released in November 2019. With AWS WAF classic you create “IP match conditions”, whereas with AWS WAF (new version) you create “IP set match statements”. Look out for wording on the exam.

The IP match condition / IP set match statement inspects the IP address of a web request’s origin against a set of IP addresses and address ranges. Use this to allow or block web requests based on the IP addresses that the requests originate from.
AWS WAF supports all IPv4 and IPv6 address ranges. An IP set can hold up to 10,000 IP addresses or IP address ranges to check.

CloudFront does not sit within a subnet so network ACLs do not apply to it.
The source IP addresses of the data in the EC2 instances’ subnets will be the ELB IP addresses.
You cannot create deny rules with security groups.

Reference:
IP set match rule statement

Save time with our AWS cheat sheets.

An application has been deployed on Amazon EC2 instances behind an Application Load Balancer (ALB). A Solutions Architect must improve the security posture of the application and minimize the impact of a DDoS attack on resources.

Which of the following solutions is MOST effective?

Configure an AWS WAF ACL with rate-based rules. Enable the WAF ACL on the Application Load Balancer.
Create a custom AWS Lambda function that monitors for suspicious traffic and modifies a network ACL when a potential DDoS attack is identified.
Enable VPC Flow Logs and store them in Amazon S3. Use Amazon Athena to parse the logs and identify and block potential DDoS attacks.
Enable access logs on the Application Load Balancer and configure Amazon CloudWatch to monitor the access logs and trigger a Lambda function when potential attacks are identified. Configure the Lambda function to modify the ALBs security group and block the attack.

Study These Flashcards

1. Configure an AWS WAF ACL with rate-based rules. Enable the WAF ACL on the Application Load Balancer.

A rate-based rule tracks the rate of requests for each originating IP address, and triggers the rule action on IPs with rates that go over a limit. You set the limit as the number of requests per 5-minute time span.

You can use this type of rule to put a temporary block on requests from an IP address that’s sending excessive requests. By default, AWS WAF aggregates requests based on the IP address from the web request origin, but you can configure the rule to use an IP address from an HTTP header, like X-Forwarded-For, instead.

There’s not description here of how Lambda is going to monitor for traffic.
Amazon Athena is not able to block DDoS attacks, another service would be needed.
Access logs are exported to S3 but not to CloudWatch. Also, it would not be possible to block an attack from a specific IP using a security group (while still allowing any other source access) as they do not support deny rules.

Reference:
Using rate-based rule statements in AWS WAF

Save time with our AWS cheat sheets.

A website is running on Amazon EC2 instances and access is restricted to a limited set of IP ranges. A solutions architect is planning to migrate static content from the website to an Amazon S3 bucket configured as an origin for an Amazon CloudFront distribution. Access to the static content must be restricted to the same set of IP addresses.

Which combination of steps will meet these requirements?

(Select TWO.)

Create an origin access identity (OAI) and associate it with the distribution. Change the permissions in the bucket policy so that only the OAI can read the objects.
Create an origin access identity (OAI) and associate it with the distribution. Generate presigned URLs that limit access to the OAI.
Create an AWS WAF web ACL that includes the same IP restrictions that exist in the EC2 security group. Associate this new web ACL with the Amazon S3 bucket.
Create an AWS WAF web ACL that includes the same IP restrictions that exist in the EC2 security group. Associate this new web ACL with the CloudFront distribution.
Attach the existing security group that contains the IP restrictions to the Amazon CloudFront distribution.

Study These Flashcards

1. Create an origin access identity (OAI) and associate it with the distribution. Change the permissions in the bucket policy so that only the OAI can read the objects.
4. Create an AWS WAF web ACL that includes the same IP restrictions that exist in the EC2 security group. Associate this new web ACL with the CloudFront distribution.

To prevent users from circumventing the controls implemented on CloudFront (using WAF or presigned URLs / signed cookies) you can use an origin access identity (OAI). An OAI is a special CloudFront user that you associate with a distribution.

The next step is to change the permissions either on your Amazon S3 bucket or on the files in your bucket so that only the origin access identity has read permission (or read and download permission). This can be implemented through a bucket policy.

To control access at the CloudFront layer the AWS Web Application Firewall (WAF) can be used. With WAF you must create an ACL that includes the IP restrictions required and then associate the web ACL with the CloudFront distribution.

Presigned URLs can be used to protect access to CloudFront but they cannot be used to limit access to an OAI.
The Web ACL should be associated with CloudFront, not S3.
You cannot attach a security group to a CloudFront distribution.

References:

Save time with our AWS cheat sheets.

A media company has grown significantly in the past few months and the management team are concerned about compliance, governance, auditing, and security. The management team requires that configuration changes are tracked a history of API calls is recorded.

What should a solutions architect do to meet these requirements?

Use AWS CloudTrail to track configuration changes and AWS Config to record API calls.
Use AWS Config to track configuration changes and AWS CloudTrail to record API calls.
Use AWS Config to track configuration changes and Amazon CloudWatch to record API calls.
Use AWS CloudTrail to track configuration changes and Amazon CloudWatch to record API calls.

Study These Flashcards

2. Use AWS Config to track configuration changes and AWS CloudTrail to record API calls.

As per definition of AWS CloudTrail and AWS Config:

CloudTrail is a web service that records AWS API calls for your AWS account and delivers log files to an Amazon S3 bucket. The recorded information includes the identity of the user, the start time of the AWS API call, the source IP address, the request parameters, and the response elements returned by the service.

AWS Config tracks changes in the configuration of your AWS resources, and it regularly sends updated configuration details to an Amazon S3 bucket that you specify. For each resource type that AWS Config records, it sends a configuration history file every six hours.

This option is the reverse of what’s needed, AWS config, as the name suggests, is used to track the configuration changes in AWS accounts.
CloudWatch is used for performance monitoring, not tracking API calls.
CloudTrail is not the right service for tracking configuration changes hence this option is incorrect.

References:

Save time with our AWS cheat sheets:

As a security measure, a finance-based organization want to introduce additional security measures for an existing application deployed in AWS. The application is serverless and has an Amazon API Gateway in front which is deployed in the us-east-1 Region and the eu-west-1 Region. The company requires the accounts to be secured against SQL injection and cross-site scripting attacks.

Which solution will meet these requirements with the LEAST amount of administrative effort?

Set up AWS WAF in both Regions. Associate Regional web ACLs with an API stage
Set up AWS Firewall Manager in both Regions. Centrally configure AWS WAF rules.
Set up AWS Shield in both Regions. Associate Regional web ACLs with an API stage.
Set up AWS Shield in one of the Regions. Associate Regional web ACLs with an API stage.

Study These Flashcards

2. Set up AWS Firewall Manager in both Regions. Centrally configure AWS WAF rules.

AWS Firewall Manager simplifies your administration and maintenance tasks across multiple accounts and resources for a variety of protections, including AWS WAF, AWS Shield Advanced, Amazon VPC security groups, AWS Network Firewall, and Amazon Route 53 Resolver DNS Firewall. With Firewall Manager, you set up your protections just once and the service automatically applies them across your accounts and resources, even as you add new accounts and resources.

AWS WAF is used for protecting against malicious web attacks and is the best service to use to protect against SQL injection and cross-site scripting attacks. Used in combination with AWS Firewall Manager this solution protects both Regions and requires the least administrative effort.

This solution requires more administrative effort in rule management.
The primary difference between AWS Shield and WAF is that while AWS WAF can mitigate DDoS attacks at layer 7 of the OSI reference model, AWS Shield protects web services from DDoS attacks at layer 3 and 4 of the OSI reference model. In this case AWS WAF should be used.
As mentioned above, AWS Shield is not an appropriate choice for securing the accounts from SQL injection and cross-site scripting attacks.

References:

Save time with our AWS cheat sheets.

A finance organization has bootstrapped a golden image for their in-house application and the resultant AMI is to be shared across various AWS accounts as a base image. This image is to be used across many applications. The company needs to design an application that captures AWS API calls and sends alerts whenever the Amazon EC2 CreateImage API operation is called within the company’s account.

Which solution will meet these requirements with the LEAST operational overhead?

Create an AWS Lambda function to query AWS CloudTrail logs and to send an alert when a CreateImage API call is detected.
Configure AWS CloudTrail with an Amazon SNS notification that occurs when updated logs are sent to Amazon S3. Use Amazon Athena to create a new table and to query on CreateImage when an API call is detected
Create an Amazon EventBridge rule for the CreateImage API call. Configure the target as an Amazon SNS topic to send an alert when a Createlmage API call is detected.
Configure an Amazon SQS FIFO queue as a target for AWS CloudTrail logs. Create an AWS Lambda function to send an alert to an Amazon SNS topic when a CreateImage API call is detected.

Study These Flashcards

3. Create an Amazon EventBridge rule for the CreateImage API call. Configure the target as an Amazon SNS topic to send an alert when a Createlmage API call is detected.

You can create an Amazon EventBridge rule that triggers on an action by an AWS service that does not emit events. In this case you can base the rule on API calls made by AWS CloudTrail. The rule can trigger when the Amazon EC2 CreateImage API is called. The rule can then trigger another service or action.

Athena is a query analysis tool hence this option is incorrect.
Since the question asks about least operational overhead, this option becomes incorrect. This is an achievable solution but involves building custom code in Lambda and requires more effort.
You cannot configure CloudTrail logs to be sent directly to an SQS queue.

Reference:
Tutorial: Create an EventBridge rule that reacts to AWS API calls via CloudTrail

An application analyzes images of people that are uploaded to an Amazon S3 bucket. The application determines demographic data which is then saved to a .CSV file in another S3 bucket. The data must be encrypted at rest and then queried using SQL. The solution should be fully serverless.

Which actions should a Solutions Architect take to encrypt and query the data?

Use Amazon S3 server-side encryption and use Amazon RedShift Spectrum to query the data
Use AWS KMS encryption keys for the S3 bucket and use Amazon Athena to query the data
Use AWS KMS encryption keys for the S3 bucket and use Amazon Managed Service for Apache Flink to query the data.
Use Amazon S3 server-side encryption and Amazon QuickSight to query the data

Study These Flashcards

2. Use AWS KMS encryption keys for the S3 bucket and use Amazon Athena to query the data

Amazon Athena is an interactive query service that makes it easy to analyze data in Amazon S3 using standard SQL. Athena is serverless, so there is no infrastructure to manage, and you pay only for the queries that you run. Amazon Athena supports encrypted data for both the source data and query results, for example, using Amazon S3 with AWS KMS.

RedShift Spectrum is not serverless as it requires a RedShift cluster which is based on EC2 instances.
Amazon Managed Service for Apache Flink is used for analyzing real-time streaming data in Kinesis streams.
Amazon QuickSight is an interactive dashboard, it is not a service for running queries on data.

References:

Save time with our AWS cheat sheets.

A software development company is creating a microservices-based application using Amazon Elastic Kubernetes Service (Amazon EKS). The company needs to ensure that sensitive configuration data like database credentials and API keys stored in Kubernetes ConfigMaps and Secrets are encrypted at rest. **Which solution will meet these requirements?** 1. Implement AWS Secrets Manager to manage, rotate, and store all sensitive data. Integrate it with the Amazon EKS cluster. 2. Create a new AWS Key Management Service (AWS KMS) key. Enable Amazon EKS KMS secrets encryption on the Amazon EKS cluster. 3. Create the Amazon EKS cluster with default options. Use the Amazon Elastic File System (Amazon EFS) Container Storage Interface (CSI) driver as an add-on. 4. Use Amazon S3 to store all sensitive data. Enable server-side encryption with a new AWS Key Management Service (AWS KMS) key.

**2.** Create a new AWS Key Management Service (AWS KMS) key. Enable Amazon EKS KMS secrets encryption on the Amazon EKS cluster. ## Footnote Amazon EKS supports using AWS KMS keys for envelope encryption of Kubernetes secrets. To meet the requirement of encrypting Kubernetes Secrets at rest, we can use a customer managed AWS KMS key and enable secrets encryption while creating or updating an EKS cluster. * While AWS Secrets Manager can store and manage sensitive information, it doesn't directly encrypt Kubernetes Secrets and ConfigMaps stored in the etcd key-value store. * The EFS CSI driver enables Kubernetes pods to mount EFS file systems, but it does not offer a mechanism for encrypting secrets stored in Kubernetes. * While S3 can store sensitive data and encrypt it using KMS, it does not provide a way to directly encrypt Kubernetes ConfigMaps and Secrets stored in etcd. **Reference:** [Encrypt Kubernetes secrets with KMS on existing clusters](https://docs.aws.amazon.com/eks/latest/userguide/enable-kms.html) Save time with our [AWS cheat sheets](https://digitalcloud.training/aws-kms/).

A healthcare company maintains patient records in Amazon S3. To comply with HIPAA regulations, the stored data must not contain any protected health information (PHI). The company recently found out that some objects in the S3 buckets contain PHI. The company needs to automate the detection of PHI in the S3 buckets and notify its compliance team when such data is detected. **Which solution will meet these requirements?** 1. Use Amazon Macie. Create an AWS Lambda function to filter the ‘SensitiveData:S3Object/Personal’ event type from Macie findings and trigger an Amazon Simple Notification Service (Amazon SNS) notification to the compliance team. 2. Use AWS Security Hub. Create an Amazon EventBridge rule to filter the ‘Security Hub findings - High severity’ event type and send an Amazon Simple Notification Service (Amazon SNS) notification to the compliance team. 3. Use Amazon Macie. Create an Amazon EventBridge rule to filter the ‘SensitiveData:S3Object/Health’ event type from Macie findings and trigger an Amazon Simple Email Service (Amazon SES) notification to the compliance team. 4. Use AWS Security Hub. Create an AWS Lambda function to filter the ‘Security Hub findings - High severity’ event type and trigger an Amazon Simple Email Service (Amazon SES) notification to the compliance team.

**3.** Use Amazon Macie. Create an Amazon EventBridge rule to filter the ‘SensitiveData:S3Object/Health’ event type from Macie findings and trigger an Amazon Simple Email Service (Amazon SES) notification to the compliance team. ## Footnote Amazon Macie is a security service that uses machine learning to automatically discover, classify, and protect sensitive data like PHI. An Amazon EventBridge rule can be created to filter specific event types from Macie findings. When Macie identifies PHI in the S3 bucket, the EventBridge rule triggers an Amazon SNS notification to the compliance team. The correct filter is ‘SensitiveData:S3Object/Personal’ which includes personally identifiable information (PII) such as passport numbers or driver's license identification numbers, personal health information (PHI) such as health insurance or medical identification numbers, or a combination of PII and PHI. * AWS Security Hub gives a comprehensive view of high-priority security alerts and compliance status, but it does not offer data-specific detection like PHI in S3 objects. * AWS Security Hub does not offer detection of specific data types like PHI in S3 objects. Therefore, using it for this purpose would not meet the requirements. **Reference:** [Types of Macie findings](https://docs.aws.amazon.com/macie/latest/user/findings-types.html)

A company is storing a large quantity of small files in an Amazon S3 bucket. An application running on an Amazon EC2 instance needs permissions to access and process the files in the S3 bucket. **Which action will MOST securely grant the EC2 instance access to the S3 bucket?** 1. Create a bucket ACL on the S3 bucket and configure the EC2 instance ID as a grantee. 2. Create an IAM role with least privilege permissions and attach it to the EC2 instance profile. 3. Create an IAM user for the application with specific permissions to the S3 bucket. 4. Generate access keys and store the credentials on the EC2 instance for use in making API calls.

**2.** Create an IAM role with least privilege permissions and attach it to the EC2 instance profile. ## Footnote IAM roles should be used in place of storing credentials on Amazon EC2 instances. This is the most secure way to provide permissions to EC2 as no credentials are stored and short-lived credentials are obtained using AWS STS. Additionally, the policy attached to the role should provide least privilege permissions. * This is not best practice, IAM roles are preferred. * Instances should use IAM Roles for delegation not user accounts. * You cannot configure an EC2 instance ID on a bucket ACL and bucket ACLs cannot be used to restrict access in this scenario. **Reference:** [IAM roles for Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) Save time with our AWS cheat sheets: * [Amazon EC2](https://digitalcloud.training/amazon-ec2/) * [AWS IAM](https://digitalcloud.training/aws-iam/)

A web application has recently been launched on AWS. The architecture includes two tier with a web layer and a database layer. It has been identified that the web server layer may be vulnerable to cross-site scripting (XSS) attacks. **What should a solutions architect do to remediate the vulnerability?** 1. Create a Classic Load Balancer. Put the web layer behind the load balancer and enable AWS WAF 2. Create a Network Load Balancer. Put the web layer behind the load balancer and enable AWS WAF 3. Create an Application Load Balancer. Put the web layer behind the load balancer and enable AWS WAF 4. Create an Application Load Balancer. Put the web layer behind the load balancer and use AWS Shield Standard

**3.** Create an Application Load Balancer. Put the web layer behind the load balancer and enable AWS WAF ## Footnote The AWS Web Application Firewall (WAF) is available on the Application Load Balancer (ALB). You can use AWS WAF directly on Application Load Balancers (both internal and external) in a VPC, to protect your websites and web services. Attackers sometimes insert scripts into web requests in an effort to exploit vulnerabilities in web applications. You can create one or more cross-site scripting match conditions to identify the parts of web requests, such as the URI or the query string, that you want AWS WAF to inspect for possible malicious scripts. * You cannot use AWS WAF with a classic load balancer. * You cannot use AWS WAF with a network load balancer. * You cannot use AWS Shield to protect against XSS attacks. Shield is used to protect against DDoS attacks. **Reference:** [Working with cross-site scripting match conditions](https://docs.aws.amazon.com/waf/latest/developerguide/classic-web-acl-xss-conditions.html) Save time with our [AWS cheat sheets](https://digitalcloud.training/aws-waf-shield/).

Security, Identity, & Compliance Flashcards

Implement security controls and identity management solutions to protect AWS environments and meet compliance needs. (28 cards)