Examkin

All practice questions

976 questions

All types976Multiple choice502Multiple select450Ordering24
Question 541Question →

A SysOps Administrator is updating an AWS CloudFormation stack. During the update process, a resource failure occurs and CloudFormation attempts to roll back the changes. However, the rollback fails, and the stack status changes to UPDATE_ROLLBACK_FAILED. The event logs indicate that the IAM service role originally used to create and manage the stack was deleted out-of-band.

What should the SysOps Administrator do to successfully complete the rollback and return the stack to a stable state?

Show answer & explanation

Answer: Run the aws cloudformation continue-update-rollback CLI command and specify a new, active IAM role ARN using the --role-arn parameter to perform the rollback operations.

Answer

Run the continue-update-rollback command and specify a new, active IAM role ARN using the --role-arn parameter to perform the rollback operations.
Executing the continue-update-rollback command with a new, active IAM role ARN allows CloudFormation to bypass the deleted execution role and complete the rollback operations.

Step-by-Step Solution

1
Analyze the stack status and events to identify why the rollback failed.
The event log reveals that the IAM execution role associated with the stack has been deleted out-of-band, preventing CloudFormation from assuming it to revert resources.
To determine the appropriate recovery action, the administrator must find the root cause of the rollback blocker.
2
Identify the remediation path for a stack in the UPDATE_ROLLBACK_FAILED state.
A stack in this state cannot be updated or deleted normally; it must either complete the rollback via the continue-update-rollback action or have specific resources skipped.
CloudFormation requires the stack to return to a stable state before accepting new updates.
3
Execute the continue-update-rollback action while providing an active execution role.
Running the continue-update-rollback command with the --role-arn parameter provides a new, valid IAM role with permissions to finish rolling back the stack.
Providing a new role ARN overrides the deleted execution role, allowing CloudFormation to successfully perform the delete and update operations needed to finish the rollback.

Key Concept

AWS CloudFormation Update Rollback Failures Remediation
Question 542Question →

A SysOps Administrator in Account AA (123456789012123456789012) is configuring an Amazon EC2 Auto Scaling group to launch instances from a shared Amazon Machine Image (AMI) owned by Account BB (987654321098987654321098). The AMI is backed by an Amazon Elastic Block Store (Amazon EBS) snapshot encrypted using a customer managed key (CMK) in Account BB. The Administrator must establish the necessary permissions so that the Auto Scaling group can decrypt the snapshot to launch the instances. Which combination of actions must the Administrator perform to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: In Account BB, update the KMS key policy of the CMK to grant the administrator identity in Account AA permissions to perform the `kms:CreateGrant` and `kms:DescribeKey` operations.; In Account AA, create a KMS grant for the Auto Scaling service-linked role (`AWSServiceRoleForAutoScaling`) using the CMK Amazon Resource Name (ARN) from Account BB, specifying the operations `Decrypt`, `GenerateDataKeyWithoutPlaintext`, and `CreateGrant`.

Answer

To resolve this, the administrator must update the KMS key policy in the key-owning account to allow the consumer account to create grants, and then create a KMS grant in the consumer account for the Auto Scaling service-linked role with the required operations.
For an Auto Scaling group to launch instances using an encrypted AMI from another account, the KMS key policy in the sharing account must allow the consumer account to create grants. Then, the consumer account must use the CLI or SDK to create a grant for the Auto Scaling service-linked role (`AWSServiceRoleForAutoScaling`) with the `Decrypt`, `GenerateDataKeyWithoutPlaintext`, and `CreateGrant` operations. This allows the Auto Scaling service to delegate the decryption of the EBS snapshot to the Amazon EC2 service when provisioning the instances.

Step-by-Step Solution

1
In Account BB, modify the KMS key policy of the CMK to delegate grant creation permissions to Account AA.
Allows administrator users or roles in Account AA to call the `kms:CreateGrant` API operation on the key.
By default, cross-account IAM policies cannot grant access to a KMS key unless the key policy itself delegates permission management to the external account.
2
In Account AA, create a KMS grant for the Auto Scaling service-linked role pointing to the CMK in Account BB.
Allows the `AWSServiceRoleForAutoScaling` role to perform `Decrypt`, `GenerateDataKeyWithoutPlaintext`, and `CreateGrant` operations.
Auto Scaling requires a grant because it uses a service-linked role to perform operations asynchronously on behalf of the customer, including delegating decryption rights to the Amazon EC2 service during instance launch.

Key Concept

Cross-account Amazon EBS encryption with Amazon EC2 Auto Scaling requires delegating KMS permissions via key policies and creating KMS grants for the service-linked role in the consumer account.
Question 543Question →

A SysOps Administrator is tasked with executing a custom configuration script on a new fleet of Amazon EC2 instances using AWS Systems Manager Run Command. The script needs to retrieve files from a private Amazon S3 bucket, and all command execution outputs must be streamed to an Amazon CloudWatch Logs group for auditing.

Arrange the steps in the correct sequence to configure the prerequisites and successfully execute the script.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the IAM role and CloudWatch Logs group, followed by attaching the IAM role to the EC2 instances and running the SSM Agent. Next, the administrator verifies that the instances are registered as managed nodes, and finally, executes the Run Command using the custom script and enabling CloudWatch Logs output.
The correct sequence begins with provisioning the necessary IAM policies and the target log group. The IAM role must then be attached to the instances to grant them an identity. Only after the instances are recognized as managed nodes by Systems Manager can the Run Command be executed to run the configuration script and stream the logs.

Step-by-Step Solution

1
Set up IAM permissions and the CloudWatch Logs group.
The destination log group exists and the IAM policy is ready with the required S3 and CloudWatch permissions.
Resources and permission policies must be established before they can be attached to instances or used as destinations.
2
Attach the IAM instance profile and verify the SSM Agent.
The EC2 instances run with the necessary IAM identity and the SSM Agent process is active.
The SSM Agent needs the IAM role permissions to successfully communicate with the Systems Manager service endpoints.
3
Verify managed node status in Systems Manager.
The instances appear in the SSM Fleet Manager console as online managed nodes.
Systems Manager cannot execute Run Command documents on instances that have not successfully completed the registration handshake.
4
Execute the Run Command targeting the managed nodes.
The shell script is executed on the target instances, and logs are successfully sent to CloudWatch.
Run Command execution is the final operational step once all IAM, agent, and network prerequisites are satisfied.

Key Concept

Configuring the necessary IAM instance profile permissions, SSM Agent registration, and executing commands using Systems Manager Run Command with logging.
Question 544Question →

A company runs a microservices application where a payment processing service in Subnet Alpha (10.200.1.0/2410.200.1.0/24) must make API calls to a verification service in Subnet Beta (10.200.2.0/2410.200.2.0/24) on TCP port 84438443. A custom Network Access Control List (NACL) is associated with Subnet Alpha, while Subnet Beta uses the default VPC NACL. Security groups for both services are configured to allow the required traffic. However, connection attempts from Subnet Alpha to Subnet Beta on port 84438443 are timing out.

Which configuration change must be made to the Subnet Alpha NACL to enable successful communication?

Show answer & explanation

Answer: Add an outbound rule to allow TCP port 8443 to Subnet Beta, and add an inbound rule to allow TCP ports 1024-65535 from Subnet Beta.

Answer

Add an outbound rule to allow TCP port 8443 to Subnet Beta, and add an inbound rule to allow TCP ports 1024-65535 from Subnet Beta.
Network Access Control Lists (NACLs) are stateless. To allow the payment processing service in Subnet Alpha to establish a connection with the verification service in Subnet Beta on port 8443, Subnet Alpha's NACL must permit outbound TCP traffic to Subnet Beta on port 8443 (for the request) and permit inbound TCP traffic from Subnet Beta on ports 1024-65535 (for the response to the client's ephemeral port).

Step-by-Step Solution

1
Analyze the traffic flow requirements from the source (Subnet Alpha) to the destination (Subnet Beta).
The initial request travels outbound from Subnet Alpha to Subnet Beta on TCP port 8443. The return traffic travels inbound from Subnet Beta back to Subnet Alpha on a client-allocated ephemeral port in the range 1024-65535.
Since Network Access Control Lists (NACLs) are stateless, separate rules must be evaluated for both outbound request traffic and inbound response traffic.
2
Formulate the outbound NACL rule for Subnet Alpha.
Create an outbound rule with a destination CIDR of Subnet Beta (10.200.2.0/24), protocol TCP, and port 8443 set to ALLOW.
This allows the client application in Subnet Alpha to initiate connections to the verification service.
3
Formulate the inbound NACL rule for Subnet Alpha to handle the return path.
Create an inbound rule with a source CIDR of Subnet Beta (10.200.2.0/24), protocol TCP, and port range 1024-65535 set to ALLOW.
This allows the response from the verification service to reach the client's temporary ephemeral port, completing the TCP handshake and session.

Key Concept

Network Access Control Lists (NACLs) are stateless network filters that require explicit rules for both the request and response traffic paths, including the allocation of ephemeral ports for client connections.
Question 545Question →

A SysOps Administrator is auditing a multi-account environment where AWS CloudTrail logs are consolidated into a central Amazon S3 bucket. The logs and digest files are encrypted using an AWS KMS customer managed key. During a compliance check, the administrator runs the AWS CLI command to verify log file integrity, but the command fails with an access denied error on decryption. Additionally, the compliance team reports that read-only API activity, such as listing S3 objects and describing EC2 instances, is missing from the logs, although resource modifications are successfully recorded. Which two actions should the SysOps Administrator take to resolve these issues? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Update the CloudTrail trail configuration to capture All Read/Write events instead of write-only events.; Ensure that the IAM identity executing the log validation command has kms:Decrypt and kms:DescribeKey permissions for the customer managed key.

Answer

Updating the CloudTrail trail configuration to capture all Read/Write events, and ensuring the IAM identity executing the validation has decrypt permissions on the customer managed key.
To resolve the missing read-only events, the CloudTrail configuration must be updated to log all events rather than write-only events. For the validation failure, the administrator's local machine performs the validation by retrieving the logs and decrypting them, meaning the IAM identity running the command must have permissions to decrypt using the KMS customer managed key.

Step-by-Step Solution

1
Identify the cause of the missing read-only events by checking the trail configuration.
The trail's event selector is configured for write-only events.
By default or by custom configuration, write-only logging excludes read-only API calls such as Describe and List actions.
2
Modify the event selector of the CloudTrail trail.
Change the setting to record 'All' events (both Read and Write).
This ensures both management modifications and read-only API calls are captured in the S3 bucket.
3
Diagnose the log validation failure.
The AWS CLI verify-log-file-consistency command fails with a decryption error.
The validation process runs locally on the administrator's machine, requiring the user's IAM credentials to download and decrypt the logs using the custom KMS key.
4
Update the policy of the customer managed key to grant decryption permissions to the validator's IAM identity.
Add kms:Decrypt and kms:DescribeKey permissions for the administrator's IAM user or role.
This allows the client executing the validation command to successfully decrypt the digests and verify log file integrity.

Key Concept

CloudTrail Log Auditing and Integrity Validation
Question 546Question →

A SysOps Administrator is using AWS Systems Manager Run Command to execute a maintenance script on a fleet of Amazon EC2 instances. All target instances have the SSM Agent installed and running, and they are associated with an IAM instance profile containing the AmazonSSMManagedInstanceCore policy. The administrator configures the Run Command to output execution logs to an Amazon S3 bucket that is encrypted using an AWS KMS customer managed key. The command runs successfully on the instances, but the execution logs fail to appear in the S3 bucket. Which of the following is the most likely cause of this issue?

Show answer & explanation

Answer: The IAM instance profile role associated with the EC2 instances lacks permission to perform the kms:GenerateDataKey action on the KMS key.

Answer

The IAM instance profile role associated with the EC2 instances lacks permission to perform the kms:GenerateDataKey action on the KMS key.
When configuring AWS Systems Manager Run Command to send output logs to an Amazon S3 bucket encrypted with SSE-KMS using a customer managed key, the SSM Agent running on the EC2 instance writes the logs directly. Therefore, the IAM instance profile role attached to the EC2 instances must have permission to perform the kms:GenerateDataKey action on the KMS key to encrypt the log objects during upload.

Step-by-Step Solution

1
Analyze the log delivery path for Systems Manager Run Command.
The SSM Agent running locally on each EC2 instance writes the execution logs directly to the target Amazon S3 bucket.
This establishes that log delivery actions are performed using the credentials of the EC2 instance profile, not a service role or the Systems Manager service principal.
2
Identify the encryption requirements for writing to the S3 bucket.
Since the S3 bucket is encrypted with an AWS KMS customer managed key, any write operation must generate a data key using that KMS key.
Writing to an SSE-KMS encrypted bucket requires permissions to perform the kms:GenerateDataKey cryptographic action.
3
Determine the necessary IAM configuration to authorize the write operation.
The instance profile role must be explicitly granted the kms:GenerateDataKey action on the custom KMS key, as the default AmazonSSMManagedInstanceCore policy does not contain permissions for custom KMS keys.
Adding these permissions resolves the Access Denied issue when the SSM Agent attempts to upload the log files.

Key Concept

Systems Manager Run Command S3 log export permissions and KMS encryption
Estimated Time:1m 30s
Question 547Question →

A SysOps administrator is configuring a scheduled backup plan using AWS Backup. The backup plan must run under a custom IAM service role. The administrator creates the service role with the necessary permissions policy but receives an 'Access Denied' error when attempting to assign the role to the backup selection in the console. Which actions must the administrator perform to successfully assign the role and ensure the backup plan executes? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Attach an IAM policy to the administrator's IAM identity that grants the iam:PassRole permission for the custom service role.; Update the trust policy of the custom service role to allow backup.amazonaws.com to perform the sts:AssumeRole action.

Answer

Attach an IAM policy to the administrator's IAM identity that grants the iam:PassRole permission for the custom service role, and update the trust policy of the custom service role to allow backup.amazonaws.com to perform the sts:AssumeRole action.
To successfully configure and run the backup plan under a custom service role, two conditions must be met: First, the administrator must have permission to pass the role to AWS Backup, which is configured via the iam:PassRole action. Second, the service role must trust the AWS Backup service to assume it, which is configured by granting the sts:AssumeRole action to backup.amazonaws.com in the role's trust policy.

Step-by-Step Solution

1
Identify the two separate permissions required when configuring an AWS service role: the permission for the administrator to associate the role, and the permission for the service to assume the role.
Determined that the administrator needs iam:PassRole and the service needs sts:AssumeRole.
AWS security requires explicit permission delegation so that users cannot pass roles with elevated privileges that they themselves do not possess, and roles must explicitly trust services that assume them.
2
Configure the administrator's IAM identity policy.
Added a statement allowing iam:PassRole on the custom service role resource.
This allows the administrator to delegate (pass) the role to AWS Backup.
3
Configure the service role's trust policy.
Added a trust relationship statement allowing the backup.amazonaws.com principal to perform sts:AssumeRole.
This allows AWS Backup to assume the role's identity at runtime.

Key Concept

Delegating permissions to AWS services using iam:PassRole and configuring role trust policies with sts:AssumeRole.
Question 548Question →

A SysOps Administrator is managing an infrastructure stack deployed via AWS CloudFormation. During a stack update, a resource modification fails, prompting CloudFormation to roll back the stack. However, the rollback fails, and the stack enters the UPDATE_ROLLBACK_FAILED state because a DynamoDB table created by the stack was manually deleted outside of CloudFormation during the update process. Which of the following actions should the SysOps Administrator take to successfully resolve the update rollback failure and return the stack to a stable state? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Continue the update rollback and specify the DynamoDB table as a resource to skip.; Manually recreate the DynamoDB table with the exact same name, and then continue the update rollback.

Answer

To resolve the rollback failure, the administrator can either continue the update rollback and select the DynamoDB table to be skipped, or manually recreate the DynamoDB table with the exact same name and then continue the update rollback.
To resolve a stack that has failed to roll back and is in the UPDATE_ROLLBACK_FAILED state, you must either fix the underlying issue that caused the failure or skip the failed resources during the rollback. Recreating a manually deleted resource (like a DynamoDB table) with the same name allows CloudFormation to find the resource and complete the rollback process. Alternatively, choosing to skip the resource allows the rollback to finish, although the resource must then be manually reconciled to match the template.

Step-by-Step Solution

1
Identify the root cause of the rollback failure from the stack events.
The events show that the rollback failed because a DynamoDB table resource was manually deleted outside of CloudFormation.
Understanding the cause allows the administrator to decide whether to skip the resource or recreate it.
2
Choose to either skip the blocked resource or recreate it.
If skipping, CloudFormation continues rollback and marks it as UPDATE_COMPLETE. If recreating, recreating the table with the same name enables CloudFormation to perform rollback actions on it.
These are the only two valid pathways to resolve a rollback block.
3
Continue the update rollback from the CloudFormation console or AWS CLI.
The rollback completes successfully, returning the stack to a stable UPDATE_ROLLBACK_COMPLETE or ROLLBACK_COMPLETE state.
This clears the failed state and allows future updates to the stack.

Key Concept

Remediating CloudFormation rollback failures caused by missing resources
Estimated Time:2m 0s
Question 549Question →

A company manages a fleet of hybrid Amazon EC2 instances and on-premises physical servers running Red Hat Enterprise Linux (RHEL). A SysOps Administrator is configuring AWS Systems Manager Patch Manager to automate patch installations on these managed nodes using a custom patch baseline. The administrator has already registered the on-premises servers as managed nodes using hybrid activations and tagged all target nodes with the key 'Patch Group' and value 'Production-RHEL'. Which of the following actions must the SysOps Administrator perform to ensure that patches are successfully applied to all managed nodes during a scheduled maintenance window? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Associate the custom patch baseline with the patch group 'Production-RHEL' within Systems Manager Patch Manager.; Register a target with the Maintenance Window using the 'Patch Group' tag key and value 'Production-RHEL', then assign the AWS-RunPatchBaseline task to that target.

Answer

Associate the custom patch baseline with the patch group 'Production-RHEL' within Systems Manager Patch Manager, and register a target with the Maintenance Window using the 'Patch Group' tag key and value 'Production-RHEL', then assign the AWS-RunPatchBaseline task to that target.
To apply the custom patch baseline to the RHEL fleet, the administrator must map the baseline to the 'Production-RHEL' patch group. Additionally, the administrator must define a target in the Maintenance Window utilizing the exact, case-sensitive tag key 'Patch Group' and assign the 'AWS-RunPatchBaseline' task to orchestrate execution.

Step-by-Step Solution

1
Register the patch group with the custom baseline.
The baseline is associated with the 'Production-RHEL' group.
This guarantees that when Patch Manager runs, it knows which update rules to apply to the Red Hat Enterprise Linux nodes.
2
Configure the Maintenance Window target.
The target definition is configured using the 'Patch Group' key with 'Production-RHEL' as the value.
This correctly groups both the EC2 instances and registered hybrid on-premises nodes for execution.
3
Assign the AWS-RunPatchBaseline task to the Maintenance Window targets.
The patching command is scheduled to run on the targeted nodes.
The task executes the SSM document that orchestrates the download and installation of patches.

Key Concept

Patch Groups and Maintenance Window Orchestration
Question 550Question →

A SysOps administrator is configuring an AWS Glue crawler to scan an Amazon S3 bucket. The administrator has created a custom IAM role named GlueCrawlerRole that has the required S3 read permissions and has configured AWS Glue as the trusted service in the trust policy. When the administrator attempts to create the crawler using the AWS Management Console and associates it with GlueCrawlerRole, the console displays an error: "Access Denied: You do not have permission to perform this action."

Which action must be taken to successfully create the crawler?

Show answer & explanation

Answer: Attach an IAM policy to the administrator's IAM user that grants iam:PassRole permissions for the GlueCrawlerRole ARN.

Answer

Attach an IAM policy to the administrator's IAM user that grants iam:PassRole permissions for the GlueCrawlerRole ARN.
The correct option is to attach an IAM policy to the administrator's IAM user that grants iam:PassRole permissions. When configuring AWS services to act on your behalf, you must have permission to pass the role to that service. The iam:PassRole permission checks if the user is authorized to associate the specific role with the service.

Step-by-Step Solution

1
Identify the context of the error.
The SysOps administrator is assigning an IAM role (GlueCrawlerRole) to an AWS service (AWS Glue) during resource configuration.
The error occurs at the time of crawler creation and role association, indicating a control plane permission issue rather than a runtime execution issue.
2
Determine the required IAM permission for associating a role with a service.
The administrator's IAM policy requires the iam:PassRole action.
AWS enforces the iam:PassRole permission to ensure that users cannot elevate their privileges by passing highly privileged roles to services they configure.
3
Verify service trust configuration.
The trust policy on GlueCrawlerRole is already configured correctly with AWS Glue as the trusted service.
AWS Glue needs to assume the role during execution, but the administrator first needs to pass it, which requires user-side permissions.

Key Concept

IAM PassRole permissions are required to associate an IAM role with an AWS service.
Question 551Question →

A SysOps Administrator deployed a security group using an AWS CloudFormation template. Later, a developer manually added an inbound rule for port 22 (SSH) to the security group using the Amazon EC2 Console. The Administrator runs drift detection on the stack and identifies that the security group status is DRIFTED. The Administrator wants to remediate the drift so that the security group configuration matches the CloudFormation template again, without replacing the resource.

Which action should the Administrator take to resolve the drift?

Show answer & explanation

Answer: Manually delete the port 22 inbound rule from the security group in the Amazon EC2 Console, and then run drift detection on the stack again.

Answer

Manually delete the port 22 inbound rule from the security group in the Amazon EC2 Console, and then run drift detection on the stack again.
To remediate resource drift back to the template's defined configuration without replacing the resource, the manual (out-of-band) changes must be reverted directly on the resource itself (e.g., deleting the rule in the EC2 Console). Once the resource is manually updated to match the template, running drift detection again will verify that the resource status has returned to IN_SYNC. AWS CloudFormation does not automatically revert or overwrite out-of-band resource modifications during a stack update if there are no changes to the template itself.

Step-by-Step Solution

1
Identify the manual configuration changes that caused the drift status to be DRIFTED.
Confirming the exact property difference (inbound port 22 rule addition) between the expected template state and the actual state.
Before remediating, you must know what modifications were made out-of-band.
2
Log in to the Amazon EC2 Console, locate the drifted security group, and delete the manually added inbound rule for port 22.
The physical resource is returned to the state defined in the CloudFormation template.
CloudFormation does not automatically overwrite manual changes during updates without template modifications, so the resource must be reverted manually.
3
Return to the CloudFormation console and run drift detection on the stack again.
The stack status returns to IN_SYNC.
This confirms that the physical resource configuration now matches the template definition.

Key Concept

Drift remediation in AWS CloudFormation requires either manually reverting the out-of-band changes on the resource or updating the template to match the new state; running a stack update with an unchanged template will not resolve the drift.
Question 552Question →

An organization uses AWS Systems Manager Patch Manager to automate security updates on a fleet of Amazon EC2 instances running Red Hat Enterprise Linux (RHEL). A SysOps administrator is setting up a Maintenance Window to run a custom OS patching automation. The administrator creates a custom SSM Automation document and an IAM service role named PatchingExecutionRole that allows Systems Manager to perform actions on the instances. When the administrator attempts to register the SSM Automation task within the Maintenance Window using the AWS CLI, the operation fails with an AccessDenied exception stating that the user is not authorized to perform iam:PassRole on the resource PatchingExecutionRole.

What is the correct action to resolve this issue and successfully register the task?

Show answer & explanation

Answer: Attach an IAM policy to the SysOps administrator's IAM identity that grants the iam:PassRole permission for the PatchingExecutionRole Amazon Resource Name (ARN).

Answer

Attach an IAM policy to the SysOps administrator's IAM identity that grants the iam:PassRole permission for the PatchingExecutionRole Amazon Resource Name (ARN).
The correct action is to attach an IAM policy to the SysOps administrator's IAM identity that grants the iam:PassRole permission for the PatchingExecutionRole Amazon Resource Name (ARN). This is because the AWS CLI registration command requires the administrator to pass the service role to Systems Manager, which requires explicit iam:PassRole permissions on the user side.

Step-by-Step Solution

1
Analyze the error message to locate the missing permission and the resource it applies to.
The administrator lacks the iam:PassRole permission on the PatchingExecutionRole resource.
This identifies that the issue is an authorization failure for the user, not a trust configuration issue on the role itself.
2
Create or modify an IAM policy to grant the missing permission.
An IAM policy is created with the action 'iam:PassRole' targeting the ARN of PatchingExecutionRole.
The user attempting to register the task must be explicitly authorized to pass the role to Systems Manager.
3
Attach the policy to the SysOps administrator's IAM identity (user, group, or role).
The administrator successfully registers the task with the Maintenance Window using the AWS CLI.
Applying the policy provides the necessary credentials for the CLI call to succeed.

Key Concept

IAM PassRole Permission for Systems Manager Tasks
Question 553Question →

A company has two VPCs: VPC A with CIDR block 10.1.0.0/1610.1.0.0/16 and VPC B with CIDR block 10.2.0.0/1610.2.0.0/16. The VPCs are connected using an AWS Transit Gateway. A SysOps administrator is troubleshooting a connectivity issue where Amazon EC2 instances in a private subnet (10.1.1.0/2410.1.1.0/24) of VPC A cannot connect to an Amazon RDS DB instance in a private subnet (10.2.2.0/2410.2.2.0/24) of VPC B.

The administrator verifies the following configuration details:
- The Transit Gateway route tables show active attachments and successful route propagation for both VPCs.
- The subnet route table for VPC A has a route for 10.2.0.0/1610.2.0.0/16 pointing to the Transit Gateway.
- The subnet route table for VPC B has a route for 10.1.0.0/1610.1.0.0/16 pointing to the Transit Gateway.
- The Network ACLs (NACLs) for all subnets in both VPCs allow all inbound and outbound traffic.

Which of the following is the most likely cause of this connection failure?

Show answer & explanation

Answer: The security group associated with the RDS DB instance in VPC B references the security group ID of the EC2 instances in VPC A as its source.

Answer

The security group associated with the RDS DB instance in VPC B references the security group ID of the EC2 instances in VPC A as its source.
The correct answer is that the database security group references the EC2 instances' security group ID. AWS Transit Gateway does not support security group referencing across VPC attachments. In contrast to VPC Peering within the same region, where you can reference security groups across VPCs, security groups across a Transit Gateway must allow traffic using CIDR blocks (e.g., 10.1.0.0/1610.1.0.0/16 or 10.1.1.0/2410.1.1.0/24) as the source.

Step-by-Step Solution

1
Analyze the network path between the EC2 instances in VPC A (10.1.1.0/2410.1.1.0/24) and the RDS DB instance in VPC B (10.2.2.0/2410.2.2.0/24).
Confirm that the routing is set up correctly in both VPC route tables and Transit Gateway route tables, and that stateless Network ACL rules are not blocking traffic.
Eliminates routing configuration and stateless firewalls as potential points of failure.
2
Evaluate the stateful firewall rules (Security Groups) on both ends.
Identify that the destination (RDS DB instance) security group uses a rule referencing the security group ID of the EC2 instances from the source VPC.
Security groups must permit the incoming database traffic (typically port 3306 for MySQL) from the source subnet or instance.
3
Determine the support for security group referencing over Transit Gateway.
Acknowledge that AWS Transit Gateway does not support referencing security groups across different VPCs (unlike VPC Peering in the same region).
This is a key technical limitation of Transit Gateway that causes security group rules based on ID references to evaluate as non-matching.
4
Recommend the resolution step.
Change the RDS security group inbound source from the EC2 security group ID to the CIDR block of VPC A (10.1.0.0/1610.1.0.0/16) or the specific EC2 subnet (10.1.1.0/2410.1.1.0/24).
Allows traffic from the private subnet range over the Transit Gateway connection.

Key Concept

AWS Transit Gateway Security Group Reference Limitation
Question 554Question →

A financial company needs to enforce OS patch compliance across its fleet of production Windows Server 2022 EC2 instances. The system requires that only critical security updates be installed, bypassing the default AWS-managed baseline. A SysOps Administrator is tasked with establishing a weekly automated patch deployment workflow using AWS Systems Manager.

Order the steps below to reflect the correct sequence for configuring and executing this patching workflow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence is: 1) Create a custom patch baseline for Windows Server, 2) Apply a tag to the target Windows Server EC2 instances with the case-sensitive key 'Patch Group' and a value like 'Win-Prod', 3) Register the 'Win-Prod' patch group with the custom patch baseline, 4) Create a Maintenance Window and register the target instances using the patch group, and 5) Register a Run Command task under the Maintenance Window executing the AWS-RunPatchBaseline document.
To successfully automate patching with a custom baseline, the administrator must first create the custom baseline containing the required rules. Next, the target instances must be tagged with the case-sensitive tag key 'Patch Group' to assign them to a patch group. The patch group must then be registered with the custom baseline to override the default baseline. Finally, a maintenance window is created, targets are registered using the patch group, and the AWS-RunPatchBaseline document task is registered to perform the installation during the window.

Step-by-Step Solution

1
Create a custom patch baseline.
A baseline exists specifying the approval rules for critical security updates.
AWS Systems Manager Patch Manager requires a baseline to know which updates to approve. By default, it uses a generic AWS-managed baseline. A custom baseline is required to enforce specific patch rules.
2
Tag the instances with the case-sensitive 'Patch Group' key.
Instances are logically grouped together in Patch Manager.
Patch groups allow you to target specific sets of instances for baseline association and maintenance window tasks. The tag key must be exactly 'Patch Group' (case-sensitive).
3
Associate the patch group with the custom baseline.
The 'Win-Prod' patch group is registered to the custom patch baseline.
This step overrides the default baseline. Systems Manager will now apply the custom baseline rules to any instance tagged with that patch group.
4
Configure the maintenance window and targets.
A scheduled window is defined with registered EC2 targets.
The maintenance window defines when patching occurs. Registering the targets using the patch group simplifies management.
5
Register the AWS-RunPatchBaseline task to the maintenance window.
The patching task is scheduled to run on the targets during the maintenance window.
The task executes the actual patching process using the AWS-RunPatchBaseline document, which references the baseline associated with the patch group.

Key Concept

AWS Systems Manager Patch Manager operational setup sequence using custom baselines, patch groups, and maintenance windows.
Question 555Question →

A SysOps Administrator is configuring Amazon EC2 instances in a private subnet to securely communicate with Amazon SNS without traversing the public internet. The administrator creates an Interface VPC Endpoint for Amazon SNS (com.amazonaws.us-east-1.sns) in the VPC. The VPC has both DNS resolution and DNS hostnames enabled. However, the EC2 instances still fail to connect to Amazon SNS, resulting in connection timeouts. Which configuration change will resolve this issue?

Show answer & explanation

Answer: Modify the security group associated with the Interface VPC Endpoint to allow inbound HTTPS traffic on port 443 from the security group of the EC2 instances.

Answer

Modify the security group associated with the Interface VPC Endpoint to allow inbound HTTPS traffic on port 443 from the security group of the EC2 instances.
The correct option is to modify the security group associated with the Interface VPC Endpoint to allow inbound HTTPS traffic on port 443 from the security group of the EC2 instances. Interface VPC Endpoints place Elastic Network Interfaces (ENIs) inside the VPC subnets. These ENIs are associated with security groups. Because the EC2 instances communicate with the SNS endpoint over HTTPS (port 443), the security group on the endpoint ENIs must explicitly allow inbound traffic from the EC2 instances.

Step-by-Step Solution

1
Identify the type of VPC Endpoint being used.
The configuration uses an Interface VPC Endpoint (AWS PrivateLink) for Amazon SNS.
Interface endpoints create Elastic Network Interfaces (ENIs) in the subnet, which are secured using security groups, whereas Gateway endpoints use route tables.
2
Analyze why connection timeouts occur to Interface Endpoints.
Connection timeouts typically point to network-level blocking, which is controlled by Security Groups or Network ACLs (NACLs) rather than route tables.
Since DNS resolution and DNS hostnames are enabled, the application correctly resolves the SNS service DNS to the endpoint's private IP addresses, but the network request is blocked by the security group.
3
Apply the correct Security Group rule.
Allow inbound HTTPS (port 443) traffic on the endpoint's security group from the EC2 instances.
This allows the HTTPS API calls from the EC2 instances to reach the Interface VPC Endpoint successfully.

Key Concept

Interface VPC Endpoints (AWS PrivateLink) require appropriate security group configurations to allow inbound traffic on port 443 from consumer resources, and they do not rely on route table updates.
Question 556Question →

An operations team is implementing a continuous integration and continuous delivery (CI/CD) pipeline to deploy infrastructure using AWS CloudFormation. The pipeline runner executes under an IAM role named `PipelineDeploymentRole`. To enforce the principle of least privilege, the team creates a separate IAM role named `CloudFormationServiceRole` that contains only the permissions required to create and manage the specific resources in the stack. When the pipeline runner attempts to initiate the deployment and specifies the service role, the deployment fails with an error indicating that the runner is not authorized to use the specified service role.

Which configuration changes must be made to allow the pipeline runner to successfully deploy the stack using this service role? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Add an IAM policy to the `PipelineDeploymentRole` that allows the `iam:PassRole` action targeting the Amazon Resource Name (ARN) of the `CloudFormationServiceRole`.; Configure the trust policy of the `CloudFormationServiceRole` to allow the `cloudformation.amazonaws.com` service principal to perform the `sts:AssumeRole` action.

Answer

To resolve the issue, the pipeline runner role must be granted `iam:PassRole` permissions to pass the CloudFormation service role, and the CloudFormation service role's trust policy must allow the CloudFormation service principal to assume it.
To successfully deploy an AWS CloudFormation stack using a service role, two components are required: first, the calling principal (the pipeline runner using `PipelineDeploymentRole`) must have `iam:PassRole` permissions to delegate the `CloudFormationServiceRole` to AWS CloudFormation; second, the `CloudFormationServiceRole` must have a trust policy allowing the AWS CloudFormation service principal (`cloudformation.amazonaws.com`) to assume the role via `sts:AssumeRole`.

Step-by-Step Solution

1
Analyze the service delegation model for AWS CloudFormation.
Understand that the deployment pipeline runner passes the execution role to AWS CloudFormation, which then assumes the role to perform resource provisioning.
This flow dictates the required permissions: the pipeline runner needs to pass the role, and CloudFormation needs to assume the role.
2
Configure the permission policy of the calling identity (`PipelineDeploymentRole`).
Add `iam:PassRole` targeting the ARN of `CloudFormationServiceRole` to the policy attached to the pipeline runner.
Without `iam:PassRole`, AWS prevents users or roles from passing a role to an AWS service to prevent privilege escalation.
3
Configure the trust policy (assume role policy document) of the execution role (`CloudFormationServiceRole`).
Set the Principal to `cloudformation.amazonaws.com` and Action to `sts:AssumeRole`.
This allows the CloudFormation service to assume the permissions of the role when executing stack operations.

Key Concept

IAM Role Delegation and PassRole vs AssumeRole Permissions
Question 557Question →

An application server in a custom VPC is deployed in Subnet App (CIDR: 192.168.10.0/24192.168.10.0/24). It is configured to send log data via TCP to a self-managed log collector instance in Subnet Service (CIDR: 192.168.20.0/24192.168.20.0/24) on port 514514. The security group for the log collector allows inbound TCP port 514514 traffic from Subnet App. The security group for the application server allows all outbound traffic. The Network Access Control Lists (NACLs) are configured as follows:

- Subnet App NACL:
- Inbound: Allow all traffic
- Outbound: Allow TCP port 514514 to Subnet Service (192.168.20.0/24192.168.20.0/24)

- Subnet Service NACL:
- Inbound: Allow TCP port 514514 from Subnet App (192.168.10.0/24192.168.10.0/24)
- Outbound: Allow TCP port 514514 to Subnet App (192.168.10.0/24192.168.10.0/24)

The application server cannot successfully establish a connection to the log collector. Which configuration change is required to resolve this connectivity issue?

Show answer & explanation

Answer: Add a rule to the Network ACL of Subnet Service to allow outbound TCP traffic to Subnet App (192.168.10.0/24192.168.10.0/24) on ports 1024−655351024-65535.

Answer

Add a rule to the Network ACL of Subnet Service to allow outbound TCP traffic to Subnet App on ports 1024-65535.
The correct option is to add an outbound rule to the Subnet Service Network ACL to allow TCP traffic to Subnet App on ports 1024-65535. Network ACLs are stateless, meaning they evaluate traffic in each direction independently. The application server initiates a connection using an ephemeral port (1024-65535) as its source port. The response from the log collector is directed to that ephemeral port as the destination port. Therefore, the outbound NACL for Subnet Service must permit traffic to those ports.

Step-by-Step Solution

1
Analyze the connection flow and ports.
The application server initiates a connection to the log collector. The request traffic travels from Subnet App (source port: ephemeral 1024−655351024-65535) to Subnet Service (destination port: 514514).
Understanding the source and destination ports for both request and response paths is necessary to configure stateless rules.
2
Evaluate the stateful security group rules.
The security groups allow the flow. Since security groups are stateful, return traffic is automatically permitted by the security group once the inbound request is allowed.
Security groups do not block the return path due to their stateful nature.
3
Evaluate the stateless Network ACL (NACL) rules for the response path.
The response traffic travels from Subnet Service (source port: 514514) to Subnet App (destination port: ephemeral 1024−655351024-65535). Currently, the outbound NACL for Subnet Service only allows outbound traffic with a destination port of 514514, which does not match the ephemeral ports.
NACLs are stateless and require explicit rules for both inbound request and outbound response paths.
4
Identify the required rule modification.
An outbound rule must be added to Subnet Service NACL allowing TCP traffic to Subnet App on ports 1024−655351024-65535.
This rule matches the destination port range of the return traffic, allowing the connection to be established successfully.

Key Concept

Stateless Network ACLs require explicit configuration for return traffic targeting client ephemeral ports.
Question 558Question →

A development team has configured a VPC peering connection (`pcx-0a1b2c3d4e5f6g7h8`) between a database VPC (CIDR 172.31.0.0/16172.31.0.0/16) and an application VPC (CIDR 10.100.0.0/1610.100.0.0/16). An application server with IP address 10.100.1.4510.100.1.45 in Subnet App-1 is unable to connect to a PostgreSQL database instance with IP address 172.31.10.12172.31.10.12 in Subnet DB-1. The database security group has been configured to allow incoming traffic on port 54325432 from 10.100.1.45/3210.100.1.45/32. The network ACLs for both subnets are configured with their default settings.

Which actions must be completed to enable successful communication between the application server and the database instance? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Add a route to the route table associated with Subnet App-1 that routes traffic for 172.31.0.0/16172.31.0.0/16 through `pcx-0a1b2c3d4e5f6g7h8`.; Add a route to the route table associated with Subnet DB-1 that routes traffic for 10.100.0.0/1610.100.0.0/16 through `pcx-0a1b2c3d4e5f6g7h8`.

Answer

Add a route to the route table associated with Subnet App-1 that routes traffic for 172.31.0.0/16172.31.0.0/16 through the peering connection, and add a route to the route table associated with Subnet DB-1 that routes traffic for 10.100.0.0/1610.100.0.0/16 through the peering connection.
For communication to succeed across a VPC peering connection, bidirectional route table entries must exist. The route table for the application subnet must route database traffic (172.31.0.0/16172.31.0.0/16) to the peering connection, and the route table for the database subnet must route return traffic (10.100.0.0/1610.100.0.0/16) back to the peering connection. Since security groups and default Network ACLs are already configured correctly, establishing these routes will resolve the connection timeout.

Step-by-Step Solution

1
Examine the network flow and routing tables of both subnets.
Confirm that traffic destined for the peered VPC needs explicit routing entries in both route tables.
VPC Peering does not automatically update subnet route tables; they must be manually updated to point to the peering connection ID.
2
Verify security groups and Network ACLs configuration.
The security group allows incoming port 54325432 from the application server's IP address. Default Network ACLs allow all inbound and outbound traffic.
Ensures that packet filters are already open and routing is the remaining bottleneck.
3
Add bidirectional routes to the VPC peering connection.
Add a route in Subnet App-1's route table pointing to 172.31.0.0/16172.31.0.0/16 via the peering ID, and add a route in Subnet DB-1's route table pointing to 10.100.0.0/1610.100.0.0/16 via the peering ID.
This establishes a bidirectional path allowing the application server to reach the database and the database to send return packets back to the application server.

Key Concept

VPC Peering Bidirectional Routing
Question 559Question →

A SysOps Administrator is troubleshooting a connectivity issue where an application on Amazon EC2 instances in Subnet A (CIDR 172.16.1.0/24172.16.1.0/24) cannot connect to a PostgreSQL database on Amazon EC2 instances in Subnet B (CIDR 172.16.2.0/24172.16.2.0/24). Both subnets are associated with different Network Access Control Lists (NACLs). The application security group allows outbound traffic to the database security group on TCP port 5432. The database security group allows inbound traffic from the application security group on TCP port 5432. Which two configuration changes must be made to the subnet NACLs to successfully permit this database traffic? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: In the Network ACL associated with Subnet A, add an outbound rule allowing TCP port 5432 to Subnet B's CIDR, and an inbound rule allowing TCP ports 1024−655351024-65535 from Subnet B's CIDR.; In the Network ACL associated with Subnet B, add an inbound rule allowing TCP port 5432 from Subnet A's CIDR, and an outbound rule allowing TCP ports 1024−655351024-65535 to Subnet A's CIDR.

Answer

The correct configurations are to add rules to the Network ACL of Subnet A allowing outbound traffic on TCP port 5432 and inbound traffic on the ephemeral port range 1024−655351024-65535, and to the Network ACL of Subnet B allowing inbound traffic on TCP port 5432 and outbound traffic on the ephemeral port range 1024−655351024-65535.
The correct options properly configure the stateless Network ACLs on both sides. In the subnet containing the application, we must allow outbound traffic on TCP port 5432 to the database CIDR and inbound traffic on the ephemeral port range 1024−655351024-65535 from the database CIDR. In the subnet containing the database, we must allow inbound traffic on TCP port 5432 from the application CIDR and outbound traffic on the ephemeral port range 1024−655351024-65535 to the application CIDR.

Step-by-Step Solution

1
Analyze the connection flow direction.
The application in Subnet A initiates a connection to the PostgreSQL database in Subnet B on TCP port 5432.
This establishes that port 5432 is outbound from Subnet A and inbound to Subnet B, while the response traffic will be outbound from Subnet B and inbound to Subnet A on ephemeral ports.
2
Evaluate the state requirements for the Network ACLs.
Network ACLs are stateless. Therefore, both the request path (port 5432) and the response path (ephemeral ports 1024−655351024-65535) must be explicitly allowed in both subnets' Network ACLs.
Unlike security groups, Network ACLs do not automatically allow return traffic.
3
Formulate the required rules for Subnet A.
Subnet A's Network ACL needs an outbound rule to allow TCP 5432 to Subnet B's CIDR, and an inbound rule to allow TCP 1024−655351024-65535 from Subnet B's CIDR.
This permits the outgoing database request and the incoming response.
4
Formulate the required rules for Subnet B.
Subnet B's Network ACL needs an inbound rule to allow TCP 5432 from Subnet A's CIDR, and an outbound rule to allow TCP 1024−655351024-65535 to Subnet A's CIDR.
This permits the incoming database request and the outgoing response.

Key Concept

Network ACLs are stateless, meaning return traffic must be explicitly allowed. In addition to the destination port, rules must allow the return traffic on ephemeral ports (1024−655351024-65535).
Estimated Time:2m 0s
Question 560Question →

A SysOps Administrator in AWS Account `123456789012` is configuring access to a customer managed KMS key. The administrator wants to grant access to an IAM user named `DataOperator`. The administrator attaches the following IAM policy to the user:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012"
}
]
}

When the `DataOperator` user attempts to encrypt a payload using the AWS CLI, they receive an `AccessDeniedException` error. The administrator checks the KMS key policy and finds it only allows access to a specific administration role.

Which of the following describes the cause of this issue and the correct resolution?

Show answer & explanation

Answer: The customer managed KMS key policy does not delegate access control to IAM policies. To resolve this, the administrator must modify the KMS key policy to grant the AWS account root principal permissions to perform KMS actions, or explicitly add the IAM user to the key policy.

Answer

The customer managed KMS key policy does not delegate access control to IAM policies. To resolve this, the administrator must modify the KMS key policy to grant the AWS account root principal permissions to perform KMS actions, or explicitly add the IAM user to the key policy.
The correct answer is correct because AWS KMS key policies are the primary authorization mechanism for KMS keys. To allow IAM policies to grant access to a key, the key policy must contain a statement that delegates authority to the account's root principal (`arn:aws:iam::account-id:root`). Without this delegation, or direct allowance of the user in the key policy, any permissions granted solely in the user's IAM policy will be ignored.

Step-by-Step Solution

1
Analyze the IAM policy and KMS key policy permissions.
The user has an IAM policy allowing KMS actions, but the KMS key policy only allows access to a specific administration role.
Identify the overlap and conflict between key policy restrictions and IAM policy grants.
2
Evaluate key policy precedence in AWS KMS.
In AWS KMS, key policies are the primary way to control access. IAM policies are only evaluated if the key policy explicitly delegates permission control to the account's root principal.
Determine why the IAM policy alone did not grant the user access to the KMS key.
3
Apply the resolution to delegate access to IAM.
Update the KMS key policy to include the root principal statement (`arn:aws:iam::123456789012:root`) with `kms:*` permissions, allowing the user's IAM policy to take effect.
Enable IAM delegation so the user's attached policy can successfully grant the encrypt and decrypt permissions.

Key Concept

AWS KMS Key Policy Precedence and IAM Policy Delegation
PreviousPage 28 / 49Next
All practice questions — AWS Certified SysOps Administrator - Associate | Examkin