Examkin

All practice questions

976 questions

All types976Multiple choice502Multiple select450Ordering24
Question 681Question →

An application tier is deployed on Amazon EC2 instances in a private subnet with CIDR block 10.0.1.0/2410.0.1.0/24. The instances must download software updates from an external repository over HTTPS (port 443443). The private subnet's route table contains a route pointing 0.0.0.0/00.0.0.0/0 to a NAT Gateway located in a public subnet. The Security Group attached to the instances allows outbound TCP traffic on port 443443 to 0.0.0.0/00.0.0.0/0, with no inbound rules. The subnet's Network Access Control List (NACL) has an inbound rule allowing TCP traffic on port 443443 from 0.0.0.0/00.0.0.0/0, and an outbound rule allowing TCP traffic on port 443443 to 0.0.0.0/00.0.0.0/0. However, the instances are unable to establish a connection to the external repository. Which configuration change will resolve this connectivity issue?

Show answer & explanation

Answer: Add an inbound rule to the NACL allowing TCP traffic on ports 1024−655351024-65535 from 0.0.0.0/00.0.0.0/0.

Answer

Add an inbound rule to the NACL allowing TCP traffic on ports 1024−655351024-65535 from 0.0.0.0/00.0.0.0/0.
The correct option is to add an inbound rule to the NACL allowing TCP traffic on ports 1024−655351024-65535 from 0.0.0.0/00.0.0.0/0. Amazon VPC Network Access Control Lists (NACLs) are stateless. This means that response traffic to allowed outbound requests is not automatically permitted; an explicit inbound rule must allow the traffic back in. When an EC2 instance initiates a connection to an external repository on port 443443, the response traffic is sent from the repository's port 443443 to an ephemeral port (1024−655351024-65535) on the EC2 instance. Therefore, the inbound NACL must allow traffic on these ephemeral ports.

Step-by-Step Solution

1
Analyze the request path from the private EC2 instances to the external repository.
The Security Group allows outbound port 443443 to 0.0.0.0/00.0.0.0/0. The outbound NACL allows port 443443 to 0.0.0.0/00.0.0.0/0. The route table correctly routes internet-bound traffic to the NAT Gateway. The outbound request successfully leaves the VPC.
To ensure the outbound connection is initiated and reaches the destination.
2
Analyze the return traffic path from the external repository back to the private EC2 instances.
The repository responds from port 443443 to the ephemeral ports (1024−655351024-65535) on the EC2 instances. The Security Group is stateful, so it automatically allows the return traffic. The NACL is stateless, so it requires an explicit inbound rule for this return traffic.
Since NACLs do not track connection state, return traffic must be evaluated against inbound rules.
3
Identify the missing rule in the NACL configurations.
The current inbound NACL rule only allows port 443443, but the incoming return packets have destination ports in the ephemeral range (1024−655351024-65535). An inbound rule allowing ports 1024−655351024-65535 is required.
To allow stateless inbound return traffic to reach the instances.

Key Concept

NACLs are stateless and require explicit rules for both inbound request traffic and outbound return traffic (or vice versa), including the ephemeral port range.
Question 682Question →

A SysOps Administrator is configuring an AWS Organization-level trail to collect management events from all member accounts. The CloudTrail logs are consolidated into an Amazon S3 bucket located in a dedicated Security Operations account. To meet compliance requirements, the trail must be encrypted using a customer managed AWS KMS key located in the same Security Operations account. After configuring the organizational trail and specifying the KMS key, the administrator notices that no logs are being delivered to the S3 bucket, and CloudTrail reports access denied errors. The S3 bucket policy is already correctly configured to allow the cloudtrail.amazonaws.com service principal to write logs. Which configuration change must the administrator make to resolve this delivery failure?

Show answer & explanation

Answer: Update the KMS key policy in the Security Operations account to grant the cloudtrail.amazonaws.com service principal permission to perform the kms:GenerateDataKey* and kms:DescribeKey actions, with a condition restricting the source ARN to the organizational trail.

Answer

Update the KMS key policy in the Security Operations account to grant the cloudtrail.amazonaws.com service principal permission to perform the kms:GenerateDataKey* and kms:DescribeKey actions, with a condition restricting the source ARN to the organizational trail.
The CloudTrail service principal requires permissions on the customer managed KMS key to generate data keys and encrypt the log files before they are written to the S3 bucket. Because the KMS key is customer managed, these permissions must be explicitly granted in the key policy. The correct approach is to allow the cloudtrail.amazonaws.com principal to perform kms:GenerateDataKey* and kms:DescribeKey operations on the key. Additionally, adding a condition that restricts the aws:SourceArn to the specific organization trail prevents unauthorized accounts or services from using the key.

Step-by-Step Solution

1
Analyze the log delivery flow and identify where the failure occurs.
The S3 bucket policy is verified to allow CloudTrail log writes, but CloudTrail reports Access Denied because it lacks authorization to use the KMS key for server-side encryption.
When a customer managed KMS key is selected for CloudTrail encryption, CloudTrail must have permissions on the KMS key to generate data keys for encryption.
2
Determine the proper location for granting KMS encryption permissions.
Identify that S3 bucket policies cannot control KMS keys, and cross-account IAM policies are blocked unless delegated by the key policy itself.
KMS key policies are the primary authorizers for KMS keys. Service principal permissions must be defined within the key policy.
3
Formulate the correct KMS key policy statement.
Configure permissions for the cloudtrail.amazonaws.com service principal to execute kms:GenerateDataKey* and kms:DescribeKey, restricted by the organizational trail's ARN to enforce the principle of least privilege.
This grants CloudTrail the minimum permissions required to perform envelope encryption on log files delivered to the target S3 bucket.

Key Concept

AWS KMS key policies for cross-account CloudTrail log encryption
Question 683Question →

A SysOps Administrator in a multi-account organization wants to organize monthly AWS spending by project using the tag key `ProjectName`. The administrator has successfully applied this tag to all Amazon EC2 instances within the member accounts. However, when generating a monthly cost report in AWS Cost Explorer from the management account, the administrator cannot find `ProjectName` in the tag filtering options. Which action must the administrator take to ensure the `ProjectName` tag is available in Cost Explorer?

Show answer & explanation

Answer: Activate the `ProjectName` tag as a cost allocation tag in the AWS Billing and Cost Management console of the management account.

Answer

Activate the `ProjectName` tag as a cost allocation tag in the AWS Billing and Cost Management console of the management account.
The correct action is to activate the `ProjectName` tag as a cost allocation tag in the AWS Billing and Cost Management console of the management account. Applying a tag to resources only creates the metadata on the resource; to use it for tracking costs and filtering in AWS Cost Explorer, it must be explicitly activated. In an AWS Organizations setup, cost allocation tags must be activated from the management account.

Step-by-Step Solution

1
Sign in to the AWS Management Console using the credentials of the management (payer) account of the organization.
Access to consolidated billing and organization-wide cost management features is established.
Only the management account has the permissions required to manage cost allocation tags for member accounts in an organization.
2
Navigate to the AWS Billing and Cost Management console, select 'Cost allocation tags' from the navigation pane, locate the user-defined tag key `ProjectName`, select it, and click 'Activate'.
The `ProjectName` tag is registered for cost allocation tracking.
Applying a tag to resources does not automatically designate it for billing. It must be explicitly activated to begin appearing in AWS Cost Explorer and cost reports.

Key Concept

Activation of User-Defined Cost Allocation Tags
Estimated Time:50s
Question 684Question →

A SysOps Administrator is configuring a launch constraint for an AWS Service Catalog product. The administrator wants to use a custom IAM role named ServiceCatalogLaunchRole to provision the resources. However, when the administrator tries to assign the role as a launch constraint in the AWS Service Catalog console, the console displays an error stating that the chosen role must have a trust relationship with Service Catalog. Furthermore, the administrator needs to ensure they have the necessary permissions to apply this constraint. Which two actions should the administrator take to resolve the console error and successfully apply the launch constraint? (Select two.)

Select all that apply

Show answer & explanation

Answer: Edit the trust policy of ServiceCatalogLaunchRole to allow the servicecatalog.amazonaws.com service principal to assume the role.; Attach an IAM policy to the administrator's IAM identity that grants the iam:PassRole permission for ServiceCatalogLaunchRole.

Answer

Edit the trust policy of the role to allow the servicecatalog.amazonaws.com service principal to assume the role, and attach an IAM policy to the administrator's IAM identity that grants the iam:PassRole permission for that role.
The correct options are to edit the trust policy of the custom role to trust the Service Catalog service principal, and to grant the administrator the iam:PassRole permission. This allows the administrator to associate the role as a launch constraint and enables Service Catalog to assume the role when provisioning the product.

Step-by-Step Solution

1
Configure the trust relationship for the launch constraint role.
The role's trust policy allows servicecatalog.amazonaws.com to assume the role.
AWS Service Catalog must be trusted to assume the role to provision resources on behalf of the user.
2
Grant the administrator permission to pass the role to Service Catalog.
The administrator has iam:PassRole permission for the launch constraint role.
An administrator cannot configure a launch constraint without permission to pass that role to the service.

Key Concept

AWS Service Catalog Launch Constraints and Role Provisioning Requirements
Question 685Question →

A SysOps Administrator is troubleshooting a cross-account Same-Region Replication (SRR) setup between a source S3 bucket in Account A and a destination S3 bucket in Account B. Objects in the source bucket are encrypted with a customer managed AWS KMS key in Account A. The destination bucket is also encrypted with a customer managed AWS KMS key in Account B. The administrator notices that replication fails for new objects, and their replication status is marked as FAILED. Which combination of actions will resolve this replication failure? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the IAM replication role in Account A with permissions to decrypt using the source KMS key, and ensure that the source KMS key policy allows the replication role to perform the decryption.; Modify the key policy of the destination KMS key in Account B to grant the replication role in Account A permissions to perform the GenerateDataKey and Encrypt operations.

Answer

Configure the replication role in Account A with decrypt permissions on the source KMS key (with the key policy allowing it), and update the destination KMS key policy in Account B to allow the replication role to generate data keys and encrypt objects.
The option to configure the IAM replication role with decrypt permissions on the source KMS key (along with the key policy allowing it) is correct because the replication process must first read and decrypt the source objects. The option to grant GenerateDataKey and Encrypt permissions in the destination KMS key policy to the replication role is correct because cross-account access to KMS keys must be explicitly allowed by the KMS key policy in the target account.

Step-by-Step Solution

1
Analyze source-side KMS decryption requirements.
The replication role in Account A needs permission to decrypt the source objects using the KMS key in Account A.
Since the source objects are encrypted with a customer managed KMS key, S3 replication cannot read the objects to replicate them without kms:Decrypt permissions.
2
Analyze destination-side KMS encryption requirements.
The replication role in Account A needs permission to encrypt objects using the KMS key in Account B.
Because the destination bucket uses a customer managed KMS key in a different account, the cross-account replication role must be allowed to perform kms:Encrypt and kms:GenerateDataKey operations using the destination key policy.

Key Concept

To replicate KMS-encrypted objects across accounts, the S3 replication IAM role must have decrypt permissions on the source key, and the destination key policy must explicitly trust the replication role for encrypt operations.
Estimated Time:1m 30s
Question 686Question →

A logistics startup runs its tracking application on an Amazon RDS for PostgreSQL DB instance in a single Availability Zone (AZ). Due to strict business continuity requirements, a SysOps Administrator must convert this database to a highly available deployment to ensure automatic failover in the event of an AZ outage. The migration must minimize downtime during implementation, and the application must automatically connect to the new database instance after failover without manual updates to the connection configuration. Which two steps should the SysOps Administrator take to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Modify the DB instance to enable the Multi-AZ deployment option, which provisions a synchronous standby replica in a different Availability Zone.; Keep the existing database endpoint in the application configuration, as Amazon RDS automatically updates the DNS record to point to the standby replica during failover.

Answer

To establish database high availability with automatic failover, the SysOps Administrator must modify the DB instance to enable the Multi-AZ deployment option, which creates a synchronous standby replica in a different Availability Zone. The application should keep using the existing database endpoint since Amazon RDS automatically updates the DNS CNAME record to point to the promoted standby instance during a failover event.
To configure high availability with automatic failover, the database must be converted to a Multi-AZ deployment. This creates a standby replica in another Availability Zone with synchronous replication. When a failover occurs, Amazon RDS automatically updates the CNAME of the database endpoint to point to the standby instance. Thus, the application configuration does not need any database endpoint updates.

Step-by-Step Solution

1
Enable the Multi-AZ option on the existing single-AZ RDS DB instance.
Amazon RDS automatically provisions a standby replica in a different Availability Zone and replicates the data synchronously.
This establishes the required high availability configuration to survive Availability Zone failures.
2
Retain the current connection endpoint in the application config.
The application targets the same database endpoint without manual connection string updates.
Amazon RDS manages DNS failover internally by updating the CNAME record of the DB instance endpoint to resolve to the standby instance during an outage.

Key Concept

Amazon RDS Multi-AZ deployments provide high availability and automatic failover by using synchronous replication to a standby replica in a different Availability Zone and updating the DNS CNAME record automatically during failover.
Question 687Question →

A central operations team manages AWS Service Catalog portfolios in a hub account (111122223333111122223333) and shares them with spoke accounts in an AWS Organization. A SysOps administrator in a spoke account (444455556666444455556666) has associated developer IAM groups with an imported portfolio containing a product that deploys a multi-tier application. When developers in the spoke account attempt to launch the product, the deployment fails during the Amazon EC2 instance provisioning stage with an 'Access Denied' error. The developers do not have direct IAM permissions to manage EC2 instances, and the administrator wants to use a local IAM role named `CustomLaunchRole` in the spoke account to perform the deployment. Which two actions must the administrator take in the spoke account to successfully configure and troubleshoot this deployment?

Select all that apply

Show answer & explanation

Answer: Apply a launch constraint to the imported portfolio in the spoke account (444455556666444455556666) that maps the product to the CustomLaunchRole role.; Configure the trust policy of CustomLaunchRole to allow the servicecatalog.amazonaws.com service principal to assume the role, and ensure the developers' IAM identity has iam:PassRole permissions for CustomLaunchRole.

Answer

To successfully deploy the Service Catalog product, the administrator must configure a launch constraint on the imported portfolio in the spoke account associating it with the CustomLaunchRole, and ensure the CustomLaunchRole trust policy trusts servicecatalog.amazonaws.com while granting the developers iam:PassRole permissions on the CustomLaunchRole.
To deploy a product where the end users (developers) do not have the required permissions to launch the underlying resources (like EC2), a launch constraint must be configured using a service role (such as CustomLaunchRole). This role needs a trust policy allowing AWS Service Catalog (servicecatalog.amazonaws.com) to assume it. Additionally, the developers' IAM identity must have the iam:PassRole permission to pass the CustomLaunchRole to AWS Service Catalog.

Step-by-Step Solution

1
Configure the local execution role trust policy
The CustomLaunchRole trust policy is modified to allow the servicecatalog.amazonaws.com service principal to assume the role.
This allows AWS Service Catalog to execute the deployment actions on behalf of the user.
2
Grant the developers permission to pass the role
An IAM policy with the iam:PassRole action targeting the CustomLaunchRole ARN is attached to the developers' IAM group/role.
This authorizes the developers to pass the deployment role to AWS Service Catalog during the launch process.
3
Create a launch constraint in the spoke account
A launch constraint is added to the imported portfolio in the spoke account (444455556666444455556666) that maps the product to the CustomLaunchRole.
This ensures that when developers launch the product, Service Catalog uses the permissions of the CustomLaunchRole instead of the developers' permissions.

Key Concept

AWS Service Catalog launch constraints allow products to be deployed using a specified IAM service role rather than the end user's IAM permissions, which requires proper trust policies and iam:PassRole configuration in the target account.
Question 688Question →

An Amazon EC2 instance is configured with two Elastic Network Interfaces (ENIs). The primary interface (eth0eth0) is in Subnet A (10.0.1.0/2410.0.1.0/24) and the secondary interface (eth1eth1) is in Subnet B (10.0.2.0/2410.0.2.0/24). Both subnets are public subnets with default routes (0.0.0.0/00.0.0.0/0) targeting the VPC's Internet Gateway. A SysOps administrator assigns an Elastic IP address to both interfaces. External clients can successfully establish SSH connections to the Elastic IP of eth0eth0. However, SSH connection attempts to the Elastic IP of eth1eth1 time out. The administrator verifies that both security groups and network ACLs allow inbound TCP port 2222 and outbound traffic. Which of the following is the root cause of this connectivity failure?

Show answer & explanation

Answer: The operating system of the EC2 instance routes all outbound traffic through the default gateway of eth0eth0, causing asymmetric routing for traffic entering eth1eth1.

Answer

The operating system of the EC2 instance routes all outbound traffic through the default gateway of the primary interface (eth0eth0), causing asymmetric routing for traffic entering the secondary interface (eth1eth1).
The correct answer is that the operating system of the EC2 instance routes all outbound traffic through the default gateway of the primary interface (eth0eth0). When an inbound packet arrives on the secondary interface (eth1eth1), the response packet is generated. Because the operating system only has a single default gateway configured for the primary interface (eth0eth0), the response is routed out through eth0eth0 instead of eth1eth1. This asymmetric routing causes the connection to time out because the client receives response packets from a different IP address than the one it initiated the connection with, or the VPC routing fabric drops the asymmetric traffic. To resolve this, policy-based routing (source-based routing) must be configured in the OS.

Step-by-Step Solution

1
Analyze the entry path of the inbound SSH request to the secondary interface (eth1eth1).
The packet successfully reaches the secondary interface (eth1eth1) via the Internet Gateway because the subnet's route table, security groups, and network ACLs permit inbound traffic.
Establishing the entry path helps isolate if the problem is inbound blockages or outbound routing.
2
Examine the operating system routing table of the EC2 instance.
The instance operating system is configured with a single default route (0.0.0.0/00.0.0.0/0) pointing to the gateway of Subnet A via eth0eth0.
Operating systems by default only configure one active default gateway route, even when multiple network interfaces are attached.
3
Trace the return packet path generated by the EC2 instance.
The operating system sends the response packet out via eth0eth0 because of the default route, even though the request entered via eth1eth1. This constitutes asymmetric routing.
Asymmetric routing causes client-side connection timeouts because the client receives response packets from a different IP address than the one it targeted, or intermediate firewalls drop the packet.

Key Concept

Asymmetric Routing on Multi-homed EC2 Instances
Estimated Time:2m 0s
Question 689Question →

A company is designing a disaster recovery (DR) strategy for a non-critical reporting application. The business requires a Recovery Point Objective (RPO) of 24 hours and a Recovery Time Objective (RTO) of 12 hours. The primary objective is to minimize ongoing infrastructure costs.

Which combination of actions should a SysOps administrator take to meet these requirements at the lowest cost? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure AWS Backup to perform daily backups of the application resources and copy them to a secondary AWS Region.; Store the infrastructure configuration as AWS CloudFormation templates to deploy the resources in a secondary AWS Region only when a disaster occurs.

Answer

To meet the RPO and RTO requirements at the lowest cost, configure AWS Backup to perform daily backups and copy them to a secondary AWS Region, and store infrastructure configurations as AWS CloudFormation templates to deploy resources only when a disaster occurs.
The RPO of 24 hours allows for a daily backup schedule. Configuring AWS Backup to run daily snapshots and copy them to a secondary Region ensures the data is safely replicated within the RPO window. The RTO of 12 hours gives the administrator enough time to spin up resources from scratch. Storing infrastructure configuration as AWS CloudFormation templates allows resources to be deployed only when a disaster occurs, ensuring zero ongoing infrastructure running costs for the secondary Region's compute resources.

Step-by-Step Solution

1
Evaluate the Recovery Point Objective (RPO) requirement.
Daily backups copied to a secondary Region satisfy the 24-hour RPO.
An RPO of 24 hours means up to 24 hours of data loss is acceptable, which matches a daily backup frequency.
2
Evaluate the Recovery Time Objective (RTO) and cost optimization requirements.
Deploying the infrastructure using CloudFormation templates only during a disaster satisfies the 12-hour RTO and minimizes cost.
Since the RTO is relatively generous (12 hours), there is no need to keep hot or warm idle resources running in a secondary Region. Using templates to provision resources on-demand is the most cost-effective approach.

Key Concept

Disaster Recovery strategies and RTO/RPO cost trade-offs
Question 690Question →

A SysOps administrator is troubleshooting an Amazon EC2 Auto Scaling group (ASG) that is scaling out too slowly during sudden traffic spikes. The ASG is configured with a step scaling policy based on the average CPU utilization of the group. The associated CloudWatch alarm has a period of 60 seconds and an evaluation period of 1. However, during high-load events, the ASG takes approximately 5 minutes to trigger the scale-out action. What is the root cause of this delay?

Show answer & explanation

Answer: Detailed monitoring is disabled in the launch template, resulting in EC2 metric data being sent to CloudWatch at 5-minute intervals.

Answer

Detailed monitoring is disabled in the launch template, resulting in EC2 metric data being sent to CloudWatch at 5-minute intervals.
The correct answer is that detailed monitoring is disabled. By default, EC2 instances are configured with standard monitoring, which sends metrics to CloudWatch at 5-minute intervals. Even if a CloudWatch alarm is configured with a 1-minute period, it cannot evaluate new data points faster than they are sent. To achieve 1-minute scaling response times, detailed monitoring must be enabled on the EC2 instances via the launch template.

Step-by-Step Solution

1
Analyze the CloudWatch alarm settings and the reported delay.
The alarm has a period of 60 seconds (1 minute), but the scale-out action takes 5 minutes to trigger.
This indicates that the alarm is not receiving metric data at the 1-minute frequency it is configured to evaluate.
2
Verify the default monitoring configuration for EC2 instances.
Standard monitoring sends data to CloudWatch at 5-minute intervals.
If detailed monitoring (1-minute intervals) is not explicitly enabled, CloudWatch will only receive updates every 5 minutes.
3
Correlate launch template settings with metric frequency.
The launch template needs detailed monitoring enabled to publish 1-minute metrics.
Enabling detailed monitoring ensures the alarm has timely data points to evaluate and trigger the scale-out policy immediately when the threshold is exceeded.

Key Concept

Auto Scaling policies rely on the resolution of the underlying CloudWatch metrics. Without detailed monitoring enabled, EC2 metrics are sent at 5-minute intervals, delaying alarm evaluation and subsequent scaling actions.
Estimated Time:2m 0s
Question 691Question →

A SysOps administrator is configuring an AWS Service Catalog portfolio to allow developers to deploy a standardized three-tier application. The administrator wants to ensure that developers can launch the product even if they do not have direct IAM permissions to create the underlying Amazon EC2 and Amazon RDS resources. The resources must be provisioned using a specific IAM service role. Which configuration should the administrator apply to meet these requirements?

Show answer & explanation

Answer: Apply a launch constraint to the product that specifies the designated IAM service role.

Answer

Apply a launch constraint to the product that specifies the designated IAM service role.
Applying a launch constraint to the product allows AWS Service Catalog to assume a specific IAM service role (the launch role) to provision the resources on behalf of the user. This allows users to launch the product even if they do not have direct IAM permissions to deploy the underlying AWS resources.

Step-by-Step Solution

1
Identify the need to provision resources through AWS Service Catalog without granting the launching users direct permissions to create those resources.
Determine that a Service Catalog constraint must be configured to delegate permissions.
By default, AWS Service Catalog uses the end user's IAM permissions to provision resources, which fails if the user lacks those permissions.
2
Select the appropriate constraint type designed for overriding user permissions during launch.
Choose a launch constraint and associate it with an IAM service role.
A launch constraint specifies the IAM role that AWS Service Catalog assumes to provision the product's resources, enabling secure delegation.

Key Concept

AWS Service Catalog Launch Constraints
Estimated Time:1m 0s
Question 692Question →

A SysOps Administrator is configuring a monitoring and remediation system for a custom application. The application runs on Amazon EC2 instances and publishes a custom metric named TransactionLatency every 10 seconds. The administrator needs to configure an Amazon CloudWatch alarm that triggers within 1 minute of a latency spike, and automatically runs an AWS Systems Manager Automation runbook to remediate the issue. Which two configuration steps should the administrator perform to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Publish the custom metric using the PutMetricData API with the StorageResolution parameter set to 1.; Create an Amazon EventBridge rule that detects when the CloudWatch alarm changes to the ALARM state, and targets the Systems Manager Automation runbook.

Answer

Publishing the custom metric with a storage resolution of 1, and creating an Amazon EventBridge rule that detects when the alarm changes to the ALARM state to target the Systems Manager Automation runbook.
To trigger an alarm within 1 minute, the underlying metric must support sub-minute evaluation periods. Setting the StorageResolution parameter to 1 in the PutMetricData call creates a high-resolution metric, allowing alarm evaluation periods of 10 or 30 seconds. Additionally, because CloudWatch alarms cannot directly call Systems Manager Automation runbooks, the correct approach to automated remediation is to configure an Amazon EventBridge rule that detects the alarm's state change and targets the runbook.

Step-by-Step Solution

1
Ensure the metric is ingested with high-resolution capabilities.
Publish the metric using the PutMetricData API with the StorageResolution parameter set to 1.
By default, custom metrics are stored at standard 1-minute resolution. High-resolution storage is required to support sub-minute alarm evaluation periods needed to alert within 1 minute of a spike.
2
Configure the CloudWatch alarm evaluation period.
Create a CloudWatch alarm with a period of 10 or 30 seconds.
A sub-minute period is necessary to evaluate the high-resolution data points quickly enough to transition to the ALARM state within 1 minute.
3
Create the automated remediation trigger.
Configure an Amazon EventBridge rule triggered by the CloudWatch alarm state change, setting the target to the Systems Manager Automation runbook.
CloudWatch alarms do not natively support direct invocation of Systems Manager Automation runbooks as actions, so EventBridge must be used as the event router.

Key Concept

High-resolution CloudWatch custom metrics and automated remediation using Amazon EventBridge
Question 693Question →

A SysOps administrator is configuring scaling for an Amazon EC2 Auto Scaling group (ASG) that processes messages from an Amazon SQS queue. The workload fluctuates significantly throughout the day. The administrator wants to use a target tracking scaling policy to scale the ASG dynamically, keeping the backlog at approximately 100 messages per EC2 instance. Which two actions must the administrator take to implement this configuration? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create a custom metric in Amazon CloudWatch using metric math to calculate the backlog per instance by dividing the SQS ApproximateNumberOfMessagesVisible metric by the Auto Scaling group's group size.; Configure a target tracking scaling policy on the Auto Scaling group that uses the custom backlog per instance metric and set the target value to 100.

Answer

The correct configuration requires creating a custom CloudWatch metric using metric math to calculate the backlog per instance (ApproximateNumberOfMessagesVisible divided by the group size) and then configuring a target tracking scaling policy on the Auto Scaling group using this custom metric with a target value of 100.
To scale an Auto Scaling group based on SQS queue backlog, the scaling metric must change in proportion to the number of instances. The correct actions are to create a custom metric using CloudWatch metric math that divides the SQS queue depth by the current group size, and then apply a target tracking policy that uses this custom metric. This ensures that when the group scales out, the backlog per instance decreases, allowing the scaling policy to stabilize.

Step-by-Step Solution

1
Calculate the queue backlog metric per instance.
A custom CloudWatch metric is created using metric math. It pulls the SQS ApproximateNumberOfMessagesVisible metric and divides it by the ASG's GroupInServiceInstances or group size metric.
Target tracking scaling policies require a metric that increases or decreases proportionally with the size of the Auto Scaling group. The raw SQS queue length does not change when the group scales out, but the backlog per instance does.
2
Configure the target tracking policy.
A target tracking policy is applied to the Auto Scaling group referencing the custom metric.
Setting the target value to 100 instructs the scaling policy to scale out when the backlog per instance exceeds 100, and scale in when it drops below 100, maintaining optimal utilization.

Key Concept

Scaling an Auto Scaling Group (ASG) based on SQS queue size requires a custom backlog-per-instance metric calculated via CloudWatch metric math, as target tracking cannot use raw queue depth directly without causing runaway scaling.
Question 694Question →

A SysOps Administrator is configuring a new AWS CloudTrail trail to deliver log files to an Amazon S3 bucket. The trail is currently failing to deliver logs. Which two configurations must be present in the S3 bucket policy to allow AWS CloudTrail to successfully deliver the log files? (Select two.)

Select all that apply

Show answer & explanation

Answer: A statement that grants s3:PutObject permission to the CloudTrail service principal (cloudtrail.amazonaws.com).; A statement that grants s3:GetBucketAcl permission to the CloudTrail service principal (cloudtrail.amazonaws.com).

Answer

To allow AWS CloudTrail to deliver logs, the S3 bucket policy must grant s3:PutObject and s3:GetBucketAcl permissions to the CloudTrail service principal (cloudtrail.amazonaws.com).
For CloudTrail to successfully deliver logs to an S3 bucket, the S3 bucket policy must allow the CloudTrail service principal (cloudtrail.amazonaws.com) to perform both s3:GetBucketAcl (to verify the bucket's existence and ownership) and s3:PutObject (to write the log files into the bucket).

Step-by-Step Solution

1
Identify the service principal for AWS CloudTrail.
The service principal is cloudtrail.amazonaws.com.
Permissions in the bucket policy must target the specific service principal representing CloudTrail.
2
Configure permissions for verifying bucket ownership.
Grant s3:GetBucketAcl to the service principal.
CloudTrail must verify the bucket exists and check its ACLs before writing files.
3
Configure permissions for writing logs.
Grant s3:PutObject to the service principal for the bucket prefix.
CloudTrail needs write permissions to upload the compressed log files to the target prefix in the bucket.

Key Concept

AWS CloudTrail requires permissions to write logs (s3:PutObject) and check bucket ownership (s3:GetBucketAcl) via an S3 bucket policy.
Question 695Question →

A SysOps Administrator is configuring Amazon CloudWatch metric filters to monitor application logs stored in a CloudWatch log group. Which of the following statements correctly describe the characteristics and behavior of CloudWatch Logs metric filters? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: They can extract numeric values from JSON-formatted log messages to publish custom metrics.; They do not modify or alter the original log events stored within the log group.

Answer

CloudWatch Logs metric filters extract numeric values from JSON-formatted log messages to publish custom metrics and do not modify or alter the original log events stored within the log group.
The correct answers are the statements that metric filters can extract numeric values from JSON-formatted log messages to publish custom metrics, and that they do not modify or alter the original log events stored within the log group. These accurately reflect how metric filters operate on log data.

Step-by-Step Solution

1
Evaluate the effect of metric filters on existing log data.
Confirm that metric filters are non-destructive and only read log events to count occurrences or extract values without changing the stored logs.
This establishes that the original log events remain unchanged in the log group.
2
Analyze metric extraction capabilities of CloudWatch metric filters.
Verify that metric filters can parse structured logs (like JSON) and extract numeric values to publish to custom CloudWatch metrics.
This confirms that numeric extraction from JSON log messages is a key feature of metric filters.

Key Concept

CloudWatch Logs metric filters define patterns to search for in log events and convert them into CloudWatch metrics without modifying the underlying log data.
Question 696Question →

A SysOps Administrator is configuring automatic remediation for an AWS Config rule. The remediation is designed to run an AWS Systems Manager Automation document. The administrator attempts to save the remediation configuration but receives an error stating that the action cannot be performed because of missing permissions. Which permission is missing from the administrator's IAM policy?

Show answer & explanation

Answer: iam:PassRole permission for the remediation execution role

Answer

iam:PassRole permission for the remediation execution role
To successfully configure automatic remediation in AWS Config, the IAM identity (user or role) setting up the remediation must have the iam:PassRole permission for the remediation execution role. This permission ensures that the administrator has the authority to delegate that execution role to AWS Config, which then passes it to Systems Manager to execute the automation document.

Step-by-Step Solution

1
Analyze the remediation mechanism
The remediation uses AWS Config automatic remediation powered by AWS Systems Manager Automation.
AWS Config requires an execution role to perform remediation actions in Systems Manager on the resources.
2
Identify the role passing requirement
The identity configuring the remediation must have permission to pass the execution role to the service.
To prevent privilege escalation, AWS requires the iam:PassRole permission whenever a user passes an IAM role to a service.

Key Concept

AWS Config Automatic Remediation Permissions
Estimated Time:45s
Question 697Question →

A company's security policy requires all API activity logs to be encrypted at rest using a customer managed key (CMK). A SysOps Administrator enables encryption on an existing multi-region CloudTrail trail by specifying the KMS key ARN. Shortly after this change, the administrator notices that new log files are no longer being delivered to the destination Amazon S3 bucket. Which of the following actions will resolve this log delivery failure?

Show answer & explanation

Answer: Update the key policy of the customer managed KMS key to grant the AWS CloudTrail service principal permission to perform kms:GenerateDataKey* operations.

Answer

Update the key policy of the customer managed KMS key to grant the AWS CloudTrail service principal permission to perform kms:GenerateDataKey* operations.
Updating the key policy of the customer managed KMS key to grant the AWS CloudTrail service principal permission to perform kms:GenerateDataKey* operations is correct because CloudTrail requires this permission to encrypt logs before delivering them to the S3 bucket. Without this key policy statement, log delivery will fail silently or report errors.

Step-by-Step Solution

1
Analyze the log delivery path of AWS CloudTrail when encryption is enabled.
CloudTrail must encrypt the logs using the specified customer managed KMS key before writing them to the destination S3 bucket.
Log delivery will fail if CloudTrail does not have permissions to generate data keys using the specified KMS key.
2
Determine where service principal permissions are defined for customer managed KMS keys.
Service principal permissions must be defined in the KMS key policy itself.
By default, customer managed KMS keys do not allow external service principals like CloudTrail to use them unless explicitly granted in their key policy.
3
Formulate the required key policy modification.
Allow the cloudtrail.amazonaws.com service principal to execute kms:GenerateDataKey* and kms:DescribeKey actions.
This enables CloudTrail to generate the necessary data keys to encrypt logs upon delivery.

Key Concept

AWS CloudTrail SSE-KMS Key Policy Requirements
Estimated Time:1m 30s
Question 698Question →

A SysOps administrator notices that an Amazon EC2 Auto Scaling group is routing client traffic to new instances before the application's configuration script has finished installing required dependencies. To resolve this issue, the administrator configures an EC2_INSTANCE_LAUNCHING lifecycle hook. What is the correct sequence of events required to ensure the instances are properly configured before they start receiving traffic?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with the Auto Scaling group initiating the launch of a new EC2 instance, followed by the instance pausing in the Pending:Wait state. Next, the configuration script completes the setup and calls the CompleteLifecycleAction API, and finally, the instance transitions to the InService state to serve traffic.
The sequence starts with the launch initiation. The lifecycle hook then immediately pauses the launch by putting the instance into the Pending:Wait state. The configuration script runs and calls the CompleteLifecycleAction API, allowing the instance to transition to the InService state and accept traffic.

Step-by-Step Solution

1
Identify the scale-out initiation trigger.
The Auto Scaling group starts launching the instance.
Before any state transitions or lifecycle hooks can occur, the instance launch must be initiated by the Auto Scaling group.
2
Trace the effect of the lifecycle hook on the state transition.
The instance enters the Pending:Wait state.
The EC2_INSTANCE_LAUNCHING lifecycle hook pauses the default flow and prevents the instance from immediately transitioning to the InService state.
3
Determine how the script signals completion.
The configuration script runs and sends a CompleteLifecycleAction API call.
An explicit signal is required to notify the Auto Scaling group that the custom initialization tasks have finished.
4
Identify the final operational state of the instance.
The instance state transitions to InService.
Once the API call is processed successfully, the instance completes its launch flow and begins receiving traffic.

Key Concept

Auto Scaling lifecycle hooks allow you to pause instance state transitions (such as Pending:Wait during scale-out) to run custom configuration tasks, which must be completed via the CompleteLifecycleAction API before the instance is marked InService.
Question 699Question →

A SysOps Administrator is investigating potential data exfiltration in a VPC. Multiple Amazon EC2 instances in a private subnet route all outbound internet traffic through a NAT Gateway located in a public subnet. The administrator needs to analyze network traffic to identify the specific private IP addresses of the EC2 instances that are initiating connections to a known malicious external IP address. The administrator attempts to analyze the default VPC Flow Logs on the NAT Gateway’s public network interface, but the `srcaddr` field only displays the NAT Gateway's private IP address.

Which action should the administrator take to identify the initiating internal EC2 instances from the NAT Gateway's network interface?

Show answer & explanation

Answer: Create a new VPC Flow Log on the NAT Gateway's network interface using a custom format that includes the `pkt-srcaddr` field, and deliver the logs to an Amazon S3 bucket.

Answer

Create a new VPC Flow Log on the NAT Gateway's network interface using a custom format that includes the `pkt-srcaddr` field, and deliver the logs to an Amazon S3 bucket.
The correct option is to create a new VPC Flow Log on the NAT Gateway's network interface using a custom format that includes the `pkt-srcaddr` field, and deliver the logs to an Amazon S3 bucket. The `pkt-srcaddr` field captures the packet-level source IP address of the traffic, which remains the private IP of the initiating EC2 instance, even after passing through a NAT Gateway. This allows the administrator to trace the traffic back to the specific initiating instance directly from the NAT Gateway's interface logs.

Step-by-Step Solution

1
Identify the limitation of default VPC Flow Logs on translation interfaces.
Understand that the default `srcaddr` field on a NAT Gateway's public ENI shows the NAT Gateway's own IP address, obscuring the original source.
In order to find the initiating instances, we need to capture the pre-translation IP address rather than the interface-level address.
2
Determine the correct custom VPC Flow Log field that captures pre-translation IP addresses.
Select the `pkt-srcaddr` field, which records the packet-level source IP address even if it passes through a NAT Gateway.
The `pkt-srcaddr` field preserves the original client IP address before NAT translation occurs.
3
Choose a supported destination that accepts custom VPC Flow Log formats.
Specify Amazon S3 (or CloudWatch Logs) as the destination for the custom flow log.
Both Amazon S3 and CloudWatch Logs support custom VPC Flow Log formats.

Key Concept

Using custom VPC Flow Log formats with packet-level fields (`pkt-srcaddr`) to track original source IP addresses through translation devices like NAT Gateways.
Estimated Time:3m 0s
Question 700Question →

A SysOps Administrator is configuring an Amazon CloudWatch alarm to monitor the CPUUtilization metric of an Amazon EC2 instance. The administrator wants the alarm to trigger within 2 minutes of the CPU utilization exceeding 90%. The alarm is configured with a period of 60 seconds and an evaluation period of 2 consecutive periods. During testing, CPU utilization is sustained at 95% for 4 minutes, but the alarm fails to transition to the ALARM state.

Which action will resolve this issue and meet the monitoring requirement?

Show answer & explanation

Answer: Enable detailed monitoring on the EC2 instance.

Answer

Enable detailed monitoring on the EC2 instance.
Enabling detailed monitoring on the Amazon EC2 instance changes the metric reporting frequency from 5 minutes (standard monitoring) to 1 minute. Since the alarm is configured with a 60-second period and requires 2 consecutive periods to breach (totaling 2 minutes), detailed monitoring ensures that CloudWatch receives the necessary data points at 1-minute intervals to evaluate and trigger the alarm within the 2-minute window.

Step-by-Step Solution

1
Analyze the metric reporting frequency of the default EC2 configuration.
By default, Amazon EC2 sends metrics to CloudWatch using standard monitoring, which has a 5-minute reporting interval.
To understand why the alarm configured with a 60-second period and 2 evaluation periods (requiring 2 minutes of data) is not triggering, we must determine how often data is sent.
2
Identify the requirement for the 60-second period alarm.
A 60-second period alarm requires new metric data points every minute to evaluate consecutive breaching periods correctly.
If data is only sent every 5 minutes, CloudWatch cannot evaluate 2 consecutive 1-minute periods in a timely manner, delaying the alarm transition.
3
Select the correct action to increase metric reporting frequency.
Enabling detailed monitoring changes the reporting interval of EC2 metrics (including CPUUtilization) to 1 minute.
This provides the necessary 1-minute granularity for the alarm to evaluate and trigger within the 2-minute requirement.

Key Concept

CloudWatch Standard vs. Detailed Monitoring for EC2
PreviousPage 35 / 49Next
All practice questions — AWS Certified SysOps Administrator - Associate | Examkin