Copyright (c) 2025 MindMesh Academy. All rights reserved. This content is proprietary and may not be reproduced or distributed without permission.

4.3.5. Sample Questions - Domain 5: Continuous Improvement for Existing Solutions

Question 1:

A DevOps team wants to implement a robust monitoring solution for their microservices application running on "Amazon EKS". They need to gain end-to-end visibility into requests as they traverse multiple services, identify latency bottlenecks between components, and visualize service dependencies. Which AWS service is best suited for providing this distributed tracing capability?

A) "Amazon CloudWatch Logs" B) "AWS CloudTrail" C) "AWS X-Ray" D) "Amazon Inspector"

Correct Answer: C
Explanation:
  • A) "Amazon CloudWatch Logs": "CloudWatch Logs" aggregates logs from various sources. While essential for troubleshooting, it provides individual log entries and doesn't inherently trace a single request's path across multiple distributed services or visualize service dependencies.
  • B) "AWS CloudTrail": "CloudTrail" records API calls made to AWS services for auditing and governance. It does not provide application performance insights or end-to-end tracing of requests through an application's internal components.
  • C) "AWS X-Ray": "AWS X-Ray" is a service that helps developers analyze and debug distributed applications. It collects data about requests that your application serves, and uses this data to generate a service map and detailed segment timelines. This allows you to visualize end-to-end request flows, identify performance bottlenecks across multiple microservices, and understand service dependencies. This directly addresses the requirements for distributed tracing and performance analysis in a microservices architecture. This aligns with the First Principle of Holistic Observability and Distributed Performance Diagnostics.
  • D) "Amazon Inspector": "Amazon Inspector" is an automated security assessment service that helps identify security vulnerabilities and deviations from best practices for "EC2 instances" and container images. It's for security, not for application performance tracing.
Question 2:

An architect needs to implement a system that automatically remediates non-compliant AWS resource configurations. For example, if a security group is created with overly permissive inbound rules (e.g., 0.0.0.0/0 for SSH), the system should detect this and automatically apply a predefined, more restrictive rule. Which AWS service combination can be used to detect this non-compliance and trigger automated remediation?

A) "AWS CloudTrail" and "Amazon SNS" B) "AWS Config" and "AWS Systems Manager Automation" C) "Amazon CloudWatch" and "AWS Lambda" D) "AWS Security Hub" and "Amazon SQS"

Correct Answer: B
Explanation:
  • A) "AWS CloudTrail" and "Amazon SNS": "CloudTrail" records API calls, and "SNS" sends notifications. While "CloudTrail" would log the creation of the permissive security group, it doesn't inherently provide the compliance rule evaluation or direct automated remediation that "Config" and "Systems Manager" provide.
  • B) "AWS Config" and "AWS Systems Manager Automation": "AWS Config" continuously monitors and records AWS resource configurations and evaluates them against desired configurations using Config Rules. When a resource is found to be non-compliant (e.g., an overly permissive security group), "AWS Config" can trigger an "AWS Systems Manager Automation document" to perform automated remediation actions, such as applying a more restrictive rule. This directly addresses the requirements for detecting non-compliance and triggering automated remediation. This aligns with the First Principle of Automated Governance and Continuous Security Remediation.
  • C) "Amazon CloudWatch" and "AWS Lambda": "CloudWatch" monitors metrics and logs, and "Lambda" can execute custom code. While a "Lambda function" could be triggered by a "CloudWatch Event" (from "Config"), "Config" is the specific service for detecting configuration compliance, and "Systems Manager Automation" provides robust runbooks for remediation, often preferred over custom "Lambda" logic for standard ops tasks.
  • D) "AWS Security Hub" and "Amazon SQS": "Security Hub" aggregates security findings, and "SQS" is a message queue. While "Security Hub" can identify non-compliant resources, it typically integrates with other services (like "Config" or "Systems Manager") for remediation, and "SQS" is a transport layer, not a direct trigger for automated remediation.
Question 3:

A company wants to ensure that all changes to their AWS infrastructure are version-controlled, auditable, and can be easily rolled back to previous states. The architecture team wants to manage all infrastructure changes using code, integrated with their "CI/CD" pipeline. Which approach is MOST suitable for this requirement?

A) Performing changes directly in the "AWS Management Console" and relying on "CloudTrail" for audit. B) Using "AWS Systems Manager Run Command" to execute scripts on "EC2 instances" for infrastructure updates. C) Implementing "Infrastructure as Code (IaC)" using "AWS CloudFormation" or "AWS CDK", stored in a version control system. D) Storing manual configuration scripts in an "S3 bucket" with versioning enabled.

Correct Answer: C
Explanation:
  • A) Performing changes directly in the "AWS Management Console" and relying on "CloudTrail" for audit: This violates the core principles of "IaC". While "CloudTrail" provides an audit log, changes made manually in the console are not version-controlled, repeatable, or easily rollback-able to a specific state defined by code. This leads to configuration drift and operational inconsistencies.
  • B) Using "AWS Systems Manager Run Command" to execute scripts on "EC2 instances" for infrastructure updates: "Systems Manager Run Command" is for executing commands on instances, not for defining and managing the underlying AWS infrastructure itself ("VPCs", databases, load balancers, etc.) in a version-controlled, repeatable way. It's an operational automation tool, not an "IaC" tool.
  • C) Implementing "Infrastructure as Code (IaC)" using "AWS CloudFormation" or "AWS CDK", stored in a version control system: This is the most suitable approach. "IaC" (like "CloudFormation" or "CDK") allows you to define your AWS infrastructure using code (templates/scripts). Storing this code in a version control system (like "Git") ensures that every change is tracked, auditable, and allows for easy rollbacks to previous versions. Integrating it with a "CI/CD" pipeline automates deployments and ensures consistency. This aligns with the First Principle of Automated, Version-Controlled Infrastructure and Operational Consistency.
  • D) Storing manual configuration scripts in an "S3 bucket" with versioning enabled: While "S3 versioning" provides object history, storing manual configuration scripts there doesn't make them "IaC". It still relies on manual execution, doesn't manage dependencies across resources, and doesn't inherently provide the same level of consistency or easy rollback as a declarative "IaC" tool.