Examkin

All practice questions

976 questions

All types976Multiple choice502Multiple select450Ordering24
Question 741Question →

A SysOps administrator is configuring an active-passive failover strategy for a web application. The primary infrastructure is located in the `eu-west-1` region, consisting of an Application Load Balancer (ALB) and an Auto Scaling group of EC2 instances. The secondary failover target is a static maintenance page hosted in an Amazon S3 bucket configured for website hosting in `us-east-1`.

To monitor the health of the primary application, the administrator creates a custom CloudWatch metric in `eu-west-1` that monitors application error rates. They then create a CloudWatch alarm in `eu-west-1` based on this metric.

Finally, the administrator sets up the Route 53 configuration:
- A Route 53 health check that monitors the state of the CloudWatch alarm.
- A primary failover Alias record pointing to the ALB in `eu-west-1`, associated with the Route 53 health check.
- A secondary failover Alias record pointing to the S3 bucket.

During a simulated failure where the error rate spikes, the CloudWatch alarm transitions to the `ALARM` state in `eu-west-1`, but Route 53 continues to route traffic to the primary ALB in `eu-west-1` instead of failing over to the S3 bucket.

Which of the following is the root cause of this issue, and what is the correct resolution?

Show answer & explanation

Answer: Route 53 health checks can only monitor CloudWatch alarms that are created in the `us-east-1` (N. Virginia) region. The administrator must recreate the CloudWatch alarm in `us-east-1` to monitor the metric in `eu-west-1`, and then update the Route 53 health check to reference the new alarm.

Answer

Route 53 health checks can only monitor CloudWatch alarms that are created in the `us-east-1` (N. Virginia) region. The administrator must recreate the CloudWatch alarm in `us-east-1` to monitor the metric in `eu-west-1`, and then update the Route 53 health check to reference the new alarm.
Route 53 health checks that monitor CloudWatch alarms can only retrieve the status of alarms located in the `us-east-1` (N. Virginia) region. Although the custom metric is generated in `eu-west-1`, the CloudWatch alarm itself must be configured in `us-east-1` using cross-region metric support for Route 53 to successfully evaluate its state and trigger DNS failover.

Step-by-Step Solution

1
Analyze the Route 53 health check configuration that monitors the CloudWatch alarm.
Identify that the CloudWatch alarm is created in the `eu-west-1` region.
Route 53 health checks can only retrieve alarm status from the `us-east-1` region.
2
Recreate the CloudWatch alarm in the `us-east-1` region.
The new alarm in `us-east-1` is configured to monitor the custom metric originating in `eu-west-1`.
CloudWatch supports alarms that reference metrics in other regions, allowing the alarm to reside in `us-east-1` while monitoring `eu-west-1` resources.
3
Update the Route 53 health check configuration.
The health check now references the newly created CloudWatch alarm in `us-east-1`.
Route 53 is now able to successfully query the state of the alarm and trigger DNS failover to the secondary record when the alarm enters the `ALARM` state.

Key Concept

Route 53 health checks monitoring CloudWatch alarms must use alarms residing in the us-east-1 region, even if the monitored metric is in another region.
Question 742Question →

A SysOps Administrator manages a production web application deployed via an AWS CloudFormation template. The application runs on an Amazon EC2 Auto Scaling group (ASG) behind an Application Load Balancer, with a desired capacity of 44 instances. The administrator is preparing to update the template to roll out a new AMI using the AutoScalingRollingUpdate policy. The application must maintain its full capacity of 44 healthy instances throughout the update process to handle peak traffic. Which configuration for the AutoScalingRollingUpdate policy will satisfy this requirement?

Show answer & explanation

Answer: Set MinInstancesInService to 44 and MaxBatchSize to 22.

Answer

Setting MinInstancesInService to 44 and MaxBatchSize to 22 ensures that AWS CloudFormation launches new instances first to maintain the desired capacity of 44 instances during the rolling update.
The correct configuration requires setting MinInstancesInService to 44 and MaxBatchSize to 22. This tells AWS CloudFormation that it must keep at least 44 instances running and healthy at all times. Since the group's desired capacity is 44, CloudFormation will satisfy this by first provisioning a batch of 22 new instances (bringing the total to 66) before terminating 22 old instances, keeping capacity at or above 44 throughout the rollout.

Step-by-Step Solution

1
Analyze the capacity requirement.
The application must maintain its desired capacity of 44 healthy instances throughout the update.
To prevent any reduction in capacity during the deployment.
2
Determine the role of MinInstancesInService.
Setting MinInstancesInService to 44 guarantees that at least 44 instances remain active.
If MinInstancesInService is less than 44, CloudFormation may terminate instances first, reducing active capacity below the required threshold.
3
Determine the role of MaxBatchSize.
Setting MaxBatchSize to 22 allows CloudFormation to update instances in batches of 22. Since 44 instances must remain in service, CloudFormation will launch 22 new instances first before terminating any old ones.
To transition the group to the new AMI incrementally while staying within the minimum capacity constraint.

Key Concept

AWS CloudFormation AutoScalingRollingUpdate UpdatePolicy configuration for maintaining application capacity

Alternative Method

Instead of an in-place rolling update on the same Auto Scaling group, the administrator could perform a blue/green deployment by creating a second Auto Scaling group using the new launch template, validating the new instances, and then updating the Application Load Balancer listener rule to point to the new target group. However, this would require managing additional resources outside the single Auto Scaling group scope.
Estimated Time:1m 30s
Question 743Question →

A company hosts a production three-tier web application in the us-east-1 Region. The database tier uses an Amazon Aurora PostgreSQL DB cluster. A SysOps administrator must implement a cross-region disaster recovery (DR) strategy in the us-west-2 Region. The strategy must achieve a Recovery Time Objective (RTO) of 15 minutes and a Recovery Point Objective (RPO) of 5 minutes while minimizing ongoing running costs in the us-west-2 Region. Which disaster recovery strategy should the administrator implement to meet these requirements?

Show answer & explanation

Answer: Configure an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Deploy an Application Load Balancer and an Auto Scaling group with the capacity set to 0 in us-west-2. Configure an Amazon Route 53 active-passive failover routing policy with health checks pointing to the primary application. During a failover, promote the secondary cluster and scale up the Auto Scaling group.

Answer

Configure an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2, set the Auto Scaling group capacity in us-west-2 to 0, configure a Route 53 active-passive failover routing policy with health checks, and promote the secondary cluster and scale up the Auto Scaling group during a failover.
The correct strategy implements a Pilot Light disaster recovery pattern. Amazon Aurora Global Database provides sub-second cross-region replication, matching the RPO of 5 minutes. Keeping the recovery region Auto Scaling group size at 0 minimizes ongoing compute costs, and both scaling up the instances and promoting the secondary Aurora database cluster can be completed within the 15-minute RTO. Route 53 active-passive failover routing automatically detects primary region failures and directs traffic to the secondary region once it is promoted.

Step-by-Step Solution

1
Evaluate the RPO requirement.
The RPO is 5 minutes, which requires continuous database replication. Aurora Global Database uses fast, physical, asynchronous replication that typically has a lag of less than one second, comfortably meeting the 5-minute RPO target.
Choosing a replication mechanism with latency under the RPO threshold is necessary to prevent data loss beyond 5 minutes.
2
Evaluate the RTO and cost requirements.
The RTO is 15 minutes, and running costs in the secondary region must be minimized. Deploying an Auto Scaling group with a desired capacity of 0 ensures no EC2 instances are running (minimizing costs), but they can be scaled up rapidly via scripts or CloudFormation during a disaster. Promoting the secondary Aurora DB cluster is also a fast operation that takes under 5 minutes.
This establishes a Pilot Light recovery model, which balances low standby cost with quick recovery times.
3
Determine the routing mechanism.
Route 53 active-passive failover routing with health checks must be used to detect outages in the primary region and direct users to the recovery region environment once it is scaled up and promoted.
Active-passive failover is necessary because the secondary database cannot accept writes under normal conditions, making active-active routing invalid.

Key Concept

Pilot Light Disaster Recovery Strategy
Estimated Time:2m 0s
Question 744Question →

An organization's security policy requires that all logs from Amazon Kinesis Data Firehose in Account A (456789012345456789012345) be delivered to an Amazon S3 bucket in Account B (567890123456567890123456). A SysOps administrator creates an IAM role named `FirehoseDeliveryRole` in Account A. The role's trust policy permits the Kinesis Data Firehose service principal, and its permissions policy allows writing to the target bucket. When the administrator runs the AWS CLI command to create the delivery stream and specify `FirehoseDeliveryRole`, the command returns an 'AccessDeniedException'. What is the reason for this failure?

Show answer & explanation

Answer: The administrator's IAM user or role lacks permission to perform the iam:PassRole action on FirehoseDeliveryRole.

Answer

The administrator's IAM user or role lacks permission to perform the iam:PassRole action on FirehoseDeliveryRole.
To associate an IAM role with an AWS service (such as Kinesis Data Firehose), the IAM identity performing the configuration must have the iam:PassRole permission for the target role resource. Without this permission, the AWS CLI command to create the delivery stream will fail with an AccessDeniedException because the user is not authorized to delegate that role to the service, even if the user has full permissions for the service itself.

Step-by-Step Solution

1
Identify the action causing the failure.
The SysOps administrator is attempting to create a Kinesis Data Firehose delivery stream and configure it to use the service role FirehoseDeliveryRole.
This determines which API actions and resource associations are being evaluated by IAM.
2
Review authorization requirements for service role delegation.
AWS requires the calling user to have the iam:PassRole permission on a role before that role can be assigned to a service.
This security measure prevents users from escalating their own privileges by assigning highly privileged roles to services.
3
Diagnose the AccessDeniedException error.
Since the administrator has firehose:* permissions and the role itself has the correct trust policy, the missing piece is authorization to pass the role itself.
The error occurs at the configuration level (creating the stream with the associated role), confirming the administrator lacks the iam:PassRole permission.

Key Concept

Delegating IAM roles to AWS services using the PassRole permission
Estimated Time:2m 0s
Question 745Question →

A SysOps Administrator is updating an application hosted on AWS Elastic Beanstalk. The application must maintain its full capacity to handle user traffic throughout the deployment process. Which of the following deployment strategies will meet this requirement? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Immutable; Rolling with additional batch

Answer

The Immutable and Rolling with additional batch deployment strategies both maintain full application capacity during deployments. Immutable achieves this by launching a completely new Auto Scaling group of instances, while Rolling with additional batch launches an extra batch of instances before updating existing ones.
The Immutable strategy maintains capacity by deploying to a completely new Auto Scaling group, while the Rolling with additional batch strategy provisions a temporary batch of instances first to maintain 100% capacity during updates to the existing instances.

Step-by-Step Solution

1
Analyze the capacity requirement
The application must maintain 100% of its capacity to handle traffic at all times during the deployment.
This rules out any deployment strategies that take existing instances out of service without first provisioning new capacity.
2
Evaluate the Elastic Beanstalk deployment policies against the capacity requirement
Immutable and Rolling with additional batch both launch new instances to offset the capacity of instances undergoing updates. All at once takes all instances offline, and Rolling takes a batch of instances offline without provisioning temporary replacements.
Identifying which policies provision temporary instances first ensures the capacity requirement is satisfied.

Key Concept

AWS Elastic Beanstalk deployment strategies and their impact on application capacity and downtime.
Question 746Question →

A company is running a critical e-commerce platform that uses a single-instance Amazon RDS for PostgreSQL DB instance. During a recent infrastructure event in the primary Availability Zone, the database became unavailable, resulting in a three-hour outage while the operations team restored the database from a backup. To prevent a recurrence, a SysOps Administrator is tasked with implementing a highly available architecture that supports automatic, synchronous failover and also offloads read-heavy reporting queries. Which combination of actions should the SysOps Administrator take to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Modify the RDS DB instance to enable a Multi-AZ deployment.; Create an Amazon RDS Read Replica and configure the reporting application to use the Read Replica endpoint.

Answer

Modify the RDS DB instance to enable a Multi-AZ deployment, and create an Amazon RDS Read Replica and configure the reporting application to use the Read Replica endpoint.
To achieve high availability with automatic, synchronous failover and zero data loss, a Multi-AZ deployment is required. Multi-AZ creates a synchronous standby instance in a different Availability Zone and automatically updates DNS records during a failover event. To offload read-heavy reporting queries, a separate Read Replica should be deployed, and the reporting application should connect to the replica's endpoint.

Step-by-Step Solution

1
Analyze the high availability and failover requirements.
Identify that automatic, synchronous failover with zero data loss within the Region requires an Amazon RDS Multi-AZ deployment.
Multi-AZ configurations replicate data synchronously to a standby instance in a different Availability Zone and handle failover automatically via DNS updates.
2
Analyze the performance offloading requirements.
Identify that read-heavy queries must be directed away from the write database.
An Amazon RDS Read Replica provides a read-only endpoint that offloads query performance from the primary DB instance.
3
Evaluate the incorrect options regarding DNS and replication routing.
Eliminate options involving Route 53 active-passive routing to replicas and cross-Region replication.
Route 53 cannot automatically promote a read-only replica to accept write traffic, and cross-Region replication is asynchronous and requires manual promotion.

Key Concept

AWS Database High Availability and Read Scaling
Estimated Time:2m 30s
Question 747Question →

A SysOps Administrator performs a drift detection operation on an AWS CloudFormation stack that contains an Amazon S3 bucket. The drift detection report shows that the S3 bucket has a drift status of DELETED. Which of the following describes the root cause of this drift status?

Show answer & explanation

Answer: The S3 bucket was deleted directly from the AWS account outside of CloudFormation operations.

Answer

The S3 bucket was deleted directly from the AWS account outside of CloudFormation operations.
The correct answer is correct because CloudFormation drift detection compares the current resource state against the expected state defined in the stack template. If a resource exists in the template but has been deleted from the AWS account via the AWS Console, CLI, or API, the drift status for that resource is marked as DELETED.

Step-by-Step Solution

1
Understand CloudFormation drift detection concepts.
Drift detection compares the expected configuration of a resource (as defined in the CloudFormation template) with its actual configuration in the AWS environment.
This establishes the baseline of what drift detection is measuring.
2
Interpret the DELETED drift status.
A drift status of DELETED means the resource exists in the template but does not exist in the AWS account.
This identifies the specific meaning of the DELETED status.
3
Differentiate between CloudFormation actions and out-of-band actions.
Out-of-band actions (deleting resources directly via console, CLI, or APIs) lead to drift. Actions managed by CloudFormation update the stack's state and do not show as drifted.
This confirms that the deletion must have happened outside of CloudFormation.

Key Concept

CloudFormation Drift Detection Statuses
Question 748Question →

A company has a critical web application running on Amazon ECS with AWS Fargate. A SysOps Administrator needs to configure a deployment strategy for a new release that ensures zero downtime, provides the ability to run verification tests on the new version before routing production traffic to it, and supports rapid rollback to the previous version in the event of an application error. Which two actions should the SysOps Administrator perform to implement a deployment strategy that meets these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the Amazon ECS service to use the AWS CodeDeploy deployment controller.; Create an AWS CodeDeploy deployment group with a blue/green deployment type, specifying a test listener on the Application Load Balancer to verify the new version.

Answer

To meet the requirements, the SysOps Administrator should configure the Amazon ECS service to use the AWS CodeDeploy deployment controller and create an AWS CodeDeploy deployment group with a blue/green deployment type, specifying a test listener on the Application Load Balancer to verify the new version.
Configuring the ECS service deployment controller to use CodeDeploy enables blue/green deployment capabilities. The CodeDeploy deployment group manages the transition of traffic from the old task set (blue) to the new task set (green). By configuring a test listener on the Application Load Balancer, the administrator can route test traffic to the green deployment to verify the application's health before redirecting production traffic, ensuring zero downtime and providing a fast path to rollback if issues are detected.

Step-by-Step Solution

1
Modify the ECS service definition to set the deployment controller type to CODE_DEPLOY.
Delegates the routing of traffic between task sets to AWS CodeDeploy.
By default, ECS uses its own rolling update controller which does not support advanced traffic routing or verification testing on a separate listener.
2
Create an AWS CodeDeploy application and deployment group targeting the ECS service.
Establishes the deployment group that defines how traffic will shift.
The deployment group configures the blue/green environment settings and rollback alarms.
3
Configure the deployment group with a production listener and a test listener on the Application Load Balancer.
Enables preview traffic routing to the new (green) task set via the test port before production traffic cutover.
This allows verification tests to run on the live green task set while production users continue accessing the stable blue task set, and enables instant rollback if tests fail.

Key Concept

Implementing Blue/Green deployments on Amazon ECS using AWS CodeDeploy for zero-downtime releases, validation testing, and rapid rollbacks.
Question 749Question →

A SysOps Administrator is managing a high-traffic web application deployed on AWS Elastic Beanstalk behind an Application Load Balancer. The administrator needs to deploy a major update while ensuring there is no downtime. The update must be initially tested with a minor portion (10%10\%) of live user traffic for a brief evaluation window. If the new version triggers any CloudWatch alarms during this evaluation, the traffic must be automatically routed back to the existing version to minimize user impact.

Which Elastic Beanstalk deployment policy meets these requirements?

Show answer & explanation

Answer: Traffic splitting

Answer

Traffic splitting
Traffic splitting is the correct choice because it is the Elastic Beanstalk deployment policy designed specifically for canary testing. It launches a new set of instances alongside the existing ones, redirects a configured percentage of traffic (such as 10%) to the new version for an evaluation period, and automatically rolls back all traffic to the old instances if any configured CloudWatch alarms trigger or health checks fail.

Step-by-Step Solution

1
Analyze the deployment requirements: zero downtime, canary testing with a small percentage of traffic (10%), and automatic rollback based on CloudWatch alarms.
Identify that the solution requires a deployment strategy that supports fractional traffic shifting and automated rollback.
This narrows down the deployment strategies to those that can split traffic at the load balancer level.
2
Evaluate Elastic Beanstalk deployment policies against the identified requirements.
Determine that traffic splitting is the only Elastic Beanstalk policy designed specifically for canary testing by routing a percentage of traffic to the new version.
Other policies like Immutable shift 100% of traffic after health checks, and Rolling policies update in batches without fractional load-balancer-level traffic routing.

Key Concept

AWS Elastic Beanstalk traffic splitting deployment strategy for canary testing and automated rollbacks
Estimated Time:1m 30s
Question 750Question →

A SysOps Administrator is deploying an AWS Config organization conformance pack from the organization's management account. The conformance pack contains a rule to evaluate whether Amazon S3 buckets have public read access enabled, and it includes an automatic remediation configuration that runs the AWS-DisableS3BucketPublicReadWrite Systems Manager (SSM) Automation document. During deployment, the administrator observes that although the conformance pack and rules deploy successfully to all member accounts, the automated remediation fails to execute when a non-compliant bucket is discovered. Which combination of configuration steps will resolve this issue and allow the remediation to run successfully? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the trust relationship of the remediation IAM role in each member account to allow the Systems Manager service principal (ssm.amazonaws.com) to assume the role.; Grant the iam:PassRole permission for the remediation IAM role to the IAM identity deploying the organization conformance pack.

Answer

Configure the trust relationship of the remediation IAM role in each member account to trust the Systems Manager service principal (ssm.amazonaws.com), and grant the iam:PassRole permission for the remediation IAM role to the IAM identity deploying the organization conformance pack.
To successfully execute automated remediations deployed via an organization conformance pack, the remediation role in each member account must have a trust policy allowing the Systems Manager service principal (ssm.amazonaws.com) to assume the role, as Systems Manager executes the Automation document. Additionally, the deploying identity in the management account must have the iam:PassRole permission for the remediation role to authorize passing it to the service.

Step-by-Step Solution

1
Identify the execution pathway for AWS Config rule remediation.
AWS Config triggers Systems Manager Automation to perform the remediation, which requires Systems Manager to assume the remediation execution role in the target member account.
This establishes that the role's trust policy must allow the ssm.amazonaws.com service principal to assume the role.
2
Determine the required permissions for the administrator or deployment role.
The identity configuring or deploying the conformance pack must have the iam:PassRole permission to pass the remediation execution role to the Systems Manager service.
Without this permission, AWS Config cannot associate the execution role with the automation execution task.
3
Verify and eliminate incorrect service integrations and permission configurations.
Eliminate EventBridge routing options because remediation is native, eliminate trust relationships for config.amazonaws.com because the execution agent is Systems Manager, and eliminate PassRole policies targeting SSM documents.
This isolates the two required configuration changes.

Key Concept

AWS Config Rule automatic remediation requires establishing correct cross-service trust relationships (specifically for AWS Systems Manager) and granting the iam:PassRole permission to the deploying identity to authorize delegation of the execution role.
Question 751Question →

A company operates a legacy accounting platform on AWS. The application tier runs on a fleet of Amazon EC2 instances, and the database tier uses an Amazon RDS for MySQL DB instance. A SysOps Administrator is designing a cost-effective Pilot Light disaster recovery (DR) strategy in a secondary Region. The strategy must achieve a Recovery Point Objective (RPO) of 1 hour and a Recovery Time Objective (RTO) of 4 hours.

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

Select all that apply

Show answer & explanation

Answer: Create a cross-region read replica of the RDS for MySQL DB instance in the secondary Region.; Configure an Auto Scaling group in the secondary Region with the minimum and desired capacity set to 0, referencing an Amazon Machine Image (AMI) copied from the primary Region.

Answer

Create a cross-region read replica of the RDS for MySQL DB instance in the secondary Region, and configure an Auto Scaling group in the secondary Region with the minimum and desired capacity set to 0, referencing an Amazon Machine Image (AMI) copied from the primary Region.
The correct solution uses a Pilot Light disaster recovery model to minimize costs. By deploying an RDS cross-region read replica, the database is kept up to date asynchronously, satisfying the 1-hour RPO. Scaling the application tier Auto Scaling group in the recovery region to 0 instances ensures there are no ongoing compute costs, while allowing the infrastructure to spin up rapidly within the 4-hour RTO during failover.

Step-by-Step Solution

1
Select the cross-region replication method that meets the RPO constraint.
Identify that a cross-region read replica for RDS for MySQL asynchronously replicates database updates to the secondary Region with a lag typically under a few minutes, satisfying the 1-hour RPO requirement.
This establishes a passive, cost-effective database standby that can be promoted during disaster recovery.
2
Determine the application tier DR provisioning strategy that meets the RTO and cost constraints.
Configure an Auto Scaling group in the secondary Region with minimum and desired capacities set to 0, using a pre-copied AMI.
This configuration incurs no EC2 compute charges during normal operation, fulfilling the Pilot Light model requirements, and allows fast scaling within the 4-hour RTO when failover is triggered.

Key Concept

Pilot Light Disaster Recovery Strategy
Estimated Time:2m 0s
Question 752Question →

A company hosts a high-traffic web application using an active-passive Amazon Route 53 DNS failover configuration. The primary record is a CNAME record pointing to an Application Load Balancer (ALB) in us-east-1 with a TTL of 900 seconds. The secondary record is an Alias record pointing to a static maintenance page hosted on an Amazon S3 bucket configured for website hosting in us-west-2. Currently, a custom Route 53 health check monitors a CloudWatch alarm based on the ALB's HTTPCode_Target_5XX_Count metric, configured with standard monitoring (5-minute period) and an evaluation period of 2 datapoints. During a database outage, the application returned 502 Bad Gateway errors. Users continued to receive errors for more than 15 minutes before being redirected to the maintenance page. Once the database recovered briefly and then failed again, Route 53 DNS resolution repeatedly flapped between the ALB and the S3 bucket. The SysOps administrator must reconfigure the setup to ensure that failover to the S3 bucket occurs within 2 minutes of an outage and that flapping is mitigated during brief periods of recovery. Which TWO actions should the SysOps administrator take to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Replace the primary CNAME record with a Route 53 Alias record pointing to the Application Load Balancer, and enable the Evaluate Target Health option.; Configure the Application Load Balancer's target group health check with an interval of 10 seconds, an unhealthy threshold of 2, and a healthy threshold of 5.

Answer

Replace the primary CNAME record with a Route 53 Alias record pointing to the Application Load Balancer and enabling the Evaluate Target Health option, and configure the Application Load Balancer's target group health check with an interval of 10 seconds, an unhealthy threshold of 2, and a healthy threshold of 5.
Replacing the CNAME record with an Alias record pointing to the Application Load Balancer and enabling 'Evaluate Target Health' enables Route 53 to determine health based on the target group health checks, while automatically reducing the DNS TTL to 60 seconds to prevent client-side caching. Configuring the ALB's target group health check with a 10-second interval, an unhealthy threshold of 2, and a healthy threshold of 5 ensures that unhealthy targets are detected in 20 seconds, and requires 50 seconds of stable recovery before failing back, preventing flapping.

Step-by-Step Solution

1
Analyze the DNS caching issue
The primary record is a CNAME with a TTL of 900 seconds (15 minutes). During a failover event, clients and resolvers will cache this record, delaying failover regardless of health check speed.
To ensure failover occurs within 2 minutes, we must reduce the TTL. Replacing the CNAME with an Alias record pointing to the ALB automatically sets the TTL to 60 seconds.
2
Evaluate the health check mechanism
The current setup uses a CloudWatch alarm based on standard monitoring (5-minute period) and 2 evaluation periods, which takes 10 minutes to alarm.
By enabling 'Evaluate Target Health' on the Route 53 Alias record, Route 53 directly queries the health of the ALB target groups, avoiding CloudWatch alarm latency.
3
Configure target group health check parameters for speed and stability
Setting the interval to 10 seconds and unhealthy threshold to 2 marks targets unhealthy in 20 seconds. Setting the healthy threshold to 5 prevents flapping by requiring 50 seconds of consecutive successful checks before marking the target healthy.
This meets both the 2-minute failover requirement and the mitigation of flapping during transient database recovery.

Key Concept

Amazon Route 53 DNS failover requires a low TTL (achieved via Alias records) and rapid, stable health check evaluation (achieved via target group health check optimization and Evaluate Target Health).
Question 753Question →

A SysOps Administrator is implementing a hybrid disaster recovery strategy using AWS Elastic Disaster Recovery (AWS DRS) to replicate on-premises database servers to AWS. The AWS Replication Agent is successfully installed and the replication status in the AWS DRS console is 'Healthy'. The administrator modifies the default EC2 Launch Template in the AWS DRS console to specify that recovered instances must launch with a predefined IAM instance profile named 'DatabaseRecoveryProfile' to grant database processes access to specific Amazon S3 buckets. When the administrator initiates a recovery drill in the AWS DRS console, the launch job fails during the EC2 instantiation phase. What is the most likely cause of this failure?

Show answer & explanation

Answer: The IAM policy of the administrator initiating the recovery drill does not include the iam:PassRole permission for the role associated with the DatabaseRecoveryProfile instance profile.

Answer

The IAM policy of the administrator initiating the recovery drill does not include the iam:PassRole permission for the role associated with the DatabaseRecoveryProfile instance profile.
To launch an EC2 instance with an associated IAM role, the user or role launching the instance (in this case, the SysOps Administrator performing the recovery drill) must have the iam:PassRole permission for that role. Without it, the EC2 service will prevent the launch because the user is not authorized to delegate permissions to the instance.

Step-by-Step Solution

1
Identify the stage at which the recovery drill failed.
The failure occurred during the EC2 instantiation phase, indicating a provisioning or launch configuration error rather than a replication issue.
Isolating the stage helps narrow down the failure to EC2 launch permissions or templates rather than agent network settings.
2
Review the configuration changes made to the default EC2 Launch Template.
An IAM instance profile ('DatabaseRecoveryProfile') was specified to be attached to the recovered EC2 instances.
Attaching an IAM role during EC2 instantiation introduces security policy dependencies, specifically the delegation of permissions.
3
Evaluate the IAM permissions required to launch an EC2 instance with a role attached.
The calling identity must have 'iam:PassRole' permission to pass the role to the EC2 service.
AWS prevents unauthorized users from elevating their privileges by passing arbitrary roles to EC2 instances.
4
Diagnose the administrator's permission set.
The administrator's IAM policy lacks 'iam:PassRole' for the specified role, resulting in an unauthorized error that fails the launch job.
Verifying the IAM user policies of the administrator is the correct resolution step.

Key Concept

AWS Elastic Disaster Recovery EC2 Launch Template IAM PassRole requirement
Question 754Question →

A company's production database runs on an Amazon RDS for MySQL DB instance configured in a Multi-AZ deployment. The primary DB instance is located in the us-east-1a Availability Zone, and the standby DB instance is in us-east-1b. To support disaster recovery, a cross-Region Read Replica has been deployed in the us-west-2a Availability Zone. An Availability Zone outage occurs in us-east-1a, causing the primary DB instance to become unreachable.

Which of the following describes the automatic failover behavior of the database tier and the required action from the SysOps Administrator?

Show answer & explanation

Answer: Amazon RDS automatically updates the DNS CNAME record of the DB instance endpoint to resolve to the standby instance in us-east-1b. The cross-Region Read Replica in us-west-2a automatically updates its replication source to the newly promoted primary instance and resumes replication. No manual intervention is required.

Answer

Amazon RDS automatically updates the DNS CNAME record of the DB instance endpoint to resolve to the standby instance in us-east-1b. The cross-Region Read Replica in us-west-2a automatically updates its replication source to the newly promoted primary instance and resumes replication. No manual intervention is required.
The correct option is correct because when an Availability Zone outage occurs in a Multi-AZ deployment, Amazon RDS automatically detects the failure, promotes the standby instance (in this case, in us-east-1b) to primary, and updates the DNS CNAME record of the DB instance endpoint to point to the new primary. Furthermore, Amazon RDS automatically updates the replication source of any associated Read Replicas (including cross-Region Read Replicas) to the new primary, so replication resumes without manual intervention.

Step-by-Step Solution

1
Analyze the database deployment architecture and identify the type of failover event.
Recognize that the deployment is a standard Multi-AZ DB instance with a cross-Region Read Replica, and the failure of the primary instance in us-east-1a will trigger automatic Multi-AZ failover within the same Region.
Determining the scope of automatic AWS operations helps clarify which parts of the recovery process are managed by Amazon RDS versus what requires manual administrator action.
2
Determine the behavior of the database endpoints during failover.
Identify that Amazon RDS updates the DNS CNAME record for the DB instance endpoint to point to the newly promoted primary instance in us-east-1b (the standby).
This ensures the application, when using the standard database endpoint, automatically reconnects to the new writer without configuration changes.
3
Determine the behavior of the cross-Region Read Replica.
Verify that Amazon RDS automatically updates the replication source of the cross-Region Read Replica to target the new primary instance in us-east-1b once it is promoted.
This confirms that replication resumes automatically without requiring the administrator to manually rebuild or promote the replica.

Key Concept

Amazon RDS Multi-AZ automatic failover behavior and automatic replication source updates for Read Replicas during failover.
Question 755Question →

A SysOps Administrator needs to enable Amazon CloudWatch Container Insights on an existing Amazon EKS cluster that runs on Amazon EC2 worker nodes. The administrator needs to collect both container-level performance metrics and application logs, and view them on a unified dashboard. Which two actions should the SysOps Administrator take to configure this monitoring solution? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Attach the CloudWatchAgentServerPolicy IAM managed policy to the IAM role of the Amazon EKS worker nodes.; Deploy the CloudWatch agent as a DaemonSet to collect performance metrics, and Fluent Bit as a DaemonSet to collect container logs.

Answer

Attach the CloudWatchAgentServerPolicy IAM managed policy to the IAM role of the Amazon EKS worker nodes, and deploy the CloudWatch agent as a DaemonSet to collect performance metrics, and Fluent Bit as a DaemonSet to collect container logs.
The correct options are attaching the CloudWatchAgentServerPolicy policy to the EKS worker nodes' IAM role, and deploying the CloudWatch agent and Fluent Bit DaemonSets. This ensures both permissions and agent workloads are properly configured on the EC2 instances supporting the cluster.

Step-by-Step Solution

1
Attach the CloudWatchAgentServerPolicy policy to the IAM role associated with the EKS worker nodes.
The EC2 worker nodes gain the necessary permissions to write metrics and logs to CloudWatch.
Security credentials must be granted to the node instances so that DaemonSets running on them can authenticate with CloudWatch endpoints.
2
Deploy the CloudWatch agent and Fluent Bit configuration maps and DaemonSets to the EKS cluster using kubectl.
The CloudWatch agent collects performance metrics from the container environments, and Fluent Bit collects stdout/stderr application logs from the containers' log paths.
DaemonSets run one pod copy per node, ensuring comprehensive collection of metrics and logs across all cluster resources.

Key Concept

Configuring Container Insights on EKS requires node permissions and DaemonSet configurations for the CloudWatch agent and Fluent Bit.
Question 756Question →

A company runs a critical transactional application in the `us-east-1` Region. The backend database is an Amazon RDS for PostgreSQL DB instance. A SysOps Administrator must configure the database infrastructure to meet the following requirements:

1. Ensure high availability within the primary Region with automatic, zero-downtime failover to a synchronous standby database in the event of an Availability Zone (AZ) outage.
2. Establish a disaster recovery (DR) solution in the `us-west-2` Region with a Recovery Point Objective (RPORPO) of less than 1515 minutes, while allowing reporting tools to query the DR database during normal operations.

Which combination of actions should the SysOps Administrator take to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Modify the primary database instance to enable Multi-AZ deployment.; Create a cross-Region read replica of the database instance in the `us-west-2` Region.

Answer

To meet the requirements, the SysOps Administrator must modify the primary database instance to enable Multi-AZ deployment and create a cross-Region read replica of the database instance in the secondary Region.
To meet the requirements, the SysOps Administrator must enable Multi-AZ deployment on the primary database instance to ensure high availability and automatic failover within the primary Region. Additionally, creating a cross-Region read replica in the secondary Region supports disaster recovery with a low Recovery Point Objective and allows reporting tools to query the replica without impacting the primary database's performance.

Step-by-Step Solution

1
Analyze the high availability requirement in the primary Region.
Identify that automatic, synchronous, zero-downtime failover within a Region requires an RDS Multi-AZ deployment, where AWS automatically manages DNS updates to the standby replica.
Multi-AZ provides synchronous replication and automatic DNS-level failover without manual intervention.
2
Analyze the disaster recovery and reporting requirements in the secondary Region.
Identify that a cross-Region read replica in the secondary Region satisfies the disaster recovery requirement (asynchronous replication with low latency) and allows read-only reporting traffic.
Read replicas are designed for read scaling (reporting) and cross-Region disaster recovery, offering asynchronous replication.
3
Evaluate and eliminate incorrect configurations involving Route 53 and read replica promotion.
Discard options proposing Route 53 for database replication or for automated read replica promotion, as Route 53 is a DNS routing service and cannot perform database-level operations.
Route 53 does not manage database-level replication or automated failover/promotion of read replicas.

Key Concept

Distinction between RDS Multi-AZ deployments for high availability and Read Replicas (same-region or cross-region) for read scaling and disaster recovery.
Estimated Time:2m 0s
Question 757Question →

A SysOps Administrator has deployed Amazon CloudWatch Container Insights on an Amazon EKS cluster running on Amazon EC2 worker nodes by running the CloudWatch agent as a DaemonSet. The Administrator notes that while the agent's diagnostic logs are successfully being written to CloudWatch, no Container Insights performance metrics (such as cluster, node, or pod CPU utilization) are appearing in the CloudWatch console. What is the most likely cause of this issue?

Show answer & explanation

Answer: The ServiceAccount used by the CloudWatch agent DaemonSet is not bound to the required ClusterRole, preventing the agent from querying the Kubernetes API for container and node metrics.

Answer

The ServiceAccount used by the CloudWatch agent DaemonSet is not bound to the required ClusterRole, preventing the agent from querying the Kubernetes API for container and node metrics.
To retrieve the performance metrics for Container Insights, the CloudWatch agent running in EKS needs read permissions to the Kubernetes API and Kubelet stats endpoint. This is achieved by creating a ServiceAccount for the DaemonSet pods and linking it to a ClusterRole that has get, list, and watch permissions on resources like pods and nodes. The link must be established using a ClusterRoleBinding. If this binding is missing, the agent cannot access the API, preventing it from writing performance events, which results in empty Container Insights metrics.

Step-by-Step Solution

1
Examine the container logs of the CloudWatch agent DaemonSet pods using the kubectl logs command.
Identify permission errors (such as HTTP 403403 Forbidden) when the agent attempts to fetch node and pod resource metrics from the API server or kubelet stats summary endpoint.
This confirms that the pod is failing to authenticate or lacks authorization to gather the required container-level telemetry data.
2
Verify the Role-Based Access Control (RBAC) definitions in the cluster, checking for the existence of the ClusterRole, ServiceAccount, and ClusterRoleBinding.
Confirm that while the ServiceAccount and ClusterRole are defined, the ClusterRoleBinding linking the ServiceAccount to the ClusterRole is either missing or incorrectly configured.
A ServiceAccount on Kubernetes cannot access cluster-level endpoints without a ClusterRoleBinding associating it with the proper ClusterRole.
3
Create and apply the ClusterRoleBinding manifest targeting the cloudwatch-agent ServiceAccount in the amazon-cloudwatch namespace.
The CloudWatch agent successfully queries the Kubernetes API, starts logging performance telemetry to the performance log group, and metrics populate in CloudWatch.
Correctly binding the ServiceAccount grants the containerized agent authorization to collect and emit the Embedded Metric Format logs required for Container Insights.

Key Concept

CloudWatch Container Insights EKS RBAC Requirements
Estimated Time:2m 0s
Question 758Question →

An organization is experiencing high data transfer costs through a NAT gateway. A SysOps Administrator attempts to create a VPC Flow Log at the subnet level to capture traffic details and deliver them to an Amazon CloudWatch Logs log group. Although the administrator has administrative permissions for Amazon EC2 and CloudWatch Logs, and has created a dedicated service role with the appropriate trust policy for delivery.logs.amazonaws.com, the creation of the flow log fails with an 'Access Denied' error. Which of the following actions should the administrator take to resolve this issue?

Show answer & explanation

Answer: Add an IAM policy to the administrator's identity that grants the iam:PassRole permission targeting the ARN of the dedicated service role.

Answer

Add an IAM policy to the administrator's identity that grants the iam:PassRole permission targeting the ARN of the dedicated service role.
The correct action is to add an IAM policy to the administrator's identity that grants the iam:PassRole permission targeting the ARN of the dedicated service role. This is required because when an AWS resource needs a role to perform actions on your behalf (such as VPC Flow Logs writing to CloudWatch Logs), the user configuring the resource must have permission to pass that role to the service.

Step-by-Step Solution

1
Analyze the IAM permission requirements for creating VPC Flow Logs that publish to Amazon CloudWatch Logs.
Identify that the administrator must pass the delivery IAM role to the VPC Flow Logs service.
VPC Flow Logs requires permission to write logs to CloudWatch Logs using a service role, which must be passed by the user creating the flow log.
2
Determine why the 'Access Denied' error occurs despite having EC2 and CloudWatch administrative access.
Realize that administrative access does not implicitly grant permission to pass roles unless explicitly allowed or using full administrator access with iam:*.
The iam:PassRole permission is a security boundary that must be explicitly granted to the identity creating the resource.
3
Select the correct IAM policy adjustment to allow role passing.
Attach an IAM policy granting iam:PassRole for the service role's ARN to the administrator's IAM identity.
This allows the administrator to successfully delegate the log delivery role to the VPC Flow Logs service, resolving the 'Access Denied' error.

Key Concept

IAM PassRole permissions for VPC Flow Logs delivery to CloudWatch Logs
Estimated Time:1m 30s
Question 759Question →

To enforce principal-based execution, a company requires all AWS Service Catalog provisioning to occur under a specific IAM role. While attempting to establish a launch constraint for a product portfolio, the platform administrator is blocked by an access denied error. The administrator already has full access to the target IAM role and AWS Service Catalog. Which specific IAM permission must be added to the administrator's IAM policy to allow them to assign this IAM role to the launch constraint?

Show answer & explanation

Answer: iam:PassRole

Answer

iam:PassRole
To apply a launch constraint to an AWS Service Catalog product or portfolio, the user or role performing the action must have the iam:PassRole permission on the target IAM role. This ensures that the administrator has the authority to delegate the execution of tasks to that specific role.

Step-by-Step Solution

1
Identify the action causing the permission error.
The administrator is trying to assign an IAM role as a launch constraint to an AWS Service Catalog portfolio.
Setting a launch constraint requires delegating provisioning capabilities to a specific role, which represents passing that role to the Service Catalog service.
2
Determine the required IAM permission for passing roles to AWS services.
The iam:PassRole action is the standard AWS mechanism for authorizing a principal to delegate a role to an AWS service.
Without the iam:PassRole permission, users are blocked from assigning highly privileged roles to services to prevent privilege escalation.

Key Concept

AWS Service Catalog Launch Constraints and IAM PassRole Requirement
Question 760Question →

A SysOps Administrator is using AWS CloudFormation to update a web application stack. The stack includes an Auto Scaling group (ASG) configured with an AutoScalingRollingUpdate update policy. The update template references a new AMI and a new IAM instance profile for the EC2 instances. During the deployment, the new instances fail to send a success signal to CloudFormation within the PauseTime period because of a misconfiguration in the UserData script. As a result, CloudFormation automatically transitions to the UPDATE_ROLLBACK_IN_PROGRESS state to revert the ASG to its previous launch template. However, the rollback process fails, and the stack status changes to UPDATE_ROLLBACK_FAILED. The error details indicate that CloudFormation is unauthorized to associate the previous IAM instance profile with the EC2 instances. Which action should the administrator take to successfully restore the stack to a stable state?

Show answer & explanation

Answer: Add the iam:PassRole permission for the previous instance profile role to the CloudFormation execution role policy, and then perform the Continue Update Rollback action.

Answer

Add the iam:PassRole permission for the previous instance profile role to the CloudFormation execution role policy, and then perform the Continue Update Rollback action.
The correct action is to add the iam:PassRole permission for the original instance profile's role to the CloudFormation execution role, and then invoke the Continue Update Rollback operation. When a CloudFormation stack update fails and attempts to roll back to a previous state, CloudFormation must perform all operations in reverse. If the original stack used an IAM instance profile, CloudFormation requires the iam:PassRole permission for that original role to re-associate it with the reverted EC2 instances. If this permission is missing, the rollback fails, placing the stack in the UPDATE_ROLLBACK_FAILED state. Resolving the authorization issue and triggering the Continue Update Rollback operation allows the rollback to finish successfully, bringing the stack back to the stable UPDATE_ROLLBACK_COMPLETE state.

Step-by-Step Solution

1
Analyze the stack status and error message.
The stack is confirmed to be in the UPDATE_ROLLBACK_FAILED state due to an authorization issue (Access Denied) when trying to associate the old IAM instance profile during the rollback phase.
Before choosing a remediation step, the administrator must determine the exact state of the stack and why the rollback operation was blocked.
2
Identify the missing IAM permission.
CloudFormation requires the 'iam:PassRole' permission for the original role used by the previous IAM instance profile to reassign it to the instances.
When reverting resources to a previous state, CloudFormation performs the actions on behalf of the user or role executing the stack update, necessitating appropriate permission coverage.
3
Update the CloudFormation execution role policy.
The policy is updated to explicitly allow the 'iam:PassRole' action on the target role ARN.
This clears the authorization block, allowing CloudFormation to proceed with the rollback actions.
4
Execute the Continue Update Rollback command.
CloudFormation resumes the rollback process and successfully moves the stack status to UPDATE_ROLLBACK_COMPLETE.
The 'continue-update-rollback' API is the only mechanism allowed to move a stack out of the UPDATE_ROLLBACK_FAILED state back to a stable configuration.

Key Concept

Handling CloudFormation Rollback Failures and PassRole Permissions
PreviousPage 38 / 49Next