Examkin

All practice questions

976 questions

All types976Multiple choice502Multiple select450Ordering24
Question 461Question →

An administrator is configuring access to an AWS Key Management Service (AWS KMS) customer managed key. The following KMS key policy is applied:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow direct admin access",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/AdminRole"
},
"Action": "kms:*",
"Resource": "*"
}
]
}

An operator in the same AWS account (111122223333) has an IAM policy attached to their user profile that grants full access to KMS (kms:*). However, the operator receives an Access Denied error when attempting to encrypt data using this key.

Which configuration change will allow the operator to use the KMS key?

Show answer & explanation

Answer: Add a statement to the KMS key policy that grants the account root principal (arn:aws:iam::111122223333:root) permission to perform the KMS actions.

Answer

Add a statement to the KMS key policy that grants the account root principal (arn:aws:iam::111122223333:root) permission to perform the KMS actions.
In AWS KMS, the key policy is the authoritative policy document for the key. To allow IAM policies in the same account to grant access to the KMS key, the key policy must contain a statement that grants the account root principal ('arn:aws:iam::111122223333:root') permissions to the key. Once this statement is in place, IAM policies can be used to control access.

Step-by-Step Solution

1
Analyze the KMS key policy to determine if IAM delegation is configured.
The key policy only grants access to the specific AdminRole, not the account root principal.
Without the account root principal statement in the KMS key policy, IAM policies attached to users or roles in the account cannot grant permission to use the key.
2
Identify the configuration change required to delegate access control to IAM.
The root principal (arn:aws:iam::111122223333:root) must be added to the KMS key policy's principal block with appropriate permissions.
This configuration allows the AWS KMS service to trust IAM policies in account 111122223333 to grant access to the key.

Key Concept

KMS Key Policy and IAM Policy Integration
Question 462Question →

A SysOps Administrator needs to collect container-level performance metrics for an Amazon ECS cluster running on Amazon EC2 instances. The administrator wants to use CloudWatch Container Insights to monitor the task and service utilization. Currently, only basic EC2 metrics are visible. Which action should the administrator take to enable Container Insights metrics for this cluster?

Show answer & explanation

Answer: Modify the cluster settings to enable Container Insights for the Amazon ECS cluster.

Answer

Modify the cluster settings to enable Container Insights for the Amazon ECS cluster.
To collect Container Insights metrics for Amazon ECS clusters (on both EC2 and Fargate), a SysOps Administrator must enable the Container Insights setting on the ECS cluster. Once enabled, ECS natively sends performance metrics to CloudWatch under the ECS/ContainerInsights namespace without requiring additional agent installation or detailed EC2 monitoring.

Step-by-Step Solution

1
Identify the target container service and environment where performance metrics are needed.
The environment is an Amazon ECS cluster running on Amazon EC2 container instances.
Container Insights must be enabled at the ECS cluster level to retrieve task and service metrics.
2
Evaluate the native integration options for Amazon ECS.
Container Insights integrates natively with Amazon ECS without requiring manual agent daemon setups on the hosts.
Enabling Container Insights on the cluster setting allows the Amazon ECS agent to handle metric collection automatically.
3
Configure the cluster-level setting using the AWS Management Console or AWS CLI.
The ECS cluster settings are modified to set Container Insights to enabled.
This updates the cluster to stream task and service metrics directly to the ECS/ContainerInsights namespace in CloudWatch.

Key Concept

Enabling Container Insights on Amazon ECS clusters
Question 463Question →

An administrator shares a Service Catalog portfolio from an AWS Organizations management account to a member account. The sharing operation is successful, and the portfolio appears in the member account as an imported portfolio. However, developers in the member account who use the AWS Management Console cannot see the portfolio or its associated products. What must the member account's administrator do to make the portfolio and its products visible to the developers?

Show answer & explanation

Answer: Associate the developers' IAM roles or groups with the imported portfolio in the member account.

Answer

Associate the developers' IAM roles or groups with the imported portfolio in the member account.
When a portfolio is shared from a management or delegated administrator account to a member account, it appears in the member account as an imported portfolio. Although the portfolio is present, it is not visible to any end-users in that account until the local administrator associates local IAM users, groups, or roles with the portfolio. Once associated, those users can see and launch the products in the portfolio.

Step-by-Step Solution

1
Identify the state of the shared portfolio in the member account.
The portfolio exists in the member account as an 'imported portfolio' but is not visible to end-users.
When a portfolio is shared, it is imported into the target account, but no local IAM users or roles are automatically associated with it.
2
Determine the mechanism for granting end-user access to Service Catalog portfolios.
Access is granted by associating IAM principals (users, groups, or roles) directly with the portfolio.
AWS Service Catalog requires explicit mapping between local IAM identities and portfolios to govern which products users can view and launch.
3
Associate the developers' IAM roles or groups with the portfolio.
The developers can now view the portfolio and its products in their Service Catalog console.
Once the association is complete, the metadata and products of the portfolio become visible to the assigned principals.

Key Concept

AWS Service Catalog Portfolio Sharing and Access Control
Estimated Time:1m 30s
Question 464Question →

A SysOps Administrator is configuring permissions for an IAM user in the same AWS account to encrypt and decrypt data using a customer managed key in AWS Key Management Service (AWS KMS). Currently, the IAM user has an IAM policy attached that allows all KMS actions on the key, but they are still receiving an Access Denied error when attempting to use the key.

Which of the following actions must be taken to successfully enable access for the user? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Modify the customer managed key's policy to grant permission to the AWS account's root principal, enabling IAM policies to manage key access.; Assign an IAM policy directly to the IAM user containing explicit permissions for the encrypt and decrypt actions targeting the key's ARN.

Answer

Modify the customer managed key's policy to grant permission to the AWS account's root principal, and assign an IAM policy directly to the IAM user containing explicit permissions for the encrypt and decrypt actions targeting the key's ARN.
For an IAM user in the same account to use a customer managed KMS key, two conditions must be met: the KMS key policy must delegate access control to the account (typically by granting the account root principal administrative or usage permissions), and the user must be granted the necessary permissions (such as encrypt and decrypt) in an IAM policy. These two policies work together to allow access.

Step-by-Step Solution

1
Examine the KMS key policy.
Confirm whether the key policy delegates control to the AWS account (root principal) to allow IAM policies to manage access.
By default, KMS keys require the key policy to explicitly delegate permission to the account before IAM policies can be used to grant access.
2
Ensure the IAM policy is properly configured and attached to the user.
The user has an IAM policy attached containing allow statements for encrypt and decrypt against the key's ARN.
Once delegation is enabled on the key policy, the IAM policy is evaluated to determine if the specific user has been granted access.

Key Concept

AWS KMS Key Policy Precedence and IAM Policy Integration
Question 465Question →

A SysOps Administrator is managing a production web application deployed via an AWS CloudFormation stack. The stack contains an Auto Scaling group, an Amazon RDS DB instance, and a Security Group. A recent drift detection operation indicates that the stack is in the DRIFTED state. The Security Group was manually modified to allow traffic on port 8080 from an unauthorized IP range, and the RDS DB instance type was manually upgraded to support higher traffic. The administrator wants to safely remediate the drift so that the resources and the CloudFormation stack are synchronized.

Which combination of actions will achieve this goal? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Manually revert the Security Group rules via the Amazon VPC console or AWS CLI to match the configurations defined in the CloudFormation template.; Update the CloudFormation template to reflect the upgraded RDS DB instance type, and then perform a stack update using the updated template.

Answer

Remediate the drift by manually reverting the Security Group rules to match the template, and updating the template to match the upgraded RDS DB instance type before performing a stack update.
Remediating drift in AWS CloudFormation requires bringing the resource configurations and the template back into alignment. This can be achieved by either manually reverting the resource's configuration in the console or CLI to match the template, or by updating the template to match the resource's current configuration and executing a stack update.

Step-by-Step Solution

1
Analyze the drift detection output to identify which properties of the Security Group and RDS DB instance have drifted from the template.
Identify that the Security Group has unauthorized port rules, and the RDS DB instance has an upgraded instance type.
Understanding the exact changes helps determine if they should be reverted or integrated into the template.
2
Revert the unauthorized Security Group configuration changes manually via the VPC Console or CLI.
The Security Group matches the template configuration, reverting the drift.
Manual out-of-band changes that violate security requirements must be reverted to restore compliance.
3
Update the CloudFormation template to match the desired upgraded RDS DB instance type and perform a stack update.
The template definition matches the actual physical resource property, and the stack status for the RDS resource becomes IN_SYNC.
Integrating desired manual changes into the template ensures they are preserved in future deployments.

Key Concept

CloudFormation Drift Remediation Options
Question 466Question →

A SysOps Administrator is setting up Amazon S3 Cross-Region Replication (CRR) to meet disaster recovery compliance requirements for an application's backup files. The administrator configures the replication rule on the source bucket, specifying a destination bucket in another Region. However, after uploading new backup files to the source bucket, the administrator notices that replication is not occurring. Which configuration step was omitted, preventing the replication from functioning?

Show answer & explanation

Answer: Versioning was not enabled on both the source and destination S3 buckets.

Answer

Versioning must be enabled on both the source and destination S3 buckets.
For Amazon S3 Cross-Region Replication (CRR) to function, versioning must be enabled on both the source and destination buckets. This allows S3 to maintain unique version IDs for objects and replicate specific versions across buckets in different Regions.

Step-by-Step Solution

1
Identify the service and feature in use.
The scenario uses Amazon S3 Cross-Region Replication (CRR) for replicating backup files.
Understanding the core service helps isolate the prerequisites required for that specific feature.
2
Recall the prerequisites for S3 Cross-Region Replication (CRR).
S3 CRR requires bucket versioning to be enabled on both the source and destination buckets.
Since replication relies on version IDs to track and sync updates, versioning is a hard requirement for CRR.
3
Evaluate the options against the CRR requirements.
Enabling versioning on both source and destination buckets is the only requirement listed that is mandatory for CRR.
This isolates the correct answer by filtering out database replication, network routing, and object lock compliance features.

Key Concept

Amazon S3 Cross-Region Replication Requirements
Estimated Time:1m 30s
Question 467Question →

A SysOps administrator is configuring automatic remediation in AWS Config for a managed rule that checks whether Amazon RDS DB instances have deletion protection enabled. The administrator wants to use the AWS Systems Manager (SSM) Automation document `AWS-EnableRdsDbInstanceDeletionProtection` as the remediation action. During configuration, the administrator receives an 'Access Denied' error when trying to associate the IAM execution role with the remediation action in AWS Config.

Which of the following is the most likely cause of this error?

Show answer & explanation

Answer: The administrator's IAM user or role lacks the `iam:PassRole` permission for the SSM Automation execution role.

Answer

The administrator's IAM user or role lacks the `iam:PassRole` permission for the SSM Automation execution role.
When configuring automated remediation in AWS Config using Systems Manager Automation, AWS Config must pass the execution role (specified by the assume role ARN) to the Systems Manager service. To do this, the IAM user or role performing the configuration must have the `iam:PassRole` permission for the execution role. Without this permission, the administrator receives an Access Denied error when trying to associate the role with the remediation configuration.

Step-by-Step Solution

1
Analyze the error message and the configuration context.
The SysOps administrator is configuring AWS Config automatic remediation with an SSM Automation document and receives an 'Access Denied' error.
To identify which action or service is failing authorization.
2
Evaluate the IAM workflow for passing roles to AWS services.
The administrator is attempting to associate an execution role that Systems Manager will assume. Since the administrator is passing this role to the service, the administrator's own IAM entity must have the `iam:PassRole` permission.
To verify if the administrator has the required authorization to delegate the execution role to Systems Manager.
3
Examine the trust relationship requirements for the execution role.
The execution role needs to trust `ssm.amazonaws.com` because Systems Manager is the service executing the remediation. The error is an Access Denied error on the administrator's association attempt, which points to the missing `iam:PassRole` permission on the administrator's identity.
To confirm the root cause of the error during association.

Key Concept

Configuring automatic remediation in AWS Config with Systems Manager Automation requires the administrator configuring the action to have the `iam:PassRole` permission for the execution role, which must trust `ssm.amazonaws.com`.
Question 468Question →

A SysOps administrator is configuring an AWS Config rule to automatically remediate non-compliant Amazon S3 buckets. The remediation action is set to run an AWS Systems Manager (SSM) Automation document. The administrator creates a service role named ConfigRemediationRole with a trust policy allowing ssm.amazonaws.com to assume it and attaches the necessary permissions to remediate S3 buckets. However, when the administrator attempts to assign this role to the remediation configuration in AWS Config, the console returns an error indicating that they are not authorized to perform the action.

Which action is required to resolve this authorization failure?

Show answer & explanation

Answer: Add the iam:PassRole permission for the ConfigRemediationRole to the IAM policy of the administrator who is configuring the remediation.

Answer

Add the iam:PassRole permission for the ConfigRemediationRole to the IAM policy of the administrator who is configuring the remediation.
When configuring AWS Config remediation (which uses Systems Manager Automation under the hood), the SysOps administrator must specify an IAM service role that the automation service will assume to execute the tasks. To assign this role, the administrator's IAM identity must have the iam:PassRole permission. This prevents users from escalating their privileges by passing highly privileged roles to AWS services.

Step-by-Step Solution

1
Identify the service role being passed to the remediation action (ConfigRemediationRole).
Confirm that the service role is designed to be assumed by ssm.amazonaws.com.
Ensure the service role itself is correctly configured before troubleshooting the administrator's rights.
2
Examine the administrator's IAM policy permissions.
Observe that the administrator lacks the iam:PassRole permission for ConfigRemediationRole.
AWS services require iam:PassRole to verify that the user configuring the service has permission to delegate the role.
3
Add the iam:PassRole action targeting the ConfigRemediationRole ARN to the administrator's IAM policy.
The administrator is now authorized to assign the service role to the AWS Config remediation action.
This grants the explicit authorization needed by the IAM console and API to pass the role to Systems Manager.

Key Concept

IAM PassRole Permission for Service Configurations
Question 469Question →

A SysOps administrator is configuring automated remediation in AWS Config for the managed rule `iam-user-mfa-enabled`. When an IAM user without Multi-Factor Authentication (MFA) is detected, the administrator wants to automatically deactivate the user's console access using the `AWS-DisableIAMUserAccess` Systems Manager (SSM) Automation document.

Which two configurations are required to successfully set up this event-driven remediation? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the remediation action in AWS Config to use the `AWS-DisableIAMUserAccess` document, and map the `AutomationAssumeRole` parameter to an IAM role that permits Systems Manager to execute the remediation.; Attach an IAM policy to the administrator's IAM identity that grants the `iam:PassRole` permission for the IAM role used by the Systems Manager Automation execution.

Answer

To configure the event-driven remediation, the administrator must configure the remediation action in AWS Config to use the `AWS-DisableIAMUserAccess` document with the `AutomationAssumeRole` parameter set to a service role, and grant the administrator's IAM identity the `iam:PassRole` permission for that execution role.
The correct configurations involve using AWS Config's remediation action to target the `AWS-DisableIAMUserAccess` Systems Manager Automation document, mapping the execution role parameter to an IAM role with the correct permissions. Additionally, the administrator's IAM identity must have `iam:PassRole` permissions to pass the execution role to Systems Manager.

Step-by-Step Solution

1
Identify the remediation execution role requirement.
Determine that the `AWS-DisableIAMUserAccess` SSM Automation document requires an IAM role with permissions to disable IAM console access, which is passed to the document via the `AutomationAssumeRole` parameter.
Systems Manager Automation needs permissions to interact with IAM and modify user credentials.
2
Identify the user permission requirements for setting up remediation.
Determine that the SysOps administrator's IAM identity must have `iam:PassRole` permissions for the Systems Manager execution role.
AWS IAM requires `iam:PassRole` to ensure users cannot pass roles with higher privileges to AWS services than they themselves possess.

Key Concept

Configuring automated remediation in AWS Config using Systems Manager Automation documents and IAM execution permissions.
Question 470Question →

A company hosts its critical production database on a single-node Amazon RDS for MySQL DB instance. A SysOps Administrator must configure a backup and recovery solution to satisfy the following requirements:
1. The database must automatically fail over to a standby instance in a different Availability Zone in the event of an infrastructure failure.
2. The administrator must be able to restore the database to any point in time within the last 14 days.
3. Daily database snapshots must be automatically copied to an Amazon S3 bucket in a different AWS Region for long-term compliance, utilizing S3 Cross-Region Replication (CRR) to keep the replication process continuous and automated.

Which combination of steps should the SysOps Administrator perform to meet these requirements?

Show answer & explanation

Answer: Convert the RDS DB instance to a Multi-AZ deployment. Set the RDS automated backup retention period to 14 days. Enable versioning on both the source and destination S3 buckets, and configure S3 Cross-Region Replication (CRR) for the daily DB snapshots exported to S3.

Answer

Convert the RDS DB instance to a Multi-AZ deployment. Set the RDS automated backup retention period to 14 days. Enable versioning on both the source and destination S3 buckets, and configure S3 Cross-Region Replication (CRR) for the daily DB snapshots exported to S3.
The correct configuration satisfies all three requirements: converting the RDS instance to Multi-AZ provides synchronous replication and automatic failover to a standby instance in a different Availability Zone; setting the automated backup retention period to 14 days enables point-in-time recovery (PITR) up to 14 days; and enabling versioning on both the source and destination S3 buckets is a mandatory prerequisite for configuring S3 Cross-Region Replication (CRR) to copy exported snapshots to another Region.

Step-by-Step Solution

1
Convert the RDS DB instance to a Multi-AZ deployment.
Enables synchronous replication to a standby instance in a different Availability Zone, offering automatic failover.
To satisfy the high availability and automatic failover requirement during infrastructure failures.
2
Set the RDS automated backup retention period to 14 days.
Allows the database to be restored to any point in time within the 14-day window.
To meet the point-in-time recovery (PITR) requirement.
3
Enable versioning on both the source and destination S3 buckets, and configure S3 Cross-Region Replication (CRR).
Allows daily database snapshots exported to S3 to be automatically replicated to a different AWS Region.
Versioning is a mandatory prerequisite for S3 CRR, which ensures compliance copies are maintained in a separate Region.

Key Concept

RDS automated backups retention and high availability combined with S3 Cross-Region Replication prerequisites.
Question 471Question →

An AWS CloudFormation stack update fails during execution, causing CloudFormation to initiate a rollback. However, the rollback process also fails, and the stack status changes to UPDATE_ROLLBACK_FAILED. The stack was configured to use a dedicated IAM service role named CloudFormationExecutionRole for all provisioning actions. Which actions should a SysOps Administrator perform to successfully return this stack to a stable, manageable state? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Continue the stack rollback from the AWS CloudFormation console or AWS CLI, specifying the failed resources to be skipped.; Identify the missing permissions in the CloudFormationExecutionRole, attach an updated IAM policy containing those permissions, and continue the rollback.

Answer

To resolve the rollback failure, the administrator should either continue the stack rollback while skipping the failed resources or update the execution role with the missing permissions and continue the rollback.
Continuing the rollback and skipping the failed resources allows CloudFormation to proceed with rolling back the rest of the stack, resolving the failed state. Alternatively, updating the execution role policy with the required permissions allows the rollback to successfully execute on the failing resource when continued.

Step-by-Step Solution

1
Analyze the stack events to identify the specific resource that caused the rollback failure and the associated error message.
The failure reason, such as missing permissions or modified resource states, is identified.
This determines whether permissions need to be adjusted or if resources must be skipped.
2
If the issue is missing permissions, update the CloudFormation execution role's IAM policy. Otherwise, prepare to skip the failed resources.
The execution environment is corrected or a skipping strategy is prepared.
Ensures that the next rollback attempt does not fail on the same resource.
3
Execute the Continue Update Rollback command via the console or CLI, optionally specifying the resources to skip.
The rollback resumes and completes, transitioning the stack to the UPDATE_ROLLBACK_COMPLETE state.
This returns the stack to a stable state where it can be updated or deleted normally.

Key Concept

AWS CloudFormation Update Rollback Failures and Remediation
Question 472Question →

A SysOps Administrator is setting up an AWS Systems Manager Automation workflow to execute a maintenance script on a fleet of Amazon EC2 instances. The SSM Agent is running on all target instances, and each instance has an IAM instance profile attached with the AmazonSSMManagedInstanceCore policy. The administrator creates a service role named SSMAutomationExecutionRole for Systems Manager to execute the workflow.

When the administrator attempts to start the Automation workflow specifying this service role, the execution fails to start with an access denied error. Additionally, the administrator notices that several EC2 instances tagged with 'role: webserver' are not receiving the maintenance script, while others tagged with 'Role: WebServer' are successfully targeted.

Which combination of actions will resolve these issues? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Add a policy to the administrator's IAM user or group that allows the iam:PassRole action on the SSMAutomationExecutionRole resource.; Update the Automation document target parameters to ensure the tag key and value match the exact case of the tags on all target EC2 instances.

Answer

Add a policy to the administrator's IAM user or group that allows the iam:PassRole action on the SSMAutomationExecutionRole resource, and update the Automation document target parameters to ensure the tag key and value match the exact case of the tags on all target EC2 instances.
To resolve the access denied error when starting the Automation workflow, the administrator's IAM identity must have permission to pass the service role (SSMAutomationExecutionRole) to Systems Manager, which is achieved by granting iam:PassRole. Additionally, because Systems Manager targeting tag keys and values are strictly case-sensitive, the tag keys and values in the Automation document targets must match the exact case of the tags on the EC2 instances.

Step-by-Step Solution

1
Analyze the access denied error during Automation startup.
Identify that the administrator lacks permission to delegate the service role to Systems Manager.
Systems Manager requires the user initiating the execution to possess iam:PassRole permissions for the service role being passed.
2
Analyze the targeting failure where some instances are skipped.
Observe the mismatch in case between the tags 'role: webserver' and 'Role: WebServer'.
AWS Systems Manager targeting filters are case-sensitive, meaning different case variations of the same words are evaluated as completely distinct tags.
3
Apply the IAM policy change and tag alignment actions.
The Automation workflow successfully starts using the SSMAutomationExecutionRole, and all target EC2 instances are matched correctly.
Resolving the case sensitivity mismatch and granting iam:PassRole access eliminates both root causes.

Key Concept

AWS Systems Manager Automation permissions and case-sensitive resource targeting
Question 473Question →

A SysOps administrator has configured Amazon VPC Flow Logs for a production VPC to publish flow logs to an Amazon CloudWatch Logs log group. Although the VPC is actively routing network traffic, no log streams are being created in the destination log group after several hours. The flow logs resource status in the VPC dashboard shows that the configuration is active.

Which of the following is the most likely cause of this issue?

Show answer & explanation

Answer: The IAM role associated with the VPC Flow Logs configuration lacks a trust policy that allows the vpc-flow-logs.amazonaws.com service principal to assume the role.

Answer

The IAM role associated with the VPC Flow Logs configuration lacks a trust policy that allows the vpc-flow-logs.amazonaws.com service principal to assume the role.
The correct answer is that the IAM role associated with the VPC Flow Logs configuration lacks a trust policy that allows the vpc-flow-logs.amazonaws.com service principal to assume the role. For VPC Flow Logs to deliver logs to CloudWatch Logs, the VPC service must assume the specified IAM role. Without a trust relationship that explicitly permits vpc-flow-logs.amazonaws.com to execute the sts:AssumeRole action, the service cannot retrieve temporary security credentials to write log data, causing the delivery to fail silently.

Step-by-Step Solution

1
Differentiate between configuration-time errors and runtime errors in AWS resource delivery.
Since the VPC Flow Logs resource status shows as successfully active but no log streams are created in CloudWatch Logs, the error occurs at runtime during log delivery, not during the initial configuration.
This rules out configuration-time IAM checks like iam:PassRole, which would have prevented the creation of the resource entirely.
2
Examine the runtime permissions required by the VPC Flow Logs service to publish to CloudWatch Logs.
The VPC Flow Logs service needs to assume the specified IAM role to gain authorization to write to the CloudWatch log group.
If the trust policy of the IAM role does not list 'vpc-flow-logs.amazonaws.com' as a trusted entity with the 'sts:AssumeRole' action, the assume-role request fails, and the service cannot deliver logs.
3
Verify that other monitoring and log group configurations are not blocking delivery.
Confirm that CloudWatch Logs retention policies and EC2 instance monitoring levels (Standard vs. Detailed) do not restrict log ingestion.
Retention settings only control the lifespan of stored logs, and instance-level CloudWatch monitoring does not affect VPC network flow capture.

Key Concept

VPC Flow Logs runtime service permissions and IAM role trust relationships
Question 474Question →

An operations team is implementing event-driven compliance controls. They deploy an AWS Config rule to monitor that all Amazon SQS queues have Server-Side Encryption enabled. To automatically encrypt non-compliant queues, they designate the Systems Manager Automation document AWS-EnableSqsQueueEncryption. The team creates a dedicated IAM role named QueueEncryptionExecutionRole with the required SQS permissions, trusting Systems Manager to assume it. However, when the team tries to save this auto-remediation configuration, the operation fails with an authorization error. Which action will resolve this configuration failure?

Show answer & explanation

Answer: Assigning iam:PassRole permissions to the IAM identity performing the configuration, targeting the QueueEncryptionExecutionRole resource.

Answer

Assigning iam:PassRole permissions to the IAM identity performing the configuration, targeting the QueueEncryptionExecutionRole resource.
When configuring automated remediation in AWS Config that uses an SSM Automation document, the AWS Config service associates a service execution role with Systems Manager. The IAM user or role performing this configuration must have the iam:PassRole permission for that execution role. This ensures the user is authorized to delegate the role's permissions to Systems Manager.

Step-by-Step Solution

1
Analyze the context of the auto-remediation authorization failure occurring at configuration time.
Determine that the failure happens while linking the AWS Config remediation rule with the SSM automation execution role.
This identifies that the configuring user lacks permission to associate the execution role with the Systems Manager service.
2
Identify the required IAM mechanism for passing roles to AWS services.
Identify that the iam:PassRole action must be permitted in the policy of the identity performing the setup.
AWS security best practices prevent users from configuring services to execute actions using roles they cannot pass.
3
Formulate the correct IAM policy change.
Add a policy granting iam:PassRole for the QueueEncryptionExecutionRole ARN to the administrator's IAM user or role.
This grants the necessary permission to complete the auto-remediation link in AWS Config.

Key Concept

AWS Config auto-remediation with Systems Manager Automation requires the configuring principal to possess iam:PassRole permission to pass the automation execution role to SSM.
Question 475Question →

A SysOps Administrator needs to execute a shell script on a group of Amazon EC2 instances using AWS Systems Manager Run Command and archive the command output in an Amazon S3 bucket. The instances are currently running, but they do not have the required IAM permissions to associate with Systems Manager.

What is the correct sequence of steps to configure, execute, and capture the output of the Run Command operation?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with attaching the IAM instance profile to the EC2 instances, followed by executing the Run Command request with the S3 bucket configuration. The Systems Manager service then processes the request and sends the payload to the SSM Agent on the instances. The SSM Agent executes the script locally on each instance, and finally, the SSM Agent uploads the output logs to the S3 bucket.
The correct sequence mirrors the lifecycle of an AWS Systems Manager Run Command execution. First, the instances must become managed nodes, which is achieved by attaching the necessary IAM instance profile. Second, the Administrator initiates the Run Command execution, specifying the Amazon S3 bucket for logs. Third, the service routes this command to the agent running on the target instances. Fourth, the agent runs the script locally. Finally, the agent uploads the command output directly to the specified S3 bucket.

Step-by-Step Solution

1
Attach the IAM instance profile containing the AmazonSSMManagedInstanceCore policy to the target EC2 instances.
The EC2 instances register with AWS Systems Manager and appear as managed nodes.
Systems Manager cannot communicate with or manage EC2 instances that lack the necessary IAM permissions.
2
Call the Run Command API specifying target tags, the execution document, and the output S3 bucket.
The Systems Manager service receives the execution request.
The administrator must specify the execution parameters, including where execution logs should be delivered.
3
The Systems Manager service delivers the command payload to the SSM Agent on the managed nodes.
The SSM Agent on each target instance receives the command instructions.
The service acts as the controller and pushes the execution instructions to the registered agents.
4
The SSM Agent executes the command script locally on the instances.
The administrative script runs within the instance OS.
The SSM Agent acts as the local executor of the command within the host environment.
5
The SSM Agent uploads the stdout and stderr outputs to the specified Amazon S3 bucket.
Logs are securely stored in the S3 bucket for auditing and analysis.
The local agent handles copying the execution outputs back to the configured AWS storage endpoint.

Key Concept

The correct sequence of operations for AWS Systems Manager Run Command requires instances to first be managed nodes via proper IAM permissions, after which command requests are processed by the service, executed by the local agent, and logs are uploaded by the agent directly.
Estimated Time:1m 30s
Question 476Question →

A SysOps Administrator is updating an AWS CloudFormation stack that contains an Amazon RDS DB instance. The stack update fails due to a configuration mismatch, prompting CloudFormation to initiate a rollback. During the rollback, the stack transitions to the UPDATE_ROLLBACK_FAILED state because an Amazon EC2 subnet group associated with the DB instance was manually deleted outside of CloudFormation. Which action must the SysOps Administrator take to return the stack to a stable, manageable state?

Show answer & explanation

Answer: Execute the ContinueUpdateRollback operation, specify the DB instance as a resource to skip, and then manually recreate the database configuration.

Answer

Execute the ContinueUpdateRollback operation, specify the DB instance as a resource to skip, and then manually recreate the database configuration.
Executing the ContinueUpdateRollback operation and choosing to skip the DB instance allows CloudFormation to bypass the resource that is failing to rollback (due to the missing subnet group) and return the stack to a stable state (UPDATE_ROLLBACK_COMPLETE). Once the stack is stable, the administrator can manually recreate the deleted subnet group and synchronize the database configuration.

Step-by-Step Solution

1
Identify the resource causing the rollback failure and the reason for the failure from the CloudFormation stack events.
The DB instance resource is identified as the blocker because its associated subnet group has been deleted outside of CloudFormation.
Understanding the root cause of the UPDATE_ROLLBACK_FAILED state is necessary to determine which resource must be skipped or manually remediated.
2
Initiate the ContinueUpdateRollback operation via the AWS Management Console or AWS CLI.
Specify the DB instance as a resource to skip during the rollback continuation.
Skipping the resource bypasses the rollback check for the missing subnet group, allowing the rest of the stack to revert to a stable state.
3
Manually recreate the deleted subnet group and associate it with the DB instance to match the template configuration.
The physical infrastructure matches the CloudFormation template, resolving the resource drift.
Skipped resources must be manually reconciled to ensure the stack template and actual infrastructure are in sync for future updates.

Key Concept

Remediating a stack stuck in the UPDATE_ROLLBACK_FAILED state by using the ContinueUpdateRollback operation and skipping the failed resource.
Question 477Question →

An application running on Amazon EC2 instances in a private subnet needs to retrieve database credentials stored as a SecureString parameter in AWS Systems Manager Parameter Store. The parameter is encrypted with an AWS KMS customer managed key (CMK). The SysOps administrator has attached an IAM policy to the EC2 instance profile's IAM role that allows both ssm:GetParameter and kms:Decrypt on the respective resource ARNs. However, when the application runs, it fails to retrieve the parameter and receives an AccessDeniedException from AWS KMS. Which action will resolve this issue?

Show answer & explanation

Answer: Update the KMS key policy of the customer managed key to allow the EC2 instance profile's IAM role to perform the kms:Decrypt action.

Answer

Update the KMS key policy of the customer managed key to allow the EC2 instance profile's IAM role to perform the kms:Decrypt action.
The correct action is to update the key policy of the KMS customer managed key (CMK). Unlike AWS managed keys (where permissions are managed automatically), customer managed keys require their key policy to explicitly authorize the caller or authorize the account to use IAM policies for permission delegation. Without this authorization in the key policy, the EC2 instance's IAM role will receive an AccessDeniedException despite having the correct IAM policy.

Step-by-Step Solution

1
Analyze the error response.
The application receives an AccessDeniedException from AWS KMS, indicating that network routing is functional, but KMS has denied authorization to decrypt.
This rules out network-related issues, such as VPC endpoint configuration or route table mismatches.
2
Evaluate KMS policy precedence.
KMS key policies control access to customer managed keys. An IAM policy alone cannot grant access to a customer managed key unless the key policy itself explicitly delegates permission to the root account or lists the IAM role as an authorized user.
KMS key policies take precedence over IAM policies for customer managed keys.
3
Update the key policy.
Modify the KMS key policy to include the EC2 instance profile's IAM role ARN in the list of principals allowed to perform the kms:Decrypt action.
This establishes the necessary trust in the key policy to allow the IAM role to use the key for decryption.

Key Concept

KMS Key Policy Precedence
Estimated Time:1m 30s
Question 478Question →

A SysOps Administrator is updating an AWS CloudFormation stack that manages an Auto Scaling group and an Amazon RDS DB instance. The update fails during the database configuration step, triggering a rollback. The rollback also fails, leaving the stack in the UPDATE_ROLLBACK_FAILED state. The stack events show that the IAM service role assigned to the CloudFormation stack lacks the rds:DeleteDBInstance permission required to remove the failed RDS resource. Which combination of actions must the SysOps Administrator perform to resolve this issue and return the stack to a stable state? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Modify the IAM service role associated with the CloudFormation stack to include the missing RDS permissions.; Run the aws cloudformation continue-update-rollback command to resume the rollback process.

Answer

To resolve the rollback failure and return the stack to a stable state, the SysOps Administrator must update the associated IAM service role to grant the missing rds:DeleteDBInstance permission and then execute the continue-update-rollback CLI command to resume the rollback process.
To resolve the UPDATE_ROLLBACK_FAILED state, you must address the root cause (the missing IAM permissions) and then explicitly instruct CloudFormation to resume rolling back the remaining resources. Thus, modifying the associated IAM service role to grant the missing permissions and running continue-update-rollback are the correct steps.

Step-by-Step Solution

1
Analyze stack events to identify the resource and missing permission causing the rollback failure.
Identified that the rollback failed on the RDS DB instance due to the IAM service role lacking rds:DeleteDBInstance permissions.
Before continuing rollback, you must identify why it failed to address the root cause.
2
Update the IAM service role associated with the CloudFormation stack to attach a policy containing the missing rds:DeleteDBInstance permission.
The IAM service role now has sufficient permissions to delete the database resource.
CloudFormation performs actions using this role, so it must have the permissions necessary to delete resources created during the failed update.
3
Execute the aws cloudformation continue-update-rollback command from the CLI.
CloudFormation retries the rollback, successfully deletes the failed database instance using the updated role permissions, and returns the stack to the ROLLBACK_COMPLETE state.
This command is the only valid way to resume and complete a failed update rollback process in CloudFormation.

Key Concept

Resolving CloudFormation update rollback failures by fixing IAM execution role permissions and using the continue-update-rollback action.
Question 479Question →

A SysOps administrator is configuring an AWS Systems Manager (SSM) Automation runbook to patch Amazon EC2 instances. The runbook must launch a temporary EC2 instance, associate a pre-configured IAM role named `PatchingInstanceRole` with the instance, run patching scripts, and then terminate the instance. The administrator runs the SSM Automation using an automation service role named `AutomationServiceRole`. The trust relationship of `AutomationServiceRole` is correctly configured to trust the `ssm.amazonaws.com` service principal. However, when the runbook attempts to launch the temporary EC2 instance with the `PatchingInstanceRole`, the execution fails with an 'Access Denied' error. Which of the following modifications will resolve this issue?

Show answer & explanation

Answer: Attach an IAM policy to the `AutomationServiceRole` that grants `iam:PassRole` permissions for the `PatchingInstanceRole` resource.

Answer

Attach an IAM policy to the `AutomationServiceRole` that grants `iam:PassRole` permissions for the `PatchingInstanceRole` resource.
To associate an IAM role with an EC2 instance, the entity initiating the action (in this case, the `AutomationServiceRole` running the SSM Automation) must be authorized to pass that role to the EC2 service. This authorization is granted by adding the `iam:PassRole` action to the identity-based policy of the caller (`AutomationServiceRole`), referencing the target role (`PatchingInstanceRole`) as the resource. Without this permission, the caller cannot assign the role to the newly created instance, resulting in an 'Access Denied' error.

Step-by-Step Solution

1
Identify the service performing the operation.
The AWS Systems Manager service role (`AutomationServiceRole`) is attempting to launch an EC2 instance with a specific IAM role (`PatchingInstanceRole`).
To fix permission issues, we must determine which identity is initiating the API call and needs to be granted permissions.
2
Determine the required permission for passing roles to AWS services.
The `iam:PassRole` permission is required for any user or service role that associates an IAM role with an AWS resource.
AWS prevents privilege escalation by requiring that a calling principal explicitly has permission to pass a specific role to a service.
3
Attach the policy containing the `iam:PassRole` action to the caller.
An identity-based policy is attached to the `AutomationServiceRole` allowing the `iam:PassRole` action, specifying the `PatchingInstanceRole` Amazon Resource Name (ARN) as the resource.
This grants the SSM service role the necessary authorization to successfully pass the patching role to the EC2 service during instance creation.

Key Concept

To configure an AWS service to act on your behalf or to pass an IAM role to a resource (such as an EC2 instance profile), the calling identity must be granted `iam:PassRole` permissions for that specific target role.
Question 480Question →

An EC2 instance is hosting a web server in a VPC subnet. The SysOps Administrator needs to configure the subnet's Network Access Control List (NACL) to allow incoming HTTP requests on port 80 from the internet (0.0.0.0/0). Which two rules must the administrator add to the custom NACL to allow this traffic?

Select all that apply

Show answer & explanation

Answer: An inbound rule that allows TCP port 80 from source 0.0.0.0/0; An outbound rule that allows TCP ports 1024-65535 to destination 0.0.0.0/0

Answer

The correct configurations are: an inbound rule allowing TCP port 80 from source 0.0.0.0/0 and an outbound rule allowing TCP ports 1024-65535 to destination 0.0.0.0/0.
The correct configuration requires allowing inbound TCP port 80 from source 0.0.0.0/0 to accept incoming HTTP requests, and allowing outbound TCP ports 1024-65535 to destination 0.0.0.0/0 to permit the return traffic. Because NACLs are stateless, separate rules are needed for both inbound request and outbound response paths, and response traffic is directed to the client's ephemeral ports.

Step-by-Step Solution

1
Identify the protocol and port of the incoming requests.
HTTP traffic uses TCP port 80.
The client initiates an inbound request on the web server's listening port.
2
Configure the inbound rule on the NACL.
Allow TCP port 80 from source 0.0.0.0/0.
This allows the external client requests to reach the web server.
3
Determine the return path port range and protocol.
Return traffic targets the client's source ephemeral ports, typically in the range of 1024-65535.
Because NACLs are stateless, they do not automatically track connection state and require explicit outbound rules for the response.
4
Configure the outbound rule on the NACL.
Allow TCP ports 1024-65535 to destination 0.0.0.0/0.
This allows the web server's responses to reach back to the clients.

Key Concept

Statelessness of Network Access Control Lists (NACLs) and ephemeral port requirements
Estimated Time:45s
PreviousPage 24 / 49Next
All practice questions — AWS Certified SysOps Administrator - Associate | Examkin