AWS Certified DevOps Engineer – Professional 1-10

In a Lambda deployment with AWS CodeDeploy, hooks in the AppSpec file let you run validation logic at each lifecycle stage.
The BeforeAllowTraffic hook runs immediately before traffic is shifted to the new version, so it is the ideal place to embed validation that waits for the database changes to finish propagating.
This guarantees that dependencies are ready before the traffic shift and prevents the intermittent failures.
AfterAllowTraffic runs after the shift, so it does not help avoid the failures.
validateService is a hook for EC2/on-premises deployments and cannot be used in Lambda deployments.
Option C targets the pre-deployment phase and is not tied to traffic control.
Keep in mind that the only hooks available for Lambda are BeforeAllowTraffic and AfterAllowTraffic.
AWS CodeDeploy AppSpec “hooks” section

This question asks about the execution order of the CodeDeploy lifecycle hooks for EC2/on-premises deployments.
In a blue/green deployment, the application installation process happens after the replacement instances launch but before they receive traffic.
The BeforeInstall hook runs before the new application version is installed, making it the ideal place to download and install the license file.
AfterBlockTraffic and BeforeBlockTraffic run around the point at which traffic is deregistered from existing instances, and do not fit this purpose.
DownloadBundle is a reserved event managed by the CodeDeploy agent, and you cannot specify a user script for it.
Accurately understanding the execution order of the hooks is the key exam takeaway.
AWS CodeDeploy AppSpec “hooks” section

The requirement is to allow only VPC-connected Lambda functions with the least operational overhead.
If you set a Null condition on lambda:VpcIds in a service control policy (SCP) to deny Lambda creation when there is no VPC connection, you can enforce it automatically and preventively across all member accounts, eliminating the need for manual remediation.
A custom AWS Config rule is detective; it cannot prevent the creation of non-compliant resources and requires after-the-fact remediation.
Control Tower proactive controls require building CloudFormation Hooks, which increases operational overhead.
Specifying allowed values is also an option, but a blanket deny based on a Null check is simpler and more reliable.
Keep in mind that SCPs are effective for preventive governance.
Service control policies (SCPs)

The requirement is to automate Control Tower guardrails with version control, review, rollback, and approval governance, all at minimal operational overhead.
By templating each guardrail as an AWS::ControlTower::EnableControl resource in CloudFormation and managing it in a CodeConnections-compatible Git repository, you can achieve version control, change review, and rollback with a standard Git workflow.
By targeting EnableControl at the OU level, you can apply it consistently to all accounts under that OU.
Furthermore, if EventBridge detects a merge to the repository and starts CodePipeline, only approved changes are deployed automatically.
Options that lack a pipeline and approval flow, or that use manual starts and account-level configuration, incur higher overhead.
The option that uses S3 as the source has no version-control or approval mechanism like Git.
A GitOps-style configuration is the most efficient.
About AWS Control Tower controls (guardrails)

The requirement is to query both the application logs and the AWS account’s API activity.
The CloudWatch agent can send logs to CloudWatch Logs, and CloudTrail can also deliver API logs to CloudWatch Logs, so you can query both together with CloudWatch Logs Insights.
Because the CloudWatch agent cannot send logs directly to S3, a configuration that sends directly from the agent to S3 does not work.
A configuration that loads data into Redshift via Kinesis requires routing the data through an intermediary and has higher operational overhead.
Consolidating the log destination into CloudWatch Logs and analyzing with Logs Insights is the standard minimal-configuration pattern.
Analyzing log data with CloudWatch Logs Insights

The requirement is to keep the Aurora cluster available with as little disruption as possible during maintenance.
If you enable Multi-AZ and place a standby (reader) instance in a different Availability Zone, failover during maintenance can minimize disruption.
Writes are directed to the cluster endpoint (primary), and reads to the reader endpoint.
With a single-instance configuration, an outage occurs during maintenance.
A configuration that mixes reads and writes on a custom ANY endpoint is not appropriate given Aurora’s characteristic that writes are limited to the primary.
Adding a replica for redundancy is the key point for improving availability.
High availability for Amazon Aurora

The requirement is to be notified when a KMS key has not been rotated for 90 days.
A custom AWS Config rule can evaluate the number of days since a key’s last rotation and publish to an Amazon SNS topic when it exceeds 90 days, providing continuous compliance monitoring and notification.
KMS itself does not have a feature to notify SNS based on elapsed days.
Trusted Advisor does not provide a check that evaluates key rotation deadlines.
Security Hub is useful for aggregated security findings, but it does not directly perform an arbitrary 90-day rotation evaluation.
Keep in mind that a custom AWS Config rule is suited to continuous evaluation of custom requirements.
Evaluating resources with AWS Config rules

The requirement is durable shared storage that provides SMB for Windows and NFS for Linux, with all instances reading and writing.
A Multi-AZ Amazon FSx for NetApp ONTAP configuration supports both the SMB and NFS protocols and provides sub-millisecond low latency and high availability.
For Linux, use Amazon EFS with Multi-AZ mount targets alongside it to ensure concurrent NFS access and durability.
Updating the user data in each application’s launch template lets new instances launched by Auto Scaling automatically mount the file system.
gp3 EBS is not suitable for shared file access from multiple instances.
Instance refresh and individually updating mounts are not required to automate this requirement.
Keep in mind the selection criteria for shared file storage based on the use case.
What is Amazon FSx for NetApp ONTAP

The requirement is to detect sensitive information in S3 across the organization, aggregate the findings centrally, and quarantine the relevant objects, all at minimal operational overhead.
Enabling Amazon Macie at the organization level automatically scans S3 across all accounts and Regions and uses machine learning to detect sensitive data such as PII.
Aggregating Macie’s findings into AWS Security Hub lets the security officer review them from a single dashboard.
Furthermore, using an EventBridge rule to trigger a Lambda function on a Macie finding, copying the target object to a quarantine S3 bucket and deleting the original, automates remediation as well.
Building custom detection logic is more complex, and an SCP cannot inspect or move data, making it inappropriate.
Keep in mind the standard configuration of Macie, Security Hub, and EventBridge integration.
What is Amazon Macie

The requirement is to operate the private-subnet EC2 instances behind an ALB while accepting requests from IPv6 clients.
If you add an IPv6 CIDR block to the VPC and the ALB’s subnets and set the ALB’s IP address type to dualstack, the ALB can accept requests over both IPv4 and IPv6 and forward them to the EC2 instances via the target group.
The ALB supports IPv6 termination and forwards to the backend over IPv4, so there is no need to assign IPv6 to the EC2 instances themselves.
You cannot assign an Elastic IP to an ALB.
Replacing it with an NLB is unnecessary for this requirement; the ALB’s dualstack support is sufficient.
The key point is IPv6 support through the load balancer’s dualstack setting.
About Application Load Balancers