AWS Certified DevOps Engineer Professional DOP-C02 (DOP-C02) — Questions 1426–1487

MemoryUtilization, published as a custom metric by the CloudWatch Agent, is calculated from /proc/meminfo or OS-level memory counters and represents the percentage of actual RAM in use. A memory leak causes this value to climb continuously over time as allocations are never freed, even when the workload is stable. Monitoring this metric reveals the leak as a monotonic upward trend, making it one of the most direct and essential signals for detection.

Enabling versioning on the bucket creates a new version for every object put, overwrite, or delete, so a delete operation only inserts a delete marker that hides old versions rather than purging them; with versioning enabled, you can permanently recover any object version. MFA Delete fortifies this by requiring an MFA code (using root credentials) to permanently delete an object version, suspend versioning, or change the versioning state—thus preventing attackers or accidental admin actions from irreversibly destroying data.

With session stickiness enabled on the ALB target group, the load balancer consistently routes a given client's requests to the same EC2 instance for the stickiness duration. When a few power users or long-lived connections generate heavy traffic, those specific instances absorb a disproportionate share of load, causing CPU utilization to spike even if the aggregate fleet average remains moderate. This creates a hot-spot pattern where some targets are saturated while others idle, and the Auto Scaling group, if scaling on average CPU, may not react in time.

The DynamoDB lock table uses conditional writes to ensure that only one Terraform run can hold the state lock at a time, preventing two `apply` executions from simultaneously updating the same S3 object and causing corruption. Enabling consistency checks (for example, verifying the lock acquisition and using DynamoDB's strongly consistent reads) ensures that the state pulled before a plan or apply is the latest known-good version, so stale or partially written state is never used as the basis for changes.

buildspec.yml is the correct file because AWS CodeBuild automatically looks for a file named buildspec.yml in the root of the source code directory, unless an alternate buildspec file is specified in the build project. This YAML file defines the build phases—install, pre_build, build, and post_build—along with environment variables, artifact output, and cache settings. For a Java application, the `build` phase would contain commands such as `mvn compile` or `gradle build` to compile the source code. Without a valid buildspec, CodeBuild will fail unless an inline buildspec is provided in the project configuration.

AWS Config conformance packs provide a way to deploy a collection of AWS Config rules and remediation actions across all accounts and Regions in an organization. A managed rule such as `cloudtrail-enabled` can be included in a conformance pack to verify that CloudTrail trails are configured and enabled, and the results are aggregated centrally in the AWS Config console for the entire organization. This approach gives a single, policy-as-code mechanism to enforce and audit CloudTrail enablement consistently across every account.

The AWS CLI's high-level command aws s3 cp does not directly invoke GetObject on a known key; it first performs a ListObjectsV2 operation to discover the objects in the bucket. Even if the IAM policy allows s3:GetObject, without the s3:ListBucket permission the CLI receives AccessDenied when attempting to list the source bucket. This is a common gotcha because users assume GetObject is sufficient for downloads, but the CLI's behavior requires both actions for object transfer commands.

Commit the variables in a .ebextensions/*.config file (e.g., option_settings for namespace aws:elasticbeanstalk:application:environment). CodePipeline packages the entire source into the application version, and the Elastic Beanstalk deployment agent processes this file automatically, injecting the values into the Node.js process's environment. This makes environment configuration declarative, versioned, and reproducible for every pipeline run, eliminating manual or post-deployment steps.

CodePipeline's S3 source action resolves the artifact by object key at the moment the pipeline execution starts. If an external system overwrites or deletes that object during the run, the pipeline may fetch a different revision or fail entirely because the original content no longer exists. Enforcing immutability through a write-once policy or access controls prevents this race condition and guarantees the pipeline operates on a stable artifact.

When an SSM association runs, the SSM Agent on the instance must assume an IAM instance profile that grants permissions such as ssm:DescribeAssociation and ssm:UpdateAssociationStatus. If that profile is missing, the agent cannot authenticate its requests to the Systems Manager API, and the association execution fails - typically with a status of 'Failed' or an 'InvalidInstanceId' error. This is the most common cause of an association failing for instances that are otherwise registered and visible in Manager.

Switching to count mode allows monitoring and tuning of WAF rules to eliminate false positives while still detecting SQL injection. Implementing an IAM policy with the aws:SourceArn condition key restricts database access to only approved AWS services, enhancing security beyond network controls.

VPC Flow Logs capture IP traffic metadata for every network interface in a VPC, subnet, or at the interface level, recording source and destination IP addresses, ports, protocol, packet/byte counts, and whether the action was accepted or rejected by security groups and network ACLs. Enabling flow logs on the affected VPC or subnets would immediately provide the raw data needed to identify the top talkers, unusual port usage, or malicious sources behind the spike. This makes it the correct service for diagnosing an unexpected increase in network traffic.

The correct approach in OpsWorks Stacks is to run the original 'Setup' recipe manually on the layer by using the 'Execute Recipes' action, which re-applies the Chef code that installs and configures the previous PHP version on all instances. Because lifecycle recipes should be idempotent, re-running the Setup recipe restores the desired PHP version without needing to recreate instances or manually edit files. This leverages OpsWorks's intended pattern for configuration changes and updates all instances in the layer in a controlled, automated manner.

A promoted read replica is a new database instance with a distinct DNS endpoint; the original master endpoint does not automatically reroute to the replica. Applications that connect using the old endpoint will continue hitting the original instance (or fail if it is down), so you must update your connection strings or configuration to use the promoted replica's endpoint. In complex environments, this is often managed via a CNAME that can be repointed to the replica, but the core requirement is that clients resolve to the new master.

The root cause is a TLS protocol version mismatch: the MySQL client library in the Docker image is too old to negotiate TLS 1.2, which is the minimum version required by Amazon RDS for MySQL. Rebuilding the Docker image with the latest MySQL client libraries ensures the client supports TLS 1.2 (and later), allowing the SSL handshake to succeed. This is the correct fix because it directly addresses the version negotiation failure at the transport layer without forcing insecure protocol fallbacks.

A PodDisruptionBudget with maxUnavailable:1 guarantees that at most one Pod is unavailable during voluntary evictions such as node drains, and pod anti-affinity rules (preferably with topologyKey kubernetes.io/hostname) force the scheduler to place replicas on distinct nodes. This means an involuntary node failure can kill only one replica, and the remaining replicas continue to serve traffic. Combined, these mechanisms directly address both failure classes—involuntary hardware failures and voluntary maintenance—by ensuring the application always has at least N-1 replicas available across different failure domains.

This creates a custom metric for error count.

DeletionPolicy: Retain on a resource instructs AWS CloudFormation to preserve that physical resource when the stack is deleted. Without it, DeleteStack removes every resource in the template; with Retain, the resource is simply left in place and becomes orphaned, allowing you to keep critical data such as databases or S3 buckets. This is the standard way to prevent accidental data loss during stack deletion.

An identity-based IAM policy can deny ec2:RunInstances unless the request's ec2:ImageId condition key matches the approved AMI ID. Because IAM policies are evaluated synchronously before the launch proceeds, this is a true preventive control that blocks the API call, not just an after-the-fact check. It can be attached to all relevant principals and combined with a Deny for a null ImageId to ensure every launch specifies an approved AMI.

The bucket policy allows s3:GetObject from anyone (*). Removing it blocks public read access.

Rotating the access keys means generating a new access key pair for the IAM user, updating dependent applications with the new credentials, and then deactivating and deleting the compromised keys. This immediately denies requests signed with the stolen keys because IAM checks key validity for every call, making it the fastest, least-disruptive way to stop the attacker.

Deregistering the instance from the Target Group stops new traffic from the Application Load Balancer while leaving the instance running, which preserves volatile memory for forensic collection. Stopping the instance (not terminating it) retains the EBS volumes, allowing investigators to create snapshots or attach them to a forensic workstation for offline analysis. This approach keeps the remaining fleet operational and maintains availability while containing the compromise.

AWS AppConfig is the correct choice because it is purpose-built for managing application configuration independently of code deployments. It supports creating and maintaining configurations in a central store, validating them with format or semantic checks, and rolling them out gradually across accounts and regions using deployment strategies. Unlike the other options, AppConfig also provides built-in monitoring, automatic rollback, and the ability to retrieve configuration at runtime, making it an enterprise-grade configuration management service.

The Elastic Beanstalk saved configuration feature exports the current environment's settings into a YAML file via `eb config save`, which can be downloaded and committed to version control. This file captures the complete environment configuration—platform, instance type, environment variables, scaling limits, health-check settings, and other option settings—without including transient data like application versions. Storing this file in Git enables you to recreate the same environment later with `eb config put`, apply it across regions or accounts, and revert to older configurations through normal version-control history.

Amazon OpenSearch Service provides the interactive search and visualization layer for a centralized logging solution. Logs ingested from Firehose, CloudWatch Logs subscriptions, or Logstash are indexed and available for real-time queries, aggregations, and Kibana dashboards, making it the correct target for log analytics. Unlike object storage or API audit trails, OpenSearch supports full-text search, ad hoc filtering, and anomaly detection across massive log volumes.

CloudTrail logs API calls and delivers to S3, which supports server-side encryption.

A NAT Gateway is a fully managed service deployed in a public subnet with an Elastic IP. To grant a private subnet outbound internet access, you must add a route 0.0.0.0/0 to the private route table pointing to the NAT Gateway. This performs source NAT, translating private instance traffic to the gateway's Elastic IP, while dropping unsolicited inbound traffic. It is highly available and scales automatically, making it the recommended solution for outbound connectivity without exposing the instances.

This option is correct because CloudFormation StackSets pre-provisions all infrastructure—ECS services, load balancers, security groups, and supporting resources—in both regions, ensuring the DR environment is ready to serve traffic. Aurora Global Database provides managed, low-latency cross-region replication, typically under one second, so the DR database is already live with minimal data loss (RPO). Route 53 health checks monitor the primary region and automatically shift DNS to the DR region using failover routing, enabling automated failover without manual runbooks. Together, these services achieve a very low RTO and RPO, satisfying the 30-minute requirement.

The AWS Config managed rule iam-role-max-session-duration evaluates every IAM role in the account, comparing each role's MaxSessionDuration setting against the rule's maxSessionDuration parameter. This rule is triggered proactively on configuration changes and periodically, so it detects both existing and newly modified roles, flagging any role whose allowed session duration exceeds the defined threshold as noncompliant. It integrates with AWS Organizations and can be remediated automatically or through Config conformance packs.

CloudWatch Logs Insights provides a queryable index of live application logs, so you can run interactive queries that filter for ERROR, FATAL, or exception patterns within the exact time window of a memory spike. Using the parse command on structured logs and grouping by timestamp or host, you can quickly identify a correlated error or log burst, making it the appropriate tool for real-time operational correlation between CloudWatch metrics and log data.

Global Accelerator uses two static Anycast IP addresses at AWS edge locations, which are announced from multiple points of presence. It monitors the health of your ALB or NLB endpoints and automatically routes each user's traffic to the closest endpoint that is healthy, using the AWS backbone instead of the public internet. This improves availability by failing over to a healthy endpoint within seconds and improves performance by reducing latency and jitter, but it still depends on the ALB to handle the actual HTTP/HTTPS load balancing.

Create an IAM role with a policy such as s3:GetObject and s3:ListBucket, then attach it to the EC2 instance profile. The instance will automatically obtain temporary security credentials from AWS STS through the instance metadata service, which are rotated every few hours and never stored on disk. This follows least privilege, avoids long-lived keys, and is the AWS best practice for granting permissions to a running instance.

The built-in deployment configuration CodeDeployDefault.ECSCanary10Percent5Minutes instructs CodeDeploy to initially route 10% of the load balancer's traffic to the new ECS task set (the green environment) while the remaining 90% continues to go to the blue task set. After a 5-minute waiting period, during which health checks and metrics can be evaluated, CodeDeploy automatically shifts the remaining 90% of traffic to green, completing the deployment. This two-step canary pattern exactly satisfies the requirement for a 10% initial shift with a 5-minute soak before the final 90% cutover.

Lifecycle hooks can trigger CodeDeploy deployments on launch.

A manual RDS snapshot taken immediately before the migration is the only mechanism that provides a point-in-time, database-level restore point independent of the application deployment. If the migration script corrupts data or fails mid-transaction, you can restore the instance from this snapshot and redeploy the previous code version, ensuring a clean rollback. This is the standard pre-migration practice because other options either target application code only or do not give you a deterministic restore point for the database itself.

An UpdateWaitCondition (typically implemented as a WaitCondition resource or UpdatePolicy with WaitOnSignals) makes CloudFormation pause the stack update until each new instance sends a success signal, usually via cfn-signal after it has passed health checks and is ready to serve traffic. This ensures that CloudFormation does not complete the update and potentially remove old resources until the new capacity is confirmed operational, directly preventing application downtime during the replacement process.

Removing the output from the CloudFormation stack is the only direct way to prevent the password from being exposed in the stack's output section. Outputs are stored in plaintext by CloudFormation and are retrievable via the console, APIs such as DescribeStacks, and any logging that captures API responses. By eliminating the output, you ensure that the password does not appear in that specific exposure path; additional best practices like using Secrets Manager for retrieval by applications should still be implemented to protect the secret throughout its lifecycle.

Enabling Block Public Access (BPA) on the bucket is the correct immediate remediation because it applies four distinct settings—BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets—that override all existing and future public access grants, including those from object ACLs, bucket policies, and access point policies. This is the most direct and comprehensive way to seal the bucket at the resource level until a full audit can be completed, and it prevents accidental re-publication through any subsequent misconfiguration.

CloudTrail is the only service that records management-plane API events such as AuthorizeSecurityGroupIngress, RevokeSecurityGroupEgress, and CreateSecurityGroup, including the requesting IAM principal, source IP, and request parameters. Delivering those trail logs to a centralized S3 bucket with S3 Object Lock enabled in compliance mode makes each log object write-once-read-many (WORM), preventing any user—even one with administrative privileges—from altering or deleting audit evidence, which satisfies the immutability and centralized audit requirements. Additionally, enabling CloudTrail in all accounts with a single organization trail and delivering to a central bucket provides a complete, tamper-proof, cross-account audit record of every security group change.

CloudWatch alarms use the state INSUFFICIENT_DATA when the number of metric data points available in the evaluation period is less than the number required to determine the alarm state. This commonly occurs for a newly created alarm before the first metric points arrive, when an instance is stopped and stops publishing metrics, or when the metric name is missing. The alarm cannot evaluate to ALARM or OK until the metric stream provides enough valid points within the configured period.

The Auto Scaling group’s activity history is the authoritative record of every scale-out and scale-in event, including the time, instance ID, reason code, and status (e.g., 'InProgress', 'Successful', or 'Failed'). By reviewing it, you can determine whether the CloudWatch alarm triggered the scaling policy, whether the capacity was blocked by the maximum instance limit, a service quota, or a launch template error. This directly shows why the instance did not receive the expected scale-out action, making it the correct first troubleshooting step.

Root access keys are long-lived and carry unrestricted permissions that cannot be scoped down by any IAM policy. If they are leaked, the entire account is compromised, and because AWS does not allow you to restrict root credentials, the keys remain an unmanageable risk. Instead, create IAM users with only the necessary permissions, and use temporary credentials from AWS STS (roles) for programmatic access, so each request is authenticated with least privilege and can be audited.

DynamoDB auto scaling adjusts provisioned capacity based on actual usage, preventing most throttling, but it cannot anticipate sudden one-off spikes because it relies on trends. A Lambda dead-letter queue, combined with the function's built-in retries and exponential backoff, ensures that any event which still fails due to a throttle is safely captured for manual or automated replay rather than silently dropped. This two-tier approach balances elasticity with data durability, which is why it is the recommended solution for unpredictable write spikes.

AWS STS is the correct service for generating temporary credentials for an IAM user. APIs like GetSessionToken and AssumeRole return an access key ID, secret access key, and a session token that is valid for a specified duration (from 15 minutes up to 36 hours). The temporary credentials carry the same permissions as the IAM user's existing permissions (in the case of GetSessionToken) or the permissions defined in the assumed role's policy, making it ideal for short-lived access without rotating long-term keys.

Amazon RDS supports encryption at rest only as an attribute that is set during the initial Create DB instance operation. When you provision the instance, you choose to enable encryption and optionally select a customer-managed KMS key; this setting is permanently attached to that instance. If you skip this option at launch, you cannot enable it later—you must migrate data to a newly created encrypted instance.

EC2 Auto Recovery uses a CloudWatch alarm on the StatusCheckFailed_System metric to detect underlying host or network failures. When the alarm triggers, EC2 automatically relaunches the same instance on a new physical host while preserving the instance ID, private and Elastic IP addresses, and attached EBS volumes. This in-place recovery requires the instance to be EBS-backed and in a VPC, making it the correct choice for restoring availability after hardware failure.

EC2 Instance Connect opens a temporary SSH session through the AWS Console, giving you direct interactive access to the running instance. Once connected, you can read /var/log/cloud-init-output.log, which captures the output of cloud-init including your user-data script, so any error or traceback from the script will be visible there. It is an effective diagnostic because it accesses the primary log source without requiring pre-installed agents or external log forwarding.

This pair provides end-to-end compliance: AWS Config continuously evaluates security group resources against rules like restricted-common-ports, and when an SG is non-compliant, Config's remediation action triggers an AWS Systems Manager Automation runbook (e.g., AWS-DisablePublicSecurityGroupIngress or a custom runbook). The Automation step performs the actual modification, such as revoking offending ingress rules, thus closing the loop. Config can remediate automatically via SSM Automation without manual intervention, making this the correct solution.

Failover routing is the Route 53 policy explicitly designed for active-passive disaster recovery. It lets you mark one record (or record set within a group) as the primary and another as secondary, and associate each with a health check. Route 53 monitors the primary endpoint's health and, when the health check fails after the configured threshold, automatically returns the secondary record's answer for all DNS queries. This deterministic, health-driven promotion of the standby region matches the company's requirement for automatic failover.

An Auto Scaling group with health checks automatically replaces failed EC2 instances by monitoring them using EC2 status checks and optionally Elastic Load Balancing health checks. When an instance is marked unhealthy, the ASC terminates it and launches a new instance in an attempt to maintain the desired capacity, and it does so across multiple Availability Zones to increase resilience. This meets the requirement for automatic replacement based on instance health, and because it is a continuous, managed process, it is the correct solution for keeping critical applications available.

AWS Config rules natively support an automated remediation feature that links a non-compliant rule evaluation to an AWS Systems Manager Automation document. This is the intended, first-party mechanism: the Automation document can run pre-built or custom steps (e.g., AWS-TagResource) to fix tag violations, and Config can automatically apply remediation to affected resources. Because it is built into the Config service itself, it avoids the need to wire separate event routing or manual workflows, making it the most direct and operationally efficient option.

This option is correct because when the 'Private DNS names enabled' option is not selected for an Amazon ECR VPC endpoint, the default DNS endpoint (ecr.<region>.amazonaws.com) continues to resolve to public IP addresses. Since the ECS task runs in a private subnet with no internet route, the ECS agent sends the request to a public IP that is unreachable, and the VPC endpoint responds with AccessDenied because the request is not being handled by the endpoint. Enabling private DNS names creates a Route 53 private hosted zone that associates the endpoint's DNS with its private IP, ensuring traffic destined for ECR is routed through the VPC endpoint and bypasses the public network.

Adding an appropriate index transforms a full table scan into an index seek, drastically reducing the number of rows the database engine must read and process, which directly lowers the CPU cycles spent on evaluating rows, join operations, and sort operations. An index that matches the query predicate (e.g., on the columns used in WHERE, JOIN, or ORDER BY) allows the optimizer to access only relevant pages, shrinking buffer pool I/O and improving overall query latency. This is the root-cause fix because it eliminates the unnecessary CPU work rather than merely hiding the symptom.

In CodePipeline, every pipeline is bound to a single region. If a Deploy action references a CodeDeploy application in another region, it is treated as a cross-region action and must be explicitly configured with the Region property. Without that, the pipeline attempts to execute the action in us-east-1, where no deployment group exists, producing the 'Deployment group not found' error. The fix is to add the cross-region configuration or move the Deploy action to the same region.

Creating a new Elastic Beanstalk environment and then swapping the environment CNAMEs is the native blue/green deployment method. The new environment is fully provisioned, tested, and warmed up behind its own URL before the CNAME swap atomically redirects production traffic. This enables immediate rollback by swapping back, and it is the standard Elastic Beanstalk pattern for zero-downtime blue/green releases.

Deploying EC2 instances across two Availability Zones behind an Application Load Balancer provides both fault isolation and active load balancing. The ALB performs health checks, routes traffic only to healthy instances, and can distribute requests across both AZs, so if one entire AZ becomes unavailable, the other continues to serve traffic. This is the standard architecture for achieving regional high availability with an HTTP web application.

HTTPCode_Target_5XX_Count is the definitive metric for monitoring application health because it directly counts HTTP 5xx responses returned by the registered targets (EC2 instances, containers, or Lambda). This value reflects actual application failures—unhandled exceptions, internal server errors, or gateway timeouts—making it the most precise indicator of unhealthy application logic. It is the recommended metric to alarm on for detecting when your web application is returning server-side errors to users.

Run Command is a valid Systems Manager capability because it lets you execute operational commands and scripts on EC2 instances and on-premises machines via the SSM agent, without opening inbound ports like SSH or RDP. It supports ad-hoc execution across targets defined by tags, resource groups, or individual instance IDs, with features like rate control, error thresholds, and integration with EventBridge for automation.

Configuring the source stage to trigger on all branches is the recommended approach because CodePipeline natively supports branch filters on source actions, allowing a single pipeline to react to every branch push. Branch-specific logic can then be implemented in the test stage using environment variables or run-time conditions to vary test suites, while a manual approval action can be conditionally added to the deploy stage only when the branch is 'main'. This leverages built-in pipeline features, avoids duplication, and keeps the deployment workflow centralized and auditable, which is the most scalable and maintainable design.