📘 Free Sample Questions
A CloudOps engineer is examining the following AWS CloudFormation template:
Why will the stack creation fail?
A
The Outputs section of the CloudFormation template was omitted.
B
The Parameters section of the CloudFormation template was omitted.
C
The PrivateDnsName cannot be sot from a CloudFormation template.
D
The VPC was not specified in the CloudFormation template.
Correct Answer:
C. The PrivateDnsName cannot be sot from a CloudFormation template.
Explanation:
C. The PrivateDnsName cannot be set from a CloudFormation template.
This question refers to creating an EC2 instance (or an EC2-based resource) in AWS CloudFormation and
attempting to explicitly set a property called:
PrivateDnsName
The key point is:
CloudFormation does NOT allow you to manually set the PrivateDnsName property of an EC2 instance.
A company applies user-defined tags to resources that are associated with the company's AWS workloads. Twenty
days after applying the tags, the company notices that it cannot use the tags to filter views in the AWS Cost
Explorer console.
What is the reason for this issue?
A
It takes at least 30 days to be able to use tags to filter views in Cost Explorer.
B
The company has not activated the user-defined tags for cost allocation.
C
The company has not created an AWS Cost and Usage Report.
D
The company has not created a usage budget in AWS Budgets.
Correct Answer:
B. The company has not activated the user-defined tags for cost allocation.
Explanation:
The reason the company cannot use tags to filter views in the AWS Cost Explorer console is that user-defined
tags must be explicitly activated for cost allocation purposes. AWS differentiates between AWS-generated
tags, which are automatically included in billing reports, and user-defined tags. For user-defined tags to be
recognized and utilized for cost analysis and filtering within services like Cost Explorer, they require manual
activation in the AWS Billing console under the "Cost allocation tags" section.
Without this crucial activation step, AWS Cost Explorer simply does not process these custom tags as
dimensions for filtering or grouping costs. Even though the tags were applied to resources for twenty days,
their absence from Cost Explorer filters indicates they were not enabled for cost allocation. Once activated, it
typically takes 24 to 48 hours for the tag data to propagate and become available for filtering in Cost
Explorer. The 20-day period mentioned in the question confirms that the delay is not due to propagation time
after activation, but rather the lack of activation itself.
Option A is incorrect because the typical propagation time for tags after activation is much shorter than 30
days. Option C is incorrect as creating an AWS Cost and Usage Report (CUR) provides very granular cost data,
but it is not a prerequisite for using activated tags to filter views directly within the Cost Explorer interface.
Cost Explorer itself relies on aggregated billing data, which activated tags enrich. Option D, creating a usage
budget, is a function of AWS Budgets for cost control and alerts, and has no bearing on enabling tag-based
filtering within Cost Explorer. Therefore, activating user-defined tags for cost allocation is the essential
missing step.
Authoritative Links:
Using Cost Allocation Tags: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-
tags.html
Activating Cost Allocation Tags in the Billing Console:
https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html
Cost Explorer Overview: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-what-is.html
An environment consists of 100 Amazon EC2 Windows instances. The Amazon CloudWatch agent is deployed and
running on all EC2 instances with a baseline configuration file to capture log files. There is a new requirement to
capture the DHCP log files that exist on 50 of the instances.
What is the MOST operationally efficient way to meet this new requirement?
A
Create an additional CloudWatch agent configuration filo to capture the DHCP logs. Use the AWS Systems Manager Run Command to restart the CloudWatch agent on each EC2 instance with the append-config option to apply the additional configuration file.
B
Log in to each EC2 instance with administrator rights. Create a PowerShell script to push the needed
baseline log files and DHCP log files to CloudWatch.
C
Run the CloudWatch agent configuration file wizard on each EC2 instance. Verify that the baseline log files
are included and add the DHCP log files during the wizard creation process.
D
Run the CloudWatch agent configuration file wizard on each EC2 instance and select the advanced detail
level. This will capture the operating system log files.
Correct Answer:
A. Create an additional CloudWatch agent configuration filo to capture the DHCP logs. Use the AWS Systems Manager Run Command to restart the CloudWatch agent on each EC2 instance with the append-config option to apply the additional configuration file.
Explanation:
Option A is the MOST operationally efficient way to meet this new requirement because it leverages AWS
native services for automation and centralized configuration management.
Firstly, creating an additional CloudWatch agent configuration file specifically for DHCP logs promotes
modularity and maintainability. This isolates the new requirement without altering the existing baseline
configuration, making it easier to manage future changes or revert if necessary.
Secondly, using AWS Systems Manager Run Command is a highly efficient method for executing commands
and managing configurations across a fleet of EC2 instances at scale. Instead of manually logging into each
of the 50 instances, Run Command allows for a single action to be applied to all targeted instances
simultaneously and programmatically. This drastically reduces manual effort, potential for human error, and
operational overhead.
The append-config option for the CloudWatch agent is crucial here. It allows the agent to merge the new DHCP
log configuration with the existing baseline configuration already running on the instances. This means the
existing log collection continues uninterrupted while the new DHCP log collection is seamlessly added,
ensuring no downtime or loss of existing data streams. This approach avoids the need to consolidate all log
configurations into a single, potentially complex, file or to restart collection of baseline logs unnecessarily.
requirements.
Authoritative Links for further research:
configuration-file-sagemaker.html
In contrast, options B, C, and D involve manual intervention on each EC2 instance (logging in or running a
wizard), which is incredibly inefficient and error-prone for 50 instances, let alone a larger fleet. Option B also
suggests abandoning the robust CloudWatch agent for custom PowerShell scripts, which would increase
maintenance burden and re-implement functionality already provided by the agent. Options C and D involve
interacting with a wizard, which is not designed for programmatic, large-scale deployment or updates in an
automated environment. Moreover, option D's "advanced detail level" might collect more data than necessary
and doesn't guarantee specific DHCP log capture without explicit configuration, nor does it address the
deployment efficiency.
Therefore, Option A aligns with best practices for infrastructure automation and centralized management
using AWS services, ensuring minimal operational effort and maximum efficiency for updating log collection
Deploy the CloudWatch agent using Systems Manager:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent
Run Commands using AWS Systems Manager: https://docs.aws.amazon.com/systems
manager/latest/userguide/execute-remote-commands.html
CloudWatch Agent Configuration File Structure:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File
Details.html (Look for append_dimensions and related options in the context of configuration management,
although append-config is a command-line option for deployment, it signifies the merging capability.)
A company is storing backups in an Amazon S3 bucket. The backups must not be deleted for at least 3 months
after the backups are created.
What should a CloudOps engineer do to meet this requirement?
A
Configure an IAM policy that denies the s3:DeleteObject action for all users. Three months after an object is
written, remove the policy.
B
Enable S3 Object Lock on a new S3 bucket in compliance mode. Place all backups in the new S3 bucket witha retention period of 3 months.
C
Enable S3 Versioning on the existing S3 bucket. Configure S3 Lifecycle rules to protect the backups.
D
Enable S3 Object Lock on a new S3 bucket in governance mode. Place all backups in the new S3 bucket with
a retention period of 3 months.
Correct Answer:
B. Enable S3 Object Lock on a new S3 bucket in compliance mode. Place all backups in the new S3 bucket witha retention period of 3 months.
Explanation:
The correct solution is B. Enable S3 Object Lock on a new S3 bucket in compliance mode. Place all backups
in the new S3 bucket with a retention period of 3 months.
Here's a detailed justification:
The core requirement is to ensure backups "must not be deleted for at least 3 months" after creation,
implying an immutable, write-once-read-many (WORM) storage mechanism for a specified duration. S3 Object
Lock is specifically designed for this purpose, providing a robust layer of data protection against accidental or
malicious deletion and modification.
Option B is correct because:
1. S3 Object Lock: This feature provides WORM capability for S3 objects, preventing them from being
deleted or overwritten for a fixed amount of time or indefinitely.
2. Compliance Mode: In compliance mode, an object version cannot be overwritten or deleted by any
user, including the root account, until the retention period expires. This offers the highest level of
protection and is ideal for scenarios where data immutability is paramount, such as regulatory
compliance or critical backup retention.
3. Retention Period: Setting a retention period of 3 months directly satisfies the specified duration for
non-deletion. Once the period is set in compliance mode, it cannot be shortened or disabled.
4. New S3 Bucket: S3 Object Lock must be enabled at the bucket level when the bucket is created. If
the existing bucket doesn't have it, a new bucket is necessary to implement this solution.
Why other options are incorrect:
modify IAM policies or the root user) could bypass it.
prone to errors, and not scalable for a backup system.
deleted" state.
A. Configure an IAM policy that denies the s3:DeleteObject action for all users. Three months after an
object is written, remove the policy.
IAM policies control user permissions, not the intrinsic immutability of the object itself. While an IAM policy
can prevent most users from deleting objects, a malicious actor with sufficient permissions (e.g., the ability to
The manual process of removing the policy for each object or batch after 3 months is operationally complex,
C. Enable S3 Versioning on the existing S3 bucket. Configure S3 Lifecycle rules to protect the backups.
S3 Versioning helps protect against accidental overwrites by keeping multiple versions of an object.
However, it does not prevent the deletion of specific object versions or the entire object if a user has the
necessary permissions. A user could still explicitly delete all versions.
S3 Lifecycle rules are primarily used for managing object storage classes and expiring (deleting) objects
after a specified period. They facilitate data deletion or transition, rather than preventing deletion for a
minimum duration. While you could set a rule to expire objects after 3 months, this is the opposite of
preventing deletion and does not provide an immutable lock. There's no lifecycle rule to enforce a "cannot be
D. Enable S3 Object Lock on a new S3 bucket in governance mode. Place all backups in the new S3 bucket
with a retention period of 3 months.
Governance Mode of S3 Object Lock prevents most users from deleting or overwriting an object version for
the retention period. However, users with specific permissions (s3:BypassGovernanceRetention) or the root
user can still modify or delete objects even when a retention period is active.
The requirement states "must not be deleted," implying a strong, unbypassable lock. Governance mode, while
strong, is not as absolute as compliance mode and thus does not fully meet the stringent "must not be
deleted" requirement if a powerful user intends to bypass it.
Therefore, enabling S3 Object Lock in compliance mode is the most robust and appropriate solution to meet
the requirement of ensuring backups are not deleted for at least 3 months.
Authoritative Links for further research:
S3 Object Lock Overview: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
Object Lock Modes: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-
overview.html#object-lock-modes
Managing S3 Versioning: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html
Managing your storage lifecycle: https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-lifecycle-
mgt.html
A company's CloudOps engineer is troubleshooting communication between the components of an application. The
company configured VPC flow logs to be published to Amazon CloudWatch Logs However, there are no logs in
CloudWatch Logs.
What could be blocking the VPC flow logs from being published to CloudWatch Logs?
A
The IAM policy that is attached to the IAM role for the flow log is missing the logs:CreateLogGroup
permission.
B
The IAM policy that is attached to the IAM role for the flow log is missing the logs:CreateExportTask
permission.
C
The VPC is configured for IPv6 addresses.
D
The VPC is peered with another VPC in the AWS account
Correct Answer:
A. The IAM policy that is attached to the IAM role for the flow log is missing the logs:CreateLogGroup
permission.
Explanation:
The issue described, where VPC flow logs are configured but no logs appear in CloudWatch Logs, strongly
indicates a permissions problem preventing the log group or log streams from being created or updated.
permissions for the flow log service to interact with CloudWatch.
When setting up VPC Flow Logs to publish to CloudWatch Logs, AWS requires an IAM role with specific
Option A is the correct answer because the IAM role used by VPC Flow Logs to publish to CloudWatch Logs
must have logs:CreateLogGroup permission. This permission allows the service to create the designated log
group in CloudWatch Logs if it doesn't already exist. If this fundamental permission is missing, the flow log
service cannot establish the necessary destination for the logs, resulting in no log data being published
Let's evaluate why the other options are incorrect:
whatsoever. Additionally, the role also requires logs:PutLogEvents and logs:CreateLogStream permissions to
write events into log streams within that log group and create new streams as needed. However,
CreateLogGroup is the critical permission for the initial setup if the log group itself doesn't exist, directly
leading to the "no logs" symptom.
B. The IAM policy that is attached to the IAM role for the flow log is missing the logs:CreateExportTask
permission. The logs:CreateExportTask permission is used for exporting existing log data from CloudWatch
Logs to an S3 bucket. It is not related to the initial process of publishing VPC flow logs to CloudWatch Logs.
Therefore, its absence would not prevent logs from appearing in CloudWatch Logs in the first place.
C. The VPC is configured for IPv6 addresses. VPC Flow Logs support capturing traffic for both IPv4 and IPv6
addresses. The presence of IPv6 configuration does not inherently block flow logs from being published; it
merely means that flow logs will include IPv6 traffic alongside IPv4 traffic, if applicable.
D. The VPC is peered with another VPC in the AWS account. VPC peering allows communication between
two VPCs but does not interfere with the functionality of VPC Flow Logs for either VPC. Flow logs capture
traffic flowing within and to/from the configured VPC, regardless of peering connections. The mechanism for
publishing these logs to CloudWatch Logs remains unaffected by VPC peering.
In summary, for VPC Flow Logs to successfully publish to CloudWatch Logs, the associated IAM role must
possess the necessary permissions to interact with CloudWatch Logs, including logs:CreateLogGroup to create
the log group if it doesn't exist, and logs:PutLogEvents to write the actual log data. The absence of
logs:CreateLogGroup is a direct blocker for the initial logging setup.
Authoritative Links for further research:
Publishing Flow Logs to CloudWatch Logs:
https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-cwl.html
IAM Role for Flow Logs: This document details the specific permissions required for the IAM role.
https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-cwl.html#flow-logs-cwl-iam
Troubleshooting VPC Flow Logs:
https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-troubleshooting.html
A company is migrating a legacy application to AWS. The company manually installs and configures the legacy
application on Amazon EC2 instances across multiple Availability Zones. The company sets up an Application Load
Balancer (ALB) for the application. The company sets the target group routing algorithm to weighted random. The
application requires session affinity.
After the company deploys the application, users report random application errors that were not present in the
legacy version of the application. The target group health checks do not show any failures. The company must
resolve the application errors.
Which solution will meet this requirement?
A
Set the routing algorithm of the target group to least outstanding requests.
B
Turn on anomaly mitigation for the target group.
C
Turn off the cross-zone load balancing attribute of the target group.
D
Increase the deregistration delay attribute of the target group.
Correct Answer:
A. Set the routing algorithm of the target group to least outstanding requests.
Explanation:
The company's legacy application explicitly requires session affinity, meaning that requests from a single
user's session should ideally be routed to the same Amazon EC2 instance to maintain session-specific data.
The current configuration uses an Application Load Balancer (ALB) with the target group routing algorithm
set to weighted random. This algorithm distributes incoming requests among healthy targets based on their
assigned weights, with no consideration for preserving a user's session. Consequently, consecutive requests
from the same user are frequently routed to different EC2 instances, causing the application to lose session
state and resulting in the reported "random application errors." The fact that health checks are passing
indicates the instances themselves are functional, but the application logic breaks due to the routing strategy.
Changing the routing algorithm to least outstanding requests (Option A) is the most effective solution among
the provided choices to mitigate these issues. The least outstanding requests algorithm directs new requests to
the target that currently has the fewest requests in progress. While this algorithm does not explicitly provide
true session stickiness (which would typically be enabled through the stickiness.enabled attribute of the target
group), it offers a more stable and less dispersive routing pattern compared to weighted random.
With weighted random, requests are distributed purely probabilistically, maximizing the chance of a user's
session being split across different instances. In contrast, least outstanding requests attempts to balance the
load evenly by always sending requests to the least busy server. This deterministic approach can
inadvertently increase the likelihood that a rapid sequence of requests from the same user arrives at the same
instance, especially if that instance remains the least busy for a short duration. By reducing the frequency of
server switches for a given user, this strategy can significantly reduce the occurrence of broken sessions and,
consequently, the "random application errors" that stem from a lack of session affinity, even if it doesn't
guarantee stickiness.
Let's briefly examine why other options are less suitable:
B. Turn on anomaly mitigation for the target group: Anomaly mitigation focuses on proactively identifying
and removing misbehaving instances before they fail health checks. This addresses instance health and
reliability, not the specific problem of session affinity breaking due to routing.
C. Turn off the cross-zone load balancing attribute of the target group: This attribute determines whether
ALB nodes route requests to targets across all Availability Zones or only within their own AZ. Turning it off
session affinity for active, healthy instances under normal operation.
Authoritative Links for Further Research:
can lead to uneven load distribution and does not resolve the core issue of session affinity across instances.
D. Increase the deregistration delay attribute of the target group: Deregistration delay (connection draining)
allows existing connections to complete gracefully when an instance is deregistering or becoming unhealthy.
This is crucial for application availability during scaling or maintenance but has no bearing on maintaining
Therefore, by selecting least outstanding requests, the company can achieve a more stable request distribution
that, while not a perfect session stickiness solution, significantly improves session continuity compared to
weighted random routing, thereby mitigating the reported application errors.
Application Load Balancer Target Groups and Routing Algorithms:
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html
(Refer to load_balancing.algorithm.type attribute)
Session Stickiness for Application Load Balancers:
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target
groups.html#sticky-sessions
A company is using an Amazon Aurora MySQL DB cluster that has point-in-time recovery, backtracking, and
automatic backup enabled. A CloudOps engineer needs to be able to roll back the DB cluster to a specific recovery
point within the previous 72 hours. Restores must be completed in the same production DB cluster.
Which solution will meet these requirements?
A
Create an Aurora Replica. Promote the replica to replace the primary DB instance.
B
Create an AWS Lambda function to restore an automatic backup to the existing DB cluster.
C
Use backtracking to rewind the existing DB cluster to the desired recovery point.
D
Use point-in-time recovery to restore the existing DB duster to the desired recovery point.
Correct Answer:
C. Use backtracking to rewind the existing DB cluster to the desired recovery point.
Explanation:
The correct solution is C. Use backtracking to rewind the existing DB cluster to the desired recovery point.
Here's a detailed justification:
1. Understanding Aurora Backtracking: Amazon Aurora Backtracking is a unique feature specifically
designed to quickly rewind an Amazon Aurora DB cluster to a prior point in time in place. It effectively
allows you to "undo" recent database changes without creating a new DB cluster or losing the
current cluster endpoint.
2. Meeting the "Same Production DB Cluster" Requirement: This is the most critical constraint in the
question. The problem explicitly states, "Restores must be completed in the same production DB
cluster." Aurora Backtracking is the only option provided that performs an in-place rewind of the
existing cluster. Other recovery methods for Aurora, such as Point-in-Time Recovery or restoring
from snapshots, always create a new DB cluster.
3. Leveraging Enabled Features: The question states that "backtracking" is enabled, indicating that the
environment is already configured to utilize this capability. This makes it a viable and intended
solution.
4. Time Window Compatibility: The requirement to roll back within the "previous 72 hours" aligns
perfectly with Aurora Backtracking's capabilities. Backtracking windows typically support up to 72
hours, providing ample flexibility within the specified timeframe.
5. Speed and Efficiency: Backtracking is significantly faster than traditional point-in-time recovery
because it doesn't involve moving data. Instead, Aurora changes its logical view of the data to reflect
6. Why other options are incorrect:
a previous state by discarding changes that occurred after the target rewind point. This makes it
ideal for rapid recovery from accidental data modifications or application errors.
A. Create an Aurora Replica. Promote the replica to replace the primary DB instance: While an
Aurora Replica could potentially have older data if created before an issue, promoting it creates a
new primary cluster from the replica. It does not rewind or modify the original production DB cluster
in place. This fails the "same production DB cluster" requirement.
B. Create an AWS Lambda function to restore an automatic backup to the existing DB cluster:
Restoring from an automatic backup (or a manual snapshot) in Aurora always creates a new DB
cluster. You cannot restore an automatic backup onto an existing cluster to overwrite or rewind it.
This violates the "same production DB cluster" constraint.
D. Use point-in-time recovery to restore the existing DB cluster to the desired recovery point:
Point-in-Time Recovery (PITR) in Aurora allows you to restore to a specific time, but it, too, creates a
new DB cluster with the restored data. It does not perform an in-place rollback of the original cluster.
Thus, it fails the critical requirement of completing the restore "in the same production DB cluster."
In summary, Aurora Backtracking is the precise feature designed for efficient, in-place recovery of an Aurora
DB cluster to a prior state, directly fulfilling all conditions outlined in the problem statement.
Authoritative Links for Further Research:
Rewinding an Aurora DB cluster with
Backtrack:https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Backtrack.html
Backtracking Aurora DB clusters:https://aws.amazon.com/blogs/aws/new-amazon-aurora-backtrack-rewind
your-db-cluster-to-an-earlier-point-in-time/
A CloudOps engineer is troubleshooting an AWS CloudFormation stack creation that failed. Before the CloudOps
engineer can identify the problem, the stack and its resources are deleted. For future deployments, the CloudOps
engineer must preserve any resources that CloudFormation successfully created.
What should the CloudOps engineer do to meet this requirement?
A
Set the value of the DisableRollback parameter to False during stack creation.
B
Set the value of the OnFailure parameter to DO_NOTHING during stack creation.
C
Specify a rollback configuration that has a rollback trigger of DO_NOTHING during stack creation
D
Set the value of the OnFailure parameter to ROLLBACK during stack creation.
Correct Answer:
B. Set the value of the OnFailure parameter to DO_NOTHING during stack creation.
Explanation:
When an AWS CloudFormation stack creation fails, the default behavior is for CloudFormation to initiate a
rollback, deleting any resources that were successfully created during the stack creation process. This
default action, while ensuring a clean state, makes it challenging to troubleshoot the root cause of the failure,
as the resources that might hold clues are removed.
To meet the requirement of preserving successfully created resources for future troubleshooting, the
CloudOps engineer should set the value of the OnFailure parameter to DO_NOTHING during stack creation.
This parameter dictates CloudFormation's behavior when a stack operation, such as creation, fails.
By setting OnFailure to DO_NOTHING, CloudFormation will halt the creation process at the point of failure and
will not attempt to roll back or delete any resources that were successfully provisioned up to that point.
Instead, the stack will remain in a CREATE_FAILED state, and all partially created resources will persist. This
allows the engineer to inspect the existing resources, logs, and configurations to identify the exact problem
without losing valuable diagnostic information.
For further research:
In contrast, setting OnFailure to ROLLBACK (the default behavior) would result in the deletion of all
successfully created resources, which directly contradicts the requirement. Similarly, setting OnFailure to
DELETE would also remove the stack and its resources.
Option A, setting DisableRollback to False, is incorrect because False is the default state, meaning rollback is
enabled, leading to resource deletion. If DisableRollback were set to True, it would prevent rollback, but
OnFailure is the more specific and recommended parameter for controlling failure actions. Option C is
incorrect because rollback triggers are for monitoring and initiating rollbacks after a stack is operational, and
"DO_NOTHING" is not a valid trigger type. Therefore, OnFailure=DO_NOTHING is the precise solution for
preserving resources upon stack creation failure.
AWS CloudFormation OnFailure parameter:
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-stack-failure.html
Controlling rollback behavior: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using
cfn-parameters.html#parameters-features-disable-rollback
A company plans to run a public web application on Amazon EC2 instances behind an Elastic Load Balancing (ELB)
load balancer. The company's security team wants to protect the website by using AWS Certificate Manager
(ACM) certificates. The load balancer must automatically redirect any HTTP requests to HTTPS.
Which solution will meet these requirements?
A
Create an Application Load Balancer that has one HTTPS listener on port 80. Attach an SSL/TLS certificate
to listener port 80. Create a rule to redirect requests from HTTP to HTTPS.
B
Create an Application Load Balancer that has one HTTP listener on port 80 and one HTTPS protocol listener
on port 443. Attach an SSL/TLS certificate to listener port 443. Create a rule to redirect requests from port 80
to port 443.
C
Create an Application Load Balancer that has two TCP listeners on port 80 and port 443. Attach an SSL/TLS
certificate to listener port 443. Create a rule to redirect requests from port 80 to port 443.
D
Create a Network Load Balancer that has two TCP listeners on port 80 and port 443. Attach an SSL/TLS
certificate to listener port 443. Create a rule to redirect requests from port 80 to port 443.
Correct Answer:
B. Create an Application Load Balancer that has one HTTP listener on port 80 and one HTTPS protocol listener
on port 443. Attach an SSL/TLS certificate to listener port 443. Create a rule to redirect requests from port 80
to port 443.
Explanation:
Option B presents the correct and most efficient solution for configuring an Application Load Balancer (ALB)
to meet the specified requirements. Application Load Balancers operate at Layer 7 of the OSI model, making
them ideal for HTTP and HTTPS traffic management, including SSL/TLS termination and content-based
routing.
Here’s a detailed justification:
1. Application Load Balancer Choice: An ALB is the appropriate load balancer type because it supports
advanced HTTP/HTTPS features required for this scenario, such as SSL termination and native
redirection. Network Load Balancers (NLBs) operate at Layer 4 and lack these application-layer
capabilities.
2. HTTP Listener on Port 80: The ALB must have an HTTP listener configured on port 80. This listener is
responsible for accepting incoming unencrypted HTTP requests from clients attempting to access
the website.
3. HTTPS Listener on Port 443: Concurrently, an HTTPS listener must be configured on port 443. This
listener handles secure, encrypted HTTPS requests. Port 443 is the standard port for HTTPS traffic,
ensuring compatibility with web browsers and clients.
instances.
6. Why other options are incorrect:
communication.
4. SSL/TLS Certificate Attachment: The AWS Certificate Manager (ACM) certificate, which secures the
website, is attached directly to the HTTPS listener on port 443. This action enables SSL/TLS
termination at the load balancer, offloading the encryption/decryption process from the backend EC2
5. Native HTTP-to-HTTPS Redirection: A key feature of Application Load Balancers is their ability to
define rules for listeners. A rule can be created for the HTTP listener on port 80 to automatically
redirect all incoming requests to the HTTPS listener on port 443. This ensures that any user trying to
access the website via an unencrypted HTTP connection is seamlessly and securely rerouted to the
HTTPS version of the site, fulfilling the security team's requirement.
Option A is incorrect because an HTTPS listener must be on port 443, not 80, for standard web operation.
Attaching an SSL certificate to an HTTPS listener on port 80 is a misconfiguration that will prevent proper secure
Option C specifies "TCP listeners" for an ALB. While ALBs support some TCP passthrough, their primary value
comes from HTTP/HTTPS listeners that enable Layer 7 features like redirection. Using generic TCP listeners
would bypass the ALB's native application-layer intelligence for HTTP/HTTPS handling and redirection.
Option D suggests a Network Load Balancer (NLB). NLBs operate at Layer 4 and do not natively support
application-layer HTTP-to-HTTPS redirection or SSL termination at the load balancer itself in the same way
an ALB does (though they can support TLS listeners, the redirection logic is absent). Implementing such
redirection with an NLB would require configuration on the backend instances, which contradicts the
requirement for the load balancer to handle it automatically.
Therefore, creating both an HTTP listener on port 80 and an HTTPS listener on port 443, attaching the ACM
certificate to the HTTPS listener, and setting up a redirection rule from port 80 to port 443 on an Application
Load Balancer is the correct, secure, and most efficient solution.
Authoritative Links for Further Research:
Application Load Balancer Listeners:
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listeners.html
Redirect actions for your Application Load Balancer:
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-update-rules.html#redirect
actions
SSL/TLS certificates for Application Load Balancers:
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html
What is AWS Certificate Manager (ACM)?
https://aws.amazon.com/certificate-manager/
A company uses AWS Organizations to manage a set of AWS accounts. The company has set up organizational
units (OUs) in the organization. An application OU supports various applications.
A CloudOps engineer must prevent users from launching Amazon EC2 instances that do not have a CostCenter-Project
tag into any account in the application OU. The restriction must apply only to accounts in the application OU.
Which solution will meet these requirements?
A
Create an IAM group that has a policy that allows the ec2:RunInstances action when the CostCenter-Project
tag is present. Place all IAM users who need access to the application accounts in the IAM group.
B
Create a service control policy (SCP) that denies the oc2:RunInstances action when the CostCenter-Project
tag is missing. Attach the SCP to the application OU.
C
Create an IAM role that has a policy that allows the oc2:RunInstances action when the CostCenter-Project
tag is present. Attach the IAM role to the IAM users that are in the application OU accounts.
D
Create a service control policy (SCP) that denies the ec2:RunInstances action when the CostCenter-Project
tag is missing. Attach the SCP to the root OU.
Correct Answer:
B. Create a service control policy (SCP) that denies the oc2:RunInstances action when the CostCenter-Project
tag is missing. Attach the SCP to the application OU.
Explanation:
The correct solution is B. Create a service control policy (SCP) that denies the ec2:RunInstances action
when the CostCenter-Project tag is missing. Attach the SCP to the application OU.
Here's a detailed justification:
1. Service Control Policies (SCPs) for Centralized Governance: AWS Organizations allows you to
centrally manage and govern your environment. SCPs are powerful guardrails that define the
maximum available permissions for accounts within an Organizational Unit (OU) or the entire
organization. They are ideal for enforcing mandatory controls across multiple accounts.
2. Explicit Deny for Prevention: The requirement is to "prevent" users from launching EC2 instances
without a specific tag. An SCP with an explicit Deny statement is the most effective way to achieve
this. An explicit deny in an SCP overrides any Allow policies that might exist at the IAM user, group, or
role level within the affected accounts, ensuring the restriction is enforced absolutely.
3. Conditional Denial based on Tags: SCPs can utilize conditions to evaluate requests. In this scenario,
the ec2:RunInstances action needs to be denied when the CostCenter-Project tag is missing. This can
be achieved using a condition key like aws:RequestTag/CostCenter-Project combined with the Null:true
operator in the SCP, which checks if the tag key is not provided in the request.
4. Targeted Scope to the Application OU: The problem statement explicitly states, "The restriction
must apply only to accounts in the application OU." By attaching the SCP directly to the application
OU, the policy's effects are confined to the accounts within that specific OU, precisely meeting this
scope requirement without impacting other OUs or accounts in the organization.
5. Why other options are less suitable:
A and C (IAM policies/roles): While IAM policies can enforce tag requirements, they are permissions
within an account. They rely on meticulous management of every user and role's permissions across
potentially many accounts. If a user has another IAM policy or role that grants ec2:RunInstances
without the tag condition, this solution can be bypassed. It's not a centralized, overriding preventative
measure.
that the restriction apply only to accounts in the application OU.
Authoritative Links for Further Research:
Service Control Policies (SCPs):
D (SCP attached to root OU): Attaching the SCP to the root OU would apply the restriction to all
accounts in the organization, including those outside the application OU. This violates the requirement
In summary, an SCP provides the necessary centralized control, explicit denial capability, and precise scoping
to meet all the requirements for preventing untagged EC2 instance launches in the specified OU.
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html
Controlling access to AWS resources using tags:
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html
AWS Global Condition Context Keys (specifically aws:RequestTag):
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-
requesttag