Amazon Practice Questions, Discussions & Exam Topics by our Authors
A SysOps administrator must ensure that all of a company's current and future Amazon S3 buckets have logging enabled. If an S3 bucket does not have logging enabled, an automated process must...
To ensure that all current and future Amazon S3 buckets have logging enabled, we need a solution that automates the process of checking for logging status and enabling it if not already enabled. Let's evaluate each option to determine which one best meets the requirements.
Option A: Use AWS Trusted Advisor to perform a check for S3 buckets that do not have logging enabled. Configure the check to enable logging for S3 buckets that do not have logging enabled.
- Reasoning: AWS Trusted Advisor is a service that provides recommendations for best practices, including checking S3 buckets for logging status. However, Trusted Advisor does not provide a direct option to automatically remediate issues, such as enabling logging for buckets that don't have it enabled. Trusted Advisor provides alerts and suggestions but requires manual intervention to apply changes.
- Why not others? This option only alerts you to non-compliant buckets but does not automate the remediation process of enabling logging for them, which is a key requirement in this case.
Option B: Configure an S3 bucket policy that requires all current and future S3 buckets to have logging enabled.
- Reasoning: While an S3 bucket policy can enforce certain rules about the access permissions for objects within a bucket, it cannot enforce logging to be enabled for the bucket. Bucket policies are used for controlling access and permissions, but they don't have the capability to manage logging configurations.
- Why not others? This option is not appropriate because a bucket policy doesn't control logging behavior, so it won't help automate enabling logging for all S3 buckets.
Option C: Use the s3-bucket-logging-enabled AWS Config managed rule. Add a remediation action that uses an AWS Lambda function to enable logging.
- Reasoning: The AWS Config managed rule s3-bucket-logging-enabled is designed to monitor whether S3 buckets have logging enabled. By adding a remediation action ...
Author: Sam · Last updated Jul 17, 2026
A company's applications run on Amazon EC2 instances and use AWS Lambda functions in multiple AWS accounts. All EC2 instances have the Amazon CloudWatch agent installed. All accounts belong to the same organization in AWS Organizations. The company has created a dedicated central log account.
All logs that the applications produce must be sent to a centr...
The key to this question is identifying the AWS service designed for centralized logging across multiple AWS accounts while minimizing administration.
Key requirements
Applications run on:
Amazon EC2 (CloudWatch Agent already installed)
AWS Lambda
Multiple AWS accounts
Accounts are in the same AWS Organizations organization
Dedicated central logging account
Logs must be centralized
Encryption must use customer-managed keys (CMKs)
Least operational overhead
---
Analyze each option
✅ Option A
> In the central log account, enable CloudWatch Logs as the data source. Add the organization ID. Deploy the CloudWatch StackSet for central monitoring.
What this is
This is CloudWatch cross-account observability (centralized monitoring).
AWS provides:
Organization-wide onboarding
CloudFormation StackSet
Automatic sharing from organization accounts
Minimal manual configuration
Why it satisfies the requirements
✔ Centralized logs
CloudWatch Logs from all accounts become visible in the monitoring account.
✔ Works with EC2
CloudWatch Agent already sends logs.
✔ Works with Lambda
Lambda automatically writes to CloudWatch Logs.
✔ AWS Organizations integration
Instead of configuring every account manually, you onboard the Organization once.
✔ Least operational overhead
AWS manages the sharing.
No Firehose per account.
No custom Lambda.
No S3 event processing.
No subscription filters everywhere.
✔ Encryption
CloudWatch Logs log groups support customer-managed KMS keys, satisfying the encryption requirement.
---
Key exam clue
Whenever you see
AWS Organizations
Central monitoring
CloudWatch Logs
Least operational overhead
Think:
> CloudWatch Cross-Account Observability
This is exactly what AWS designed for this use case.
---
❌ Option B
> One Firehose in central account. Store subscription ARN in Parameter Store for every project.
Problems
Firehose cannot magically receive logs from every account.
Each account must create:
subscription filters
permissions
configuration
The option even says
> Store subscription ARN in Parameter Store for each project
That means every project must configure its own logging.
Higher operational overhead.
Also, CloudWatch Logs subscriptions are created on the source log groups, not centrally.
---
Why rejected
Manual setup in every project
Subscription filters everywhere
Parameter Store coordination
More maintenance
---
When would this be used?
Use when
exporting logs into S3
building a data lake
analytics wit...
Author: Manish · Last updated Jul 20, 2026
A company uses Amazon Elastic Kubernetes Services (Amazon EKS) to host containerized applications that are available in Amazon Elastic Container Registry (Amazon ECR).
The company currently launches EKS clusters in the company's development environment by using the AWS CLI aws eks create-cluster command. The company uses the aws eks create-addon command to install required add-ons. All installed add-ons are currently version compatible with the version of Kubernetes that the company uses. All clusters exclusively use managed node groups for compute capacity...
Let’s carefully analyze this scenario with exam-style reasoning.
---
Requirement Recap
- Company uses Amazon EKS with managed runtimes and managed node groups.
- Clusters created via `aws eks create-cluster` and add-ons installed via `aws eks create-addon`.
- Need to upgrade EKS clusters continuously within the AWS standard support schedule.
- Goal: least operational overhead.
---
Option Analysis
A) Run `aws eks update-cluster-version` manually
- Pros: Directly upgrades cluster version.
- Cons: Manual process → requires ongoing human intervention. Does not ensure continuous upgrades within AWS support schedule.
- Rejected: Too much operational overhead.
---
B) Enable EKS Auto Mode and remove managed node groups
- Pros: EKS Auto Mode automatically manages upgrades, scaling, and add-ons. Ensures clusters stay within AWS support schedule.
- Cons: Requires migration from managed node groups to Auto Mode, but once enabled, it drastically reduces operational ove...
Author: SolarFalcon11 · Last updated Jul 20, 2026
A company uses a pipeline in AWS CodePipeline to upload AWS CloudFormation templates to an Amazon S3 bucket. The pipeline uses the templates to deploy CloudFormation stacks that match the names of the templates.
The company has experienced issues when it tries to revert templates to a previous version. To prevent these issues, the company must have the ability to revie...
The key requirements are:
1. Prevent issues when reverting templates to previous versions → Need version control.
2. Review template modifications before deployment to production → Need an approval/review mechanism.
3. Least operational overhead → Prefer managed AWS services instead of custom automation.
Let's evaluate each option.
---
Option A
> Configure AWS CodeConnections to a Git repository. Store templates in Git. Configure a pull request workflow to review modifications. Configure CloudFormation Git sync for the stacks.
Key factors
✅ Git provides version history and rollback.
✅ Pull Requests (PRs) provide code review before merge.
✅ CloudFormation Git sync automatically updates stacks from Git.
Why it's attractive
This creates a GitOps workflow:
```
Developer
↓
Git Branch
↓
Pull Request Review
↓
Merge
↓
CloudFormation Git Sync
↓
Deploy Stack
```
Why it is NOT the best answer
Notice the requirement:
> review modifications before modifications are deployed to production
CloudFormation Git sync deploys automatically after a PR is merged into the configured branch.
There is no explicit production approval stage inside the deployment pipeline.
Also, Git sync is mainly intended for synchronizing CloudFormation stacks directly with Git repositories—not integrating with an existing CodePipeline that the company already uses.
AWS exam key point:
Git PR approval ≠ deployment approval.
Therefore this is not the best fit.
---
Option B
> Add a manual review action in the pipeline.
Key factors
Manual approval:
```
Pipeline
↓
Deploy?
↓
Manual Approval
↓
Continue
```
Advantages
✅ Very easy
✅ Built into CodePipeline
✅ No custom code
Why it is rejected
The company's current pipeline uploads templates directly to S3.
The problem statement also says:
> experienced issues when trying to revert templates to previous versions
Adding manual approval does not solve version management.
There is still no source control.
You can approve bad code.
You still cannot easily compare versions.
Requirement isn't only approval.
It also implies proper versioning.
---
Option C
> Invoke a Lambda function to check template modifications.
Key factors
Pipeline
```
Upload
↓
Lambda
↓
Deploy
```
Advantages
Lambda could:
lint templates
compare changes
enforce naming rules
validate policies
Why rejected
Requirement says:
> ability to review template modifications
A Lambda performs automated validation, not human review.
Also:
more operational overhead
custom code
maintenance
testing
AWS exams almost always reject Lambda when a managed feature exists.
---
Option D ✅
> Configure CodeConnections to a Git repository. Store templates in Git. Configure CodePipeline source action from Git. Add a manual approval action before deployment.
Pipeline becomes:
```
Git Repository
↓
CodeConnections
↓
CodePipeline
↓
Manual Approval
↓
Deploy CloudFormation
```
Why this satisfies every req...
Author: FlamePhoenix2025 · Last updated Jul 20, 2026
A company manages environments for its application in multiple AWS accounts. Each environment account is in a different OU in AWS Organizations.
A DevOps team is responsible for the application deployment process across the environments. The deployment process uses an AWS CodePipeline pipeline in a Shared Services account. The DevOps team members are in the same user group. The team members have administrative access to all accounts through AWS IAM Identity Center.
A recent deployment problem in the development environment required the DevOps team to perform manual steps. The deployment to the production environment then resulted in an incident that caused the pipeline to fail, which blocked new depl...
Key requirements
Let's extract the important requirements first.
1. Only the pipeline can perform deployments in production. ✅ (Most important)
2. DevOps team should NOT be able to manually deploy to production.
3. One DevOps engineer must still have emergency (break-glass) access.
4. Solution should be operationally efficient.
5. Pipeline is running from a Shared Services account.
6. Production account is in a separate OU under AWS Organizations.
---
Evaluate each option
Option A
> Update the DevOps group to ReadOnlyAccess for production. Give the DevOps engineer AdministratorAccess and permission to assume the pipeline role. Add an SCP that denies modification of resources by any entity other than the pipeline role.
What happens?
Entire DevOps group becomes read-only in Production.
Only one engineer gets AdministratorAccess.
SCP allows only the pipeline role to modify resources.
Even AdministratorAccess cannot bypass an SCP.
Therefore:
DevOps team cannot manually deploy. ✅
Pipeline can deploy. ✅
Engineer has admin permissions for investigation.
If an emergency occurs, engineer can assume the pipeline role to perform deployments through the same trusted deployment identity.
This preserves the requirement:
> Only the pipeline role performs deployments.
The engineer isn't deploying as themselves—they are using the pipeline role.
Why this is good
This follows AWS security best practices:
SCP provides organization-wide guardrails.
ReadOnlyAccess prevents accidental changes.
Pipeline role remains the only deployment identity.
Break-glass access exists.
Key reasoning
Notice the wording:
> only the pipeline can perform deployments
The engineer is allowed to assume the pipeline role, meaning deployments still happen via the pipeline identity.
This exactly satisfies the requirement.
✅ Meets every requirement.
---
Option B
> SCP denies all write actions for DevOps team members. Create another IAM Identity Center user for the engineer with AdministratorAccess. Add SCP denying modification except pipeline role.
Looks attractive, but there's a problem.
The first SCP denies writes only for DevOps team members.
The engineer uses another Identity Center user.
That user is not a DevOps team member, so the first SCP doesn't affect it.
The second SCP says only pipeline role can modify resources.
Now the engineer's AdministratorAccess is blocked by the SCP.
Question requirement:
> engineer must have emergency access
This solution doesn't explain how the engineer bypasses the SCP or assumes the pipeline role.
Therefore emergency access is effectively lost.
Also:
Creating a second user just for emergencies is operational overhead.
Why rejected
Break-glass access not properly implemented.
Extra user management.
Doesn't mention assuming pipeline role.
❌ Reject.
---
Option C
> DevOps group can assume the pipeline role. Engineer has AdministratorAccess. SCP denies modification except DevOps engineer.
This directly violates the requirement.
The SCP says:
> only DevOps engineer can modify resources
But the requirement says:
> only pipeline can deploy
Now the engineer can deploy directly.
Also, the DevOps group can assume the pipeline role.
This...
Author: Mia · Last updated Jul 20, 2026
A company builds container images and stores them on Amazon Elastic Container Registry (Amazon ECR) in the company's primary AWS Region.
A DevOps engineer wants to replicate all the company's ECR repository images to a secondary Region. The DevOps engineer creates a new ECR repository in the secondary Region and configure...
The correct answer is A.
Key facts to recognize
The question contains two important clues:
"Replicate all the company's ECR repository images to a secondary Region."
"DevOps engineer creates a new ECR repository in the secondary Region and configures permission on the new repository to allow replication."
The tricky part is understanding how Amazon ECR cross-Region replication works.
Important AWS fact
When you enable ECR cross-Region replication, it only replicates new image pushes after the replication rule is created.
Existing images are NOT copied automatically.
Therefore, to have all images in the secondary Region:
1. Existing images must be copied manually (pull → push).
2. Future images should be replicated automatically using an ECR replication rule.
This is exactly what Option A does.
---
Option A
> Pull the existing primary ECR images and then push the images to the secondary ECR repository. Create a replication rule on the primary ECR registry to replicate the images to the secondary ECR registry.
Why it is correct
It satisfies both requirements.
Existing images
Since replication rules don't copy old images, manually:
Pull image
Tag image
Push to secondary repository
This copies everything already stored.
Future images
After creating the replication rule,
every new image pushed into the primary registry is automatically replicated.
No future manual work.
Operational efficiency
Very high.
Manual work happens only once for historical images.
After that AWS handles everything.
---
Why Option B is wrong
> Pull existing images and push them to the secondary repository. Configure permission on the primary registry to allow access from the secondary Region.
Good part
✔ Existing images get copied.
Problem
There is no replication rule.
Future pushes are not replicated automatically.
Someone would have to manually copy every new image forever.
Key factor
Permission alone does not perform replication.
Permissions only allow actions.
They never trigger automatic copying.
---
Why Option C is wrong
> Configure permission on the primary registry. Create a replication rule.
Looks attractive because it uses replication.
But notice what is missing.
There is no manual copy of existing images.
Remember:
> ECR re...
Author: Vivaan · Last updated Jul 20, 2026
A company is experiencing failures in its AWS CodeDeploy deployments for a critical application. The application is deployed on Amazon EC2 instances. A DevOps engineer must analyze the failed deployments to identify the root cause of the fai...
The correct answer is:
C) Use Amazon CloudWatch Logs to review application logs. Analyze CodeDeploy deployment logs in the /opt/codedeploy-agent/deployment-root/ directory on the EC2 instances. Use AWS X-Ray to trace requests through the application components.
---
Key requirement in the question
Keywords
AWS CodeDeploy deployments are failing
Application deployed on Amazon EC2
Need to analyze failed deployments
Identify the root cause
The question is specifically asking about deployment troubleshooting, not infrastructure monitoring or security analysis.
For CodeDeploy deployment failures, AWS recommends checking:
1. CodeDeploy agent logs
2. Deployment lifecycle event logs
3. Application logs
4. Hook script outputs (BeforeInstall, AfterInstall, ApplicationStart, ValidateService, etc.)
Option C directly targets these.
---
Option C (Correct)
> Use Amazon CloudWatch Logs to review application logs. Analyze CodeDeploy deployment logs in the /opt/codedeploy-agent/deployment-root/ directory on the EC2 instances. Use AWS X-Ray to trace requests through the application components.
Why it is correct
Key Factor 1: CodeDeploy deployment logs
The CodeDeploy agent stores deployment information under:
```
/opt/codedeploy-agent/deployment-root/
```
This contains:
lifecycle event logs
hook execution results
script outputs
deployment history
These logs usually reveal:
BeforeInstall failed
AfterInstall script exited with non-zero status
ValidateService failed
permissions issue
missing dependency
script timeout
These are exactly what you need for deployment failures.
---
Key Factor 2: CloudWatch Logs
Application logs may contain:
startup failures
configuration issues
dependency failures
runtime exceptions
Sometimes deployment succeeds but application startup fails.
CloudWatch Logs is the standard service to centralize these logs.
---
Key Factor 3: X-Ray
While X-Ray is mainly used for request tracing after deployment, it can help identify issues in application components if the deployment introduced runtime problems.
Although not essential for deployment itself, it is still relevant to application troubleshooting.
---
Why the other options are wrong
---
Option A
> Configure VPC Flow Logs...
Why rejected
VPC Flow Logs
These record:
source IP
destination IP
ports
allowed/denied traffic
They do not record deployment failures.
Useful when:
application cannot reach database
security groups block traffic
networking issues
Not useful for:
BeforeInstall failure
AfterInstall failure
ValidateService failure
deployment script errors
---
Amazon Inspector
Inspector checks:
vulnerabilities
CVEs
package issues
software exposure
It does not diagnose CodeDeploy failures.
---
Amazon Detective
Detective analyzes:
security investigations
suspicious activity
threat analysis
Deployment failures are not security incidents.
---
Scenario where Option A is appropriate
Use when:
deployment succeeds
application cannot communicate across VPC
suspected networking issue
security investigation
Not deployment debugging.
---
Option B
> Enable detaile...
Author: Noah · Last updated Jul 20, 2026
A company has developed a web application that conducts seasonal sales on public holidays. The web application is deployed on AWS and uses AWS services for storage, database, computing, and encryption. During seasonal sales, the company expects high network traffic from a large number of users. The company must receive insights regarding any unexpected behavior during the sale.
A DevOps team wants to review the insights upon detecting anomalous behaviors during the sale. The DevOps team wants to receive recommended actions to resolve the anomalous beha...
The key to this question is identifying what AWS service provides anomaly detection with recommendations and how the team is notified with the least operational overhead.
Key requirements
Web application running on AWS.
Heavy traffic during seasonal sales.
Detect unexpected/anomalous behavior.
DevOps team wants to review insights.
Team wants recommended actions to resolve issues.
Recommendations should be about the AWS infrastructure.
Least operational overhead.
The phrase "recommended actions" is the biggest clue.
The AWS service designed specifically for this is Amazon DevOps Guru.
---
Option A ✅ (Correct)
> Enable Amazon DevOps Guru in the AWS account. Determine the coverage for DevOps Guru for all supported AWS resources in the account. Use the DevOps Guru dashboard to find the analysis, recommendations, and related metrics.
Why this is correct
Amazon DevOps Guru:
Uses ML to detect anomalies.
Monitors supported AWS resources automatically.
Correlates metrics, logs, and events.
Provides:
Insights
Root-cause analysis
Related CloudWatch metrics
Recommendations to fix the issue
Recommendations to prevent future occurrences
This directly satisfies:
✔ Detect anomalies
✔ Review insights
✔ Infrastructure recommendations
✔ Least operational overhead
No custom analytics need to be built.
---
Key factor
Whenever the exam mentions:
anomaly detection
operational issues
root cause
recommendations
AWS infrastructure
Think:
> Amazon DevOps Guru
---
Option B ✅ (Correct)
> Create an Amazon SNS topic. Configure Amazon DevOps Guru to send notifications about important events to the company when anomalies are identified.
Why this is correct
Detecting anomalies alone is not enough.
The question says:
> "The DevOps team wants to receive insights upon detecting anomalous behaviors."
DevOps Guru integrates directly with SNS.
Flow:
```
Infrastructure
↓
DevOps Guru detects anomaly
↓
Creates Insight
↓
SNS Notification
↓
DevOps team reviews dashboard
```
Very little operational effort.
---
Key factor
Whenever AWS asks:
> notify team when DevOps Guru detects issues
Use
DevOps Guru + SNS
---
Option C ❌ (Rejected)
> Store CloudWatch logs, CloudTrail, Config data in S3 → Athena → QuickSight
This builds an entire analytics platform.
Problems:
Manual data lake
Manual Athena queries
Manual dashboard creation
No ML anomaly detection
No infrastructure recommendations
High operational overhead
The question explicitly asks for:
> least operational overhead
This solution is the opposite.
---
When is Option C used?
Use this architecture when:
Long-term log analytics
Compliance reporting
Security investigations...
Author: SolarFalcon11 · Last updated Jul 20, 2026
A DevOps engineer needs to design a cloud-based solution to standardize deployment artifacts for AWS Cloud deployments and on-premises deployments. There is currently no routing traffic between the on-premises data center and the AWS environment.
The solution must be able to consume downstream packages from public repositories and must be highly available. Data must be encrypted in transit and at rest. The solution must store the deployment artifacts in object storage and deploy the deployment artifacts into Amazon Elastic Container Service (Amazon ECS)....
The key to solving AWS exam questions is to identify the hard requirements first and eliminate options that violate even one requirement.
Step 1: Identify the key requirements
| Requirement | Important? | Impact |
| -------------------------------------------------------- | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
| Standardize deployment artifacts for AWS and on-premises | Yes | Need a common artifact repository |
| No existing connectivity between on-premises and AWS | Yes | Need connectivity solution |
| Consume downstream packages from public repositories | Yes | Repository should proxy external repositories |
| Highly available | Yes | Avoid single points of failure |
| Encrypt in transit and at rest | Yes | Built-in encryption preferred |
| Store deployment artifacts in object storage | Yes | Artifact storage should ultimately be backed by object storage (managed services like CodeArtifact use durable AWS storage internally) |
| Deploy artifacts into Amazon ECS | Yes | Repository integrates with CI/CD |
| Encrypt over public internet | Yes | VPN/HTTPS satisfy this |
| Deploy in less than 2 weeks | Very important | Managed services strongly preferred |
---
Analyze Option A
> Use an AWS Direct Connect connection and a VPN connection to connect the on-premises data center to AWS. Deploy third-party artifact management software on Amazon EC2 instances.
Positives
Direct Connect + VPN provides secure connectivity.
Third-party repositories (Nexus, Artifactory) can proxy Maven, npm, PyPI, etc.
Can support both AWS and on-premises.
Problems
❌ Deployment time
Requirement:
> Deploy in less than two weeks.
Deploying and configuring:
EC2
HA cluster
Storage
Backups
Security
Scaling
Monitoring
Patching
takes significant effort.
AWS exam prefers managed service whenever deployment speed is mentioned.
---
❌ High Availability
You would need:
Multiple EC2 instances
Load balancer
Shared storage
Backups
Auto Scaling
Nothing in the option mentions this.
---
❌ Unnecessary Direct Connect
There is no requirement for:
private network
low latency
predictable bandwidth
Direct Connect is expensive and takes weeks or months to provision.
Requirement only says:
> encrypt over public internet
VPN already satisfies this.
---
Verdict
Reject.
---
Analyze Option B
> Use two AWS VPN connections to connect the on-premises data center to AWS. Use AWS CodeArtifact to store the deployment artifacts.
This immediately matches several requirements.
---
Requirement 1
Common artifact repository
✔ AWS CodeArtifact
Supports
Maven
npm
Python
NuGet
Swift
generic packages
Works for both AWS and on-premises developers.
---
Requirement 2
Cons...
Author: Ella · Last updated Jul 20, 2026
A DevOps engineer successfully creates an Amazon Elastic Kubernetes Service (Amazon EKS) cluster that includes managed node groups. When the DevOps engineer tries to add node groups to the cluster, the cluster returns an error that states, "NodeCreationFailure: Instances failed to join the Kubernetes cluster."
The DevOps engineer confir...
The key clue in the question is the error:
> "NodeCreationFailure: Instances failed to join the Kubernetes cluster."
Also note:
✅ EKS cluster is Active
✅ EC2 worker nodes are running
❌ Nodes cannot register (join) the cluster
This means the issue is not EC2 launch, but node bootstrap/registration.
---
Analyze each option
A) Ensure that the EKS cluster's VPC subnets do not overlap with the 172.17.0.0/16 CIDR range.
Why this looks tempting
Docker traditionally uses 172.17.0.0/16 as the default bridge network.
If your VPC overlaps with Docker networking, networking problems can occur.
Why it is NOT the best answer
Overlapping CIDRs can cause:
Pod networking issues
Container communication issues
Routing conflicts
But they do not usually prevent EC2 instances from joining the cluster.
The node joins through:
kubelet
bootstrap script
API server communication
IAM authentication
Those are unrelated to Docker bridge CIDRs.
When this option is correct
Use this when questions mention:
Pod connectivity failures
Containers cannot reach services
Docker bridge conflicts
Networking/routing issues after nodes already joined
Key factor
> Networking issue after node registration, not node creation failure.
Rejected.
---
B) Use kubectl to update the kubeconfig file to use the credentials that created the cluster.
Why this looks tempting
The cluster creator has admin permissions.
Updating kubeconfig is commonly done using:
```bash
aws eks update-kubeconfig
```
Why it is wrong
The error is:
> Worker nodes cannot join.
Updating kubeconfig only affects:
Your local kubectl client
Administrator access
It has absolutely nothing to do with:
EC2 instances
kubelet
bootstrap
worker node registration
Worker nodes never use your local kubeconfig.
When this option is correct
Use when:
kubectl gets Unauthorized
kubectl cannot connect
administrator lost access
switching AWS accounts
Key factor
Human access problem, not worker node problem.
Rejected.
---
C) Run the AWSSupport-TroubleshootEKSWorkerNode runbook.
This is the correct answer.
Why?
AWS provides a Systems Manager Automation runbook specifically for this exact error.
The runbook checks:
IAM role attached to worker node
Security groups
Network ACLs
Route tables
Cluster endpoint access
DNS resolution
Bootstrap logs
kubelet status
Required IAM permissions
aws-auth Conf...
Author: FlamePhoenix2025 · Last updated Jul 20, 2026
A company is developing an ecommerce application that has a backend that runs on Amazon EC2 instances. The application has a static frontend website that is hosted in an Amazon S3 bucket.
The company uses a GitHub repository for version control and must automate builds and deployments whenever code is pushed to the main bra...
Let’s carefully analyze this AWS exam-style scenario.
---
Requirement Recap
- Backend: runs on EC2.
- Frontend: static website hosted in S3.
- Source control: GitHub repository.
- Must automate builds and deployments when code is pushed to main branch.
- Must deploy frontend and backend independently.
So the solution must support separate deployment targets (EC2 vs S3) and automation triggered by GitHub commits.
---
Option Analysis
A) Single pipeline, CodeBuild for both, CodeDeploy for both
- Backend deployment via CodeDeploy → valid.
- Frontend deployment via CodeDeploy → invalid, because CodeDeploy is not used for static S3 website hosting.
- Rejected: Wrong deployment mechanism for frontend.
---
B) Single pipeline, CodeBuild for both, CodeDeploy for backend, S3 for frontend
- Backend deployment via CodeDeploy → correct.
- Frontend deployment via S3 action provider → correct.
- Both handled in one pipeline, but still independent build and deploy stages.
- Pros: Simple, minimal overhead, correct deployment targets.
- Cons: Single pipeline means both frontend and backend are tied to the same source trigger. They are independent in stages, but not fully decoupled pipelines.
- Valid solution.
---
C) Two pipelines, CodeBuild for both, CodeDeploy for both
- Backend deployment via CodeDeploy → valid.
- Frontend deployment via Code...
Author: Emma Brown · Last updated Jul 20, 2026
A company has an RPO of 24 hours and an RTO of 10 minutes for a critical web application that runs on Amazon EC2 instances. The company uses AWS Organizations to manage its AWS account. The company wants to set up AWS Backup for its AWS environment.
A DevOps engineer configures AWS Organizations for AWS Backup. The DevOps engineer creates a new centralized AWS account to s...
We are asked to choose the MOST secure AWS Backup design for a critical EC2-based application with:
RPO: 24 hours (daily backups acceptable)
RTO: 10 minutes (fast restore required)
Centralized backup account via AWS Organizations
EC2 instances with multiple EBS volumes
Requirement: AWS Backup + cross-account backup vault
The key focus is security (encryption, key ownership, and isolation).
---
Key Security Factors in AWS Backup Design
1. KMS key ownership (most important here)
Customer managed KMS keys (CMKs) provide full control (key rotation, policies, access control).
AWS managed keys reduce control and are less preferred for sensitive backups.
2. Cross-account backup isolation
Best practice: each account should have its own encryption domain (its own KMS keys).
Avoid sharing a single KMS key across accounts for backup storage.
3. Backup vault encryption
AWS Backup vaults should be encrypted using customer managed KMS keys per account.
This ensures compromise in one account does not affect another.
4. Backup type (AMI)
AWS Backup can create EBS-backed AMIs, which is appropriate for full EC2 recovery (includes all attached EBS volumes).
Meets RTO requirement because AMIs allow fast instance restoration.
---
Option Analysis
✅ Option A (Correct)
> Create encrypted backup vaults and customer managed AWS KMS keys in both accounts. Configure AWS Backup to create full EC2 backups as AMIs. Copy the backups to the centralized vault.
Why this is correct:
Uses customer managed KMS keys in both source and centralized accounts
Ensures strong encryption control in both environments
Provides true cross-account security boundary
Supports AMI-based backups (fast restore → meets RTO)
...
Author: Leah · Last updated Jul 20, 2026
A company wants to proactively monitor and respond to AWS service issues that might affect an application. The company must correlate AWS Health events with application performance metrics and must set up automated alerts. The solution must give the company the ability to archive events, tes...
Requirement breakdown (what the solution must achieve)
The solution needs to:
Ingest AWS Health events (service issues affecting AWS resources)
Correlate them with application performance metrics
Create custom metrics and automated alerts
Archive events for historical analysis
Support latency testing in different scenarios (indirectly via monitoring/metrics framework)
Key architectural clue: AWS Health integrates natively with Amazon EventBridge, which is the standard event-routing mechanism for automation and correlation.
---
Option analysis
❌ A) CloudTrail + Athena + Timestream + Chatbot
Problem 1: Wrong event source
AWS Health events are not logged in AWS CloudTrail
CloudTrail tracks API activity, not service health events
Problem 2: Overcomplicated analytics stack
Athena + Timestream adds unnecessary complexity
No native event-driven correlation between Health events and metrics
Problem 3: Weak real-time alerting integration
Chatbot is fine for notifications, but the ingestion pipeline is incorrect
👉 Use case this option fits:
Auditing API calls and querying historical logs, not real-time health event correlation.
❌ Rejected
---
✅ B) EventBridge + CloudWatch Logs + metric filters + CloudWatch alarms
Correct ingestion mechanism
AWS Health events are natively delivered to Amazon EventBridge
Strong correlation model
EventBridge → CloudWatch Logs → Metric Filters → Custom Metrics
This enables direct linkage between:
AWS Health events
Application performance metrics
Automated alerts
CloudWatch Alarms can trigger notifications or remediation acti...
Author: Ryan · Last updated Jul 20, 2026
A company uses a CI/CD pipeline to deploy its workload in the ap-southeast-2 Region. The company receives images through a Network Load Balancer (NLB) and processes the images in AWS Fargate tasks on an Amazon Elastic Container Service (Amazon ECS) cluster.
An Amazon Elastic Container Registry (Amazon ECR) repository stores the images as Docker images. The company uses Amazon Route 53 to configure DNS. The company saves the images in an Amazon S3 bucket and saves the metadata from the images in an Amazon DynamoDB table.
The company wants to expand the workload to a ...
Correct approach: A, C, E
The goal is to extend the workload to a second Region (eu-west-2) with high availability, resilience, and minimal operational change. The key design principle here is to replicate only what is necessary and keep application logic region-agnostic whenever possible.
---
✅ A) ECR replication + ECS/NLB in second Region + Route 53 latency routing
Why this is correct:
Amazon ECR cross-Region replication allows Docker images to be automatically available in eu-west-2 without modifying CI/CD pipelines significantly.
Deploying ECS Fargate + NLB in eu-west-2 mirrors the existing architecture.
Route 53 latency-based routing intelligently directs users to the closest/lowest-latency Region, improving performance and providing regional failover capability.
Key benefit:
Minimal change to CI/CD while enabling true multi-Region active-active architecture.
When this is used:
When you want active-active multi-Region workloads with traffic optimization.
---
❌ B) DynamoDB global table but tasks always use ap-southeast-2
Why this is wrong:
This defeats the purpose of a global table.
All EU traffic would still incur cross-Region latency to ap-southeast-2.
Creates a hidden single-Region dependency, reducing resilience.
When this would be used:
Rarely used; only in transitional migrations where EU is read-only or temporary.
---
✅ C) DynamoDB global table + region-local access per ECS task
Why this is correct:
DynamoDB global tables replicate data automatically across Regions.
Each ECS service accesses local DynamoDB replica, ensuring:
Low latency
High availability
No cross-Region dependency
Key benefit:
This is the standard AWS best practice for multi-Region s...
Author: Emma · Last updated Jul 20, 2026
A company uses AWS Organizations, AWS Control Tower, AWS Config, and Terraform to manage its AWS accounts and resources. The company must ensure that users deploy only AWS Lambda functions that are connected to a VPC in membe...
The requirement is to prevent creation or update of AWS Lambda functions unless they are attached to a VPC, across all member accounts managed via AWS Organizations, with least operational effort.
The key constraints are:
Must be preventive (not detective)
Must work across all accounts and IaC tools like Terraform
Must be low maintenance (no lists of VPC IDs, no frequent updates)
Must enforce at the organization level
---
Option A: Control Tower proactive controls (CloudFormation hooks)
This approach uses AWS Control Tower proactive controls backed by CloudFormation hooks.
Why it is not optimal:
Proactive controls only evaluate CloudFormation deployments, not direct AWS API calls.
Terraform deployments bypass CloudFormation, so enforcement gaps exist.
Requires custom hook logic for Lambda VPC validation → high implementation complexity
More operational overhead to maintain and extend across OUs
Use case:
Best when all workloads are deployed via CloudFormation and you want pre-deployment template validation.
---
Option B: SCP with StringEquals on VPC ID list
This uses an SCP to allow Lambda actions only if a VPC ID condition matches a predefined list.
Why it is incorrect:
Requires maintaining a static list of VPC IDs, which is operationally heavy
Requirement is “must be attached to a VPC,” not “must use specific VPCs”
SCP logic is flawed because Lambda VPC association is not validated this way in IAM conditions
Allow-based SCPs with conditions are harder to manage than explicit deny guardrails
Use case:
...
Author: Evelyn · Last updated Jul 20, 2026
A DevOps engineer is planning to use the AWS Cloud Development Kit (AWS CDK) to manage infrastructure as code (IaC) for a microservices-based application. The DevOps engineer must create reusable components for common infrastructure patterns and must apply...
Key requirements from the question
1. Reusable components for common infrastructure patterns (microservices architecture)
2. Consistent cost allocation tags across all microservices
3. Use AWS CDK best practices
4. Prefer microservices deployed independently (typical DevOps best practice)
---
Correct approach analysis
✔️ Why CDK Construct Library is required (not Service Catalog)
AWS CDK best practice for reuse is custom construct libraries
Constructs allow:
Reusable infrastructure patterns
Composable microservice architecture
Native CDK integration
AWS Service Catalog is more for:
Self-service provisioning for end users
Standardized approved products in enterprises
NOT ideal for CDK-native microservice composition
So, any option using Service Catalog for CDK constructs is less appropriate.
---
✔️ Tagging requirement (important exam trap)
`Tags` class (cdk.Tags) is the correct way to apply tags at:
App level
Stack level
Construct level (propagates down)
❌ `TagManager` is NOT used for global tagging across an app
It is internal and resource-level specific
Not used for applying consistent org-wide tagging strategy in CDK apps
So:
Tags class = correct
TagManager = incorrect for this requirement
---
✔️ Deployment strategy
Microservices should be:
Independently deployable
Isolated in separa...
Author: NightmareDragon2025 · Last updated Jul 20, 2026
A company runs an application that uses an Amazon S3 bucket to store images. A DevOps engineer needs to implement a multi-Region disaster recover (DR) strategy for the S3 objects. The DevOps engineer enables two-way replication between the S3 buckets.
The company must be able to fail over to a second S3 bucket that is in a second AWS Region. When an image is added to either S3 bucket, the image mu...
To meet the requirements—two-way S3 replication across Regions, failover capability, and replication within 15 minutes with minimal operational overhead—we evaluate each option against AWS best practices for Amazon S3 Multi-Region replication and failover design.
---
✅ A) Enable S3 Replication Time Control (S3 RTC) for each replication rule
Selected
S3 RTC guarantees that 99.9% of objects are replicated within 15 minutes, which directly matches the requirement.
Without RTC, standard replication is “best effort” and may exceed 15 minutes.
RTC adds an SLA-backed replication window, making it ideal for DR requirements with strict timing.
✔ Used when: strict replication time guarantees (e.g., DR, compliance, fast failover readiness).
---
✅ B) Create an S3 Multi-Region Access Point in an active-passive configuration
Selected
Amazon S3 Multi-Region Access Points provides a single global endpoint that can route traffic across buckets in multiple Regions.
Simplifies client access during normal operations.
Supports active-passive failover between Regions.
Reduces need for custom DNS logic or application changes.
✔ Used when: you need global access + simplified failover across S3 buckets.
---
✅ C) Call the SubmitMultiRegionAccessPointRoutes operation when failing over
Selected
This API is used to update routing configuration for an S3 Multi-Region Access Point during failover.
It programmatically shifts traffic from the primary Region to the secondary Region.
Works directly with Multi-Region Access Points (from option B).
Enables controlled, operationally efficient failover.
...
Author: Suresh · Last updated Jul 20, 2026
A company is developing a mobile app that requires extensive automated testing across multiple device types. The company is using AWS CodePipeline for its CI/CD pipeline.
The company must implement a scalable testing solution that can handle increased t...
We need a solution for automated mobile app testing across multiple device types, integrated with AWS CodePipeline, that is also scalable with minimal operational overhead.
---
Key evaluation factors
1. Device diversity (real devices vs emulators)
2. Scalability under increasing test load
3. Operational overhead (patching, scaling, infra management)
4. CI/CD integration simplicity
5. Suitability for mobile testing workloads (UI, OS fragmentation, device matrices)
---
Option A) AWS Device Farm integrated with CodePipeline ✅
Why this is correct
Amazon Web Services AWS Device Farm is a fully managed mobile testing service that provides:
Access to a large pool of real Android and iOS devices
Parallel test execution across many devices
Built-in support for automated UI tests (Appium, Espresso, XCTest)
Native integration with CI/CD tools like CodePipeline
Automatic scaling (no capacity planning needed)
Key advantages
Zero infrastructure management
No need to maintain device farms or emulators
Scales automatically with test demand
Best fit for mobile device compatibility testing
When to use this
Cross-device mobile UI testing
Real device testing (camera, sensors, OS behavior)
Large-scale regression testing for mobile apps
---
Option B) EC2 fleet + emulators + Lambda orchestration ❌
Why it is not ideal
Requires managing:
EC2 instances
Emulator setup for Android/iOS
Auto Scaling policies
Test orchestration logic via Lambda
High operational burden
Key issues
Emulators are not equivalent to real devices (accuracy gap)
Scaling requires manual tuning of EC2 groups
Complex pipeline orchestration
When this option would be used
Specialized testing requiring ...
Author: William · Last updated Jul 20, 2026
A company has an application that streams logs to an Amazon CloudWatch Logs log group. The logs must be available for the team to search in CloudWatch for at least 30 days. Logs must be accessible with low latency for at least 90 days. After 180 days, log retrieval is rare and latency is not important.
A DevOps engineer creates an Amazon S3 bucket to store the l...
Key requirement breakdown
CloudWatch Logs retention ≥ 30 days → keep logs in log group for 30 days.
Searchable in CloudWatch (low latency) ≥ 90 days → logs must be exported to S3 in a way that supports fast retrieval tier (S3 Standard / Standard-IA).
After 180 days: rare access, latency not important → cheapest archival storage (Glacier Deep Archive preferred).
Cost-effectiveness is primary goal.
Data protection and availability metrics important → avoid reduced resilience storage classes.
---
Evaluate each option
❌ A) Metric Streams + Kinesis Data Streams + Standard-IA + Glacier Flexible Retrieval
Invalid design choice: CloudWatch Metric Streams are for metrics, not logs.
Uses Kinesis Data Streams, which is:
Over-engineered for simple log delivery
Requires consumer applications (Lambda/Firehose) to write to S3
Glacier Flexible Retrieval is acceptable, but overall pipeline is unnecessarily complex and costly.
👉 Rejected due to incorrect service (metric streams) and unnecessary complexity.
---
❌ B) Metric Streams + Firehose + One Zone-IA + Glacier Flexible Retrieval
Again Metric Streams are incorrect for logs.
Uses S3 One Zone-IA, which:
Stores data in a single AZ
Conflicts with “data protection is important”
Not ideal for compliance or durability-sensitive logs.
👉 Rejected due to:
Wrong ingestion method (metric streams)
Weak durability (One Zone-IA)
---
❌ C) Subscription filter + Kinesis Data Streams + Standard-IA ...
Author: Andrew · Last updated Jul 20, 2026
A company has an organization in AWS Organizations. The organization has all features enabled and has AWS CloudTrail trusted access configured for the management account. An Amazon Simple Notification Service (Amazon SNS) topic is configured for notifications.
The company needs all AWS events in all AWS Regions in the organization to be recorded and retained in an audit account. The company needs near real-time notifications of any failed login attemp...
We need to satisfy two core requirements:
1. Organization-wide CloudTrail logging (all Regions) with retention in an audit account
2. Near real-time alerting for failed AWS console login attempts with minimal operational overhead
Key AWS design considerations
AWS CloudTrail organization trail can deliver logs to:
Amazon S3 (for durable, long-term audit storage — best practice for compliance)
Amazon CloudWatch Logs (for near real-time processing and alerting)
Amazon CloudWatch Logs metric filters + CloudWatch alarms provide a serverless, low-maintenance way to detect patterns like failed console logins.
Amazon EventBridge can process events, but cross-account + org-trail integration for specific filtered CloudTrail events typically requires more careful setup and is less straightforward than CloudWatch metric filters.
Solutions involving Athena, Lambda polling, or streaming pipelines (Kinesis/Flink) introduce unnecessary operational complexity.
---
Option analysis
A) S3 in audit + EventBridge rule on CloudTrail failed logins
Pros:
S3 in audit account satisfies retention requirement
Cons:
EventBridge-based detection from CloudTrail in an org setup is not the simplest or most deterministic approach for this use case
Cross-account/event routing complexity is under-specified
More setup ambiguity compared to CloudWatch Logs metric filters
When this is used:
When you already rely heavily on EventBridge for centralized event routing and have clear org event bus architecture
---
B) S3 + Athena + Lam...
Author: Kai99 · Last updated Jul 20, 2026
A company runs a microservices application on Amazon Elastic Kubernetes Service (Amazon EKS). Users recently reported significant delays while accessing an account summary feature, particularly during peak business hours.
A DevOps engineer used Amazon CloudWatch metrics and logs to troubleshoot the issue. The logs indicated normal CPU and memory utilization on the EKS nodes. The DevOps engineer was not able to identify where the delays occurred within th...
What the question is really testing
This is an observability vs monitoring vs tuning question in an Amazon EKS microservices environment where:
CPU and memory look normal
The problem is latency inside the request path across microservices
You need to identify where delays occur inside the architecture
So the key requirement is distributed tracing, not just infrastructure metrics.
---
✅ Correct Option: A
A) Deploy the AWS X-Ray daemon as a DaemonSet in the EKS cluster. Use the X-Ray SDK to instrument the application code. Redeploy the application
Why this is correct
This solution provides distributed tracing, which is exactly what is missing.
Key reasoning factors:
Microservices delays → need request-level visibility across services
CPU/memory are normal → infrastructure metrics are NOT enough
X-Ray provides:
End-to-end request tracing
Latency breakdown per service
Identification of slow downstream calls (DB, API, queues, etc.)
Running the X-Ray daemon as a DaemonSet in EKS ensures:
Every node can collect trace data
SDK instrumentation enables:
Propagation of trace IDs between services
Visibility into service-to-service latency
When this is used
Use AWS X-Ray when:
You need to debug latency in microservices
You want to see which service call is slow
You need request flow visualization
---
❌ Why other options are incorrect
B) Enable CloudWatch Container Insights for the EKS cluster
Why it is wrong:
Container Insights focuses on:
CPU
Memory
Disk
Node/pod performance
It does NOT provide:
Request tracing
Inter-service ...
Author: Emma · Last updated Jul 20, 2026
A company uses a trunk-based development branching strategy. The company has two AWS CodePipeline pipelines that are integrated with a Git provider. The pull_request pipeline has a branch filter that matches the feature branches. The main_branch pipeline has a branch filter that matches the main branch.
When pull requests are merged into the main branch, the pull requests are deployed by using the main_branch pipeline.
The company's developers need test results for all submitted pull requests as quickly as possible from...
We need to choose the correct CodePipeline execution modes for two pipelines:
pull_request pipeline → must return test results for all submitted PRs as quickly as possible
main_branch pipeline → must ensure each deployment completes before the next execution starts
---
Key AWS concept: CodePipeline execution modes
1. PARALLEL
Multiple pipeline executions run at the same time
Best for high-throughput CI (e.g., many PRs)
No blocking between runs
Use when: independent builds/tests must run as fast as possible
---
2. QUEUED
Executions run one at a time in order
Next execution waits for current one to finish
Guarantees deployment order and completion
Use when: deployments must not overlap (production safety)
---
3. SUPERSEDED
Only the latest execution is kept
Older in-flight executions are stopped
Optimizes for “latest code only”
Use when: intermediate results are not needed (e.g., rapid commits to same branch where only latest matters)
---
Evaluate requirements
Pull request pipeline requirement:
> “test results for all submitted pull requests as quickly as possible”
We must NOT drop executions → rules out SUPERSEDED
We must NOT delay execution → rules out QUEUED
Be...
Author: Amira99 · Last updated Jul 20, 2026
A DevOps engineer needs to configure an AWS CodePipeline pipeline that publishes container images to an Amazon Elastic Container Registry (Amazon ECR) repository. The pipeline must wait for the previous run to finish and must run when new Git tags are pushed to a Git repository that is connected to AWS CodeConnections. An exis...
Requirements recap
The solution must:
Wait for the previous pipeline execution to finish → requires QUEUED mode
Trigger on new Git tags via CodeConnections → requires tag-based trigger filtering
Start an existing deployment pipeline when a new container image is pushed to ECR → best handled via Amazon EventBridge integration
---
Option analysis
A) CodePipeline V2 + QUEUED mode + tag filter + EventBridge rule for ECR pushes
This option correctly satisfies all requirements:
CodePipeline V2 is the modern pipeline type that integrates with AWS CodeConnections (GitHub/GitLab/Bitbucket) and supports advanced trigger filtering (including tags).
QUEUED mode ensures pipeline executions are processed serially, meaning each run waits for the previous one to complete (meets the “must wait” requirement).
Tag-based trigger filter ensures pipeline runs only when new Git tags are pushed, not branches.
Amazon EventBridge rule for ECR image push events is the recommended decoupled mechanism to trigger the existing deployment pipeline when new container images are published.
This is the most scalable and event-driven architecture.
---
❌ B) V2 + SUPERSEDED mode + branches + EventBridge
SUPERSEDED mode cancels older runs in favor of the newest → violates the requirement to wait for previous run to finish.
Uses branches instead of tags, which does not match the requirement.
Even though EventBridge is correct for ECR triggers, core execution logic is wrong.
👉 Typically used when only the latest com...
Author: Isabella1 · Last updated Jul 20, 2026
A company is running an application on Amazon Elastic Kubernetes Service (Amazon EKS). The company needs to implement comprehensive logging for the control plane and the nodes. The company must analyze API requests to the Kubernetes control plane and must monitor cont...
Correct Answer: B
Why option B is correct (least operational overhead)
This requirement has two parts:
1. Control plane logging (API requests to Kubernetes API server)
2. Node/container performance monitoring
Option B uses fully managed AWS-native integrations:
EKS control plane logging → Amazon CloudWatch Logs
Native EKS feature (no custom pipeline)
Captures Kubernetes API server logs (audit, API, authenticator, scheduler, etc.)
Direct integration → minimal setup and maintenance
Amazon CloudWatch Container Insights
Purpose-built for EKS node + container performance monitoring
Collects metrics, logs, and performance data automatically
No need to deploy custom agents manually in most cases (AWS-managed add-ons available)
CloudWatch Logs Insights
Serverless querying of both control plane and node logs
No infrastructure management required
👉 Overall: fully managed, tightly integrated, and minimal components = lowest operational overhead
---
Why the other options are incorrect
❌ A) CloudTrail + Logstash + OpenSearch
CloudTrail is incorrect for Kubernetes API server logs
CloudTrail logs AWS API calls (e.g., EKS API), not Kubernetes control plane internals like `kubectl apply`, scheduler actions, etc.
Logstash on EKS nodes
Self-managed ReplicaSet → high operational burden (patching, scaling, failures)
Amazon OpenSearch Service
Requires cluster sizing, scalin...
Author: William · Last updated Jul 20, 2026
A company wants to improve its security practices by enforcing least privilege across all projects. Developers must be able to access Amazon EC2 resources but not Amazon RDS resources. Database administrators must have access only to Amazon RDS resources.
Every employee has a unique IAM user. There are already pre-existing IAM policies for developer and database administrator job functions. All AWS resources are already tagged with appropriate project tags. All the IAM users are tagged wit...
The requirements describe a classic ABAC (Attribute-Based Access Control) setup in AWS using IAM tags on users, roles, and resources, combined with job-function-based permissions. The goal is:
Developers → EC2 only
DBAs → RDS only
Access limited to the project they are assigned to (via tags)
Key design signals in the question:
IAM users are already tagged (job function + project)
Resources are tagged
Pre-existing job-function policies exist
Requirement explicitly enforces tag-based access control across projects
This strongly points to ABAC using `aws:PrincipalTag` and `aws:ResourceTag`, plus role-based access per job function.
---
✅ Correct Options
A) Create IAM roles per project and job function, and tag them
Why this is correct:
Separates access by both project and job function
Allows isolation per project boundary (important for compliance)
Tags on roles enable ABAC evaluation later
When used:
When each project must have isolated access paths
When combining RBAC (job function) + ABAC (project tag)
---
B) Modify IAM policies to use `StringEquals` with ResourceTag and PrincipalTag
Why this is correct:
This is the core ABAC enforcement mechanism
Ensures:
User’s `PrincipalTag: project`
Must match `ResourceTag: project`
Directly enforces “users can only access their assigned project”
When used:
Central ABAC enforcement across services (EC2, RDS, S3, etc.)
When tags already exist (as in this scenario)
---
D) Create an IAM policy allowing users to assume roles based on matc...
Author: Charlotte · Last updated Jul 20, 2026
A company runs a development environment website and database on an Amazon EC2 instance that uses Amazon Elastic Block Store (Amazon EBS) storage. The company wants to make the instance more resilient to underlying hardware issues. The company wants to automatically recover the E...
The requirement is to automatically recover the same EC2 instance (not replace it) when AWS detects underlying infrastructure or connectivity issues. The key mechanism for this is EC2 instance recovery using CloudWatch status checks, specifically the System Status Check.
---
✅ Correct Option: C) Create an Amazon CloudWatch alarm for the `StatusCheckFailed_System` metric. Add an EC2 action to recover the instance when the alarm state is in ALARM
Why this is correct:
`StatusCheckFailed_System` detects AWS-side infrastructure problems such as:
Underlying host failure
Network connectivity loss due to AWS hardware issues
When this alarm triggers, AWS can perform EC2 automatic recovery, which:
Moves the instance to a healthy underlying host
Preserves instance configuration and EBS data (for supported configurations)
This directly matches the requirement: recover instance automatically due to AWS-detected hardware/network issues
---
❌ Why other options are incorrect:
A) Auto Scaling group (min=1, desired=1, max=1)
This does not recover the same instance
If the instance fails, ASG will:
Terminate the unhealthy instance
Launch a new replacement instance
❌ Fails requirement of instance...
Author: Isabella · Last updated Jul 20, 2026
A company operates a fleet of Amazon EC2 instances that host critical applications and handle sensitive data. The EC2 instances must have up-to-date security patches to protect against vulnerabilities and ensure compliance with industry standards and regulations. The company needs an automated ...
Key requirement breakdown
The company needs:
Automated patching (not manual)
Continuous monitoring of patch compliance
Enforcement of security patch standards
Works at fleet scale for EC2
Must support audit/compliance requirements
This strongly points to a native AWS patch management + compliance tracking service, not instance replacement or manual operations.
---
✅ Correct Option: A
A) AWS Systems Manager Patch Manager + AWS Config + Patch Baselines + Automation
This is the standard AWS-native solution for enterprise patch compliance.
Why this is correct:
AWS Systems Manager Patch Manager
Automates OS patching across EC2 fleets (Windows/Linux)
Uses patch baselines to define approved/required patches
Can schedule patching windows (maintenance windows)
AWS Config
Continuously evaluates compliance (e.g., “are instances patched as per baseline?”)
Provides audit history and compliance dashboards
Systems Manager Automation documents
Can remediate non-compliant instances automatically
Together:
Detect + enforce + remediate + audit = full lifecycle compliance
Key exam keyword match:
“automated solution”
“monitor and enforce compliance”
“security patch compliance across fleet”
👉 This is exactly what Systems Manager Patch Manager is designed for.
---
❌ Why other options are wrong
B) Manual SSH patching
Requires human intervention
No cent...
Author: Andrew · Last updated Jul 20, 2026
A company has implemented a new microservices-based application on an Amazon Elastic Container Service (Amazon ECS) cluster. After each deployment, the company wants to validate the critical user journeys and API endpoints before routing traffic to the new application version.
The company must implement an automated solution to detect issue...
The requirement is automated post-deployment validation of critical user journeys and APIs with minimal operational overhead, plus automatic rollback if issues are detected before full traffic exposure. The key idea is to use synthetic testing + native AWS rollback integration, avoiding custom orchestration.
---
✅ Correct Answer: D
Why Option D is correct
Option D uses:
Amazon CloudWatch Synthetics canaries → simulate real user journeys and API calls against the new deployment
Amazon CloudWatch alarms → detect canary failures (latency, errors, broken flows)
Native Amazon ECS deployment rollback integration → automatically rolls back when alarms trigger
Key reasoning factors
True end-to-end user validation: Synthetics directly tests real user behavior, unlike metrics-based monitoring.
Pre-traffic validation support: Canaries can run against the new deployment before full traffic shift (common in canary/blue-green patterns).
Lowest operational overhead: Fully managed services + native alarm integration, no custom compute or orchestration needed.
Automatic rollback capability: ECS supports rollback via alarms (deployment circuit breaker / alarm-based rollback).
When this option is best used
You need synthetic user testing for APIs/UI flows
You want canary-style validation before full production rollout
You want fully managed monitoring + rollback with minimal custom logic
---
❌ Why other options are...
Author: Ming88 · Last updated Jul 20, 2026
A DevOps engineer needs to implement a CI/CD pipeline in an AWS account. The pipeline must consume sensitive database credentials that are stored in an AWS Systems Manager Parameter Store parameter. The Parameter Store parameter is in a separate central account. The DevOps engineer needs to create...
Key requirement breakdown
Central account holds sensitive DB credentials in AWS Systems Manager Parameter Store
CI/CD account must securely consume those parameters cross-account
Must ensure:
Correct Parameter Store capability for sensitive data
Cross-account access control
Proper KMS permissions for decryption
---
Step-by-step evaluation of options
✅ A) Use an advanced tier Parameter Store parameter to store the database credentials in the central AWS account.
✔️ Correct
Secure strings with encryption and higher limits/features require Standard or Advanced tier, but Advanced tier is specifically used when you need higher throughput, larger parameters, and enhanced capabilities in enterprise setups
In exam context, sensitive credentials in centralized governance accounts are commonly assumed to use Advanced tier for better management and scaling
Most importantly: Parameter Store supports secure storage in central account regardless, but Advanced tier is acceptable and often preferred in cross-account enterprise patterns.
📌 When used:
Large-scale enterprise Parameter Store usage
High throughput / advanced parameter features
❌ Why not C?
Standard tier also works for secrets, but exam usually prefers Advanced tier for enterprise cross-account + sensitive config at scale scenarios
---
❌ B) Create an IAM role in the AWS account that hosts the CI/CD pipeline. Add the full ARN of the parameter to the IAM policy
❌ Incorrect
Key issue:
You cannot grant access to Parameter Store just by referencing ARN alone without proper actions + KMS permissions
Also cross-account Parameter Store access requires both IAM policy + resource policy (or KMS key policy if encrypted)
📌 When this option would be partially relevant:
Same-account Parameter Store access
IAM policy granting `ssm:GetParameter`
---
❌ C) Use a standard tier Parameter Store parameter
❌ Not the best answer in this scenario
Why:
Standard tier is fine for basic usage
But exam emphasizes enterprise secure cross-accou...
Author: John · Last updated Jul 20, 2026
A company is using the AWS Cloud Development Kit (AWS CDK) to develop a microservices-based application. The company needs to create reusable infrastructure components for three environments: development, staging, and production. The components must include networking resources, database resources, and serverless compute resources.
The company must implement a solution that provides consistent infrastructure across environments while off...
Key requirements from the question
The solution must:
Create reusable infrastructure components for networking, database, and serverless compute
Support three environments: dev, staging, prod
Ensure consistent infrastructure across environments
Allow environment-specific customization
Minimize code duplication
Have least development overhead
---
Key AWS CDK concepts (important for elimination)
L1 constructs: Low-level, direct CloudFormation resources → high verbosity, more code, more duplication risk
L2 constructs: Higher-level abstractions provided by AWS CDK → recommended for most use cases
L3 constructs (patterns): Opinionated, reusable architectures combining multiple L2 constructs → best for reducing duplication and enforcing consistency
So:
L3 > L2 > L1 in terms of abstraction and reuse
Also:
Single stack with environment parameter → best for DRY (Don't Repeat Yourself)
Multiple stacks + context switching → adds operational complexity
---
Option analysis
❌ Option A
> Create custom L1 constructs from L2 constructs… single stack with environment argument
Uses L1 constructs
L1 increases boilerplate and duplication
Even though single stack with env param is good, the construct level is wrong
Why it's wrong:
L1 is too low-level for reusable enterprise patterns
Does not minimize development overhead
When it might be used:
When you need direct CloudFormation control
Rare cases requiring fine-grained overrides not supported in L2/L3
---
❌ Option B
> L1 constructs + separate stacks per environment + CDK context
Worst combination for simplicity:
L1 → verbose
Separate stacks → duplication risk
Context-based deployment logic → operational overhead
Why it's wrong:
Violat...
Author: Olivia Johnson · Last updated Jul 20, 2026
A company runs an application on an Amazon Elastic Container Service (Amazon ECS) service by using the AWS Fargate launch type. The application consumes messages from an Amazon Simple Queue Service (Amazon SQS) queue. The application can take several minutes to process each message from the queue. When the application processes a message, the application reads a file from an Amazon S3 bucket and processes the data in the file. The application writes the processed output to a second S3 bucket. The company uses Amazon CloudWatch Logs to monitor processing errors and to ensure that the application processes messages successfully.
The SQS queue typic...
The correct answer is A.
In this scenario, the key requirement is to reduce processing time during burst traffic from an SQS queue in a cost-effective way, while still using ECS on Fargate.
✅ Why A is correct: ECS Service scaling with Application Auto Scaling
A) Register the ECS service as a scalable target in AWS Application Auto Scaling and scale based on SQS queue size
This is the most appropriate and cost-effective solution because:
The bottleneck is message backlog in Amazon SQS during bursts
ECS tasks on Fargate are the compute layer processing messages
Scaling out ECS tasks increases parallel message processing
AWS Application Auto Scaling can use metrics like:
`ApproximateNumberOfMessagesVisible`
`ApproximateAgeOfOldestMessage`
This allows dynamic scaling only during bursts, keeping cost low during normal traffic
📌 Key advantage:
You get automatic horizontal scaling of consumers based on queue depth, which directly reduces processing time during spikes.
---
❌ Why other options are incorrect
B) Increase batch size and use long polling
Helps reduce API call overhead, not processing capacity
Batch size is limited (max 10 messages per SQS receive call)
Long polling improves efficiency but does NOT increase throughput significantly
Each message still takes minutes → bottleneck remains
📌 When B is useful:
Low-cost optimization for steady workloads
...
Author: StarryEagle42 · Last updated Jul 20, 2026
A global company uses Amazon S3 to host its product catalog website in the us-east-1 Region. The company must improve website performance for users across different geographical regions and must reduce the load on the origin server. The company must implement a highly available cross-Re...
This is primarily testing CloudFront architecture design + multi-Region resilience with minimal operational overhead.
Key requirements breakdown
Improve global performance for users → use Amazon CloudFront
Reduce origin load → maximize edge caching + optional Origin Shield
Highly available cross-Region setup → origin redundancy / replication
Least operational effort → avoid unnecessary multiple distributions, scripts, or custom sync systems
---
✅ Correct Answer: B
Why Option B is correct
Uses a single Amazon CloudFront distribution, which is the recommended global pattern (CloudFront is already globally distributed; no need for multiple distributions).
Enables Origin Shield (in us-east-1):
Adds an extra caching layer between edge locations and origin
Reduces direct hits to Amazon S3
Implements cache behaviors with optimized TTLs:
Maximizes edge caching → reduces latency and origin requests globally
Uses origin failover to a second S3 bucket in another Region:
Provides high availability across Regions
Enables S3 replication between Regions:
Keeps content synchronized automatically
Why this is the best (key factors)
Single CloudFront distribution (low ops overhead)
Built-in failover mechanism (no custom routing logic)
Native AWS services only (no external orchestration)
Proper combination of:
performance (edge + Origin Shield)
availability (multi-Region origin failover)
simplicity (managed replication)
---
❌ Why other options are wrong
A) Multiple CloudFront ...
Author: SolarFalcon11 · Last updated Jul 20, 2026
A company is using AWS CodeDeploy to deploy applications to a fleet of Amazon EC2 instances. During a recent deployment, several EC2 instances failed to update successfully.
A DevOps engineer must investigate the root cause of the failures and must determine which specific deployment lifecycle events encou...
What the question is really testing
This is an operational efficiency + AWS native observability question. You need to identify:
Where CodeDeploy lifecycle failure details live
How to access logs at scale
Which approach avoids manual instance access
Which gives centralized querying and analysis
The key clue is:
> “determine which specific deployment lifecycle events encountered errors”
That means you need structured, queryable logs across all instances, not per-instance troubleshooting.
---
Option A: SSH into each EC2 instance
Why it’s not optimal
Requires manual SSH access per failed instance
Not scalable for fleets
Operationally heavy (key management, bastion host, permissions)
Still relies on local log inspection
When it is used
One-off debugging
No SSM enabled environment
Emergency access in legacy setups
❌ Reject: Not operationally efficient, not centralized
---
Option B: AWS Systems Manager Session Manager + logs
Why it's better than SSH
No SSH keys required
Secure, audited access
Works without opening inbound ports
Why it is still not best
Still instance-by-instance manual log inspection
No centralized aggregation or querying
Does not scale for fleet-wide deployment analysis
When it is used
Secure interactive troubleshooting on EC2
When investigating a single or few instances
Environments already using Systems Manager but lacking centralized logging
❌ Reject: Still manual and not analytical at scale
---
Option C: S3 + appspec.yml log copying + Athena
Why it’s not ideal
Requires custom modification of deployment lifecycle (appspec.yml)
CodeDeploy already produces logs—no need to reinvent log shipping
Athena adds query capability but:
Logs are not naturally structured for lifecycle ...
Author: Ava · Last updated Jul 20, 2026
A company built its serverless infrastructure on AWS. The infrastructure consists of an Amazon API Gateway REST API, multiple AWS Lambda functions, and Amazon EventBridge.
The company wants to be aware of any new supply chain attacks that the company's CI/CD pipelines do not catch. The c...
The requirement is to detect malicious activity in a deployed serverless application, including supply chain attacks that bypass CI/CD checks. This points to a runtime threat detection + managed threat intelligence solution, not just preventive controls in the build pipeline or request filtering.
---
Option A: AWS WAF + managed rule group
AWS WAF can block known malicious HTTP patterns (e.g., SQL injection, XSS) at the API Gateway layer.
Key factor: It is a preventive edge-layer control, not a detection system.
It does not analyze Lambda behavior, API call patterns beyond HTTP requests, or supply chain compromises.
It cannot detect compromised dependencies or runtime anomalies.
Why rejected: Focuses on request filtering, not post-deployment malicious activity detection.
---
Option B: Amazon GuardDuty + Lambda Protection + EventBridge
GuardDuty provides continuous security monitoring and threat detection using logs from AWS services like CloudTrail, VPC Flow Logs, DNS logs, and Lambda runtime signals.
Key factor: It is a managed threat detection service designed for runtime environments.
Lambda Protection specifically detects suspicious behavior in Lambda functions, such as unusual execution patterns or indicators of compromise.
Findings can be routed via EventBridge for automated alerting and response.
Strong fit for detecting supply chain attacks...
Author: Maya2022 · Last updated Jul 20, 2026
A company has a stateless web application that is deployed on Amazon EC2 instances. The EC2 instances are in a target group behind an Application Load Balancer (ALB). Amazon Route 53 manages the application domain.
The company updates the application UI and develops a beta version of the application. The company wants to...
Correct Answer: B
Why Option B is correct (best fit for least changes)
Option B uses weighted target groups on the existing Application Load Balancer (ALB). This is the most efficient and minimally disruptive way to route 10% of live traffic to the beta version.
Key reasons:
The ALB already exists in the architecture.
You only add a new target group for beta EC2 instances.
ALB supports weighted forwarding between target groups in a listener rule.
Traffic splitting (90/10) is handled at the ALB layer—no DNS or infrastructure redesign needed.
No need to modify Route 53 or introduce new load balancers.
This is a standard blue/green or canary deployment pattern using ALB weighted target groups.
---
Why other options are incorrect
❌ Option A (Route 53 weighted routing with new ALB)
Requires provisioning a new ALB, which increases cost and operational overhead.
Route 53 weighted routing works at DNS level, but:
DNS caching can cause inaccurate traffic split
Slower propagation of changes
More configuration changes than necessary.
👉 Use case...
Author: BlazingPhoenix22 · Last updated Jul 20, 2026
A company frequently creates Docker images of an application. The company stores the images in Amazon Elastic Container Registry (Amazon ECR). The company creates both tagged images and untagged images.
The company wants to implement a solution to automatically delete images that have not been updated for a long time and are not frequently use...
The correct answer is B) Use Amazon ECR lifecycle policies to delete images based on age or the number of images that need to be retained in the repository.
Why option B is correct
Amazon Elastic Container Registry (Amazon ECR) provides native lifecycle policies specifically designed for automated image cleanup with minimal operational effort.
Key factors:
Native integration: Lifecycle policies are built into ECR—no external services required.
Supports required conditions:
Image age (e.g., older than X days)
Image count (retain last N images)
Tag-based and untagged image rules
Lowest operational overhead: No code, no scheduling, no infrastructure.
Directly matches requirement: Automatically deletes unused/old images while ensuring a minimum number are retained.
This is exactly what the question asks for: automated cleanup with retention control and minimal management effort.
---
Why other options are incorrect
A) Amazon S3 lifecycle policies
Amazon S3 lifecycle policies do not apply to ECR repositories.
ECR is not S3-backed in a way that supports S3 lifecycle rules.
This option is a misapplied service feature.
Even though S3 lifecycle supports age-based deletion and tag filtering, it cannot manage container images in ECR.
✔ When...
Author: Maya · Last updated Jul 20, 2026
A company is developing a web application that runs on Amazon EC2 Linux instances. The application requires monitoring of custom performance metrics. The company must collect metrics for API response times and database query latency across mu...
The requirement is to collect custom performance metrics (API response time and DB query latency) across multiple EC2 Linux instances with the least operational overhead.
✅ Correct Answer: A) Install the Amazon CloudWatch agent on the instances. Configure the agent to collect the custom metrics. Instrument the application to send the metrics to the agent.
---
Why Option A is correct
This is the lowest operational overhead native AWS approach for EC2-based custom metrics.
Key factors:
Uses the Amazon CloudWatch Agent
Can collect:
System metrics (CPU, memory, disk)
Custom application metrics (via StatsD or Embedded Metric Format / custom config)
Works directly on EC2 instances without additional infrastructure
Fully managed ingestion into Amazon Web Services CloudWatch
Scales automatically across multiple instances with consistent configuration
Why it fits the requirement
Minimal components (just agent + app instrumentation)
No external monitoring systems required
Near real-time metrics ingestion
Native integration with CloudWatch dashboards and alarms
---
Why other options are incorrect
❌ B) Amazon Managed Service for Prometheus + CloudWatch agent forwarding
Uses Amazon Managed Service for Prometheus
Requires:
Prometheus scraping configuration
Exporters in the application
Addi...
Author: Ethan Smith · Last updated Jul 20, 2026
A company uses AWS Lambda functions in the primary operating AWS Region of its AWS account. The company manually created the Lambda functions.
The company needs to use a Python-based AWS Cloud Development Kit (AWS CDK) application to manag...
Key requirement analysis
Existing Lambda functions were manually created in AWS (so no IaC baseline yet).
Goal: manage them using a Python AWS CDK application.
Constraint: least implementation effort.
We need a way to import existing resources into CDK/IaC with minimal manual conversion.
---
Option analysis
A) CloudFormation IaC Generator → CDK app → use `from_asset`
Uses AWS CloudFormation IaC generator, which is designed specifically to reverse-engineer existing AWS resources into IaC.
Directly generates an AWS CDK application (not just a template).
Minimal transformation needed afterward.
Lambda code can be referenced using `from_asset` (normal CDK pattern for local code packaging).
Why this is good:
End-to-end CDK generation → avoids intermediate conversion steps.
Least manual effort.
Purpose-built for “existing infrastructure → CDK”.
Best fit scenario:
You already have deployed AWS resources and want to quickly generate CDK code to manage them going forward.
---
B) IaC Generator → CloudFormation template → modify S3/ZipFile → convert to CDK
Produces CloudFormation template first, not CDK.
Requires manual modification of Lambda `Code` properties.
Then requires conversion from CloudFormation → CDK (extra step/tooling complexity).
Problems:
Two-stage transformation (CFN → CDK)...
Author: Siddharth · Last updated Jul 20, 2026
A company produces builds for an open source project every day. The company hosts the open source project in a public code repository that the company supports. The company manually invokes a pipeline in AWS CodePipeline to build artifacts for the project. The company wants to make the build artifacts publicly available on ...
Correct Answer: B
---
Why Option B is correct (Key reasoning)
This requirement is about automating a daily build process with minimal management effort and publishing artifacts to Amazon S3.
Key factors:
Scheduled execution (daily builds required) → Amazon EventBridge schedule fits perfectly
Low operational overhead → No need to maintain full CI/CD pipeline structure
Direct build-to-S3 publishing → CodeBuild supports native artifact output to S3
Security best practice → Artifact encryption enabled is appropriate
Decoupled architecture → CodeBuild + EventBridge is lightweight and serverless
Why this works best:
CodeBuild runs builds directly from the public repository
EventBridge triggers it once per day (cron-like scheduling)
Build artifacts are automatically pushed to S3
No need for CodePipeline stages or manual invocation
Best use scenario:
Use this approach when you want:
Scheduled builds (daily/hourly)
Simple CI/CD without complex pipeline orchestration
Direct artifact publishing to S3
---
Why other options are incorrect
❌ Option A
Uses webhook trigger (event-based on commits) instead of daily schedule
This contradicts th...
Author: Olivia · Last updated Jul 20, 2026
A company has deployed a microservices-based application on Amazon Elastic Container Service (Amazon ECS). The application is experiencing performance issues. The company needs to identify which m...
The correct choice is B.
Why B is correct
This scenario is about identifying which microservices are causing performance degradation in an ECS-based microservices architecture. The key requirement is end-to-end request tracing across services, not just container-level metrics.
Using Amazon Web Services AWS X-Ray with AWS X-Ray service maps allows you to:
Visualize the entire request flow across microservices
Identify latency hotspots between services
Filter traces by response time and error rate
Drill into individual traces to pinpoint which service is slow
This directly addresses the requirement to find which microservices are causing performance issues.
In practice:
Use X-Ray service map → quickly spot problematic services
Use trace filtering → isolate slow requests
Use trace inspection → confirm root cause at microservice level
---
Why other options are incorrect
A) X-Ray with custom subsegments per microservice
While X-Ray is correct, this option is over-engineered:
Creating custom subsegments in every microservice adds unnecessary development overhead
Defining X-Ray groups per microservice is not required to identify performance bottlenecks
The solution is more complex than needed for the problem statement
👉 This would be used when:
You need ...
Author: VioletCheetah55 · Last updated Jul 20, 2026
A company recently configured AWS Control Tower in its organization in AWS Organizations. The company enrolled all existing AWS accounts in AWS Control Tower. The company wants to ensure that all new AWS accounts are automatically enrolled in AWS Control Tower.
The company has an existing AWS Step Functions workflow that creates new AWS accounts and performs any actions required as part of account creation. The Step Functions wor...
In AWS Control Tower, new accounts should not be “manually enrolled” after creation. Instead, they must be provisioned through Account Factory (Service Catalog) so Control Tower can automatically apply guardrails, baselines, and enroll them into the landing zone. Additionally, Control Tower requires a predefined cross-account role in each managed account to administer governance.
Let’s evaluate each option.
---
✅ Correct Option D — Call `ServiceCatalog ProvisionProduct` API
This is the key mechanism for Account Factory in AWS Control Tower.
Control Tower uses AWS Service Catalog Account Factory product to create new accounts.
Calling `ProvisionProduct` triggers:
Account creation in AWS Organizations
OU placement
Automatic Control Tower enrollment
Baseline setup (guardrails, logging, etc.)
When to use:
Whenever you want automated, compliant account creation inside Control Tower.
---
✅ Correct Option C — Create `AWSControlTowerExecution` role in the new account
This role is mandatory for Control Tower governance.
Control Tower uses the `AWSControlTowerExecution` role in member accounts to:
Apply guardrails
Configure logging and auditing
Manage lifecycle operations
It must exist in every enrolled account and must be assumable by the Control Tower management account.
When to use:
When setting up any account to be governe...
Author: Arjun · Last updated Jul 20, 2026
A company has an AWS Lambda function that creates image thumbnails from larger images. The Lambda function needs read and write access to an Amazon S3 bucket in the same AWS account...
Let's break down each of the options to determine which will work for providing the Lambda function with access to the S3 bucket:
A) Create an IAM user that has only programmatic access. Create a new access key pair. Add environmental variables to the Lambda function with the access key ID and secret access key. Modify the Lambda function to use the environmental variables at runtime during communication with Amazon S3.
- Analysis: This option suggests creating an IAM user, generating access keys, and using environment variables to pass the keys to the Lambda function. This is not the recommended approach for Lambda functions because managing access keys directly within environment variables can be insecure and difficult to manage. Additionally, IAM roles are more suitable for Lambda functions because they allow temporary credentials and provide better security.
- Rejection Reason: This approach is not recommended for Lambda functions due to security concerns around hardcoding access keys and the preference for IAM roles.
B) Generate an Amazon EC2 key pair. Store the private key in AWS Secrets Manager. Modify the Lambda function to retrieve the private key from Secrets Manager and to use the private key during communication with Amazon S3.
- Analysis: EC2 key pairs are used for SSH access to EC2 instances, not for granting S3 access. Additionally, managing EC2 keys and private keys for Lambda functions is an unnecessary and overly complex solution. Lambda does not need EC2 key pairs for accessing S3; it requires IAM roles for managing permissions.
- Rejection Reason: EC2 key pairs are not relevant for Lambda functions' access to S3. This option is unnecessarily complicated and not suited for this use case.
C) Create an IAM role for the Lambda function. Attach an IAM policy that allows access to the S3 bucket.
- Analysis: This is the recommended approach. AWS Lambda functions should use IAM r...
Author: Siddharth · Last updated Jul 19, 2026
A security engineer is configuring a new website that is named example.com. The security engineer wants to secure communications with the website by requiring users to connect to example.com throu...
Let's go through each option and analyze which one is valid for storing SSL/TLS certificates for the website example.com:
A) Custom SSL certificate that is stored in AWS Key Management Service (AWS KMS)
- Analysis: AWS Key Management Service (KMS) is primarily designed for managing encryption keys, not SSL/TLS certificates. KMS helps with key management for encryption, but it does not store SSL/TLS certificates directly. You can use KMS to manage the private keys, but not the certificates themselves.
- Rejection Reason: AWS KMS is not designed for storing SSL/TLS certificates. While it manages encryption keys, the SSL/TLS certificates themselves should be stored in services like AWS Certificate Manager (ACM).
B) Default SSL certificate that is stored in Amazon CloudFront
- Analysis: Amazon CloudFront provides a default SSL certificate that is automatically used when you distribute content over HTTPS via CloudFront. However, the default certificate is valid only for CloudFront's domain (`.cloudfront.net`), not for custom domains like `example.com`.
- Rejection Reason: The default SSL certificate for CloudFront is not valid for custom domains. To use HTTPS with your own domain (example.com), you need to use a custom SSL c...
Author: NebulaEagle11 · Last updated Jul 19, 2026
A security engineer needs to develop a process to investigate and respond to potential security events on a company's Amazon EC2 instances. All the EC2 instances are backed by Amazon Elastic Block Store (Amazon EBS). The company uses AWS Systems Manager to manage all the EC2 instances and has installed Systems Manager Agent (SSM Agent) on all the EC2 instances.
The process that the security engineer is developing must comply with AWS security best practices and must meet the following requirements:
A compromised EC2 instance's volatile memory and non-volatile memory must be preserved for forensic purposes.
A compromised EC2 instance's metadata must be updated with corresponding incident ticket information.
A compromised EC2 instance must remain online ...
To meet the security requirements with the least operational overhead, we need to follow a methodical process that ensures the EC2 instance is preserved for forensic purposes, is isolated during the investigation, and the investigation actions are documented. Let's break down the options and select the best course of action.
A) Gather any relevant metadata for the compromised EC2 instance. Enable termination protection. Isolate the instance by updating the instance's security groups to restrict access. Detach the instance from any Auto Scaling groups that the instance is a member of. Deregister the instance from any Elastic Load Balancing (ELB) resources.
- Analysis: This option outlines good isolation steps by modifying security groups and detaching the instance from Auto Scaling and ELB. However, it does not directly address the preservation of volatile data or the capture of the investigative actions.
- Rejection Reason: While isolating the instance is critical, this option does not mention capturing volatile memory or collecting forensic data, which are important parts of the requirements. Also, it doesn't include tagging or documenting incident ticket information, which is necessary for tracking the investigation.
B) Gather any relevant metadata for the compromised EC2 instance. Enable termination protection. Move the instance to an isolation subnet that denies all source and destination traffic. Associate the instance with the subnet to restrict access. Detach the instance from any Auto Scaling groups that the instance is a member of. Deregister the instance from any Elastic Load Balancing (ELB) resources.
- Analysis: This option suggests moving the instance to an isolation subnet, which could be a good way to prevent traffic, but it's a bit more complex than just modifying the security groups. This option also doesn't mention collecting volatile data or tagging the instance with incident information.
- Rejection Reason: While isolation is necessary, this option adds unnecessary complexity with subnet reconfiguration and doesn't explicitly address other critical actions like volatile data capture and metadata tagging. This introduces more operational overhead without additional benefits.
C) Use Systems Manager Run Command to invoke scripts that collect volatile data.
- Analysis: This option directly addresses the need to collect volatile memory (RAM) data from the compromised instance, which is a critical part of forensic investigations. AWS Systems Manager Run Command allows you to run scripts or commands on the EC2 instances without needing to directly log into the instance, which is secure and ensures that all actions are captured.
- Acceptance Reason: This is a highly recommended option because it allows you to securely collect volatile data without requiring direct access to the instance, and the actions can be logged as pa...
Author: Max · Last updated Jul 19, 2026
A company has an organization in AWS Organizations. The company wants to use AWS CloudFormation StackSets in the organization to deploy various AWS design patterns into environments. These patterns consist of Amazon EC2 instances, Elastic Load Balancing (ELB) load balancers, Amazon RDS databases, and Amazon Elastic Kubernetes Service (Amazon EKS) clusters or Amazon Elastic Container Service (Amazon ECS) clusters.
Currently, the company's developers can create their own CloudFormation stacks to increase the overall speed of delivery. A centralized CI/CD pipeline in a shared services AWS account deploys each CloudFormation stack.
The company's security team has already provided requirements for each service in accordance with internal standards. If there are any resources that do not comply wi...
Let's analyze each solution and evaluate how well it meets the company's requirements of maintaining operational efficiency while ensuring security compliance:
A) Create an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the security team's email addresses to the SNS topic. Create a custom AWS Lambda function that will run the `aws cloudformation validate-template` AWS CLI command on all CloudFormation templates before the build stage in the CI/CD pipeline. Configure the CI/CD pipeline to publish a notification to the SNS topic if any issues are found.
- Analysis: This solution suggests creating a Lambda function that uses `aws cloudformation validate-template` to check the CloudFormation templates before they are deployed in the CI/CD pipeline. This approach ensures that templates are validated for syntax and structure, but it does not explicitly cover security compliance checks beyond basic validation. The Lambda function would need to be custom-built, and the solution does not address compliance checks in detail, such as ensuring security configurations or resource standards are met.
- Rejection Reason: While it addresses the syntax and structure of the templates, it does not meet the need to check for compliance with the security team's internal standards. Moreover, using the CLI tool (`validate-template`) doesn't provide a comprehensive compliance check.
B) Create an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the security team's email addresses to the SNS topic. Create custom rules in CloudFormation Guard for each resource configuration. In the CI/CD pipeline, before the build stage, configure a Docker image to run the `cfn-guard` command on the CloudFormation template. Configure the CI/CD pipeline to publish a notification to the SNS topic if any issues are found.
- Analysis: This solution uses CloudFormation Guard (cfn-guard), which allows you to create custom rules for AWS resources and validate CloudFormation templates against those rules. By running `cfn-guard` as part of the CI/CD pipeline, the templates can be validated for compliance with the security team's standards before deployment. This approach allows for comprehensive policy enforcement, such as ensuring specific security settings for EC2 instances, ELB load balancers, RDS databases, and other resources.
- Acceptance Reason: This solution is effective because it allows the security team to define specific rules in CloudFormation Guard to enforce their standards, and it fits well with the CI/CD pipeline. The notification via SNS ensures that the security team is alerted when issues arise, maintaining security compliance without slowing down the development process.
C) Create an Amazon Simple Notification Service (Amazon SNS) topic and an Amazon Simple Queue Service (Amazon SQS) queue. Subscribe the s...
Author: VenomousSerpent42 · Last updated Jul 19, 2026
A company is migrating one of its legacy systems from an on-premises data center to AWS. The application server will run on AWS, but the database must remain in the on-premises data center for compliance reasons. The database is sensitive to network latency. Additionally, the data that travels between the on-pr...
Let's break down each option and analyze which AWS solutions best meet the requirements of the company:
Requirements:
1. The application server will run on AWS, but the database remains on-premises for compliance.
2. Sensitive to network latency: The network connection between AWS and on-premises must be low-latency.
3. IPsec encryption: The data traveling between AWS and on-premises must be encrypted using IPsec.
A) AWS Site-to-Site VPN
- Analysis: AWS Site-to-Site VPN creates an IPsec-encrypted connection between an on-premises data center and an AWS VPC. This solution is ideal for securing traffic between AWS and on-premises infrastructure with IPsec encryption. However, Site-to-Site VPN uses the internet to connect, so it may not provide the low latency required for the sensitive database.
- Rejection Reason: While AWS Site-to-Site VPN provides IPsec encryption, it might not offer the low-latency connection needed for the database since it uses the public internet for the VPN tunnel, which could introduce variability in network performance.
B) AWS Direct Connect
- Analysis: AWS Direct Connect establishes a dedicated, private network connection between your on-premises data center and AWS. This solution can provide a low-latency and high-throughput connection, ideal for sensitive databases. Direct Connect also supports IPsec encryption through the use of a Virtual Private Gateway, which would meet the encryption requirement. The private connection ensures much lower latency compared to a VPN over the internet.
- Acceptance Reason: Direct Connect is the best solution for achieving low-latency, high-performance connectivity with IPsec encryption. It meets both the low latency and encryption requirements efficiently.
C) AWS VPN CloudHub
- Analysis: AWS VPN CloudHub connects multiple remote sites to AWS using Site-to-Site VPN connections. It is primarily used to connect m...
Author: Ahmed97 · Last updated Jul 19, 2026
A company has an application that uses dozens of Amazon DynamoDB tables to store data. Auditors find that the tables do not comply with the company's data protection policy.
The company's retention policy states that all data must be backed up twice each month: once at midnight on the 15th day of the month and again at midnight on the 25th day of the mont...
To meet the company's requirements of backing up DynamoDB tables twice a month and retaining the backups for 3 months, let's evaluate the options one by one based on key factors.
Key Factors:
1. Backup Frequency: The company needs backups twice a month (on the 15th and 25th at midnight), which requires the ability to specify a custom backup schedule.
2. Retention: Backups need to be kept for 3 months. This implies an automatic expiration policy to ensure compliance with retention.
3. Backup Service: The service used must support DynamoDB backup and allow the specified schedule and retention policies.
Evaluation of Each Option:
- A) Use the DynamoDB on-demand backup capability to create a backup plan. Configure a lifecycle policy to expire backups after 3 months.
- Pros: DynamoDB’s on-demand backup feature allows manual backups, and it integrates well with lifecycle policies for data retention (like deleting backups after 3 months).
- Cons: On-demand backups are typically more manual and may not easily support scheduled automated backups at specific times (e.g., the 15th and 25th). It is better suited for immediate, one-time backups rather than scheduled recurring backups.
- Conclusion: While it supports backup retention, it does not directly support the specific backup schedule needed here.
- B) Use AWS DataSync to create a backup plan. Add a backup rule that includes a retention period of 3 months.
- Pros: AWS DataSync is used to transfer data between different AWS services or between on-premises systems and AWS.
- Cons: DataSync is not designed for creating backups of DynamoDB tables; it is more for data transfer and replication. It doesn't directly support DynamoDB backup and restore functionalities.
- Conclusion: AWS DataSync is not the right tool for creating backups for DynamoDB tables, so this option is rejected.
- C) Use AWS Backup to create a backup plan. Add a backup rule that includes a retention period of 3 months.
- Pros: AWS Backup is designed to manage backups across various AWS services, including DynamoDB. It allows for defining backup schedules...
Author: Akash · Last updated Jul 19, 2026
A company needs a security engineer to implement a scalable solution for multi-account authentication and authorization. The solution should not introduce additional user-managed architectural components. Native AWS features should be used as much as possible. The security engineer has set up AWS Organizations with all features act...
To address the need for a scalable solution for multi-account authentication and authorization, it’s important to leverage AWS-native features to ensure simplicity and maintainability. Given that AWS Organizations and IAM Identity Center (formerly AWS Single Sign-On) are already in place, the solution should integrate well with these services, avoid introducing additional user-managed architectural components, and be scalable.
Key Factors to Consider:
1. AWS Identity Management Integration: The solution needs to utilize IAM Identity Center, which is designed to integrate with AWS Organizations and manage user access centrally across multiple accounts without adding complexity.
2. Scalability: The solution should be scalable to accommodate multiple accounts and ensure that access management can be handled efficiently as the number of users and accounts grows.
3. Minimizing Management Overhead: The solution should avoid introducing user-managed components like an external directory unless necessary, as the goal is to reduce overhead and take advantage of native AWS features.
Evaluation of Each Option:
- A) Use AD Connector to create users and groups for all employees that require access to AWS accounts. Assign AD Connector groups to AWS accounts and link to the IAM roles in accordance with the employees' job functions and access requirements. Instruct employees to access AWS accounts by using the AWS Directory Service user portal.
- Pros: AD Connector can integrate on-premises Active Directory with AWS, allowing centralized management of users and groups.
- Cons: This option introduces AD Connector, which is an external component that increases complexity and management overhead. This solution is not fully leveraging AWS-native features, and AWS IAM Identity Center is already enabled, which would make this approach unnecessary. Furthermore, AD Connector requires ongoing management of an external directory service, which goes against the requirement to minimize user-managed components.
- Conclusion: Not the best choice because it introduces an additional layer of management and is not fully AWS-native.
- B) Use an IAM Identity Center default directory to create users and groups for all employees that require access to AWS accounts. Assign groups to AWS accounts and link to permission sets in accordance with the employees' job functions and access requirements. Instruct employees to access AWS accounts by using the IAM Identity Center user portal.
- Pros: This solution is fully based on AWS-native features. IAM Identity Center allows for centralized user management, easy integration with AWS Organizations, and supports scalable, fine-grained access controls. Permission sets can be linked to user groups, making it easy to manage and automate user access.
- Cons: None significant. This approach fits well with the existing AWS setup and requirem...
Author: Sofia · Last updated Jul 19, 2026
A company has deployed Amazon GuardDuty and now wants to implement automation for potential threats. The company has decided to start with RDP brute force attacks that come from Amazon EC2 instances in the company's AWS environment. A security engineer needs to implement a solution that blocks the detected communi...
To address the requirement of automatically blocking communication from suspicious EC2 instances detected by Amazon GuardDuty (specifically for RDP brute force attacks), we need to focus on a solution that is efficient, integrates with GuardDuty's findings, and ensures the immediate isolation of the suspicious instance. Let's evaluate each option based on these key factors:
Key Factors:
1. Integration with GuardDuty: The solution must efficiently ingest and process GuardDuty findings to identify threats in real-time.
2. Blocking Communication: The solution must isolate the suspicious instance or block traffic to/from it while investigation or remediation is carried out.
3. Simplicity and Automation: The solution should minimize manual intervention and leverage AWS-native services for automated response.
Evaluation of Each Option:
- A) Configure GuardDuty to send the event to an Amazon Kinesis data stream. Process the event with an Amazon Kinesis Data Analytics for Apache Flink application that sends a notification to the company through Amazon Simple Notification Service (Amazon SNS). Add rules to the network ACL to block traffic to and from the suspicious instance.
- Pros: This solution uses Kinesis for processing events, which can scale effectively. The SNS notification is a good practice for alerting.
- Cons: Adding rules to a network ACL (NACL) is not the most effective or efficient way to block traffic for specific EC2 instances. NACLs operate at the subnet level, meaning the blocking action could impact all instances in the subnet, potentially creating unintended consequences. It is less granular than security group-based solutions.
- Conclusion: While this solution involves automation, using NACLs for blocking traffic is less precise than security group modifications and is not the best fit for isolating specific instances.
- B) Configure GuardDuty to send the event to Amazon EventBridge. Deploy an AWS WAF web ACL. Process the event with an AWS Lambda function that sends a notification to the company through Amazon Simple Notification Service (Amazon SNS) and adds a web ACL rule to block traffic to and from the suspicious instance.
- Pros: Using EventBridge is a good way to trigger automation based on GuardDuty findings. AWS WAF is designed for HTTP/S traffic and can block requests at the application layer.
- Cons: AWS WAF is primarily focused on web application traffic (HTTP/S) and wouldn't be effective for blocking RDP (which operates over TCP, port 3389). This makes WAF unsuitable for the specific need of blocking RDP brute force attacks.
- Conclusion: Although this option integrates well with EventBridge and Lambda, AWS WAF is not suited for blocking RDP traffic, making it an ina...
Author: FrozenWolf2022 · Last updated Jul 19, 2026
A company has an AWS account that hosts a production application. The company receives an email notification that Amazon GuardDuty has detected an Impact:IAMUser/AnomalousBehavior finding in the account. A security engineer needs to run the investigation playbook for this security incident and must ...
To respond to the Impact:IAMUser/AnomalousBehavior finding from Amazon GuardDuty, the security engineer needs to investigate the event without affecting the production application. The solution should quickly provide the necessary information to understand and remediate the suspicious activity.
Key Factors:
1. Non-Disruptive Investigation: The solution should allow for investigation without disrupting the production application.
2. Analysis of API Calls: The focus is on identifying what specific API calls were made, especially those related to the IAM user that triggered the GuardDuty finding.
3. Efficient Tools for Investigation: The solution should make use of tools that provide context and history about the suspicious activity to help the engineer analyze the situation without introducing unnecessary complexity.
Evaluation of Each Option:
- A) Log in to the AWS account by using read-only credentials. Review the GuardDuty finding for details about the IAM credentials that were used. Use the IAM console to add a DenyAll policy to the IAM principal.
- Pros: Using read-only credentials ensures no accidental changes are made to the environment. Adding a "DenyAll" policy to the IAM principal would immediately block the malicious activity.
- Cons: This option is too focused on mitigation (blocking the IAM user) and does not directly help with gathering detailed context about the API calls and understanding the incident. Blocking the IAM user immediately could disrupt the application or escalate the situation before a full investigation is done. It also doesn't involve tools specifically designed for in-depth investigation, such as Amazon Detective or AWS CloudTrail.
- Conclusion: While blocking the user may be necessary later, this solution does not prioritize investigation and analysis, which should be the first step.
- B) Log in to the AWS account by using read-only credentials. Review the GuardDuty finding to determine which API calls initiated the finding. Use Amazon Detective to review the API calls in context.
- Pros: Amazon Detective is a tool specifically designed for deep security analysis. It allows you to visualize and investigate the security findings from GuardDuty and provides context for the API calls and IAM activity, which is exactly what is needed in this situation.
- Cons: None significant. This option focuses on investigation first, with minimal disruption to the environment....
