All practice questions

976 questions

All types976 Multiple choice502 Multiple select450 Ordering24

A SysOps Administrator is configuring an Amazon CloudFront distribution to serve private files from an Amazon S3 bucket. The S3 bucket is encrypted with SSE-KMS using an AWS Key Management Service (AWS KMS) customer managed key. The administrator creates an Origin Access Control (OAC), associates it with the distribution's S3 origin, and updates the S3 bucket policy to allow the CloudFront service principal to retrieve objects. Despite these configurations, when users attempt to access files via CloudFront, they receive an HTTP 403 Forbidden error.

Which of the following actions will resolve this issue?

Update the key policy of the AWS KMS customer managed key to grant the CloudFront service principal permissions to perform the kms:Decrypt action.

Update the S3 bucket policy to grant the CloudFront service principal permission to perform the kms:Decrypt action.

Configure the CloudFront distribution to use an Origin Access Identity (OAI) and enable automatic KMS key decryption in the OAI settings.

Configure the S3 bucket's route table to associate a gateway endpoint for S3 and enable route propagation.

Show answer & explanation

Answer: Update the key policy of the AWS KMS customer managed key to grant the CloudFront service principal permissions to perform the kms:Decrypt action.

Answer

Update the key policy of the AWS KMS customer managed key to grant the CloudFront service principal permissions to perform the kms:Decrypt action.

When an S3 bucket is encrypted with an AWS KMS customer managed key (SSE-KMS), CloudFront needs permission to use the KMS key to decrypt the objects it retrieves. Because S3 bucket policies cannot delegate KMS permissions, you must update the KMS key policy to allow the CloudFront service principal (cloudfront.amazonaws.com) to execute the kms:Decrypt action.

Step-by-Step Solution

Identify the origin type and encryption mechanism used for the S3 bucket.

The origin is S3 and it uses AWS KMS (SSE-KMS) with a customer managed key.

CloudFront OAC requires explicit KMS key permissions to decrypt objects encrypted with customer managed KMS keys.

Analyze why the S3 bucket policy update alone is insufficient for SSE-KMS encrypted objects.

The bucket policy can grant access to the S3 actions but cannot delegate permissions to the KMS key.

KMS key access is governed strictly by the KMS key policy, which must trust the CloudFront service principal.

Determine the required modification to the KMS key policy.

Add a statement to the KMS key policy that allows the 'cloudfront.amazonaws.com' service principal to perform 'kms:Decrypt'.

This allows CloudFront to decrypt the encrypted files on behalf of the client requests.

Key Concept

Amazon CloudFront OAC integration with S3 buckets encrypted with AWS KMS customer managed keys.

Estimated Time:1m 30s

Question 302Question →

An EC2 instance with private IP address $10.0.1.50$ is hosted in a private subnet and runs an HTTPS service on TCP port $443$ . The instance is associated with a security group named `sg-secure` and the subnet is associated with a network ACL named `nacl-custom`.

An external client at IP address $198.51.100.5$ attempts to connect to the HTTPS service on the instance. A SysOps Administrator configures VPC Flow Logs to capture traffic on the instance's elastic network interface (ENI). The flow log output shows the following records:

text
version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 123456789012 eni-0a1b2c3d4e5f6g7h8 198.51.100.5 10.0.1.50 49152 443 6 5 260 1601828400 1601828460 ACCEPT OK
2 123456789012 eni-0a1b2c3d4e5f6g7h8 10.0.1.50 198.51.100.5 443 49152 6 5 260 1601828400 1601828460 REJECT OK

The configuration of the security group `sg-secure` is:
- Inbound: Allow TCP port $443$ from $198.51.100.5/32$
- Outbound: Allow all traffic (destination $0.0.0.0/0$ , all ports)

The configuration of the network ACL `nacl-custom` is:
- Inbound:
- Rule 100: Allow TCP port $443$ from $0.0.0.0/0$
- Rule 32767: Deny all traffic
- Outbound:
- Rule 100: Allow TCP port $443$ to $0.0.0.0/0$
- Rule 32767: Deny all traffic

Which of the following changes will resolve the connectivity issue and allow the client to successfully establish a connection to the HTTPS service?

Add an outbound rule to the nacl-custom network ACL allowing TCP traffic with a destination port range of 1024-65535 to destination 0.0.0.0/0.

Add an outbound rule to the sg-secure security group allowing TCP traffic with a destination port of 49152 to destination 198.51.100.5/32.

Update the route table of the private subnet to add a route for 0.0.0.0/0 pointing directly to the Internet Gateway.

Modify the IAM role assigned to the VPC Flow Logs delivery service to grant the iam:PassRole permission for the Amazon CloudWatch Logs service.

Show answer & explanation

Answer: Add an outbound rule to the nacl-custom network ACL allowing TCP traffic with a destination port range of 1024-65535 to destination 0.0.0.0/0.

Answer

Add an outbound rule to the nacl-custom network ACL allowing TCP traffic with a destination port range of 1024-65535 to destination 0.0.0.0/0.

The correct answer is to add an outbound rule to the network ACL allowing TCP traffic with a destination port range of 1024-65535 to destination 0.0.0.0/0. Network ACLs are stateless, meaning they evaluate traffic in each direction independently. While the inbound rule allows port 443 traffic to enter, the outbound response traffic is sent from the server's port 443 to the client's ephemeral port (in this case, 49152). Because the outbound network ACL only allows destination port 443, the response packet is blocked by the default deny rule. Adding a rule for the ephemeral port range resolves this block.

Step-by-Step Solution

Analyze the VPC Flow Log records to identify the source of the drop.

The log shows that inbound traffic (from 198.51.100.5:49152 to 10.0.1.50:443) is ACCEPT, but the outbound response (from 10.0.1.50:443 to 198.51.100.5:49152) is REJECT.

This establishes that routing is functional (since the request reached the ENI) and that the block is caused by a firewall configuration (Security Group or Network ACL) rather than routing.

Evaluate the statefulness of the Security Group.

Since Security Groups are stateful, they track connection state and automatically permit return traffic. Additionally, the security group has an outbound rule allowing all traffic.

This rules out the Security Group as the cause of the REJECT action on the outbound packet.

Evaluate the stateless nature and rules of the Network ACL.

Network ACLs are stateless, requiring explicit rules for both inbound and outbound traffic. The outbound NACL only allows destination port 443. The return traffic is sent from source port 443 to destination port 49152 (the client's ephemeral port).

Since 49152 does not match the rule allowing destination port 443, the packet is denied by the default Rule 32767 (Deny all traffic).

Determine the required resolution.

An outbound rule must be added to the Network ACL to allow traffic to the ephemeral port range (1024-65535) for return packets.

This permits the stateless response traffic to reach the client, completing the TCP handshake.

Key Concept

Stateless Network ACLs require explicit rules for return traffic targeting client ephemeral ports, whereas stateful Security Groups automatically allow return traffic.

Alternative Method

Alternatively, replacing the custom stateless Network ACL with the default Network ACL (which permits all inbound and outbound traffic) would resolve the block, though this represents a broader configuration change that reduces the custom subnet-level restrictions.

Estimated Time:3m 0s

Question 303Question →

A SysOps Administrator is hosting a public website on an Amazon EC2 instance within a custom VPC. The Security Group associated with the EC2 instance allows all outbound traffic and inbound HTTP traffic on port 80. The Network ACL (NACL) associated with the subnet has an inbound rule that allows HTTP traffic on TCP port 80 from 0.0.0.0/0. However, external users cannot connect to the website. Which configuration change is required to allow external traffic to reach the web server?

Configure an outbound rule in the Network ACL that allows TCP traffic on port 80 to destination 0.0.0.0/0.

Add an outbound rule to the Network ACL that allows TCP traffic on ports 1024-65535 to destination 0.0.0.0/0.

Add an outbound rule to the Security Group that allows TCP traffic on ports 1024-65535 to destination 0.0.0.0/0.

Create a Gateway VPC Endpoint for the subnet and associate it with the subnet's route table.

Show answer & explanation

Answer: Add an outbound rule to the Network ACL that allows TCP traffic on ports 1024-65535 to destination 0.0.0.0/0.

Answer

Add an outbound rule to the Network ACL that allows TCP traffic on ports 1024-65535 to destination 0.0.0.0/0.

The correct answer provides the necessary outbound rule for the stateless Network ACL. Since Network ACLs do not track connection states, return traffic from the web server back to the web clients must be explicitly permitted. Web clients initiate HTTP requests using random source ports from the ephemeral port range (TCP 1024-65535), meaning the return traffic must be allowed to leave the subnet on these ports.

Step-by-Step Solution

Evaluate the stateful or stateless properties of the subnet's security controls.

The Security Group is stateful, while the Network ACL is stateless.

Because the Network ACL is stateless, any allowed inbound request must also have a corresponding outbound rule configured to allow the return traffic back to the client.

Determine the destination ports for the return traffic.

The return traffic targets the client's client-side source ports, which fall in the ephemeral port range (TCP 1024-65535).

Web browsers initiate connections using random ports in the ephemeral range rather than the service port (80).

Apply the outbound rule to permit return traffic through the Network ACL.

An outbound rule allowing TCP traffic on ports 1024-65535 to 0.0.0.0/0 is configured on the custom Network ACL.

This configuration allows packets originating from the EC2 instance's web server to exit the subnet back to the public internet client.

Key Concept

Network ACLs (NACLs) are stateless firewalls that control inbound and outbound traffic at the subnet level. They require explicit configuration of outbound rules for ephemeral port ranges (1024-65535) to allow response traffic back to clients.

Estimated Time:1m 0s

Question 304Question →

A company hosts a dynamic web application with a primary origin hosted on an Application Load Balancer (ALB) in the us-east-1 Region. To ensure high availability, the company deploys a secondary origin on another ALB in the us-west-2 Region. A SysOps administrator needs to configure Amazon CloudFront to automatically route traffic to the secondary ALB when the primary ALB returns HTTP 502 or 504 status codes. Which two configurations must the SysOps administrator implement to achieve this failover behavior? (Select TWO.)

Select all that apply

Create an origin group in the CloudFront distribution that includes the primary ALB as the primary origin and the secondary ALB as the secondary origin.

Update the cache behavior of the CloudFront distribution to point to the newly created origin group as the origin.

Configure Route 53 CNAME records pointing to the CloudFront distribution at the zone apex to automatically resolve traffic to the healthy ALB endpoint.

Configure an Amazon Route 53 Active-Passive failover routing policy with health checks to route traffic between the primary ALB and secondary ALB, and target this Route 53 record as the single origin for the CloudFront distribution.

Show answer & explanation

Answer: Create an origin group in the CloudFront distribution that includes the primary ALB as the primary origin and the secondary ALB as the secondary origin.; Update the cache behavior of the CloudFront distribution to point to the newly created origin group as the origin.

Answer

Create an origin group in the CloudFront distribution that includes the primary ALB as the primary origin and the secondary ALB as the secondary origin, and update the cache behavior of the CloudFront distribution to point to the newly created origin group as the origin.

To set up automatic failover between two Application Load Balancer origins in CloudFront based on HTTP status codes (such as 502 or 504), you must create an origin group. Within the origin group, you define the primary origin and the secondary origin, and specify the failover status codes. Next, you must associate the distribution's cache behavior with this origin group so that CloudFront knows to direct requests to it and trigger failover when those status codes are returned.

Step-by-Step Solution

Define both Application Load Balancers as origins under the CloudFront distribution settings.

Two separate origins are configured in the distribution.

Before grouping origins for failover, each origin must be defined individually.

Create an origin group, specifying the us-east-1 ALB as the primary origin and the us-west-2 ALB as the secondary origin, and select the HTTP 502 and 504 status codes to trigger failover.

An origin group is configured with failover criteria on specific HTTP status codes.

This establishes the failover relationship and conditions (502 and 504 status codes).

Modify the default cache behavior (or appropriate path-specific cache behavior) to target the newly created origin group.

The distribution routes viewer traffic to the origin group instead of a single origin.

CloudFront requires cache behaviors to map to the origin group to utilize failover capabilities.

Key Concept

CloudFront Origin Failover using Origin Groups

Question 305Question →

A company manages a multi-account environment using AWS Organizations with consolidated billing. The workloads are distributed as follows:
- The production account runs a steady-state fleet of Amazon EC2 m6i.large instances.
- The staging account runs microservices on Amazon ECS with AWS Fargate.
- The analytics account runs batch processing using AWS Lambda functions.

The SysOps administrator must implement a cost optimization strategy that achieves the maximum possible savings across Fargate, Lambda, and EC2 workloads while allowing the EC2 instance families to be changed in the future. Which of the following actions should the SysOps administrator take to meet these requirements? (Select TWO.)

Select all that apply

Purchase a Compute Savings Plan to cover the Fargate, Lambda, and EC2 workloads.

Ensure that Savings Plan sharing is enabled in the billing preferences of the Organizations management account.

Purchase an EC2 Instance Savings Plan for the m6i instance family to cover both the EC2 instances and the Fargate tasks.

Purchase Standard Reserved Instances at the management account level to cover the Lambda functions.

Purchase Regional Reserved Instances for the Fargate tasks to cover their steady-state run time.

Show answer & explanation

Answer: Purchase a Compute Savings Plan to cover the Fargate, Lambda, and EC2 workloads.; Ensure that Savings Plan sharing is enabled in the billing preferences of the Organizations management account.

Answer

Purchase a Compute Savings Plan to cover all three workloads, and ensure that Savings Plan sharing is enabled in the Organizations billing preferences.

The correct options are to purchase a Compute Savings Plan and ensure Savings Plan sharing is enabled. Compute Savings Plans are the only commitment discount type that covers Amazon EC2, AWS Fargate, and AWS Lambda simultaneously. Enabling sharing across AWS Organizations ensures that the commitment applies to workloads running in the staging and analytics member accounts, maximizing overall savings.

Step-by-Step Solution

Analyze the workload requirements and resource types.

Identify that the workloads span EC2 instances, AWS Fargate, and AWS Lambda across different accounts in an AWS Organization.

Understanding the resource mix determines which Savings Plans or Reserved Instances are eligible.

Evaluate the eligibility of each service for commitment-based discounts.

Confirm that Compute Savings Plans cover EC2, Fargate, and Lambda, whereas EC2 Instance Savings Plans and Reserved Instances do not apply to Fargate or Lambda.

This narrows down the eligible purchase options to satisfy the requirement of covering all three workloads.

Select the correct Savings Plan type that supports flexibility.

Choose a Compute Savings Plan because it allows changing EC2 instance families in the future, unlike standard Reserved Instances or EC2 Instance Savings Plans which limit flexibility.

The scenario requires maintaining the ability to change EC2 instance families.

Configure the organization-wide sharing of the Savings Plan benefits.

Ensure that Savings Plan sharing is active in the management account's preferences so that the staging and analytics accounts can utilize the purchased commitment.

By default, consolidated billing shares benefits, but if sharing is disabled, the member accounts running Fargate and Lambda will not receive the discounted rates.

Key Concept

Compute Savings Plans offer the greatest flexibility and automatically apply across EC2, Fargate, and Lambda, even across multiple accounts in an AWS Organization when sharing is enabled.

Question 306Question →

A company runs a data processing application in a single AWS account. The application uses a fleet of Amazon EC2 instances in an Auto Scaling group that dynamically scales between $5$ and $20$ `c6i.large` instances depending on queue depth. The application also invokes AWS Lambda functions to perform lightweight pre-processing on incoming data. Additionally, a single `db.r6g.large` Amazon RDS for PostgreSQL database runs continuously to store processing metadata. The company wants to minimize costs over the next year with a commitment plan, while retaining the flexibility to change EC2 instance families in the future if needed. Which combination of purchases should the SysOps administrator make to achieve the maximum cost optimization? (Select TWO.)

Select all that apply

Purchase a Compute Savings Plan to cover the baseline usage of the EC2 instances and the AWS Lambda functions.

Purchase a

1

-year Reserved Instance for the db.r6g.large RDS database instance.

Purchase an EC2 Instance Savings Plan to cover the EC2 instances and the AWS Lambda functions.

Purchase a Compute Savings Plan that covers the EC2 instances and the db.r6g.large RDS database instance.

Purchase a single

1

-year Regional Reserved Instance to cover both the EC2 Auto Scaling group and the RDS database instance.

Show answer & explanation

Answer: Purchase a Compute Savings Plan to cover the baseline usage of the EC2 instances and the AWS Lambda functions.; Purchase a $1$ -year Reserved Instance for the db.r6g.large RDS database instance.

Answer

Purchase a Compute Savings Plan to cover the baseline usage of the EC2 instances and the AWS Lambda functions, and purchase a 1-year Reserved Instance for the db.r6g.large RDS database instance.

The correct strategy involves purchasing a Compute Savings Plan to cover the EC2 instances and AWS Lambda functions, as Compute Savings Plans apply to both services and allow changes to instance families. In addition, a 1-year Reserved Instance must be purchased for the db.r6g.large RDS database because Savings Plans do not support Amazon RDS.

Step-by-Step Solution

Analyze the workload components and find which components can be grouped under a single Savings Plan type.

The EC2 instances and AWS Lambda functions can both be covered under a Compute Savings Plan, which applies to EC2, Fargate, and Lambda usage.

This matches the requirement to cover the dynamically scaling EC2 fleet and the Lambda functions with flexibility to change instance families.

Determine the optimization option for the Amazon RDS database instance.

Amazon RDS does not support Savings Plans, so the only commitment-based discount mechanism available for RDS is a database Reserved Instance.

This requires purchasing an RDS Reserved Instance for the db.r6g.large database tier to reduce database costs.

Key Concept

Compute Savings Plans provide flexible coverage across EC2 and Lambda, whereas Amazon RDS requires database Reserved Instances as it is not covered by Savings Plans.

Question 307Question →

A SysOps team is tasked with reducing compute costs for a new serverless application. The application's architecture includes a mix of Amazon EC2 instances, AWS Fargate containers, and AWS Lambda functions across several AWS Regions. Which commitment-based pricing model should the SysOps team select to optimize costs with the greatest flexibility?

Convertible Reserved Instances

EC2 Instance Savings Plans

Compute Savings Plans

Standard Reserved Instances

Show answer & explanation

Answer: Compute Savings Plans

Answer

Compute Savings Plans are the most appropriate choice because they automatically apply to compute usage across Amazon EC2, AWS Fargate, and AWS Lambda, providing the maximum flexibility for the multi-service architecture.

Compute Savings Plans offer the greatest flexibility and automatically apply to compute usage across Amazon EC2, AWS Fargate, and AWS Lambda, regardless of region, instance family, size, operating system, or tenancy.

Step-by-Step Solution

Identify the compute resources in scope for cost optimization.

The architecture consists of EC2 instances, AWS Fargate containers, and AWS Lambda functions.

Understanding the resource types is necessary to select a pricing model that covers all of them.

Evaluate the coverage of available savings models.

Compute Savings Plans apply to EC2, Fargate, and Lambda. EC2 Instance Savings Plans and Reserved Instances (Convertible or Standard) apply only to EC2 instances.

Comparing coverage boundaries helps identify which models can apply to all the targeted resources.

Determine the pricing model that offers the greatest flexibility for this multi-service deployment.

Compute Savings Plans are selected.

They automatically apply to all three compute services across different regions and configurations without manual modification.

Key Concept

Compute Savings Plans automatically apply to EC2, Fargate, and Lambda usage across any AWS Region and configuration, making them the most flexible commitment option.

Question 308Question →

A company hosts a static website using Amazon CloudFront. The security team mandates that all communication between the viewers and the CloudFront distribution must be encrypted in transit. Which two Viewer Protocol Policy settings will satisfy this requirement? (Select TWO.)

Select all that apply

Redirect HTTP to HTTPS

HTTPS Only

HTTP and HTTPS

HTTP Only

Show answer & explanation

Answer: Redirect HTTP to HTTPS; HTTPS Only

Answer

The settings 'Redirect HTTP to HTTPS' and 'HTTPS Only' ensure that all communication between the viewers and the CloudFront distribution is encrypted in transit.

The correct options are 'Redirect HTTP to HTTPS' and 'HTTPS Only'. The 'Redirect HTTP to HTTPS' setting automatically redirects unencrypted HTTP requests to the secure HTTPS protocol. The 'HTTPS Only' setting blocks unencrypted HTTP requests entirely, forcing the viewer to use HTTPS. Both settings ensure that all viewer communication with the distribution is encrypted.

Step-by-Step Solution

Analyze the requirement for transport encryption between viewers and the CloudFront distribution.

The requirement dictates that all client-to-edge connections must use HTTPS.

This establishes the necessary protocol constraint for the CloudFront behavior configuration.

Evaluate the Viewer Protocol Policy options available in CloudFront.

Viewer Protocol Policy has three main settings: 'HTTP and HTTPS', 'Redirect HTTP to HTTPS', and 'HTTPS Only'.

Identifying the available settings allows selection of the ones that enforce encryption.

Select the settings that enforce HTTPS.

'Redirect HTTP to HTTPS' and 'HTTPS Only' both guarantee that no unencrypted HTTP traffic is served by the distribution.

Choosing these two configurations successfully meets the requirement.

Key Concept

CloudFront Viewer Protocol Policy options for enforcing HTTPS

Question 309Question →

A company currently hosts a batch processing workload on a fleet of Amazon EC2 $c6g.2xlarge$ instances in the $us-east-1$ region. Over the next year, the company plans to modernize the workload by migrating $50\%$ of the processing to containerized tasks running on AWS Fargate in the same region, and upgrading the remaining EC2 instances to the newer $c7g.2xlarge$ instance family. Which commitment-based discount option should a SysOps administrator recommend to optimize costs for both the remaining EC2 instances and the Fargate tasks without requiring manual exchanges or interventions?

EC2 Instance Savings Plans for the c6g instance family

Compute Savings Plans

Convertible Reserved Instances for the c6g instance family

Standard Reserved Instances for the c6g instance family

Show answer & explanation

Answer: Compute Savings Plans

Answer

Compute Savings Plans

Compute Savings Plans provide the greatest flexibility. They automatically apply to compute usage across Amazon EC2, AWS Fargate, and AWS Lambda regardless of instance family, size, Availability Zone, region, OS, or tenancy. This ensures that as the company transitions their batch workloads from c6g instances on EC2 to a combination of c7g instances on EC2 and containerized tasks on Fargate, the discounts continue to apply seamlessly without requiring manual exchanges or interventions.

Step-by-Step Solution

Analyze the target architecture changes over the one-year period.

The target state consists of a mix of EC2 c7g instances and AWS Fargate tasks, representing changes in both EC2 instance families and compute service types.

Understanding the final architecture helps match the target workloads to the correct discount capabilities.

Evaluate the scope and flexibility of the available discount options.

Compute Savings Plans apply to EC2 instances (any family, size, or region) and AWS Fargate automatically. EC2 Instance Savings Plans and Reserved Instances do not support Fargate or require manual adjustments for instance family changes.

Selecting the most flexible discount model is necessary to avoid lock-in when workloads and instance types evolve.

Identify the option that applies automatically to both compute types without operational overhead.

Compute Savings Plans are selected as they require no manual modifications, exchanges, or interventions to cover both the upgraded EC2 instances and the Fargate tasks.

This meets the business goal of optimizing costs with minimal administrative overhead.

Key Concept

Compute Savings Plans offer the highest level of flexibility among AWS commitment-based discounts, automatically applying to EC2 instance usage across families, sizes, and regions, as well as AWS Fargate and AWS Lambda.

Estimated Time:1m 30s

Question 310Question →

A company manages a multi-account AWS environment using AWS Organizations with consolidated billing enabled. The environment has two member accounts:

* Account A (Production) runs a steady-state web application on Amazon EC2 $m6i.large$ instances and Amazon ECS on AWS Fargate.
* Account B (Testing) runs temporary development workloads using various EC2 instance families (such as $t3$ and $c6g$ ) that are frequently stopped, started, or terminated.

The company wants to optimize its compute costs. The SysOps administrator must ensure that the commitment discount is applied to both the Fargate tasks and the EC2 instances in Account A as a priority, and is not consumed by the fluctuating workloads in Account B.

Which strategy should the SysOps administrator implement to meet these requirements?

Purchase a Compute Savings Plan in Account A.

Purchase an EC2 Instance Savings Plan in Account A.

Purchase a Compute Savings Plan in the Management Account.

Purchase Regional Reserved Instances for

m6i

instances in Account A.

Show answer & explanation

Answer: Purchase a Compute Savings Plan in Account A.

Answer

Purchase a Compute Savings Plan in Account A.

Purchasing a Compute Savings Plan in Account A is correct because Compute Savings Plans apply to compute usage across Amazon EC2, AWS Fargate, and AWS Lambda. Additionally, in an AWS Organization with consolidated billing, Savings Plan discounts are applied first to the account that purchased the plan. Buying the plan in Account A ensures that Account A's steady-state EC2 and Fargate workloads receive the discount first, with any excess sharing to other accounts like Account B.

Step-by-Step Solution

Identify the compute resource types in the production workload.

Account A runs both Amazon EC2 instances and AWS Fargate tasks.

EC2 Instance Savings Plans and Reserved Instances only apply to EC2 instances, meaning Fargate usage would remain at On-Demand rates. A Compute Savings Plan is required to cover both services under a single commitment.

Determine the optimal account for purchasing the Savings Plan.

Purchase the Compute Savings Plan directly within Account A.

AWS billing consolidated billing logic applies Savings Plan discounts to the purchasing account's usage first. If purchased in the Management Account, the discount is distributed across the organization based on where it yields the highest discount, which could cause Account B's testing workloads to consume the commitment first.

Confirm sharing behavior for any excess commitment.

Enable Savings Plan sharing across the Organization.

Buying the plan in Account A prioritizes Account A's usage. If Account A has periods of lower usage, any excess commitment can still automatically scale to cover Account B's eligible workloads, maximizing the investment.

Key Concept

AWS Savings Plans application order and scope in consolidated billing environments.

Question 311Question →

A SysOps Administrator applied the tag key `CostCenter` to several Amazon EC2 instances and Amazon S3 buckets to track project expenditures. However, when analyzing costs, the `CostCenter` tag key does not appear as a filtering option in AWS Cost Explorer. Which two actions must the SysOps Administrator perform to resolve this issue and track costs by this tag? (Select TWO.)

Select all that apply

Activate the CostCenter tag in the AWS Billing and Cost Management console.

Wait up to 24 hours after activation for the tag to appear in AWS Cost Explorer.

Create an IAM policy that grants the Billing service permission to read resource tags on the S3 buckets and EC2 instances.

Enable resource tag synchronization in the AWS Cost Explorer settings.

Re-apply the tags in the AWS Organizations management account, because tags applied in member accounts cannot be used for cost allocation.

Show answer & explanation

Answer: Activate the CostCenter tag in the AWS Billing and Cost Management console.; Wait up to 24 hours after activation for the tag to appear in AWS Cost Explorer.

Answer

Activate the CostCenter tag in the AWS Billing and Cost Management console, and wait up to 24 hours for the activated tag to appear in AWS Cost Explorer.

To track costs using a custom resource tag, the tag must be activated in the AWS Billing and Cost Management console. Once activated, it can take up to 24 hours for AWS to update the billing dashboard and display the tag as a filter in AWS Cost Explorer.

Step-by-Step Solution

Access the AWS Billing and Cost Management console using credentials from the management account or an account with billing administration permissions.

The SysOps Administrator is authenticated and can manage billing-wide configurations.

Cost allocation tags must be activated from the Billing console, and in a multi-account environment, this is managed at the Organization payer/management account level.

Navigate to the Cost Allocation Tags page, search for the CostCenter tag key under the User-defined cost allocation tags tab, select it, and click Activate.

The tag is marked as active for cost allocation.

AWS does not automatically use standard resource tags for cost tracking; they must be explicitly activated to begin generating cost allocation metadata.

Allow up to 24 hours for the AWS Billing system to process the new tags and update Cost Explorer.

The CostCenter tag is indexed and becomes available as a filter and grouping dimension in AWS Cost Explorer.

AWS updates cost allocation tag data on a daily cycle, requiring a propagation period before the tags can be queried.

Key Concept

Standard resource tags applied to AWS resources do not automatically function as cost allocation tags. They must be explicitly activated within the AWS Billing and Cost Management console (typically in the management/payer account of an AWS Organization) before they can be used to filter or group costs in AWS Cost Explorer. Once activated, it can take up to 24 hours for the tags to be reflected in Cost Explorer.

Estimated Time:1m 30s

Question 312Question →

A SysOps administrator is troubleshooting a low cache hit ratio on an Amazon CloudFront distribution that serves content from an Application Load Balancer (ALB). The administrator observes that the distribution is forwarding all query string parameters and headers to the ALB origin, which causes identical content requests with different user-agent headers and tracking query strings to be cached as separate objects. The origin application only requires the session_id query string parameter to function correctly. Which configuration change will improve the cache hit ratio while ensuring the application still receives the required parameter?

Create a Canonical Name (CNAME) record in Amazon Route 53 at the zone apex that forwards the session_id query string parameter to the CloudFront distribution domain name.

Route all traffic from the CloudFront distribution through a NAT Gateway inside the VPC to strip out any query parameters other than the session_id parameter.

Configure a custom CloudFront Cache Policy that includes only the session_id query string parameter in the cache key, and associate this policy with the distribution's cache behavior.

Modify the Application Load Balancer target group health check settings to listen on a port that filters query parameters before traffic reaches the origin instances.

Show answer & explanation

Answer: Configure a custom CloudFront Cache Policy that includes only the session_id query string parameter in the cache key, and associate this policy with the distribution's cache behavior.

Answer

Configure a custom CloudFront Cache Policy that includes only the session_id query string parameter in the cache key, and associate this policy with the distribution's cache behavior.

The correct option is to configure a custom Cache Policy containing only the session_id query string parameter. Cache Policies determine the values (headers, cookies, and query strings) that make up the cache key. By limiting the cache key to only the session_id parameter, CloudFront ignores other variables like tracking parameters or User-Agent headers, thereby consolidating requests for identical objects into a single cache hit while still ensuring that session_id is forwarded to the origin.

Step-by-Step Solution

Identify which parameters must be included in the cache key to maximize cache hit efficiency while meeting application requirements.

Determine that only the session_id query string parameter should be part of the cache key, and all other headers and query strings must be ignored.

Including unnecessary headers (like User-Agent) or query strings (like tracking IDs) in the cache key makes otherwise identical requests unique, degrading the cache hit ratio.

Determine the appropriate CloudFront policy type that controls cache key composition.

Select a Cache Policy rather than an Origin Request Policy.

Cache Policies explicitly define what request values are included in the cache key and thus determine cacheability, whereas Origin Request Policies only control forwarding parameters without affecting the cache key.

Create and associate a custom Cache Policy containing the session_id query string parameter.

Apply the new Cache Policy to the relevant cache behavior of the CloudFront distribution.

This updates the cache behavior settings, instructing CloudFront edge locations to apply the new cache key logic to all incoming viewer requests.

Key Concept

CloudFront Cache Policies manage cache key composition to optimize cache hit ratios by controlling which headers, cookies, and query strings are included in cache lookups.

Question 313Question →

A company distributes a multilingual web application globally using an Amazon CloudFront distribution. The origin server requires the viewer's language preference and device type to return the correct localized version of the page. Currently, the CloudFront distribution has a cache policy that forwards the raw `User-Agent` and `Accept-Language` headers to the origin. A SysOps administrator reports that the cache hit ratio is less than 5% because of the high variance in these headers. Which combination of actions should the administrator take to improve the cache hit ratio while ensuring the origin still receives the correct localization and device information?

Move the User-Agent and Accept-Language headers from the cache policy to an origin request policy, and keep them removed from the cache policy.

Configure a Lambda@Edge function on the origin response event to overwrite the Cache-Control header to no-store, no-cache for all requests that include User-Agent or Accept-Language headers.

Configure a CloudFront Function on the viewer request event to normalize the Accept-Language header to a set of supported language codes and write the value to a new X-Language header. Update the cache policy to cache on the X-Language header and the CloudFront device detection headers (such as CloudFront-Is-Mobile-Viewer), while removing the raw User-Agent and Accept-Language headers.

Replace the CloudFront distribution's DNS record with a Route 53 CNAME record at the zone apex, and configure latency-based routing policies to bypass the cache for localized headers.

Show answer & explanation

Answer: Configure a CloudFront Function on the viewer request event to normalize the Accept-Language header to a set of supported language codes and write the value to a new X-Language header. Update the cache policy to cache on the X-Language header and the CloudFront device detection headers (such as CloudFront-Is-Mobile-Viewer), while removing the raw User-Agent and Accept-Language headers.

Answer

The correct option is correct because using a CloudFront Function on the viewer request event allows the incoming Accept-Language header to be normalized to a limited set of language codes (such as 'en', 'es', or 'fr') and mapped to a custom header. Caching on this custom header and the built-in device detection headers (which are normalized to boolean values) instead of the raw headers dramatically reduces cache key cardinality and improves the cache hit ratio while preserving the origin's ability to localize content.

Step-by-Step Solution

Identify the root cause of the low cache hit ratio.

The raw User-Agent and Accept-Language headers contain thousands of unique value combinations, causing CloudFront to treat almost every request as unique and forward it to the origin.

This establishes that high cardinality in the cache policy is responsible for the low cache hit ratio.

Select a solution for device type detection that minimizes cache key variation.

Use CloudFront's built-in device detection headers (like CloudFront-Is-Mobile-Viewer), which map complex User-Agent strings into simple boolean indicators.

This reduces the cardinality of the device-related cache key variations while still conveying the needed device information to the origin.

Normalize the Accept-Language header.

Write a lightweight CloudFront Function triggered on the viewer request event to normalize the Accept-Language header into a set of supported languages and store the normalized string in a new custom header (such as X-Language).

CloudFront Functions execute at the edge with sub-millisecond latency, making them ideal for simple header manipulation before the cache lookup occurs.

Update the cache configuration to use the normalized headers.

Modify the cache policy to include only the new X-Language header and the CloudFront device detection headers, and remove the raw User-Agent and Accept-Language headers from the cache key.

This ensures that CloudFront caches content based only on the few supported languages and device categories, dramatically increasing the cache hit ratio while ensuring the correct version is served.

Key Concept

CloudFront Cache Optimization using Header Normalization and Device Detection Headers

Question 314Question →

A SysOps Administrator is managing a multi-account AWS environment under a single organization in AWS Organizations. To track department spending, the administrator deploys a Tag Policy at the organization root that enforces the CostCenter tag on all Amazon EC2 instances. Several member accounts deploy new EC2 instances successfully, compliant with the policy. However, when the administrator runs a query in AWS Cost Explorer in the management account grouping by the CostCenter tag, all costs are grouped under the 'No tag key' category. What should the administrator do to ensure the cost data is properly categorized by the tag key in Cost Explorer?

Log in to the Billing and Cost Management console of the management account, navigate to Cost Allocation Tags, select the CostCenter tag, and click Activate.

Log in to the Billing and Cost Management console of each member account, navigate to Cost Allocation Tags, select the CostCenter tag, and click Activate.

Modify the Tag Policy at the organization root to set the 'CostAllocation' parameter to true for the CostCenter tag key.

Create an AWS Budgets rule in the management account targeting the CostCenter tag to trigger Cost Explorer to index the resource tags.

Show answer & explanation

Answer: Log in to the Billing and Cost Management console of the management account, navigate to Cost Allocation Tags, select the CostCenter tag, and click Activate.

Answer

Log in to the Billing and Cost Management console of the management account, navigate to Cost Allocation Tags, select the CostCenter tag, and click Activate.

The correct answer is to activate the tag in the management account. In AWS Organizations, billing features are consolidated under the management account. Newly created tags do not automatically become active for cost allocation; they must be manually activated in the Billing and Cost Management console of the management account before they appear in Cost Explorer.

Step-by-Step Solution

Identify where cost allocation tags are managed in a multi-account organization.

In AWS Organizations consolidated billing, cost allocation tags must be managed centrally from the management (payer) account.

Member accounts lack the permission to activate cost allocation tags for the organization's billing data.

Locate the Cost Allocation Tags settings within the management account.

Navigate to the Billing and Cost Management console and select the Cost Allocation Tags page.

This is the console section where resource tags are registered for billing reports.

Activate the user-defined tag key.

Select the CostCenter tag from the list of user-defined tags and click Activate.

Activating the tag key registers it so AWS can begin generating billing datasets grouped by that tag.

Key Concept

Activation of user-defined cost allocation tags in the management account of AWS Organizations is required before those tags are recognized and grouped in Cost Explorer.

Estimated Time:3m 0s

Question 315Question →

A SysOps administrator is configuring an Amazon CloudFront distribution to serve static content from an Amazon S3 bucket. The administrator must secure the content so that viewers can only access the files through CloudFront, preventing direct access to the S3 bucket. Which action should the administrator take to meet this security requirement?

Enable origin access control (OAC) on the CloudFront distribution and update the S3 bucket policy to allow read access to the CloudFront service principal.

Configure an Elastic Load Balancing health check on the S3 bucket to verify that only CloudFront requests are accepted, routing traffic to a backup bucket if access is direct.

Attach an IAM policy to the CloudFront distribution that uses the iam:PassRole action to delegate access to the S3 bucket.

Set up an S3 Gateway Endpoint in the VPC and associate it with the subnet route tables used by CloudFront edge locations to bypass the public internet.

Show answer & explanation

Answer: Enable origin access control (OAC) on the CloudFront distribution and update the S3 bucket policy to allow read access to the CloudFront service principal.

Answer

Enable origin access control (OAC) on the CloudFront distribution and update the S3 bucket policy to allow read access to the CloudFront service principal.

Enabling origin access control (OAC) on the CloudFront distribution and updating the S3 bucket policy to allow read access to the CloudFront service principal restricts direct S3 access. OAC signs the requests sent to S3 using AWS Signature Version 4, and the bucket policy permits access only when the request is signed by the designated CloudFront distribution.

Step-by-Step Solution

Configure the CloudFront distribution origin settings by enabling Origin Access Control (OAC) for the S3 origin.

CloudFront will begin signing all requests to the S3 origin using the CloudFront service principal credentials.

This establishes the identity framework that allows S3 to verify that incoming requests are coming from the designated CloudFront distribution.

Modify the S3 bucket policy to allow 's3:GetObject' action where the principal is the CloudFront service principal ('cloudfront.amazonaws.com') and the condition specifies the ARN of the CloudFront distribution.

The S3 bucket will allow requests initiated by the CloudFront distribution while rejecting all other direct requests.

This enforces the security boundary by validating the signature generated by CloudFront and blocking anonymous or direct access.

Key Concept

Securing an Amazon S3 origin using CloudFront Origin Access Control (OAC)

Question 316Question →

A SysOps Administrator is configuring a VPC Flow Log to capture network traffic from a subnet and deliver it to an Amazon CloudWatch Logs log group. The administrator has already created the target log group and an IAM role with the necessary permissions for the VPC Flow Logs service to publish logs. However, during the creation process, the administrator receives an 'Access Denied' error. In addition, the administrator wants to ensure that the logs do not persist indefinitely to manage storage costs.

Which of the following actions should the administrator take to resolve the error and manage log retention? (Select TWO.)

Select all that apply

Add the iam:PassRole permission to the IAM policy of the user creating the flow log, referencing the flow log IAM role.

Configure a retention period on the CloudWatch Logs log group in the CloudWatch console.

Add the iam:PassRole permission directly to the trust policy of the flow log IAM role.

Specify a log retention period in the VPC Flow Log configuration settings during creation.

Enable detailed monitoring on the EC2 instances in the subnet to automatically archive flow logs after 14 days.

Show answer & explanation

Answer: Add the iam:PassRole permission to the IAM policy of the user creating the flow log, referencing the flow log IAM role.; Configure a retention period on the CloudWatch Logs log group in the CloudWatch console.

Answer

Add the iam:PassRole permission to the IAM policy of the user creating the flow log, referencing the flow log IAM role, and configure a retention period on the CloudWatch Logs log group in the CloudWatch console.

To resolve the Access Denied error, the user creating the flow log must be granted the `iam:PassRole` permission in their IAM policy for the role that the VPC Flow Logs service will assume. To control log storage costs, a retention period must be configured on the CloudWatch Logs log group since the default setting is to keep logs indefinitely.

Step-by-Step Solution

Analyze the 'Access Denied' error during flow log creation.

Identify that the administrator's IAM identity lacks the permission to pass the flow log service role to the VPC Flow Logs service.

VPC Flow Logs requires the user to have iam:PassRole permissions on the IAM role being passed to the service.

Address the log storage cost requirement.

Determine that logs should have a configured expiration policy rather than remaining indefinitely.

By default, CloudWatch log groups retain logs indefinitely. Setting a retention policy deletes old log events and limits ongoing storage fees.

Combine the resolutions into the final answer.

Select the option to add the iam:PassRole permission to the creator's IAM policy and the option to configure a retention period on the target CloudWatch Logs log group.

These two steps directly resolve the permission block and address the cost requirement.

Key Concept

Configuring VPC Flow Logs requires proper IAM permissions (such as iam:PassRole) to allow the flow logs service to assume the logging role, while cost management for CloudWatch Logs requires setting log group retention periods.

Question 317Question →

An administration team needs to secure a collection of premium media files delivered via an Amazon CloudFront distribution. The media files are stored in a private Amazon S3 bucket and encrypted using an AWS KMS customer managed key. The security requirements state that the S3 bucket must not be publicly accessible, and access to the files must be restricted to authorized subscribers. Additionally, subscribers must be able to view multiple files in a single session without changing the application's current URL paths.

Which combination of configurations will meet these requirements? (Select TWO.)

Select all that apply

Configure the CloudFront distribution to use signed cookies, and update the application to set these cookies in the user's browser.

Configure the CloudFront distribution to use Origin Access Control (OAC), and update both the S3 bucket policy and the KMS key policy to allow the CloudFront service principal access.

Configure the CloudFront distribution to use Origin Access Identity (OAI), and update both the S3 bucket policy and the KMS key policy to allow the OAI access.

Configure the CloudFront distribution to use signed URLs, and configure the application to generate a unique signed URL for every media file request.

Configure the CloudFront origin settings to assume an IAM role with S3 and KMS permissions, and attach a trust policy allowing CloudFront to assume the role.

Show answer & explanation

Answer: Configure the CloudFront distribution to use signed cookies, and update the application to set these cookies in the user's browser.; Configure the CloudFront distribution to use Origin Access Control (OAC), and update both the S3 bucket policy and the KMS key policy to allow the CloudFront service principal access.

Answer

The correct configurations are to use signed cookies to restrict access to multiple files without altering URLs, and to use Origin Access Control (OAC) while updating both the S3 bucket policy and the KMS key policy to allow access to the CloudFront service principal.

To secure premium files stored in S3 and encrypted with SSE-KMS while maintaining the same URL paths for multiple files, the SysOps administrator must configure CloudFront signed cookies and Origin Access Control (OAC). Signed cookies allow users to access multiple premium files in a single session without modifying individual resource URLs, which would be required if signed URLs were used. Furthermore, OAC is the only origin access method that supports S3 buckets encrypted with custom KMS keys (SSE-KMS). The KMS key policy must be updated to grant the CloudFront service principal (cloudfront.amazonaws.com) permission to decrypt the objects using the key.

Step-by-Step Solution

Analyze the access restriction requirements.

Identify that signed cookies are required because the subscribers need access to multiple files without changing the application's URL paths.

Signed URLs require modifying URLs for individual resources, whereas signed cookies allow access to multiple files under a directory or pattern using the same URL paths.

Determine the origin security and encryption requirements.

Identify that Origin Access Control (OAC) must be used instead of Origin Access Identity (OAI) since the S3 bucket is encrypted with an AWS KMS customer managed key.

OAI does not support SSE-KMS encrypted origins, whereas OAC allows CloudFront to sign requests to KMS and decrypt encrypted S3 objects.

Determine the policy updates needed for KMS-encrypted S3 with OAC.

Identify that both the S3 bucket policy and the KMS key policy must explicitly allow the CloudFront service principal (cloudfront.amazonaws.com) to perform s3:GetObject and kms:Decrypt operations.

By default, CloudFront cannot decrypt KMS-encrypted S3 objects without explicit permission granted in the key policy for the CloudFront service principal.

Key Concept

CloudFront Private Content Security and KMS-Encrypted Origins

Question 318Question →

A SysOps Administrator has configured an Amazon VPC Traffic Mirroring session to send traffic from an Amazon EC2 instance (source) to an appliance instance (target) for deep packet inspection. The administrator notices that the target appliance is not receiving any mirrored packets. Which of the following configuration issues could cause this problem? (Select TWO.)

Select all that apply

The security group associated with the traffic mirror target network interface does not allow inbound traffic on UDP port 4789.

The Network ACL of the subnet where the traffic mirror target resides does not allow inbound traffic on UDP port 4789.

The IAM policy attached to the SysOps Administrator's role lacks the iam:PassRole permission for the traffic mirror target's service role.

The Amazon CloudWatch Logs log group associated with the mirror target has a log retention period that has expired, preventing log creation.

The Network ACL rules for the traffic mirror source subnet block outbound ephemeral port traffic (1024-65535) needed to send VXLAN packets.

Show answer & explanation

Answer: The security group associated with the traffic mirror target network interface does not allow inbound traffic on UDP port 4789.; The Network ACL of the subnet where the traffic mirror target resides does not allow inbound traffic on UDP port 4789.

Answer

The target network interface's security group and target subnet's Network ACL must allow inbound UDP port 4789 traffic.

VPC Traffic Mirroring copies network packets from a source ENI and routes them to a target ENI or Network Load Balancer using VXLAN encapsulation, which uses UDP port 4789. Because the target instance must receive these encapsulated packets, its stateful security group must permit inbound UDP port 4789. In addition, since Network ACLs are stateless, the NACL associated with the target subnet must also explicitly allow inbound traffic on UDP port 4789.

Step-by-Step Solution

Identify the protocol and port used by Amazon VPC Traffic Mirroring to encapsulate copied network traffic.

VPC Traffic Mirroring encapsulates raw packets inside VXLAN (UDP port 4789) headers.

This determines which security rules and ports must be opened on the path and at the target.

Evaluate the stateful security controls of the target network interface.

The target's security group must permit inbound UDP port 4789 traffic.

Stateful security groups evaluate incoming traffic and will drop VXLAN packets if port 4789 is not explicitly allowed.

Evaluate the stateless security controls of the target subnet.

The Network ACL (NACL) for the target's subnet must explicitly permit inbound UDP port 4789 traffic.

Stateless NACLs evaluate traffic at the subnet boundary and must allow the VXLAN traffic port explicitly.

Key Concept

VPC Traffic Mirroring relies on VXLAN encapsulation on UDP port 4789, requiring both target security groups and Network ACLs to permit this inbound traffic.

Question 319Question →

A company manages a multi-account environment using AWS Organizations with consolidated billing enabled. The SysOps administrator is reviewing the compute usage for the following workloads:

* Production Account: A steady-state fleet of $10$ Amazon EC2 $m7g.xlarge$ instances running $24/7$ in the $us-west-2$ Region, and a dynamically scaling web application running on Amazon ECS with AWS Fargate.
* Development Account: A fleet of $t4g.medium$ EC2 instances that are shut down outside of business hours, and various AWS Lambda functions for sporadic testing.

The company wants to implement a cost optimization strategy that maximizes savings while providing flexibility for the scaling and serverless workloads.

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

Select all that apply

Purchase an EC2 Instance Savings Plan in the production account for the

m7g

instance family in

us-west-2

Purchase a Compute Savings Plan in the management account to cover the AWS Fargate tasks and AWS Lambda functions.

Purchase an EC2 Instance Savings Plan to cover both the

m7g

instances and the AWS Fargate tasks in the production account.

Purchase regional Standard Reserved Instances to cover the AWS Lambda functions in the development account.

Purchase an EC2 Instance Savings Plan in the development account for the

t4g

instance family to cover the development instances.

Show answer & explanation

Answer: Purchase an EC2 Instance Savings Plan in the production account for the $m7g$ instance family in $us-west-2$ .; Purchase a Compute Savings Plan in the management account to cover the AWS Fargate tasks and AWS Lambda functions.

Answer

Purchasing an EC2 Instance Savings Plan for the m7g family in us-west-2 to cover the steady-state EC2 instances, and purchasing a Compute Savings Plan to cover the Fargate and Lambda workloads.

Purchasing an EC2 Instance Savings Plan for the m7g family in us-west-2 provides the highest discount for the 24/7 production EC2 instances. Purchasing a Compute Savings Plan provides the required flexibility to automatically cover the scaling AWS Fargate tasks and the sporadic AWS Lambda functions across any region or instance type.

Step-by-Step Solution

Analyze the workload characteristics of each account.

The production EC2 instances are steady-state (running 24/7) in a single region (us-west-2) and family (m7g). The Fargate and Lambda workloads are dynamic and serverless.

Identifying workload patterns helps determine whether to prioritize commitment flexibility or maximum savings rate.

Evaluate the scope of EC2 Instance Savings Plans.

EC2 Instance Savings Plans offer up to 72% discount and apply to a specific instance family in a specific region, which fits the production EC2 fleet perfectly but cannot cover Fargate or Lambda.

This matches the steady-state production EC2 fleet requirements for maximum cost optimization.

Evaluate the scope of Compute Savings Plans.

Compute Savings Plans offer up to 66% discount and apply automatically to EC2, Fargate, and Lambda across any region or instance family.

This covers the dynamically scaling Fargate tasks and sporadic Lambda functions where operational flexibility is required.

Key Concept

Selecting the optimal combination of Compute Savings Plans and EC2 Instance Savings Plans based on workload stability and compute service types.

Question 320Question →

An organization uses AWS Organizations with consolidated billing. A SysOps administrator enforces a tag policy across all member accounts to ensure all Amazon EC2 instances are tagged with `InitiativeID` for tracking project costs. After verifying that the member accounts have compliant resources with the `InitiativeID` tag applied, the administrator attempts to create a cost-budget in the management account but finds that `InitiativeID` is missing from the tag filter list in the AWS Budgets console. Which action must the administrator perform to resolve this issue?

Navigate to the Cost Allocation Tags section in the management account's Billing and Cost Management console, select the `InitiativeID` tag, and click Activate.

Access the Billing and Cost Management console of each individual member account, locate the Cost Allocation Tags list, and activate the `InitiativeID` tag.

Update the tag policy JSON document in AWS Organizations to include a boolean parameter that marks the `InitiativeID` tag as active for billing.

Wait for the next invoicing cycle to run, allowing the AWS Billing service to discover and populate the `InitiativeID` tag dynamically.

Show answer & explanation

Answer: Navigate to the Cost Allocation Tags section in the management account's Billing and Cost Management console, select the `InitiativeID` tag, and click Activate.

Answer

The administrator must navigate to the Cost Allocation Tags section in the management account's Billing and Cost Management console, select the `InitiativeID` tag, and activate it.

The correct action is to navigate to the Cost Allocation Tags section in the management account's Billing and Cost Management console, select the `InitiativeID` tag, and click Activate. In a multi-account environment consolidated under AWS Organizations, only the management account can manage and activate cost allocation tags. Additionally, user-defined tags are never activated for cost allocation automatically upon creation or policy application; they require manual activation in the Billing console before they can be used as filters in tools like AWS Budgets and Cost Explorer.

Step-by-Step Solution

Determine where cost allocation tags are managed in a multi-account setup.

Identify that in AWS Organizations, cost allocation tags for consolidated billing must be managed and activated in the management (payer) account.

Member accounts do not have the authority to activate cost allocation tags for the consolidated billing family.

Identify the difference between applying tags / enforcing tag policies and activating them for cost allocation.

Realize that applying tags to resources or enforcing them via AWS Organizations tag policies is separate from cost allocation tracking. User-defined tags must be explicitly activated in the Billing console to be used in Cost Explorer, AWS Budgets, or billing reports.

AWS does not automatically track costs by new user-defined tags to prevent billing data clutter and performance overhead.

Formulate the correct configuration step.

Access the Billing and Cost Management console of the management account, go to Cost Allocation Tags, select the `InitiativeID` tag under user-defined cost allocation tags, and activate it.

This registers the tag key for cost tracking, making it available as a filter in AWS Budgets and Cost Explorer within 24 hours.

Key Concept

Activation of User-Defined Cost Allocation Tags in AWS Organizations

Estimated Time:1m 30s

PreviousPage 16 / 49Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Alternative Method

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution