Examkin

All practice questions

976 questions

All types976Multiple choice502Multiple select450Ordering24
Question 901Question →

A company has a production database in the us-east-1 region. Applications running in both the us-east-1 and us-west-2 regions connect to this database. The database credentials are stored in a primary secret in AWS Secrets Manager in the us-east-1 region and are replicated to the us-west-2 region. A SysOps administrator must configure automatic credential rotation every 30 days without causing application downtime in either region.

Which steps should the SysOps administrator take to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the automatic rotation schedule and associate the rotation AWS Lambda function on the primary secret in the us-east-1 region.; Configure the database credentials to use a multi-user rotation strategy with two database users, so one user remains active while the other is rotated.

Answer

Configure the automatic rotation schedule and associate the rotation AWS Lambda function on the primary secret in the us-east-1 region, and configure the database credentials to use a multi-user rotation strategy with two database users.
To configure automatic secret rotation without downtime in a replicated multi-region architecture, the rotation must be configured only on the primary secret in the us-east-1 region. Secrets Manager automatically handles the propagation of the new secret value to the replica in the us-west-2 region. Furthermore, a multi-user rotation strategy must be used. By maintaining two users (active and standby), the rotation function updates the password for the standby user and updates the secret. The active user's credentials remain valid until the next rotation, ensuring that applications using cached credentials can continue to connect to the database without interruption.

Step-by-Step Solution

1
Determine the correct target for configuring secret rotation in a replicated scenario.
Identify that automatic rotation must be configured on the primary secret in the us-east-1 region.
Replica secrets in secondary regions are read-only and automatically updated by AWS Secrets Manager when the primary secret is rotated.
2
Select a rotation strategy that prevents downtime for database connections.
Choose the multi-user rotation strategy over the single-user rotation strategy.
The multi-user strategy updates a standby database user's credentials while keeping the active user's credentials valid. This prevents application instances from failing to connect due to out-of-sync cached credentials during the rotation window.
3
Implement the configuration on the primary secret.
Configure the rotation schedule and link the AWS Lambda rotation function to the primary secret in us-east-1.
This initiates the rotation sequence which updates the database, updates the primary secret, and automatically replicates the new secret value to us-west-2.

Key Concept

AWS Secrets Manager replica secrets are read-only and automatically synchronized with the primary secret. In order to rotate database credentials without causing downtime, a multi-user rotation strategy must be used, and the rotation must be configured on the primary secret in the source region.
Question 902Question →

A company stores an API key for a third-party billing platform in AWS Secrets Manager. To comply with security policies, the API key must be rotated automatically every 30 days. A SysOps administrator creates a custom AWS Lambda function to perform the rotation and deploys it in a private subnet of a VPC. When the administrator attempts to enable automatic rotation, the rotation fails. Which configurations are required to resolve this issue and successfully rotate the secret? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Add a resource-based policy to the Lambda function that grants the lambda:InvokeFunction permission to the secretsmanager.amazonaws.com service principal.; Configure the route table of the Lambda function's private subnet with a route to a NAT gateway to enable outbound internet access to the billing platform.

Answer

Grant the Secrets Manager service principal permission to invoke the Lambda function using a resource-based policy, and configure the private subnet's route table with a route to a NAT gateway to allow outbound internet access.
To successfully execute a custom rotation, the AWS Secrets Manager service principal must be granted lambda:InvokeFunction permissions on the Lambda function via a resource-based policy. Furthermore, since the Lambda function is situated in a private subnet and must reach a public third-party SaaS API endpoint to update the credentials, the subnet's route table must route internet-bound traffic through a NAT gateway located in a public subnet.

Step-by-Step Solution

1
Analyze rotation initiation requirements
Identify that AWS Secrets Manager needs permission to invoke the Lambda function, which must be configured using a Lambda resource-based policy for the service principal.
By default, Secrets Manager cannot invoke resources across services without explicit resource-based permissions.
2
Analyze network pathing for the private subnet
Identify that the Lambda function is executing inside a private VPC subnet and must reach an external SaaS billing endpoint.
Since VPC endpoints are only for AWS services or specific PrivateLink services, a route to a NAT gateway is required to reach the public internet.
3
Discard unnecessary and invalid configurations
Exclude passing roles, granting the RotateSecret permission to the Lambda execution role, or attempting to create a gateway endpoint for a third-party platform.
These actions do not align with Secrets Manager's operational model or VPC gateway routing capabilities.

Key Concept

Configuring AWS Secrets Manager custom rotation for non-AWS services requires both a Lambda resource-based policy allowing invocation by the Secrets Manager principal and a valid network routing path (such as a NAT gateway) for the VPC-bound Lambda function to reach public SaaS APIs.
Question 903Question →

A SysOps Administrator is using AWS Systems Manager Run Command to execute a custom configuration script on a fleet of Amazon EC2 instances. The SSM Agent is running on all instances, and an IAM instance profile with the `AmazonSSMManagedInstanceCore` policy is attached to each instance. The administrator configures the command to write its execution output to an Amazon S3 bucket. The S3 bucket is encrypted using a customer managed key (CMK) in AWS Key Management Service (AWS KMS). When the command is executed, it runs successfully on the instances, but the console displays a log delivery failure with an 'Access Denied' error. Which of the following actions will resolve this issue?

Show answer & explanation

Answer: Add permissions for `kms:GenerateDataKey` and `kms:Decrypt` to the IAM instance profile role of the EC2 instances, and update the KMS key policy to allow the instance profile role to use the key.

Answer

Add permissions for `kms:GenerateDataKey` and `kms:Decrypt` to the IAM instance profile role of the EC2 instances, and update the KMS key policy to allow the instance profile role to use the key.
The correct answer is to add the required KMS permissions to the instance profile role and update the KMS key policy. When Systems Manager Run Command is configured to upload logs to an S3 bucket, the upload is performed directly by the SSM Agent running on the target EC2 instance. The SSM Agent uses the credentials of the IAM instance profile role attached to the instance. Because the S3 bucket is encrypted with a customer managed KMS key, the agent must be able to generate a data key and decrypt using the KMS key. To authorize this, the permissions must be present in both the IAM instance profile role policy and the KMS key policy (since KMS key policies are authoritative).

Step-by-Step Solution

1
Identify the entity uploading the Run Command logs to S3.
The SSM Agent runs locally on each EC2 instance and uses the credentials from the attached IAM instance profile to upload logs directly to the S3 bucket.
Understanding which entity performs the operation is critical for applying the correct IAM permissions.
2
Determine the encryption requirements for the S3 bucket.
The S3 bucket is encrypted using a customer managed key (CMK) in AWS KMS, which requires the writing entity (the EC2 instance profile role) to have `kms:GenerateDataKey` and `kms:Decrypt` permissions.
Writing to an encrypted S3 bucket requires access to the KMS key that protects the bucket.
3
Configure the KMS key policy and IAM policies to allow access.
Grant the permissions in the IAM instance profile policy and also update the KMS key policy to explicitly trust the instance profile role.
KMS key policies are authoritative; an IAM policy alone cannot grant access to a KMS key unless the key policy delegates access or explicitly allows the principal.

Key Concept

AWS Systems Manager Run Command S3 Logging and KMS Key Policy Precedence
Question 904Question →

A SysOps administrator is troubleshooting an issue where an IAM user in a member account is unable to access an Amazon S3 bucket located in a different AWS account. The IAM user has an identity-based policy that grants full S3 permissions (s3:*) to the external bucket. The bucket policy in the destination account explicitly allows access from the IAM user's ARN. However, when the user attempts to list the bucket contents, they receive an Access Denied error. The member account is located within an Organizational Unit (OU) in AWS Organizations. The organization's root has the default FullAWSAccess Service Control Policy (SCP) attached. The OU containing the member account has a custom SCP attached with the following policy document:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*",
"dynamodb:*"
],
"Resource": "*"
}
]
}

What is the root cause of this Access Denied error?

Show answer & explanation

Answer: The custom SCP attached to the OU does not explicitly allow S3 actions, resulting in an implicit deny for all S3 operations originating from the member account.

Answer

The custom Service Control Policy (SCP) attached to the Organizational Unit (OU) does not explicitly allow S3 actions, resulting in an implicit deny for all S3 operations originating from the member account.
For an AWS Organizations member account, permissions are filtered by Service Control Policies (SCPs). Even if an identity-based policy and a resource-based policy explicitly allow an action, it will be blocked if it is not explicitly allowed by SCPs at every level of the hierarchy. The custom SCP at the OU level allows only EC2 and DynamoDB actions, thereby implicitly denying S3 actions for all principals in the member account.

Step-by-Step Solution

1
Verify the IAM user's identity-based policy and the destination S3 bucket policy.
Both policies allow S3 access, confirming that local and resource-level permissions are correct.
To rule out misconfigurations in the standard identity-based and resource-based policies.
2
Examine the Service Control Policies (SCPs) applied to the member account's OU.
The OU has a custom SCP that allows only ec2:* and dynamodb:* actions.
To verify if organizational boundaries are restricting permissions.
3
Determine the effective S3 permissions based on the SCP evaluation logic.
Because S3 is not explicitly allowed in the custom SCP at the OU level, it is implicitly denied for all principals in the member account.
SCPs define the maximum allowed permissions; if an action is not allowed by at least one SCP at each level, it is implicitly denied.

Key Concept

In AWS Organizations, Service Control Policies (SCPs) act as filters that define the maximum permissions for member accounts. For an action to be allowed, it must be explicitly allowed at every level of the Organization hierarchy (Root, OU, and Account). Any action not explicitly allowed is implicitly denied.
Question 905Question →

A SysOps Administrator creates a new multi-region trail in AWS CloudTrail to log all API activity in the AWS account. The administrator configures a new Amazon S3 bucket as the storage target. After several hours, the administrator notices that no CloudTrail logs have been delivered to the S3 bucket. Which of the following is the most likely cause of this log delivery failure?

Show answer & explanation

Answer: The Amazon S3 bucket policy does not grant the CloudTrail service principal permissions to write objects to the bucket.

Answer

The Amazon S3 bucket policy does not grant the CloudTrail service principal permissions to write objects to the bucket.
The correct answer is correct because AWS CloudTrail requires explicit resource-based permissions (via an S3 bucket policy) to write log objects into the designated S3 bucket. If the bucket policy does not authorize the CloudTrail service principal (cloudtrail.amazonaws.com) for the s3:PutObject action, log delivery will fail.

Step-by-Step Solution

1
Analyze the relationship between AWS CloudTrail and the target Amazon S3 bucket.
Identify that CloudTrail must write log objects directly to the S3 bucket.
CloudTrail needs permission from the resource owner (S3 bucket policy) to write logs into a destination bucket in the AWS account.
2
Evaluate the bucket policy requirements for log delivery.
Determine that the bucket policy must contain a statement allowing the CloudTrail service principal (cloudtrail.amazonaws.com) to perform the s3:PutObject action.
Without this permission, S3 will deny the write requests from CloudTrail, causing log delivery to fail.

Key Concept

Configuring permissions for log delivery targets in security monitoring.
Question 906Question →

An organization has a web application that stores transactional records in an Amazon DynamoDB table and daily report templates in an Amazon S3 bucket. A SysOps Administrator must configure a backup and disaster recovery solution that meets the following requirements:

- The DynamoDB table must support recovery to any point in time within the last 35 days.
- The S3 bucket content must be continuously replicated to a backup bucket in a secondary AWS Region.

Which TWO actions should the SysOps Administrator take to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Enable point-in-time recovery (PITR) on the source Amazon DynamoDB table.; Enable versioning on both the source and backup Amazon S3 buckets, and configure S3 Cross-Region Replication (CRR).

Answer

Enable point-in-time recovery (PITR) on the source Amazon DynamoDB table, and enable versioning on both the source and backup Amazon S3 buckets while configuring S3 Cross-Region Replication (CRR).
The correct options are enabling point-in-time recovery (PITR) on the DynamoDB table and enabling versioning on both S3 buckets while configuring S3 Cross-Region Replication (CRR). DynamoDB PITR natively supports restoring data to any second within a 35-day window. S3 Cross-Region Replication successfully replicates objects asynchronously to a secondary Region, provided that versioning is enabled on both the source and destination buckets.

Step-by-Step Solution

1
Enable DynamoDB point-in-time recovery (PITR).
This provides continuous backups of the DynamoDB table data for a rolling 35-day window, satisfying the requirement to restore to any point in time.
PITR is the native DynamoDB feature designed specifically for continuous backup and granular recovery within 35 days.
2
Enable versioning on the source and destination S3 buckets.
Both buckets are now prepared for replication.
S3 Cross-Region Replication (CRR) has a prerequisite that versioning must be enabled on both the source and destination buckets.
3
Configure S3 Cross-Region Replication (CRR).
An IAM role is created to authorize S3 to replicate objects, and a replication rule is established to continuously copy new objects to the backup bucket in the secondary Region.
CRR provides automatic, asynchronous copying of objects across buckets in different AWS Regions.

Key Concept

Continuous backups via DynamoDB PITR and object replication via S3 Cross-Region Replication (CRR) require specific configuration prerequisites, such as S3 bucket versioning.
Question 907Question →

A SysOps administrator is configuring an automated CI/CD pipeline in Account A (111111111111111111111111) to register a new Amazon ECS task definition and deploy a service on AWS Fargate. The task definition specifies an ECS Task Execution Role (`ECSTaskExecutionRole`) and an ECS Task Role (`ECSTaskRole`). The pipeline runs using the credentials of an IAM user named `PipelineDeployer`. During deployment, the pipeline fails with an error indicating that `PipelineDeployer` is not authorized to perform `iam:PassRole` on the role resources. Additionally, the application inside the ECS container must read configuration files from an Amazon S3 bucket located in Account B (222222222222222222222222). Which of the following configuration changes are required to resolve the deployment failure and grant the application the necessary runtime permissions? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Attach an IAM policy to the PipelineDeployer user in Account A that grants the iam:PassRole permission on the ECSTaskRole and ECSTaskExecutionRole ARNs.; Attach an IAM policy to the ECSTaskRole in Account A that grants s3:GetObject permission on the S3 bucket in Account B, and configure the S3 bucket policy in Account B to allow access from the ECSTaskRole ARN.

Answer

Attach an IAM policy to the PipelineDeployer user in Account A that grants the iam:PassRole permission on the roles, and attach an IAM policy to the ECSTaskRole in Account A that grants access to the S3 bucket in Account B while configuring the S3 bucket policy to permit the role.
The correct options identify the proper application of permissions. First, the PipelineDeployer user needs the iam:PassRole permission to associate the IAM roles with the ECS task definition during deployment. Second, the containerized application uses the ECS Task Role to make AWS API calls, meaning that S3 access must be granted to the ECS Task Role, and the cross-account bucket policy must allow that role's ARN.

Step-by-Step Solution

1
Analyze the deployment error.
The deployment fails due to a missing iam:PassRole permission for the PipelineDeployer user.
When creating or updating ECS tasks that use IAM roles, the deploying principal must have permission to pass those roles to the AWS service.
2
Address the runtime permission requirement.
Identify that the application code runs under the ECS Task Role, whereas the ECS container agent runs under the ECS Task Execution Role.
To retrieve configuration files from S3, the ECS Task Role must have the s3:GetObject permission, and the bucket policy in the target account must trust the ECS Task Role ARN.
3
Formulate the correct configuration changes.
Grant iam:PassRole to the PipelineDeployer user, and grant S3 access to the ECSTaskRole while establishing cross-account trust in the S3 bucket policy.
This resolves both the deployment-time permission issue and the run-time cross-account resource access issue.

Key Concept

ECS Task Role vs. ECS Task Execution Role and the necessity of the iam:PassRole permission for deployment identities.
Question 908Question →

An application container runs on Amazon Elastic Container Service (Amazon ECS) in AWS Account B (444455556666444455556666). The application must send messages to an encrypted Amazon Simple Queue Service (Amazon SQS) queue in AWS Account A (111122223333111122223333). The SQS queue is encrypted using an AWS KMS customer managed key (CMK) also located in Account A. The queue policy in Account A is configured to allow the ECS task role from Account B to perform `sqs:SendMessage` actions.

To enable the encryption flow, an administrator attached an IAM policy to the ECS task execution role in Account B, permitting `kms:GenerateDataKey` and `kms:Decrypt` on the KMS key ARN in Account A. However, the ECS task container logs show `KMS.AccessDeniedException` errors when the application attempts to publish messages.

Which combination of actions will resolve this issue? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: In Account A, update the KMS key policy to grant the Account B root principal (`arn:aws:iam::444455556666:root`) permissions to perform `kms:GenerateDataKey` and `kms:Decrypt` actions.; In Account B, attach the IAM policy containing the KMS permissions to the ECS task role instead of the ECS task execution role.

Answer

To resolve the issue, the KMS key policy in Account A must be updated to trust Account B's root principal, and the IAM policy in Account B must be attached to the ECS task role instead of the ECS task execution role.
For cross-account resource access using KMS, the resource-owning account (Account A) must delegate authorization to the caller's account (Account B) within the KMS key policy. This is achieved by adding Account B's root principal as an allowed entity for key usage. Furthermore, the application code inside the ECS container relies on the ECS task role for permissions, not the task execution role. Attaching the IAM policy to the task role gives the application container the necessary permissions to call KMS and SQS.

Step-by-Step Solution

1
Identify the credential context of the application container.
The application container running inside the ECS task uses the ECS task role, not the task execution role (which is only used by the ECS container agent).
This determines that the KMS policy must be moved from the task execution role to the task role.
2
Reassign the IAM policy granting KMS actions to the ECS task role in Account B.
The task role now possesses the permissions to call KMS endpoints.
Allows the containerized application to request KMS actions.
3
Analyze cross-account KMS evaluation logic.
For an IAM role in Account B to access a KMS key in Account A, the key policy in Account A must explicitly trust Account B (either the specific role or the root principal of Account B).
Without this delegation in the resource policy, local IAM policies in Account B have no authority.
4
Modify the KMS key policy in Account A to trust Account B's root principal (`arn:aws:iam::444455556666:root`) for the `kms:GenerateDataKey` and `kms:Decrypt` actions.
The trust path is established, allowing local IAM policies in Account B to successfully authorize the ECS task role.
Completes the cross-account authorization chain.

Key Concept

Cross-account AWS KMS key access delegation and ECS IAM role distinction.
Question 909Question →

A SysOps administrator needs to deploy a standardized security policy to protect all Application Load Balancers (ALBs) across multiple AWS accounts within an organizational unit (OU) named ProductionOU. The security policy must block known malicious IP addresses and mitigate HTTP flood attacks. The solution must centrally deploy the configurations, automatically remediate any local disassociations or modifications to the security rules, and ensure all changes are audited. Which combination of actions will meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Designate a delegated administrator account for AWS Firewall Manager, and create a Firewall Manager WAF policy targeting ALBs in the ProductionOU with auto-remediation enabled.; Include a rate-based rule and the AWS Managed Rules Amazon IP Reputation list rule group within the Firewall Manager WAF policy.

Answer

To meet the requirements, the administrator should designate a delegated administrator account for AWS Firewall Manager and create a WAF policy targeting ALBs in the ProductionOU with auto-remediation enabled. Additionally, the policy must include a rate-based rule and the AWS Managed Rules Amazon IP Reputation list rule group.
AWS Firewall Manager provides centralized management of AWS WAF rules across multiple accounts in an AWS Organization. By designating a delegated administrator and targeting the ProductionOU with auto-remediation enabled, any non-compliant local changes are automatically corrected. Including the Amazon IP Reputation list and a rate-based rule in the policy ensures protection against known threats and HTTP floods.

Step-by-Step Solution

1
Establish centralized management using AWS Firewall Manager by designating a delegated administrator account and defining a security policy targeting Application Load Balancers in the ProductionOU.
Standardized Web ACLs are pushed to all target ALBs in the specified accounts.
Firewall Manager centralizes the deployment and lifecycle of security rules across accounts.
2
Define protection rules within the Firewall Manager policy, including the AWS Managed Rules Amazon IP Reputation list to block known malicious IPs and a rate-based rule to mitigate HTTP floods.
Both threat vectors (known bad actors and rate-based floods) are blocked at the Web ACL level.
This satisfies the technical threat protection requirements.
3
Enable auto-remediation in the policy to automatically overwrite local disassociations or modifications.
Any local changes deviate from the policy are automatically corrected, returning the resources to compliance.
Ensures consistent enforcement of the security policy across all accounts.

Key Concept

Centralized threat protection and Web Application Firewall (WAF) deployment using AWS Firewall Manager to enforce security compliance across multiple AWS Organization accounts.
Question 910Question →

An enterprise application deployment contains EC2 instances in an application subnet (10.10.1.0/24) that must connect to a Microsoft SQL Server database cluster in a database subnet (10.10.2.0/24) on TCP port 1433. The default Network Access Control Lists (NACLs) have been replaced with custom NACLs that deny all traffic by default.

The current configurations are:
- The application subnet's custom NACL has an outbound rule allowing TCP port 1433 to 10.10.2.0/24, and an inbound rule allowing TCP ports 1024-65535 from 10.10.2.0/24.
- The database subnet's custom NACL has an inbound rule allowing TCP port 1433 from 10.10.1.0/24, and an outbound rule allowing TCP port 1433 to 10.10.1.0/24.
- The security groups associated with the instances allow the necessary stateful database traffic.

Although the security groups are correctly configured, database connections from the application subnet fail. Which of the following changes to the custom NACL configurations will resolve this connectivity issue?

Show answer & explanation

Answer: In the database subnet's NACL, modify the outbound rule to allow TCP port range 1024-65535 to destination 10.10.1.0/24.

Answer

In the database subnet's NACL, modify the outbound rule to allow TCP port range 1024-65535 to destination 10.10.1.0/24.
The correct option is the one that recommends modifying the database subnet's NACL outbound rule to allow TCP port range 1024-65535. Because NACLs are stateless, return traffic must be explicitly allowed. When the application client initiates a connection to the SQL Server database on port 1433, the client uses an ephemeral port (1024-65535) as its source port. The database's response will therefore have a destination port within the ephemeral port range. The database subnet's outbound NACL rule currently only allows TCP port 1433, which blocks the response traffic.

Step-by-Step Solution

1
Analyze the request path from the application subnet to the database subnet.
The application subnet's NACL outbound rule allows port 1433. The database subnet's NACL inbound rule allows port 1433. Security groups allow port 1433. The request path is clear.
Identify where in the connection lifecycle the failure occurs.
2
Analyze the response path from the database subnet to the application subnet.
The database response source port is 1433, and its destination port is the client's ephemeral port (1024-65535). Security groups are stateful and automatically allow response traffic, but NACLs are stateless and must be explicitly configured.
Since SGs are stateful and NACLs are stateless, we must check if both NACLs allow the response traffic.
3
Evaluate the database subnet's outbound NACL rule against the response packet.
The current database subnet outbound NACL rule allows TCP port 1433. However, the destination port of the response packet is ephemeral (1024-65535). Because NACL rules filter on destination ports, the response packet is denied by the default rule.
Stateless firewalls like NACLs examine the destination port of outbound packets. For return traffic, this is the client's ephemeral port range.
4
Formulate the correct configuration change to permit the response.
Modify the database subnet's outbound NACL rule to allow TCP ports 1024-65535 to destination 10.10.1.0/24.
This allows the stateless NACL to permit outgoing response packets destined for the client's ephemeral ports.

Key Concept

Stateless Network Access Control Lists (NACLs) require explicit rules for both request and response traffic, where the response traffic is destined for ephemeral ports.
Question 911Question →

A SysOps Administrator needs to schedule a weekly task that runs a custom configuration script on a fleet of Amazon EC2 instances by using an AWS Systems Manager Automation document. The EC2 instances are tagged with the key `Env` and the value `Production`. The instances have the SSM Agent installed and running, and they are associated with an IAM instance profile containing the `AmazonSSMManagedInstanceCore` managed policy.

The Administrator is using a custom IAM service role named `SSMAutomationServiceRole` to allow Systems Manager to execute the Automation workflow. However, when the Administrator attempts to run the Automation using their own IAM user account, the execution fails with an access denied error. What combination of steps must the Administrator perform to execute the Automation and target the correct instances? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Add a policy to the SysOps Administrator's IAM user that grants the `iam:PassRole` permission for the `SSMAutomationServiceRole` ARN.; Define the targets for the Automation execution by specifying resource tags with the key `Env` and the value `Production`.

Answer

To run the Automation successfully, the Administrator must add an IAM policy to their user account granting the `iam:PassRole` permission for the `SSMAutomationServiceRole` ARN, and define the targets for the Automation execution by specifying resource tags with the key `Env` and the value `Production`.
To successfully execute a Systems Manager Automation document that uses a service role, the IAM user initiating the task must have the `iam:PassRole` permission for that service role. This ensures the user is authorized to delegate permissions to the service. Additionally, specifying target filters by tag key and value is the correct way to scope the execution to the production instances dynamically.

Step-by-Step Solution

1
Analyze the IAM configuration error during the Automation execution.
Identify that the error is caused by the Administrator's IAM user lacking the ability to pass the `SSMAutomationServiceRole` to Systems Manager.
When an AWS service executes actions on a user's behalf using a service role, the user's IAM entity must have the `iam:PassRole` permission for that specific role.
2
Address the IAM permission gap.
Attach an IAM policy with the `iam:PassRole` permission for the role's ARN to the SysOps Administrator's IAM user.
This allows the user to authorize Systems Manager to use the service role to perform the configuration audit script execution.
3
Configure the target parameter for the Systems Manager Automation.
Use target tags under the Execution parameters to dynamically filter instances by key `Env` and value `Production`.
Selecting targets by resource tags is the standard, dynamic way to scope Run Command and Automation actions to a subset of managed nodes.

Key Concept

AWS Systems Manager Configuration and Run Command Automation
Question 912Question →

A SysOps Administrator is configuring AWS CloudTrail to send log events to Amazon CloudWatch Logs for real-time monitoring of security group changes. Which TWO configurations are required to successfully enable this log delivery? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: An IAM role with a trust policy that allows the AWS CloudTrail service principal to assume the role; An IAM policy attached to the role that grants permissions to perform the logs:CreateLogStream and logs:PutLogEvents actions on the target log group

Answer

To successfully enable AWS CloudTrail log delivery to Amazon CloudWatch Logs, an IAM role must be created with a trust policy that allows the CloudTrail service principal to assume the role, and this role must have a permissions policy that allows the logs:CreateLogStream and logs:PutLogEvents actions on the target log group.
To deliver logs from AWS CloudTrail to a CloudWatch Logs log group, CloudTrail must assume an IAM role. The role must have a trust policy allowing 'cloudtrail.amazonaws.com' to assume it. Additionally, the role's permissions policy must allow the logs:CreateLogStream and logs:PutLogEvents actions so that the service can write logs into the log group.

Step-by-Step Solution

1
Configure the trust policy of the IAM role to allow assume role permissions for the CloudTrail service principal.
The CloudTrail service gains the ability to assume the specified IAM role.
CloudTrail needs to assume a role in the customer account to deliver logs to resources like CloudWatch Logs log groups.
2
Attach a policy to the IAM role that allows the logs:CreateLogStream and logs:PutLogEvents permissions for the CloudWatch Logs log group resource.
The assumed role has permissions to create streams and publish log events to the log group.
Without these permissions, the CloudTrail service will fail to write the log events into the log group.

Key Concept

AWS CloudTrail integration with CloudWatch Logs requires a service-linked or user-configured IAM role with trust relationships and write permissions to the destination log group.
Question 913Question →

A company implements AWS Systems Manager Patch Manager to automate operating system updates for a fleet of Windows Server instances. An administrator creates a custom patch baseline and registers a patch group named 'Win-Prod' to this baseline. The administrator then configures a Maintenance Window targeted to target instances by group, and applies tags to the managed instances. However, during the next execution cycle, the administrator observes that none of the instances receive updates, and their compliance status remains 'Never'. Which of the following describes the most likely reason for this behavior?

Show answer & explanation

Answer: The instances are tagged with the key 'patch-group' instead of the case-sensitive key 'Patch Group', causing the maintenance window targeting the 'Win-Prod' group to skip these instances.

Answer

The target EC2 instances are tagged with the key 'patch-group' instead of the case-sensitive key 'Patch Group', which prevented Patch Manager from matching the instances to the registered baseline.
For AWS Systems Manager Patch Manager to associate a managed node with a specific patch baseline, the node must be tagged with the exact case-sensitive key 'Patch Group' and the value must match the patch group name registered to the baseline. If an incorrect tag key such as 'patch-group' is used, Patch Manager will not map the node to the custom baseline. Furthermore, if the Maintenance Window targets instances by the patch group tag, these mis-tagged instances will not be targeted at all, resulting in no patch scans executing on them and leaving their compliance status as 'Never'.

Step-by-Step Solution

1
Verify the tag keys on the target EC2 instances.
Observe that the tag key is 'patch-group' instead of 'Patch Group'.
AWS Systems Manager is strictly case-sensitive and expects the tag key 'Patch Group' to associate instances with their respective patch groups.
2
Check the Patch Group association under the custom Patch Baseline configuration.
Ensure the patch group name 'Win-Prod' is correctly registered to the custom baseline.
Confirming the baseline is mapped to the intended patch group name ensures that once tags are corrected, the instances will inherit the correct rules.
3
Correct the tag key on the EC2 instances to 'Patch Group' and trigger a scan.
The instances are targeted by the Maintenance Window and their compliance status updates from 'Never' to compliant or non-compliant.
Using the correct case-sensitive tag allows Systems Manager to resolve the association, execute the patch scan, and record compliance data.

Key Concept

Applying correct patch baseline rules through case-sensitive Patch Group tags in Systems Manager
Question 914Question →

A SysOps administrator initiates an update on a production AWS CloudFormation stack. The update fails during the modification of a database resource, triggering an automatic rollback. During this process, the stack status transitions to `UPDATE_ROLLBACK_FAILED`. Upon reviewing the stack events, the administrator discovers that CloudFormation cannot delete an old security group because it is still associated with an EC2 instance that was manually launched by a developer outside of CloudFormation. Which action should the SysOps administrator take to resolve the `UPDATE_ROLLBACK_FAILED` state and return the stack to a stable configuration?

Show answer & explanation

Answer: Run the `continue-update-rollback` CLI command with the `--resources-to-skip` parameter to skip the security group, then manually disassociate it from the EC2 instance once the stack is stable.

Answer

Run the `continue-update-rollback` CLI command with the `--resources-to-skip` parameter to skip the security group, then manually disassociate it from the EC2 instance once the stack is stable.
The correct action is to run the `continue-update-rollback` CLI command with the `--resources-to-skip` parameter specifying the logical ID of the blocked security group. When a resource rollback fails because of an external dependency (such as an active association with a manually created EC2 instance), CloudFormation blocks the rollback. Skipping this resource allows CloudFormation to complete the rollback for the remaining resources and return the stack to a stable `UPDATE_ROLLBACK_COMPLETE` status, after which the administrator can clean up the manual resource dependency.

Step-by-Step Solution

1
Identify the resource blocking the rollback by checking the stack event log in the CloudFormation console or using the CLI command `describe-stack-events`.
The log reveals that the security group cannot be deleted because it is still in use by an external EC2 instance.
Before resolving the rollback failure, you must identify which specific resource is blocking CloudFormation from reverting to the previous state.
2
Execute the `continue-update-rollback` CLI command (or use the equivalent action in the AWS Console) specifying the logical ID of the blocked security group in the `--resources-to-skip` parameter.
CloudFormation sets the status of the skipped security group to `UPDATE_COMPLETE` and resumes rolling back the rest of the stack resources.
Skipping the blocked resource allows the stack to successfully transition out of the failed rollback state to a stable `UPDATE_ROLLBACK_COMPLETE` status.
3
Once the stack is in `UPDATE_ROLLBACK_COMPLETE` status, manually detach the security group from the non-stack EC2 instance to clean up the configuration drift.
The security group is no longer associated with the external EC2 instance, allowing future clean stack updates to succeed.
Manually resolving the dependency post-rollback ensures that the infrastructure state is cleaned up without blocking immediate stack recovery.

Key Concept

Handling stack rollback failures by skipping resources that cannot be deleted or updated due to external dependencies.
Question 915Question →

A SysOps administrator is configuring a Python script to automate the remediation of non-compliant Amazon EC2 instances. The script associates an IAM instance profile containing the IAM role `AppLoggingRole` with EC2 instances that currently lack one.

The administrator's IAM user has the following IAM policy attached:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:AssociateIamInstanceProfile",
"ec2:ReplaceIamInstanceProfileAssociation"
],
"Resource": "*"
}
]
}

When running the script, the `ec2:AssociateIamInstanceProfile` API call fails with an `AccessDenied` error.

Which of the following is the root cause of this error?

Show answer & explanation

Answer: The administrator's IAM user lacks the iam:PassRole permission to pass the AppLoggingRole role to the Amazon EC2 service.

Answer

The administrator's IAM user lacks the iam:PassRole permission to pass the AppLoggingRole role to the Amazon EC2 service.
To associate an IAM instance profile with an EC2 instance, the SysOps administrator's IAM user must have the iam:PassRole permission. This permission allows the user to pass the specified role to the Amazon EC2 service. Without it, the ec2:AssociateIamInstanceProfile API call returns an AccessDenied error.

Step-by-Step Solution

1
Analyze the IAM policy attached to the SysOps administrator's IAM user.
The policy permits EC2 operations (DescribeInstances, AssociateIamInstanceProfile, ReplaceIamInstanceProfileAssociation) but does not permit any IAM operations.
Determining user permissions is the first step in diagnosing Access Denied errors.
2
Identify the AWS mechanism used when associating an IAM role with an AWS service.
AWS requires the calling identity to have the iam:PassRole permission to verify that the user is authorized to delegate the role's permissions to the service.
This prevents unauthorized users from elevating their privileges by assigning powerful roles to services they can control.
3
Differentiate between the root cause of the API failure and post-assignment issues.
The failure occurs at the ec2:AssociateIamInstanceProfile API level, which is governed by user permissions (including iam:PassRole), rather than the role's trust policy (which controls the EC2 service's ability to assume the role later).
This clarifies why missing trust relationships or lack of sts:AssumeRole do not cause the association API itself to fail.

Key Concept

IAM PassRole Permission for Service Delegation
Estimated Time:2m 0s
Question 916Question →

A SysOps Administrator is using AWS Systems Manager Run Command to execute a configuration script on a fleet of Amazon EC2 instances. The administrator attempts to target the instances using the resource tag key `Environment` with the value `Production`. The administrator verifies that the SSM Agent is installed and running on the instances, and an IAM instance profile containing the `AmazonSSMManagedInstanceCore` policy is attached. However, the Run Command console reports that zero instances are targeted. Upon checking the Systems Manager Fleet Manager console, the administrator notices that none of the target EC2 instances are listed as managed nodes. Which of the following is the most likely cause of this issue?

Show answer & explanation

Answer: The target EC2 instances are launched in a private subnet and lack network routing to a NAT gateway or interface VPC endpoints for Systems Manager.

Answer

The target EC2 instances are launched in a private subnet and lack network routing to a NAT gateway or interface VPC endpoints for Systems Manager.
The correct answer identifies that the instances lack a network path to contact AWS Systems Manager endpoints. For the SSM Agent to register an EC2 instance as a managed node, it must communicate with the Systems Manager service. In a private subnet, this requires either a route to a NAT gateway/instance or interface VPC endpoints (PrivateLink) for Systems Manager. If this connectivity is missing, the instances will never show up in Fleet Manager, rendering them untargetable by Run Command.

Step-by-Step Solution

1
Analyze the preconditions specified in the troubleshooting scenario.
The SSM Agent is running, and the IAM instance profile with `AmazonSSMManagedInstanceCore` is attached, but the instances are not showing up as managed nodes in Fleet Manager.
This narrows the root cause down to network connectivity issues rather than agent status or IAM role permissions on the instance.
2
Evaluate the network connectivity requirements for the SSM Agent.
The SSM Agent requires outbound access to Systems Manager service endpoints (ssm, ssmmessages, ec2messages) to register the instance as a managed node.
If instances are in a private subnet without a NAT gateway or interface VPC endpoints, the agent cannot establish communication, and the instances will not appear in Fleet Manager.
3
Determine which option represents the correct network connectivity resolution.
Ensuring the private subnet has routing to a NAT gateway or configuring interface VPC endpoints resolves the registration failure.
This establishes the necessary connection path for the SSM Agent to register the node.

Key Concept

AWS Systems Manager Managed Node Registration and Connectivity Requirements
Question 917Question →

A SysOps administrator is configuring an Amazon EventBridge Scheduler schedule to invoke an AWS Lambda function on a recurring basis. The schedule must execute using a custom IAM service role named SchedulerExecutionRole that has permissions to invoke the Lambda function. When the administrator attempts to create the schedule, the operation fails with a permission error indicating that the schedule cannot be created. Which of the following actions must be taken to successfully create the schedule? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Add a statement to the trust policy of the SchedulerExecutionRole to allow the scheduler.amazonaws.com service principal to perform the sts:AssumeRole action.; Attach an IAM policy to the administrator's IAM user that allows the iam:PassRole action on the SchedulerExecutionRole resource.

Answer

To resolve the permission issue, the trust policy of the SchedulerExecutionRole must be updated to allow the EventBridge Scheduler service principal (scheduler.amazonaws.com) to assume the role, and the SysOps administrator's IAM user must be granted the iam:PassRole permission to pass the role to the scheduler service.
To successfully configure Amazon EventBridge Scheduler to run using a custom execution role, two configuration conditions must be met: the scheduler service principal (scheduler.amazonaws.com) must have trust permissions to assume the role via its trust policy, and the deploying IAM identity must have the iam:PassRole permission to pass the role to the service.

Step-by-Step Solution

1
Ensure the service principal for the AWS service is trusted to assume the IAM role.
The trust policy of SchedulerExecutionRole allows scheduler.amazonaws.com to perform the sts:AssumeRole action.
EventBridge Scheduler needs to temporarily assume the execution role's identity to execute the Lambda function on your behalf.
2
Ensure the user configuring the service has permission to delegate the IAM role.
The SysOps administrator's IAM user is granted the iam:PassRole permission for the SchedulerExecutionRole.
AWS prevents users from passing arbitrary roles with elevated privileges to services by requiring the iam:PassRole permission.

Key Concept

AWS Service Role Delegation and Trust Relationships
Question 918Question →

A SysOps administrator is configuring an automated task using Amazon EventBridge Scheduler to run an AWS Systems Manager (SSM) Automation runbook (`AWS-StopEC2Instance`) on a weekly schedule. The SSM Automation runbook must execute using a service role named `SSMRemediationRole`. The EventBridge Scheduler schedule will run under a service role named `EventBridgeSchedulerExecutionRole`. When the administrator attempts to create the schedule using the AWS CLI, the command fails with an `AccessDeniedException` error. Which of the following actions must the administrator take to resolve this issue and successfully run the scheduled automation? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Attach an IAM policy to the administrator's IAM identity that allows the `iam:PassRole` action on the `EventBridgeSchedulerExecutionRole` resource.; Attach an IAM policy to the `EventBridgeSchedulerExecutionRole` that allows the `iam:PassRole` action on the `SSMRemediationRole` resource.

Answer

Attach an IAM policy to the administrator's IAM identity that allows the `iam:PassRole` action on the `EventBridgeSchedulerExecutionRole` resource, and attach an IAM policy to the `EventBridgeSchedulerExecutionRole` that allows the `iam:PassRole` action on the `SSMRemediationRole` resource.
To resolve the access denied issue, two distinct `iam:PassRole` permissions are required. First, the administrator's IAM identity must be allowed to pass the scheduler execution role (`EventBridgeSchedulerExecutionRole`) to the EventBridge Scheduler service when creating the schedule. Second, because the scheduler must start the SSM Automation runbook using the remediation role (`SSMRemediationRole`), the scheduler's execution role itself must be allowed to pass the remediation role to the Systems Manager service.

Step-by-Step Solution

1
Identify the permission required for the administrator to associate the execution role with the EventBridge Scheduler schedule.
The administrator's IAM identity requires `iam:PassRole` on the `EventBridgeSchedulerExecutionRole` to delegate permissions to the Scheduler service.
When configuring AWS services to act on behalf of a user, the user must have permission to pass the role to the service.
2
Identify the permission required for the EventBridge Scheduler to trigger SSM Automation and pass the target execution role.
The EventBridge Scheduler execution role requires `iam:PassRole` on the `SSMRemediationRole` resource.
Because the Scheduler service is starting an SSM Automation execution that requires its own service role, the Scheduler's role must have permission to pass that target role to the Systems Manager service.
3
Differentiate between `iam:PassRole` and `sts:AssumeRole` permissions.
`iam:PassRole` is an IAM permission checked when passing a role to a service, whereas `sts:AssumeRole` is an STS API call used by the service principal or entity to assume the role.
Understanding this distinction eliminates distractors that incorrectly suggest the administrator or the Scheduler role needs `sts:AssumeRole` permissions.

Key Concept

Configuring IAM PassRole and service delegation for multi-layered service invocations.
Question 919Question →

A company hosts a web application behind an Application Load Balancer (ALB) protected by an AWS WAF Web ACL. The Web ACL contains the AWS Managed Rules Common Rule Set (AWSManagedRulesCommonRuleSet) to block common web exploits.

During a deployment, a SysOps Administrator notices that legitimate requests to an administrative API endpoint, /import/config, are being blocked with an HTTP 403 Forbidden error. Troubleshooting WAF logs reveals that these requests are matching the GenericLFI_BODY rule within the managed rule group, which flags local file inclusion patterns in the request body. The administrator must resolve this false positive to allow legitimate requests to /import/config while ensuring that the rest of the application remains protected by this rule.

Which configuration will resolve the issue with the least administrative effort?

Show answer & explanation

Answer: Set the action of the GenericLFI_BODY rule within the AWSManagedRulesCommonRuleSet rule group to Count. Create a custom WAF rule in the Web ACL that evaluates after the managed rule group. Configure the custom rule to block requests that contain the awswaf:managed:aws:common-ruleset:GenericLFI_BODY label, unless the request's URI path matches /import/config.

Answer

Set the action of the GenericLFI_BODY rule within the AWSManagedRulesCommonRuleSet rule group to Count. Create a custom WAF rule in the Web ACL that evaluates after the managed rule group. Configure the custom rule to block requests that contain the awswaf:managed:aws:common-ruleset:GenericLFI_BODY label, unless the request's URI path matches /import/config.
The correct configuration overrides the specific rule action to Count in the managed rule group and creates a custom rule evaluating after it. By overriding the rule to Count, AWS WAF does not block matching requests but still applies the label 'awswaf:managed:aws:common-ruleset:GenericLFI_BODY'. The custom rule then inspects this label using the HasLabel statement and blocks requests only if they do not match the exempted URI path (/import/config). This allows the administrator to handle the false positive precisely without compromising security on other paths.

Step-by-Step Solution

1
Override the action of the specific rule (GenericLFI_BODY) within the managed rule group (AWSManagedRulesCommonRuleSet) from Block to Count.
Requests matching the Local File Inclusion rule will no longer be blocked immediately, but AWS WAF will append the label 'awswaf:managed:aws:common-ruleset:GenericLFI_BODY' to the request metadata.
This allows subsequent custom rules in the Web ACL to inspect the label before deciding whether to allow or block the request.
2
Create a custom rule in the Web ACL that is positioned to evaluate after the managed rule group.
The custom rule evaluates requests that have already passed through the managed rule group and have been labeled.
Rule order is critical in AWS WAF; the label must be applied by the managed rule group before the custom rule tries to evaluate it.
3
Configure the custom rule using an AND statement that checks if the request has the label 'awswaf:managed:aws:common-ruleset:GenericLFI_BODY' AND does NOT match the URI path '/import/config', then set the action to Block.
Requests to '/import/config' that trigger the LFI rule are allowed to pass through, while all other requests triggering the LFI rule are blocked.
This isolates the exclusion specifically to the '/import/config' path, keeping the rest of the application protected from LFI exploits.

Key Concept

Handling false positives in AWS WAF Managed Rule Groups using Rule Action Overrides and WAF Labels.
Question 920Question →

A SysOps administrator launches an Amazon EC2 instance in a subnet that is intended to be public. However, the instance is unable to send or receive traffic from the internet. Which two configurations should the administrator verify to resolve this connectivity issue?

Select all that apply

Show answer & explanation

Answer: Verify that the subnet's route table contains a route for 0.0.0.0/00.0.0.0/0 pointing to the VPC's Internet Gateway (IGW).; Verify that the EC2 instance has been assigned a public IPv4 address or an Elastic IP address.

Answer

To resolve the connectivity issue, the administrator must verify that the subnet's route table contains a route for 0.0.0.0/00.0.0.0/0 targeting the Internet Gateway, and verify that the EC2 instance is assigned a public IPv4 address or an Elastic IP address.
For an EC2 instance in a public subnet to communicate with the internet, the subnet's route table must route all non-local traffic (0.0.0.0/00.0.0.0/0) to an attached Internet Gateway, and the instance must have a public IP address (either auto-assigned or an Elastic IP) so the Internet Gateway can translate it to the private IP.

Step-by-Step Solution

1
Check the route table associated with the subnet of the EC2 instance.
Ensure there is a route with a destination of 0.0.0.0/00.0.0.0/0 pointing to the VPC's Internet Gateway (igw-xxxx).
Without an Internet Gateway target in the route table, the subnet behaves as a private subnet.
2
Check the network configuration of the EC2 instance.
Verify that a public IPv4 address or Elastic IP is assigned to the primary network interface.
An instance needs a public IP to allow the Internet Gateway to perform one-to-one NAT for internet communications.

Key Concept

Basic public subnet configuration and internet routing requirements
PreviousPage 46 / 49Next