AWS Certified Security - Specialty (SCS-C03) Course

A classification-driven monitoring policy starts with three separate consequences: disclosure impact from unauthorized access, integrity impact from unauthorized modification, and availability impact from loss or interruption. A public dataset can have low disclosure impact but high integrity and availability impacts. A single label such as “confidential” can hide these differences.

A monitoring requirement starts with a prioritized attack scenario, not a list of available logs. Describe the actor’s capability, the asset, the abusive action, and the business consequence. Prioritize using impact, plausible exposure, and existing safeguards. A severe consequence with a credible attack path deserves attention even when its activity resembles normal use.

CloudWatch workload telemetry describes resource and application behavior. Metrics measure properties over time; application and system logs contain details emitted by their producers. CPU utilization can reveal saturation, and an application log can explain a failed transaction. Neither inherently identifies the AWS principal that changed the infrastructure.

A reliable alarm starts with the metric identity and statistic, not the threshold. A metric is identified by its namespace, name, and complete dimension set. Selecting one instance does not select the fleet, and CloudWatch does not automatically aggregate custom metrics across dimensions. Match the dimensions to the failure boundary: one unhealthy instance can disappear inside a fleet average.

Log retention specifies how long records should remain available. A retention setting often implements an expiration schedule: records become eligible for removal after a configured age. That schedule does not necessarily reject a separate request to alter or delete records earlier.

Define a searchable window: the age range investigators must be able to query within an agreed response time. Separately define total retention: how long records must remain available, including any archived period. These windows overlap. Sixty days searchable within 180 days total does not mean 240 days of retention. Set both commitments per log category and investigative purpose.

Log generation is not log delivery. An application can write healthy local files while nothing reaches CloudWatch Logs. Likewise, enabling an AWS service does not automatically enable every supported log destination. Identify the producer, its delivery mechanism, and its configured destination before changing permissions.

An organization trail applies one centrally managed trail configuration to the management account and member accounts in AWS Organizations. Configure the organization prerequisites, including all features and CloudTrail trusted access, then create it from the management account or a CloudTrail delegated administrator. Accounts joining the organization are brought into its scope automatically; member accounts cannot modify or stop the organization trail.

Cross-account observability lets a monitoring account inspect source logs without making an independent archive. For preservation, distinguish access to logs from delivery of stored copies. CloudWatch Logs also supports organization-based centralization into destination log groups; this lesson follows a different, explicit pattern: cross-account subscriptions to a security-owned S3 archive.

A canonical mapping is a versioned contract from one source format and event type into a shared event class. Parse the record, identify its source version and event type, then select the mapping. Define each destination field's meaning, type, allowed values, and missing-value behavior. JSON conversion alone provides none of these guarantees. The field names below are illustrative, not official OCSF attributes.

Event correlation links observations through an explicit relationship: the same credential performed two actions, a session belongs to a role, or an action affected a particular resource. Start with that relationship, then choose its keys. A shared source IP is only supporting context: NAT and proxies can combine unrelated actors, and one actor can change addresses.

Log normalization establishes how to interpret an event. Different source fields and values are represented using common meanings, so a query can compare authentication outcomes without separately interpreting each source format. Merely collecting records together, or converting them all to JSON, does not establish that common meaning.

Amazon Athena over S3 and CloudWatch Logs Insights have different query boundaries. Athena reads objects in Amazon S3 through table definitions; the source data stays in S3 rather than being loaded into an Athena database. Logs Insights queries events stored in CloudWatch Logs, scoped to selected log groups and a time range.

CloudWatch Logs Insights QL queries events already stored in CloudWatch Logs. Start by selecting the relevant log groups and the smallest useful time range. Those choices bound the search before parsing or aggregation. In the console, select the groups directly; programmatic queries can use SOURCE to select groups by criteria such as name prefix and account. SOURCE is not supported in the console query editor.

Amazon GuardDuty analyzes supported activity and security signals to detect potential threats. Its behavioral detections use techniques such as anomaly detection and threat intelligence. A finding expresses a detection supported by particular observations; it is not, by itself, proof of compromise.

Security Hub CSPM aggregates findings from enabled integrations and its security checks using the AWS Security Finding Format (ASFF). Common fields let you filter findings from different providers together. Normalization makes records comparable; it does not make their detection methods, evidence depth, or severity judgments equivalent.

A baseline describes expected behavior for a particular metric and context, not a universal safe value. Define the event, population, aggregation period, and statistic before learning it. Access-denied counts for a production application should not share a baseline with an administrative application simply because both count the same event. Pooling them can hide a small application's surge inside a large application's normal variation.

A GuardDuty finding is a structured detection record, not a complete transcript of the underlying activity. In the native API representation, Type identifies the detection category, Resource describes the affected entity, and Service carries detection-specific context. Where present, Service.Action describes the observed action and Service.ResourceRole distinguishes an actor from a target. Available evidence varies by finding type; do not assume every finding contains an IP address, API operation, or process.

Macie produces two categories of findings. Policy findings describe potential security or privacy issues with S3 buckets, such as public access. Sensitive-data findings describe sensitive data discovered in S3 objects through analysis. Finding severity expresses priority; it does not make the two categories interchangeable.

Security Hub CSPM automation rules match finding criteria and update supported finding fields, such as severity, workflow status, notes, and user-defined fields. They can prioritize an investigation or suppress an accepted exception. They do not change the affected resource, invoke a remediation runbook, or prove that a failed control now passes.

An authoritative baseline must identify the approved version, applicable targets, comparison logic, and exceptions. Automate deployment of that definition, not just a recurring scan. Record the template revision, rule parameters, or host document version with each assessment so a later investigator can reconstruct what was expected.

EventBridge Scheduler invokes a configured target API on a schedule; it does not need an event bus rule. Use cron for calendar requirements and rate for elapsed intervals. For example, cron(0 9 ? * MON-FRI *) means weekday mornings at 09:00 in the configured time zone. Scheduler cron has six fields, including year, and uses ? for the unspecified day-of-month or day-of-week field.

AWS Config evaluates a resource against a rule: does this configuration satisfy this policy? Managed or custom rules can express security requirements, but also operational requirements such as required tags. Detective rules evaluate deployed resources on configuration changes, periodically, or both, depending on the rule.

A conformance pack is a YAML template that deploys AWS Config rules and their remediation configurations as one managed collection. Rule definitions specify what to assess; remediation configurations associate selected rules with corrective actions. A successful deployment means the collection was provisioned, not that its resources are compliant.

A State Manager association binds a Systems Manager document and its parameters to targets and an execution schedule. It also carries execution controls and compliance settings. For node configuration, the document runs through SSM Agent on managed nodes; creating an association does not make an unmanaged or unreachable machine executable.

Security Hub CSPM evaluates enabled security controls associated with security standards. Each control defines a specific configuration requirement. Its documentation identifies its evaluation method, supported resources, and whether checks are change-triggered or periodic. Continuous assessment does not mean every resource change immediately produces a new result.

AWS CloudTrail records activity: which API operation was invoked, its recorded caller and request context, and the outcome information available for that event. A recorded AuthorizeSecurityGroupIngress request can identify the requested rule and the calling role session. An event with an access-denied error is evidence of a failed attempt, not evidence that the rule was added.

Start with a requirement for a particular data class, not a blanket assumption about all telemetry. Record the approved Regions and whether the restriction covers collection, processing, persistent copies, and remote access. Logs can contain identities, addresses, request parameters, and payloads; select only the fields needed for the investigation or audit purpose.

A log repository has three distinct contracts: who may deliver objects, how those objects are encrypted, and who may consume them. This example uses VPC Flow Logs delivered directly to S3. These records describe network traffic metadata, not packet payloads. CloudTrail records API activity; AWS Config records resource configuration history. Neither replaces this producer.

In a versioning-enabled general purpose bucket, an object key names a sequence of object versions. A new upload to the same key creates a new version ID and makes the previous version noncurrent; it does not replace that version's bytes. Versioning preserves history, but does not itself prevent an authorized caller from permanently deleting a particular version.

S3 Glacier storage classes are storage classes for objects in S3 buckets: S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, and S3 Glacier Deep Archive. An object in one of these classes still has an S3 bucket, key, and version ID when versioning is enabled. Its retention mechanism is S3 Object Lock, not Glacier Vault Lock.

An audit pipeline starts with an evidence requirement, not a destination. For each investigative question, identify the actor, action, target, event time, source context, and outcome you need to establish. Preserve role-session and identity-provider context where available; a temporary role identity alone may not identify the originating person.

Amazon S3 Object Lock protects individual object versions in a versioned bucket. Identify authoritative evidence by bucket, key, and version ID, together with its retention metadata. A new upload to the same key creates another version; it does not rewrite the protected version. A delete request without a version ID can create a delete marker, hiding the object from ordinary reads without permanently deleting the retained version.

A security lake needs two different contracts. A raw dataset preserves source-format records and their provenance so investigators can revisit the original event or reprocess it with a corrected parser. A normalized dataset provides consistent event classes, field names, and types for cross-source analysis. Keep their locations, permissions, and retention policies distinct; normalization is not proof that every original field survived.

Amazon Data Firehose, formerly Amazon Kinesis Data Firehose, buffers records before delivery. Size and interval settings generally trigger delivery when either condition is met, but they are hints, not end-to-end latency guarantees. Smaller buffers favor freshness; larger batches reduce request overhead and can produce larger S3 objects.

Amazon Security Lake stores security telemetry in Amazon S3; it is not a detection engine or an investigation console. For supported AWS sources, it collects the selected records, normalizes them to the Open Cybersecurity Schema Framework (OCSF), and writes Apache Parquet. Source type and source version determine which dataset and schema downstream tools must understand.

Lake Formation authorizes access to cataloged data; it is neither the log store nor the query engine. For a query-based Security Lake subscriber, source selection establishes which security-log tables are shared. The subscriber queries those tables through an integrated engine such as Athena rather than receiving object notifications for direct ingestion.

A data-access subscriber reads Security Lake objects from Amazon S3, typically to ingest them into a third-party tool. It can receive new-object notifications through Amazon SQS or an HTTPS endpoint. A query-access subscriber queries shared tables through AWS Lake Formation, commonly using Amazon Athena, instead of ingesting every object.

Athena tables describe how to read S3 objects; creating an external table does not import or rewrite those objects. The AWS Glue Data Catalog holds column types, the S3 location, the serialization/deserialization library (SerDe), and partition metadata. Separate tables should describe sources with different record layouts, even when their files share a bucket.

The important distinction is when work is done, not whether the interface accepts SQL. In indexed log search, Amazon OpenSearch Service builds searchable structures as documents arrive. An inverted index maps terms to matching documents; other structures support operations such as sorting and aggregation. That preparation consumes ingestion capacity and storage before an investigator searches.

A defensible timeline represents when activities occurred, the evidence linking them, and the uncertainty in their order. Begin with an anchor record and preserve its original timestamp, source, account, Region, resource, identity, and available request or session identifiers. A timestamp alone is not a relationship.

A handler must follow its source event contract, not assume every invocation contains individual JSON log records. For a direct CloudWatch Logs subscription to Lambda, event.awslogs.data contains a base64-encoded, gzip-compressed JSON envelope. Base64-decode it, gzip-decompress the resulting bytes, then parse the decompressed JSON. Kinesis and Firehose integrations have different outer contracts; do not reuse their response formats here.

Cross-source log analytics needs more than a common destination. Collection transports events, an adapter handles the delivery envelope, and an ingest pipeline transforms each document before indexing. This diagram shows one configured path for application logs and AWS API activity, not every supported ingestion option.

Amazon Managed Grafana correlates logs by querying connected sources and working with their returned fields. For example, application logs in CloudWatch Logs might expose requestId, while service logs in OpenSearch expose request_id. If both values identify the same request, Grafana can present them consistently and provide a path between them.

VPC Flow Logs record IP traffic metadata at network interfaces, not packets or application conversations. Creating a flow log at VPC or subnet scope covers network interfaces in that scope, including interfaces created later. Interface scope gives a narrower observation point. A VPC-scoped flow log is not a single observation point at the VPC boundary.

Transit Gateway Flow Logs record metadata about IP traffic traversing a transit gateway. Create a flow log on the transit gateway to cover its attachments, or on an individual transit gateway attachment to narrow collection. Gateway-wide collection provides a broad monitoring baseline; attachment collection isolates a particular connection. Overlapping collection can produce duplicate observations that downstream queries must distinguish.

Resolver query logging records eligible DNS queries handled by Route 53 Resolver for associated VPCs. A regional query logging configuration selects a destination; a VPC association selects the source. Creating the configuration alone does not enable logging for every VPC. The diagram combines control-plane relationships with logical log delivery: the configuration is not an extra DNS forwarding hop.

DNS tunneling carries information in query names or response data. A compromised workload can send encoded labels beneath an attacker-controlled domain through a recursive resolver; it does not need a direct connection to the attacker's authoritative server. To investigate that behavior, you need the queried names, not just evidence that a DNS connection existed.

Start with a path inventory: source and destination interfaces, subnets, routes, transit attachments, and security controls. Include local, peered, transit, and hybrid paths. A route alone does not establish reachability; forwarding and security controls must also permit traffic. Include attempted paths that controls reject, because blocked probing is useful evidence.

Reconstruct lateral movement as a chain of bounded claims, not a sequence of suspicious timestamps. A workload boundary asks whether one workload reached and authenticated to another. An account boundary asks whether an identity obtained and used authority in another account. These paths can connect, but a network connection is not required for identity-based movement through AWS APIs.

A service name is not enough to identify the principal making a request. Lambda logging uses the function's execution role; API Gateway REST logging uses a configured CloudWatch logging role. CloudFront standard logging v2 to S3 uses a managed delivery mechanism whose destination policy authorizes the log-delivery service principal.

Lambda function logging has separate controls for delivery and visibility. The function's logging configuration selects a CloudWatch Logs destination, output format, and severity thresholds. Its execution role must authorize writes, while the person reading the logs needs separate read permissions.

Access logs describe requests using a format you choose: request identity, route, response status, timing, and selected error details. Execution logs describe API Gateway's internal request processing, including errors and, when configured, additional processing details. Enabling one does not enable the other.

CloudFront request logs describe viewer requests, including cache hits; they are not just records of requests forwarded to an origin. Standard and real-time logging can coexist, but enabling one does not enable the other.

The security pillar treats preparing for security events as an operational capability, not just a document. Before an event, identify who declares an incident, directs the response, authorizes disruptive containment, and communicates with stakeholders. AWS manages security of the cloud; the customer still needs response ownership for its workloads, identities, configurations, and data.

The response plan establishes incident command, severity rules, escalation, communication, and decision authority. A scenario runbook translates that policy into actions with inputs, prerequisites, commands, expected results, failure branches, and recorded outputs. Define these terms internally. Lifecycle phases describe the work; they are not a rigid workflow. New evidence during recovery can require renewed containment.

Systems Manager Automation executes an operational procedure described by a runbook: a JSON or YAML document with parameters, mainSteps, action inputs, and outputs. Actions such as aws:executeAwsApi operate through AWS APIs. Automation does not inherently require an agent on the affected resource; actions that run commands on managed nodes have node-management prerequisites.

An incident-response runbook has two authorization boundaries: starting the execution and performing its actions. An operator launching Automation through OpsCenter needs permission to start the selected runbook. An EventBridge rule targeting Automation uses a target role with that permission. Neither entry point grants approval or makes the runbook's resource changes automatically authorized.

A SageMaker AI notebook can combine response instructions, Python SDK calls, and their outputs in one document. This is a custom incident-response tool, not a built-in incident workflow or approval system. No model training is required: the kernel executes your response code.

A containment boundary is an enforced limit on what a compromised identity or failed workload can affect. Account, VPC, and application boundaries are useful only when the permissions, connections, and shared dependencies crossing them remain narrow. Evaluate the boundary from the compromised principal’s position: which resources can it change, which roles can it assume, and which shared systems can it disrupt?

A subnet uses one effective route table: an explicit association, or the VPC main route table when no explicit association exists. Routing chooses the longest matching destination prefix, not the route that best expresses security intent. Separate subnet route tables let you give different subnets different external paths, but the VPC local route normally still connects its subnets. Removing an internet default route does not isolate a subnet from its neighbours.

Security groups filter traffic at associated network interfaces. Their rules only allow traffic: there is no deny rule and no rule ordering. When several security groups are attached to an interface, their permissions combine. A restrictive group cannot cancel an allow in another attached group.

A dedicated workload identity gives each workload permissions for its own work, rather than inheriting a shared administrator or deployment role. An invoice reader needs permission to read its invoice objects and write its logs—not to update functions, select more powerful roles, or change IAM policies.

Effective access is the result for a particular principal, action, resource, and request context—not a property of one policy document. Identity-based and resource-based policies can supply grants. A permissions boundary sets a maximum for a user or role, and a session policy restricts a particular temporary session. Neither independently grants access.

The root user is not a backup administrator account for everyday repairs. Some account tasks require root, and an IAM role with AdministratorAccess does not become root. For repairs that IAM permissions can authorize, prepare a separate emergency IAM role with only the permissions needed to restore access.

Retained root credentials are an exceptional recovery capability, not a substitute for an emergency IAM role. Keep them only where required, avoid root access keys, and document which tasks justify root sign-in. Centralized root access for member accounts does not replace protection of the management account's own root credentials.

Independent authentication means emergency entry does not require the federation service it must survive. This implementation uses a dedicated IAM user with securely held bootstrap credentials and MFA to assume a precreated emergency role. Give the user permission only to assume that designated role, not to operate workloads directly. Restrict the role trust policy to the intended user and require aws:MultiFactorAuthPresent for this IAM-user path.

Centralized root access separates managing member-account root credentials from performing supported privileged tasks. Before an incident, use the management account to establish IAM trusted access with AWS Organizations and enable the required capabilities. The organization must use all features. A registered delegated administrator can provide a central operating point without routine management-account access.

Session Manager separates permission to request a session from the node's ability to establish it. The node needs a supported, running SSM Agent, managed-node credentials, and outbound HTTPS access to required Systems Manager endpoints, including ssm and ssmmessages. Older agent and Region combinations can also require ec2messages. Session Manager itself needs no inbound SSH or RDP rule.

A Shield Advanced subscription does not automatically register every resource for Advanced protection. Create a protection for each eligible resource, identifying it by its ARN. Through the API, CreateProtection takes the resource ARN and returns a protection ID. Keep both identifiers: later operations use either the resource ARN or the protection ID.

A tabletop exercise validates an incident response plan through structured discussion. Start with the decisions the plan must support, not an elaborate attack story. Define the plan version, accounts and workloads in scope, participating roles, and exclusions. Include people who hold actual decision authority: responders, operations, application owners, and relevant business, legal, privacy, or communications representatives.

Chaos engineering tests a specific resilience claim by introducing a controlled fault and comparing measured behavior with a prediction. Define the steady state using customer outcomes, such as successful requests and latency, under a stated workload. Infrastructure health alone cannot establish that customers can complete their work.

Tabletop exercises validate an incident response plan through structured discussion. Participants explain decisions using a simulated incident and the current plan. The observations concern organizational readiness: whether people can identify authority, reconcile responsibilities, and explain how they would coordinate. A simulated alert described by a facilitator is not an alert delivered through the monitoring system.

An AWS FIS experiment template defines fault actions, resource targets, an execution role, and stop conditions. Starting an experiment creates a run of that definition; it does not create an isolated sandbox. The selected resources experience real disruption.

AWS Resilience Hub assesses the resources and configuration represented in an application against a resiliency policy. The policy defines recovery objectives for disruption types, such as infrastructure, Availability Zone, and Region disruptions. RTO is the target maximum time to restore service; RPO is the target maximum acceptable data loss expressed as time. Different disruption types can have different targets.

AWS Resilience Hub assesses whether an application's modeled configuration is expected to meet resilience objectives. AWS Fault Injection Simulator (AWS FIS) executes controlled fault-injection experiments against selected resources. They provide complementary evidence, not interchangeable verdicts.

AWS Lambda executes application code. In incident response, a function can evaluate custom containment policy, call a remediation API, and return a result. Choose it when the missing capability is an algorithm or action implemented in code.

Idempotency means repeating one logical request does not change its intended effect after that effect has been achieved. It does not require identical responses, logs, or execution counts. A timeout is not proof of failure: the destination may have completed the request before the response was lost.

An event is evidence that remediation may be needed, not permission to make an arbitrary change. This design uses a Lambda handler to place an approved EC2 network interface into a predefined quarantine security-group configuration. The handler must tolerate duplicate delivery, stale findings, concurrent invocations, and failure after an API call has already succeeded.

A remediation state machine should record which action is running, what counts as success, and where failures go. This design uses an Amazon States Language Standard Workflow, with execution history for inspecting state transitions. Event routing starts the execution; it does not implement the remediation sequence.

Begin with an evidence scope: the identities, resources, accounts, Regions, and actions under investigation. Select complementary sources that can connect an identity to an action and its effect. Preserve the selection criteria and known gaps; an empty result is not proof that nothing happened.

A legal hold preserves information until an authorized person explicitly releases it. Time-based retention protects information until a defined time boundary. These are independent protections, not two names for the same countdown.

Implement retention with a minimum boundary against premature destruction and a disposal boundary against unnecessary retention. For each data class, define its owner, the event that starts its clock, and approved exceptions. Object creation, becoming noncurrent, and backup creation start different clocks.

Preservation starts at acquisition, not at the first search query. Forward logs away from workloads before an incident, using authenticated transport and a destination that workload administrators cannot erase. For file artifacts, collect closed, rotated files or a consistent capture: hashing a file while it changes does not establish a stable baseline.

A custody workflow must identify every acquisition, not merely finish successfully. Bind each artifact to a case ID, evidence ID, source account and resource, UTC collection interval, collector role session, tool version, and workflow execution. Record API request IDs where available, outcomes, and failed attempts. Retried collection must not silently replace an earlier acquisition.

Chain of custody supports a claim about an artifact's origins and handling: where it came from, who or what collected it, and what happened afterward. For a cloud log export, that history can connect the source account and resource, collection window, automation role, and subsequent transfers to a specific evidence identifier.

Amazon GuardDuty asks whether observed activity indicates a threat. It analyzes sources such as CloudTrail management events, VPC flow data, and DNS query data using threat intelligence, anomaly detection, and other detection techniques. A finding can identify behavior consistent with credential misuse or communication with malicious infrastructure; it does not require a known software vulnerability.

Amazon Macie produces two distinct kinds of findings. A sensitive-data finding reports sensitive information detected in an analyzed S3 object using managed or custom data identifiers. A policy finding reports an S3 bucket security or privacy risk, such as public access or sharing outside the account. Content classification and bucket posture are separate observations: neither requires a malicious reader.

Amazon Inspector network reachability findings identify EC2 ports that network configuration makes accessible from outside the instance's VPC. Entry points can include internet gateways, virtual private gateways, and VPC peering connections. Reachable therefore does not always mean publicly accessible from the internet. Inspector analyzes configuration; it does not send connection attempts to discover listening services.

Amazon Detective correlates security telemetry into a behavior graph and presents investigative views through entity profiles. The diagram shows its core input paths, not a log-delivery pipeline you must assemble. Detective collects its supported source data independently of your configured CloudTrail trails and VPC flow-log delivery destinations.

A finding is an investigative claim, not a verdict. Identify the account, Region, resource, principal, time window, and exact condition asserted. An attempted operation, a successful operation, an exposed configuration, and unusual behavior are different claims. Severity helps prioritize investigation; it does not prove compromise or impact.

Potential exposure is what a compromised identity could reach under the permissions, trust relationships, and other access controls effective during the incident. Observed impact is what evidence establishes actually happened. A permission policy establishes neither successful use nor data theft; even potential access requires considering applicable denies, resource policies, and conditions.

Bidirectional quarantine means that neither unauthorized inbound traffic nor unauthorized outbound traffic can use any workload network path. Inventory every network interface, attached security group, IPv4 and IPv6 address, subnet ACL, route, load balancer attachment, and reachable endpoint. Include same-subnet peers, peering, transit, VPN, NAT, and private service access: no public address does not mean no connectivity.

Access-key deactivation prevents an IAM user's long-term access key from authenticating subsequent requests once the change has propagated. It is reversible; deletion is permanent. Neither action changes the status of another access key belonging to the same user.

A compromised credential is often the root of a credential chain: an IAM access key obtains a role session, which assumes another role or opens an application session. Preserve credential identifiers and relevant audit records without copying secret values. Trace the identity's activity, role assumptions, newly created credentials, and trust-policy changes; the exposed key is only the starting point.

A patch baseline defines which patches are approved for an operating system. Approval rules filter patch metadata, such as classification and severity, and can delay approval after release. Explicit approved and rejected lists handle exceptions. Approval means eligible for installation, not installed, scheduled, or proven safe for your application.

A trusted image baseline is an artifact produced from controlled inputs, not a snapshot of a convenient running server. Review the build definition, restrict its modification, and separate permission to build from permission to approve production releases. Build identities need only the access required for their stage.

Replacement is recovery, not proof of eradication. A new instance removes the old instance’s local changes. It does not remove stolen credentials, attacker-created permissions, or malicious files on shared storage. Treat containment, evidence preservation, eradication, and recovery as separate outcomes.

Cross-account copies separate backup administration from production credentials. Cross-Region copies separate recovery points from a regional failure. Neither separation makes a copy immutable: the destination also needs restrictive access controls and Vault Lock.

A recent backup is not necessarily a clean recovery point. Use the incident timeline to identify the earliest credible compromise, not merely the detection time. Select a candidate before that boundary, then validate it after restoration: a timestamp alone cannot prove that data or software is safe. Record the selected recovery point ARN, source resource, backup time, and reason for selection.

Read userIdentity.type before interpreting identity fields. An IAMUser, AssumedRole, and AWSService represent different kinds of callers. For an assumed role, userIdentity.arn identifies the STS role session, such as arn:aws:sts::111122223333:assumed-role/Deploy/build-42. It does not identify the original human or workload that obtained the credentials.

Attack path analysis asks which access transitions connect an entry point to an objective. Its relationships describe capabilities or actions: assuming a role, retrieving a credential, or reading an object. Timeline reconstruction asks what happened when. Its ordering relates observations by time, not automatically by dependency.

A defensible timeline separates source evidence from the investigator's interpretation. For each event, preserve the source and original-record reference, original timestamp and offset, normalized UTC time, principal, resource, action, and result. Keep the query scope and transformation rules with the derived timeline so another investigator can reproduce it. Preserve original records separately; correcting a normalized field must not silently rewrite the evidence.

An attack path connects an entry point to an objective through resource and identity relationships. Treat each transition as a separate claim: which principal acted, what capability it used, which resource it reached, and what evidence supports that connection. A role attachment, network route, or permission grant identifies a relationship, not proof that an attacker used it.

An edge threat model connects an attacker capability to a resource or operation the attacker can misuse. A botnet can exhaust network capacity without sending valid application requests. A small client can repeatedly invoke an expensive report. A stolen account can make ordinary-looking requests for another customer's records. State the objective, reachable endpoint, protocol, and business impact before selecting controls.

AWS Shield protects availability against distributed denial-of-service attacks. Network and transport attacks can exhaust bandwidth or connection-handling capacity without carrying a meaningful HTTP request. AWS WAF evaluates HTTP/S requests against a web access control list, or web ACL, at a supported resource. It can reject an exploit request even when traffic volume is low.

Start with the resource being exhausted, not the request count. Reflection and amplification floods consume bandwidth; SYN floods attack connection establishment and state; valid-looking searches or logins consume application workers and database capacity. Filter before the constrained resource: a regional firewall cannot recover an upstream link that is already saturated, and autoscaling web servers cannot remove a database bottleneck.

Defense in depth means that one control's failure does not remove every downstream restriction. Start with the anticipated attack: volumetric floods, malicious HTTP requests, direct-origin access, and lateral movement need different enforcement points. Repeating an HTTP rule at several places does not address all four.

The OWASP Top 10 groups broad web application risks; it is not ten attack signatures or a complete testing standard. Categories change between editions, so identify the edition when reporting coverage. For control selection, ask what causes the failure and which component has enough information to prevent it.

The Same-Origin Policy isolates browser contexts by scheme, hostname, and effective port. Paths do not matter: https://app.example.com/dashboard and https://app.example.com/settings share an origin. Explicit HTTPS port 443 is the default and changes nothing; a different scheme, hostname, or effective port creates another origin.

AWS WAF evaluates a web ACL's rules in ascending numeric priority: the lowest number runs first. A nonmatching rule passes evaluation onward. A matching rule applies its action, but evaluation stops only if that action is terminating. The web ACL's default Allow or Block action applies only when evaluation finishes without a terminating action.

An IP set matches addresses against CIDR ranges. Each set contains either IPv4 or IPv6 addresses; use separate sets when both families matter. By default, AWS WAF uses the request's origin IP: the source address it sees, which can belong to a proxy rather than the original client. Shared NAT addresses and changing client addresses make an IP match a network signal, not proof of identity.

A rate-based rule tracks requests in separate aggregation instances and applies its action to instances whose estimated request rate exceeds the configured limit. The aggregation key defines those instances: source IP creates one per IP address; custom keys create one per distinct combination of values. The limit applies independently to each combination, not to the rule's combined traffic.

A managed rule group is maintained by AWS or a Marketplace seller; you reference it rather than edit its rules. For a Marketplace group, subscribe before adding it. Discover groups with ListAvailableManagedRuleGroups, and inspect the chosen group with DescribeManagedRuleGroup. Add a web ACL rule containing ManagedRuleGroupStatement with the exact VendorName and Name, a priority, and visibility settings. Use OverrideAction: None to preserve the group's resulting action. Associate the web ACL with the supported resource in the appropriate scope.

For certificate-authenticated MQTT connections, authentication establishes the device's identity; an AWS IoT policy authorizes its operations. An active certificate alone grants no MQTT permissions. Policies attached to the certificate, including applicable thing-group policies, contribute permissions. A matching allow is required, and an applicable explicit deny overrides allows.

CloudFront geographic restrictions apply a country allowlist or denylist to an entire distribution. AWS WAF geographic rules can combine location with paths, methods, IP exceptions, and other request conditions. A native CloudFront geo block cannot be overridden by a WAF exception; requests blocked by that restriction do not reach WAF evaluation.

AWS WAF uses JA3 and JA4 fingerprints derived from TLS ClientHello characteristics to correlate requests with similar client implementations. JA3 hashes selected, ordered handshake parameters into a 32-character value. JA4 uses a different, normalized representation with 36 characters; sorting selected inputs reduces sensitivity to changes such as TLS extension ordering.

An AWS WAF rate-based rule combines a request population, an aggregation method, an evaluation window, a limit, and an action. The scope-down statement selects the population: for example, requests whose method is POST and whose URI path is /login. Requests outside that scope neither contribute to this rule’s rate nor receive its rate-based action.

OCSF is a schema framework, not a transport or an enforcement control. Start a mapping contract by pinning the OCSF version and describing what each source record asserts. Choose the event class from that assertion, not from the vendor name or the fact that the source is a security product.

A third-party managed rule group has two separate lifecycles. An AWS Marketplace subscription establishes the subscribing account’s entitlement under the seller’s terms and pricing. AWS WAF configuration determines where the group evaluates requests. Subscribing does not create a web ACL, associate one with a resource, or insert the group into an existing ACL.

A workload-specific baseline states what must exist, what must be prohibited, and what evidence proves both. For a Linux web workload, record approved packages, listening services, application identities, writable paths, administrative access, auditing, and required management and security agents. Use a benchmark matched to the distribution and release as a starting point; give each exception an owner, justification, and review date.

A hardened AMI captures a reviewed operating system baseline, not a permanently secure instance. Bake in approved packages, current patches, restrictive file permissions, audit rules, host firewall configuration, and required security agents. Choose a benchmark profile appropriate to the workload; blindly applying every rule can break boot, management, or application behavior. Record justified exceptions alongside the baseline.

An AMI creation runbook is an Automation workflow that turns a known base image into a reusable machine image. Use a temporary EC2 instance, not a production server: the builder must contain only the software and configuration intended for future instances. Pin the source AMI ID, runbook version, and configuration inputs so that the build has a traceable starting point.

A container baseline defines the user-space files, dependencies, permissions, and default identity needed by one workload. Start with a trusted, supported base and pin it by digest so the build selects known content. Pinning provides repeatability, not freshness: regularly update the selected digest and rebuild. Minimal means removing unnecessary components, not choosing the smallest image regardless of compatibility.

A minimal base reduces installed software and the dependencies you must maintain; small size alone does not establish trust. Choose a maintained source, verify compatibility, and pin each FROM to an approved digest. Pinning makes the input stable, but also freezes its vulnerabilities until you deliberately update it. A distroless image omits many administrative tools; scratch provides an empty filesystem. Neither supplies dependencies your application still needs, such as shared libraries or CA certificates.

A hardened image can pass review and still be replaced before deployment if the deployment references a movable tag. In Amazon ECR, a tag names an image manifest; a digest identifies its content. With mutable tags, pushing different content under an existing tag changes what a later pull by that tag selects.

IAM manages durable identity and authorization configuration: users, groups, roles, and policies. An IAM role is a persistent identity with a trust policy and permissions configuration, not a stored set of access keys. A role can exist while nobody is using it.

A service role is an IAM role that a service assumes to act on your behalf. An execution role names that role's purpose in a particular service; it is not a different IAM identity type. The integration determines where you configure the role and which service principal its trust policy must allow.

ECS does not use one role for everything. The task role authorizes application SDK calls; the task execution role authorizes supported agent operations such as private image retrieval, log delivery, and startup secret retrieval. Execution-role credentials are not exposed directly to application containers. ECR supplies container images, unlike source-code or software-package repositories.

Vulnerability assessment asks whether an asset contains an identifiable weakness. For a known package vulnerability, an assessment matches package identity and version information against vulnerability intelligence. This supports the claim that a component is affected, subject to the accuracy of that information. It does not establish that the vulnerable code is reachable, that exploitation will succeed in this deployment, or that exploitation has occurred.

Amazon Inspector identifies known software vulnerabilities by comparing discovered packages and versions with vulnerability intelligence, including vendor advisories. A finding ties an affected package to a resource and supplies remediation information when available. Package identity matters: a vendor can backport a fix without adopting the upstream version number, so version strings alone are not a reliable assessment.

A Lambda function's deployment package determines where its executable components come from. A ZIP function combines your package, any attached Lambda layer versions, and a managed or custom runtime. A container-image function gets its application, dependencies, and runtime from the image. Container-image functions do not attach Lambda layers; include equivalent content when building the image.

Amazon Inspector coverage is scoped to an account and Region. Enable the required scan types in each intended scope: EC2, ECR, Lambda standard scanning, and optionally Lambda code scanning. An organization's delegated administrator and automatic enablement settings help manage member accounts, but do not replace checking each account's actual activation status.

Systems Manager Patch Manager installs patches and reports patch-operation results. Amazon Inspector independently evaluates supported software for known vulnerabilities. A successful patch operation does not, by itself, prove that a particular Inspector finding has been remediated: the affected package might not have been updated by that operation.

Runtime sensors observe activity such as process execution, file access, and network connections on supported workloads. Amazon GuardDuty evaluates collected evidence using threat intelligence and behavioral detection. An unexpected shell or suspicious connection can support a finding, but a finding is an investigative lead, not proof of successful compromise.

Runtime Monitoring adds workload-level visibility through a GuardDuty security agent. The agent observes operating-system activity, including process execution, file access, and network connections, and sends runtime events to GuardDuty. This is different from relying only on service logs: enabling GuardDuty alone does not install a working runtime collector everywhere.

AWS Systems Manager Patch Manager separates approval policy from execution controls. A patch baseline defines which patches are approved through rules and explicit approvals or rejections. Rules can filter by properties such as classification and severity, with available filters depending on the operating system. Approval makes a patch eligible for installation; it neither schedules installation nor proves application compatibility.

Patch compliance and vulnerability assessment answer different questions. AWS Systems Manager Patch Manager evaluates patch state against the applicable baseline. Amazon Inspector identifies known vulnerabilities within its supported scanning coverage; it does not install fixes. A compliant baseline result does not establish that every known vulnerability is remediated.

EC2 Instance Connect lets an authorized caller publish an SSH public key for a particular instance and operating-system user. SendSSHPublicKey makes that key available through instance metadata for 60 seconds. It does not copy the private key to AWS or permanently add the public key to authorized_keys.

Controlled administrative access needs independent controls for AWS authorization, network reachability, operating-system privilege, and retained evidence. This design compares a restricted Session Manager shell with private SSH using EC2 Instance Connect. Arrows represent logical delivery, not TCP initiation; the managed node establishes its service connections outbound.

A vulnerability feedback loop needs three distinct outcomes: findings reach developers, fixes are checked again, and failed artifacts cannot advance. Here, CodePipeline orchestrates a managed CodeBuild job whose buildspec generates a software bill of materials, calls Amazon Inspector, and evaluates policy. CodeDeploy later deploys to an existing deployment group; neither orchestration nor deployment replaces buildspec execution.

SAST examines code without running the application. A data-flow analyzer can follow an untrusted source, such as a request parameter, through function calls to a sensitive sink, such as SQL execution. Its value comes from recognizing whether an appropriate defense interrupts that path—not merely spotting suspicious text.

Amazon CodeWhisperer capabilities became part of Amazon Q Developer. For this comparison, Q Developer is the developer-facing assistant: it helps developers write and understand code, identify security issues, and work on corrections close to the editing task. Generating a code suggestion and performing a security review are different activities; a suggestion is not evidence that the code is secure.

Amazon CodeWhisperer capabilities are now part of Amazon Q Developer. For IDE-based scanning, install a supported Amazon Q Developer extension and authenticate with an AWS Builder ID or your organization's IAM Identity Center identity, as appropriate. Confirm that your IDE, extension version, language, and sign-in method support the scanning capability you intend to use. Successful code completion does not establish that a security scan has run.

Availability note: AWS discontinued support for Amazon CodeGuru Security on November 20, 2025. This lesson explains the historical integration and its control mechanics, not a service to select for a new deployment.

AWS CodeBuild supplies the environment that executes security-check commands. A scanner runs there as a tool or is invoked through an API. CodeBuild is not itself a vulnerability-analysis engine: the selected tool determines what is inspected and what findings mean.

A security gate is executable build logic, not merely a scanner report. In buildspec version 0.2, commands run in the same shell instance, so shell state can carry between commands. Keep candidate creation, scanning, and status propagation in a reviewed wrapper such as ./ci/build-and-gate.sh, called from the build phase.

A vulnerability gate is a required dependency in the release path. Consider a pipeline that builds a release artifact, scans it, and then deploys it. Deployment must be downstream of successful scanning; putting a scan somewhere in the pipeline is not sufficient.

A security quality gate must stop promotion, not merely publish findings. This architecture shows the forward flow from a container image to a mandatory release decision. Lines represent evidence and release handoffs, not every API call or the earlier build workflow.

Prompt injection tries to turn model-readable content into instructions that override the application's intended behavior. Direct injection arrives in an attacker-controlled user message. Indirect injection arrives in retrieved documents, web pages, repository files, or tool responses. An instruction embedded in a document remains untrusted even when the document is stored in your own bucket.

A classification-aware disclosure policy decides whether particular data may cross a particular boundary. Evaluate the authenticated principal, tenant, data classification, purpose, action, and destination. Authorization establishes permission; inspection checks actual content. A clean scan does not grant permission, and permission to read a document does not automatically permit sending it to a model or tool.

A model response is untrusted input, even when it follows the requested format. Define an acceptance contract for each destination: what data it accepts, what content it prohibits, and which actions the authenticated caller may request. A refund proposal can be valid JSON yet name another customer's order. Generated markup can become executable when a browser renders it.

A stateless filter evaluates each packet independently. A stateful filter retains flow context, commonly using protocol, addresses, ports, and timeout information. For TCP, connection progress also matters. UDP can be tracked using flow attributes and timeouts despite having no TCP-style handshake.

For traffic reaching AWS Network Firewall, stateless evaluation comes first. Stateless rule groups are evaluated by ascending group priority, and rules within a group by ascending rule priority: lower numbers run first. The first matching rule supplies the action; a later rule does not override it.

Forward and return routes are independent. Each routing decision uses the packet's current destination and the applicable routing table. A successful outbound route does not create its reverse. Asymmetry is not inherently invalid IP routing; it becomes a problem when a direction misses required inspection or connection state.

AWS Network Firewall inspects traffic delivered to its firewall endpoints; deploying a firewall does not intercept every packet in a VPC. This example uses a VPC-subnet deployment, a workload with an associated public IPv4 address, and a dedicated firewall subnet. It shows only that workload’s internet connection and its replies.

Private connectivity controls how traffic reaches its destination. It does not, by itself, establish confidentiality, integrity, or peer authentication. AWS Direct Connect does not encrypt traffic by default; private addresses, private endpoints, and security groups are not evidence that a connection is encrypted.

AWS Direct Connect supplies connectivity that bypasses the public internet; it does not encrypt customer traffic by default. It requires connectivity to a Direct Connect location, directly or through a provider, plus a virtual interface and BGP routing. Its more consistent network path is not a guarantee of application latency or availability.

AWS Site-to-Site VPN uses IKE to authenticate tunnel peers and establish cryptographic state. A reachable peer IP address is not proof of identity. With a pre-shared key (PSK), each peer proves possession of the configured secret during authentication; the secret is not sent across the network. Configure the correct secret for each tunnel, protect its distribution, and avoid reusing it across unrelated connections.

MACsec protects Ethernet frames between participating devices, providing confidentiality, integrity, data-origin authentication, and replay protection. For AWS Direct Connect, protection runs between a compatible customer router and the AWS Direct Connect device—not all the way to an application. Direct Connect is not encrypted by default.

MACsec encrypts Ethernet traffic between your customer router and the AWS Direct Connect router. It is available on eligible dedicated connections at supported locations and port speeds, not on hosted connections. Check the connection’s MACsec capability and your router’s Direct Connect MACsec compatibility before configuring it; a private circuit alone does not provide encryption.

A gateway endpoint gives a VPC route-table access to Amazon S3 or DynamoDB. Associating a route table adds a route for the service's AWS-managed prefix list, targeting the endpoint. There are no endpoint network interfaces or endpoint security groups. For matching regional service traffic, this route is more specific than a default route through NAT.

An interface endpoint creates endpoint network interfaces with private IP addresses in selected consumer subnets. Clients connect to those addresses, and AWS PrivateLink carries their traffic to the selected service without an internet gateway, NAT gateway, or VPC peering connection.

AWS Client VPN terminates an encrypted, client-based VPN connection. A successful connection is not blanket access: authentication admits the client, authorization rules permit destination networks, routes provide paths, and security groups constrain traffic. The diagram follows only the outbound request, not its replies or authentication exchanges.

AWS Verified Access evaluates access to a particular application using trusted context. An office address, private route, or successful VPN connection is not permission to use that application. For this design, require both an authenticated workforce identity and acceptable device posture.

Routed user access and application-specific access grant different capabilities. AWS Client VPN authenticates a remote client and provides an encrypted tunnel for routed access to permitted destinations. AWS Verified Access evaluates access to configured applications using policies and trusted identity or device context, without requiring a traditional VPN.

Start with an allowed-flow contract: source workload or network, destination, protocol, destination port, and purpose. Record who initiates the connection. For this lesson, external clients may initiate TCP 443 to an HTTPS application, and only that application may initiate TCP 5432 to PostgreSQL. Other workload connections are not required.

Start with a connectivity contract: the permitted source, destination, protocol, port, purpose, and, where relevant, user or device conditions. Then evaluate every complete path against it. A rule allowing 0.0.0.0/0 is not proof of internet reachability: addressing, routes, gateways, security groups, and network ACLs determine whether the path exists. Review IPv6 separately, including ::/0.

Identity federation separates authentication at an identity provider from acceptance at a relying party. The relying party must establish both that the evidence is authentic and that it is acceptable for this particular use. A valid signature alone does not establish either a local role assignment or permission to read data.

Identity federation lets a relying party accept identity evidence from an external identity provider. Cross-account access authorizes access across AWS account boundaries. These answer different questions: whose identity evidence is accepted, and which account's principals may access another account's roles or resources.

A role's trust policy is a resource-based policy that controls who may assume that role. It selects a Principal, permits an assumption action, and can require conditions. The role itself is the resource, so its trust policy does not need a Resource element. The role's permissions policies answer a different question: what an established session may do.

Amazon Cognito supplies identity capabilities for applications you build. A Cognito user pool provides an application-facing user directory and authentication service, including self-service registration and federation. Its contract is with your application's clients and token consumers. IAM Identity Center organizes workforce access to AWS accounts and business applications. Its contract is with organizational identities, assignments, and supported access integrations.

IAM defines identities and permissions within an AWS account. IAM users and roles belong to an account; an IAM group collects IAM users for policy attachment and is not itself a principal. A role can support cross-account access, but it still belongs to one account.

AWS Directory Service supports directory-based identity. With AWS Managed Microsoft AD, it operates a Microsoft Active Directory domain for domain identities, authentication, and directory-aware workloads. An AD group can influence domain access without granting any AWS API permissions.

A user pool has two distinct entry paths. User-pool authentication APIs, such as InitiateAuth, authenticate local users through flows admitted by the app client's ExplicitAuthFlows. For example, USER_SRP_AUTH uses SRP, while USER_PASSWORD_AUTH submits a password over TLS. Enabling one does not enable the other. AdminInitiateAuth is a separate, IAM-authorized operation; giving a caller IAM permission does not enable a disabled app-client flow.

An identity pool exchanges evidence of an application identity for temporary AWS credentials. A user pool supplies authentication tokens; it does not itself issue the AWS access key, secret key, and session token used to sign AWS API requests.

MFA assurance belongs to an authentication event and its resulting session, not permanently to a person. Enrolling an authenticator does not enforce its use. Signing in to the console with MFA does not change requests signed separately with long-term access keys.

Workload identity authenticates software without borrowing a person's sign-in or storing an IAM user's access keys. The runtime binding determines which software receives which role credentials: an EC2 instance profile binds a role to an instance, an ECS task role serves application containers, and a Lambda execution role serves a function. Choose the smallest practical workload boundary; a shared host role cannot distinguish every application on that host.

A persistent credential, such as an IAM user access key, remains usable until explicitly disabled or deleted. Rotation replaces it and retires its predecessor. Creating another key does not invalidate the first one. Likewise, changing a stored secret does not change what the authenticating system accepts unless a rotation integration performs that change.

AssumeRole is an authenticated STS API request. The caller signs it with existing AWS credentials and supplies the target RoleArn and a RoleSessionName. The existing credentials identify the caller; knowing a role ARN does not authorize assuming it.

Federation exchanges an external identity proof for temporary AWS role credentials. The client submits a SAML assertion to AssumeRoleWithSAML, or an OIDC token to AssumeRoleWithWebIdentity. Neither operation requires the caller to sign the request with existing AWS credentials.

A presigned URL is an S3 request authenticated with the creator’s signing credentials through query parameters. The recipient does not need AWS credentials. S3 evaluates the request using the signing principal’s authority, not the recipient’s identity. Creating the signature is a local operation: successfully generating a URL does not prove that S3 will authorize its use.

A signed JWT starts as untrusted input. Decoding exposes its claims; it does not authenticate them. Configure the allowed issuer, signing algorithms, and trusted JWKS location outside the token. A kid selects a candidate key within that issuer's key set; it is not a trust decision. Never follow an arbitrary token-supplied key URL or accept an algorithm merely because the header requests it.

Clock skew is a difference between clock readings; drift is the rate at which that difference changes. Authentication compares timestamps created on one system with the current time on another. A valid signature proves integrity and origin, not that the signed material is currently usable.

AWS Managed Microsoft AD runs Microsoft AD domain controllers in AWS. In the new-forest deployment used here, accounts created in that managed domain are authenticated by its domain controllers. Corporate accounts remain in their original domain; a supported trust can let them access resources in the managed forest without copying their passwords into it.

Effective permissions are evaluated for a particular principal, action, resource, and request context. A statement matters only when it matches that request, including its conditions. An applicable explicit Deny overrides an Allow; an implicit deny means that a required permission was not granted. Adding another Allow cannot defeat an explicit Deny.

Cross-account role assumption separates permission to obtain a role session from permission to use that session. Here, an application in account A assumes ReadB in account B, then reads an encrypted report. Its compute location does not change; its signing identity does.

A confused deputy authenticates successfully and uses legitimate privileges, but uses them for the wrong caller. A monitoring provider trusted by several customers can become a deputy if a caller supplies another customer's role ARN and the provider assumes it. The ARN is a resource identifier, not proof that the caller may direct access to that resource.

Attribute-based access control (ABAC) uses attributes in policy conditions. A common rule compares aws:ResourceTag/Project with the policy variable ${aws:PrincipalTag/Project}. For supported actions, a StringEquals comparison can restrict an allow to resources whose Project value matches the caller's effective Project value. Matching tags alone grant nothing: the request must still have applicable permission for the action and resource.

IAM Policy Simulator evaluates selected policies for an action, resource, and request context without making the service request. Use it to isolate an authorization question: for example, whether s3:GetObject is allowed for one object ARN when a particular condition key has a particular value. You can evaluate existing identity policies or test proposed policy documents before attaching them.

Role-Based Access Control (RBAC) grants permissions through approved responsibilities. A developer role might permit deployment to a defined set of development resources; an auditor role might permit inspection without modification. The boundary depends on both the role's permitted actions and its resource scope—not merely its name. Assignment determines who can use that permission set.

Start with a task contract, not a job title: what must the person accomplish, on which resources, and what must remain impossible? A finance report reader needs to list published reports and read their contents, not upload reports, delete them, or administer access. Keep unrelated responsibilities in separate roles so that assignments remain understandable and reviewable.

A tag-matching policy is an authorization rule, not a property of tagging itself. For a concrete implementation, let Project be the security attribute and use AWS Secrets Manager secrets as the resources. First check the Service Authorization Reference for each action: support for tagging does not imply support for resource-tag conditions, and list operations need separate treatment.

Effective permissions are the authorization result for a particular principal, action, resource, and request context. Authentication identifies the caller; it does not authorize the operation. Ordinary IAM authorization starts with implicit deny: an applicable authorization path must grant access. An applicable explicit deny overrides an Allow.

An explicit deny is an applicable policy statement whose effect is Deny. In AWS IAM authorization, it defeats an allow for the same request, even if the allow names a more specific resource or appears later in a policy. Evaluation is not a first-match list, and administrator permissions do not override an applicable explicit deny.

Indirect privilege escalation combines individually valid permissions into an unintended capability. Consider a deployer who cannot read sensitive S3 objects. If that deployer can supply code to a function whose execution role can read those objects, the deployer can cause the read without ever receiving direct S3 permission. Review effective capabilities, not just attached administrator policies.

Encryption protects traffic from disclosure, and TLS record protection also detects modification. Peer authentication establishes which endpoint holds the credentials used in the handshake. An encrypted connection is not, by itself, evidence that both application peers have been authenticated.

TLS coverage follows TLS sessions, not subnet boundaries. This application path has two sessions: the calling application establishes HTTPS with an application pod through a TCP pass-through load balancer; the pod then establishes a separate TLS connection to PostgreSQL. Arrows show the request path, not response traffic.

Start at each TLS termination point: which peer verifies its identity, which DNS name does that peer use, and which certificate authorities does it trust? A server certificate must cover that name in its subject alternative names (SANs), be within its validity period, and chain to a trusted root. The server must also prove possession of the corresponding private key. Domain validation during issuance does not install trust in clients.

When an Application Load Balancer (ALB) terminates TLS, the client connection ends at the load balancer. An HTTPS target group creates a separate TLS connection to the target. Encryption on the first connection does not automatically encrypt the second.

Configure each TLS endpoint to validate the peer's certificate chain against an explicit trust bundle, check validity periods and appropriate certificate usages, and require proof of possession of the corresponding private key. On the receiving side, require a client certificate rather than merely requesting one optionally. A trusted issuer alone is not an access policy.

For Amazon EMR on EC2, a security configuration tells EMR how to configure encryption on cluster nodes. Set EncryptionConfiguration.EnableInTransitEncryption to true and supply the certificate-provider settings under InTransitEncryptionConfiguration.

Amazon EKS does not automatically require mutual TLS for application traffic between pods. Kubernetes API TLS, encrypted Kubernetes Secrets, and application traffic are separate protection boundaries. For pod-to-pod mTLS, configure TLS in the applications or deploy a service mesh that authenticates workloads and enforces encrypted connections.

Inter-container traffic encryption protects communication between containers in a distributed SageMaker AI training job. Workers exchange information such as model parameters and gradients; protecting the input files alone does not protect that exchange.

Client-side encryption means the application encrypts the payload before submitting it to the receiving storage service. Server-side encryption means the receiving service performs encryption before persisting the data. The boundary is the storage service, not the cloud provider: an application running on cloud compute can still perform client-side encryption before uploading to Amazon S3.

Envelope encryption separates bulk encryption from key protection. A random data encryption key (DEK) encrypts the payload, normally through an established authenticated-encryption format. A key-encryption key (KEK) wraps the DEK. Both keys can be symmetric; a hierarchy does not require public-key cryptography.

Server-side encryption protects data within the receiving service’s documented storage boundary. In this example, S3 encrypts object data, while KMS controls the key protecting the data key. The object payload does not pass through KMS.

Start with the trust boundary: which processes may hold plaintext, who may authorize decryption, and who must remain unable to recover the data? Client-side encryption puts the application inside that boundary. A compromised application can expose the plaintext and keys it is authorized to use.

In envelope encryption, a data key encrypts the payload locally; a symmetric KMS key protects that data key. GenerateDataKey returns a plaintext data key and an encrypted copy. Use the plaintext only in memory, then remove it as soon as practical. Store the encrypted data key with the encrypted payload, never the plaintext key.

A KMS key is a resource with an identity, policies, and lifecycle state. Its key material supplies the cryptographic secret. For customer managed keys in the standard KMS key store, origin AWS_KMS means KMS generates and protects the material; origin EXTERNAL means you generate material outside KMS and import it. Importing changes who provisions the secret, not where KMS uses its imported copy.

In envelope encryption, a data encryption key, or DEK, encrypts the payload. A longer-lived key encryption key, or KEK, protects the DEK. The stored envelope contains encrypted data, the protected DEK, and the information needed to decrypt them—not either plaintext key.

Both AWS KMS and AWS CloudHSM protect keys with hardware security modules. The distinction is who controls the HSM environment and how permission to use a key is enforced. For this comparison, standard KMS means customer managed keys in the default KMS key store; custom key stores are a separate option.

S3 Object Lock protects individual object versions, not an object key as a whole. It requires S3 Versioning. Writing to an existing key creates another version; it does not replace the bytes of a protected version. Versioning alone is not WORM because authorized users can permanently delete unprotected versions.

A Vault Lock policy is a resource-based policy attached to an Amazon S3 Glacier vault. Define retention by denying glacier:DeleteArchive while an archive is younger than the required age. An explicit deny overrides an allow, so granting an administrator deletion permission does not bypass the retention rule.

A cryptographic hash maps bytes to a fixed-length digest. SHA-256 is deterministic: identical input bytes produce identical digests. A match provides strong evidence of byte equality under the algorithm’s security assumptions; it does not provide confidentiality, prevent changes, or recover damaged data.

A cryptographic digest is a deterministic summary of bytes, not a credential. For an artifact m and reference digest d, checking H(m) = d establishes consistency with that reference. With a suitable collision-resistant hash, this is useful integrity evidence—but the comparison says nothing about who supplied either value.

A production verifier makes two decisions. Cryptographic validity asks whether a signature verifies for the supplied message and public key. Release authorization asks whether that key, artifact identity and release are permitted here. Admission requires both: a correctly signed release can still come from an unapproved key or be too old to use.

EFS lifecycle management moves eligible file data among storage classes within the same file system. Applications continue using the same paths and file interfaces: tiering does not create a backup or move files into an S3 bucket. Lifecycle policies apply at the file-system level, rather than selecting directories by prefix.

FSx for Lustre backups protect eligible file systems, not every Lustre deployment. Persistent file systems using SSD or HDD storage support backups when they are not linked to an Amazon S3 bucket. Scratch file systems and file systems linked to S3 do not support these backups. Check eligibility before treating a backup setting as protection.

A legal hold enforces preservation on identified evidence, not on a case label. Build a preservation manifest containing resource identifiers, relevant dates, owners, case references, and required metadata. Include historical evidence and relevant copies; discovering an object or backup is not proof that it is protected.

AWS Backup manages recovery history for supported resources. Backup plans associate resource selections with rules for scheduling backups and retaining recovery points. A recovery point represents recoverable backup data; it is not a destination file tree that must keep matching the live source.

Backup isolation means production credentials cannot administer the destination copies, their retention, or the keys needed to recover them. This architecture uses AWS Backup copies of Amazon EFS backups in a separately administered account. AWS Backup cross-account copying requires supported resources, accounts in the same AWS Organization, and cross-account backup enabled.

A backup schedule expresses intent: create recovery points and expire them later. A retention lock adds enforcement: the storage service rejects prohibited deletion or retention changes, even when ordinary access permissions would allow them. The protection applies to a particular recovery point, snapshot, or object version—not automatically to every copy of the data.

Backup isolation asks: which identities can control recovery? Its purpose is to keep production administrators from automatically controlling backup deletion, retention, and recovery dependencies. A separate account is useful only when production credentials cannot also obtain administrative authority there. Separation of storage locations is not necessarily separation of authority.

Amazon Data Lifecycle Manager (DLM) turns an EBS snapshot policy into recurring work: select resources by tags, create snapshots on schedules, and expire policy-managed snapshots using retention rules. A custom snapshot policy can target volumes or instances; instance targeting supports multi-volume snapshots. Count-based retention keeps a specified number of snapshots, while age-based retention keeps them for a specified period.

This lesson configures an S3-to-S3 DataSync task that copies new objects into an encrypted destination without replacing existing objects or deleting destination-only objects. The diagram separates the object path from role assumption and encryption requests; it does not show every API call or response. These AWS storage locations do not require a DataSync agent.

Replication reduces the gap between production and another usable copy. It can also carry malicious writes, corrupted objects, or ransomware-encrypted content. A recent replica is therefore not automatically a safe recovery point.

A credential cutover must align the validating system, the secret store, and the consumers. This example uses a Lambda-based rotation callback, Secrets Manager versions, RDS database login accounts, and ECS applications. Updating any one of these does not atomically update the others.

Sensitive data does not automatically require Secrets Manager. Systems Manager Parameter Store can store sensitive configuration as SecureString, encrypted with AWS KMS. Secrets Manager also uses KMS encryption. Both support IAM-controlled access and API activity logging through CloudTrail, so encryption and auditability alone do not decide between them.

Lambda-based rotation coordinates two systems: a versioned secret and the account that accepts its credential. Secrets Manager owns the rotation schedule and invokes a Lambda handler during the configured rotation window. A schedule is not a promise of execution at one exact instant.

Imported BYOK separates who generates key material from where it is used. AWS KMS receives and uses the imported material; this is not an external key store. This lesson follows symmetric encryption keys: generate suitable 256-bit symmetric material in an approved environment, then create a KMS key with Origin=EXTERNAL and KeySpec=SYMMETRIC_DEFAULT. The new key starts in PendingImport.

An external key store (XKS) lets AWS KMS use key material held by an external key manager without importing that material. Applications address a KMS key through the usual KMS API; KMS delegates the external cryptographic operation through an XKS proxy. KMS also applies its own encryption layer: external custody does not mean KMS never handles plaintext.

A customer-managed KMS key is a logical resource with an identity, permissions, and lifecycle settings. Its key material origin tells you where the cryptographic material comes from, not who administers the resource. This lesson compares single-Region, symmetric encryption keys in the standard KMS key store.

A KMS key is a logical resource with an identifier, policy, and lifecycle state. Its key material supplies the cryptographic secret. Customer-managed describes control over the resource; it does not mean the customer generated the material or can export it. This lesson compares symmetric encryption keys in the standard AWS KMS key store.

A KMS key is a logical resource; its key material performs the cryptographic operations. Rotation can change the material without changing the key ID, ARN, policies, or aliases. First inspect the key's origin, type, and configuration: origin alone does not establish rotation eligibility.

A CloudWatch Logs data protection policy selects the sensitive data to detect using data identifiers. Managed identifiers recognize supported categories such as email addresses and credentials; some also use contextual keywords rather than pattern matching alone. Custom identifiers use regular expressions for organization-specific formats. Detection is therefore only as complete as the identifiers and matching rules you select: masking is not a guarantee that every secret has been found.

An Amazon SNS message data protection policy detects selected sensitive data and applies a response at a message boundary. It is supported on Standard topics. It is separate from the topic access policy: permission to publish does not mean that the message content passes data protection checks.

A data protection policy controls disclosure at a particular service boundary. It does not follow a sensitive value through every system. Trace each copy and identify which reader or delivery must receive masked content. The diagram uses synthetic values and deliberately includes an independent raw archive.

ACM manages certificates; AWS Private CA operates private certificate authorities. These are different layers, not competing implementations of the same task. ACM can request publicly trusted certificates, import existing certificates, and request private certificates from an authorized AWS Private CA.

An ACM certificate has both a source and a Regional identity. Start with its source: requesting a public certificate through ACM gives ACM responsibility for issuance and, when eligible, managed renewal. You must validate control of every requested domain name before ACM can issue it.

Controlled issuance starts before signing. For direct API issuance, the requester generates a key pair and a certificate signing request (CSR); AWS Private CA receives the CSR, not the leaf certificate’s private key. The CSR proves possession of the corresponding key, but it does not establish permission to claim a particular service name. Your enrollment workflow must authorize the requested identity.

A shared root can certify separate regional subordinate CAs without sharing their signing keys. Each AWS Private CA has its own protected, non-exportable CA private key. The diagram shows certificate delivery, not request traffic, authorization calls, trust-store distribution, or key replication.

A cross-Region CA hierarchy connects separate regional certificate authorities through certificate signatures. Each subordinate has its own key pair; the root signs a CA certificate binding that subordinate's public key to its identity and authority. Both subordinates can therefore lead back to the same root of trust without sharing a private key.

The management account creates and administers the organization and pays its consolidated bill. Consolidated billing only combines billing without policy-based governance. All features includes consolidated billing and enables governance capabilities such as service control policies (SCPs). An SCP limits available permissions; it does not grant permissions.

AWS Organizations owns the account hierarchy: the organization root, organizational units (OUs), and accounts. It provides account creation and invitations, consolidated billing, and organization policies. Policy-based governance such as service control policies (SCPs) requires all features, not the consolidated-billing-only feature set.

A landing zone is the managed foundation for a multi-account environment: shared accounts, governance configuration, and supporting resources deployed by AWS Control Tower. In a new environment, setup establishes the organization and its foundation. In an existing organization, setup uses the existing management account; it does not require rebuilding the account hierarchy or automatically enrolling every existing workload account.

An optional control's guidance and behavior answer different questions. Guidance such as strongly recommended or elective helps you prioritize adoption. Behavior determines what the control actually does: prevent an operation, detect a resource's state, or check a CloudFormation deployment before provisioning.

Service control policies (SCPs) bound the permissions of principals in member accounts. Resource control policies (RCPs) bound access to resources in member accounts for supported services. Neither grants permission: passing these ceilings still leaves IAM authorization and other applicable controls to evaluate.

Management-policy inheritance combines policy settings along an account’s path through the AWS Organizations hierarchy. The result is an effective policy, not simply a copy of the document attached directly to the account. An account with no directly attached policy can still inherit configuration.

Delegated administration lets a designated member account operate a supported service across organization accounts. Keep routine security operations in a dedicated security account, organization governance in the management account, and application administration in workload accounts. This separates responsibilities only if incompatible administrative powers remain under independent control.

AWS Firewall Manager defines and maintains security policy across accounts; the underlying protection service enforces traffic rules. This diagram follows a regional AWS WAF policy's control-plane dependencies, not application traffic.

Root credential management starts with eliminating credentials where they are unnecessary, not distributing more authenticators. In AWS Organizations, centralized root access supports two distinct capabilities: managing member-account root credentials and performing supported privileged tasks through temporary root sessions. With root credentials removed and password recovery blocked, a member account does not need a standing root password or root MFA device.

A reusable definition reduces variation, but also amplifies mistakes: an unsafe default can reach every account. Treat the release as a versioned bundle of templates or modules, pinned dependencies, validation rules, and reviewed environment inputs. Promote the same bundle between deployment waves rather than rebuilding from a moving branch.

Infrastructure as code (IaC) describes intended resources and their configuration. Policy as Code expresses requirements against which definitions or running resources are evaluated. Both can be versioned, reviewed, and tested, but they answer different questions: what should be created, and is that configuration acceptable?

Static analysis inspects a template without deploying its resources. For CloudFormation, combine cfn-lint with CloudFormation Guard: they answer different questions, and neither tool's success substitutes for the other's.

cfn-lint checks CloudFormation templates against resource schemas and additional lint rules. It can identify unsupported properties, incorrect property types, invalid references, and other template problems without creating resources. For example, a misspelled RDS property such as StorageEncryped is a structural defect. Run linting for the intended deployment Regions because resource support can differ.

CloudFormation Guard evaluates structured input against authored rules; it does not deploy resources or automatically block CloudFormation. A blocking gate exists only when automation runs Guard, checks the outcome, and withholds deployment on failure. cfn-lint checks template validity and configuration issues; passing it does not prove that your security rules passed.

A StackSet holds a template and deployment settings; a stack instance represents its deployment into one account and Region. The permission model determines how CloudFormation gets authority in target accounts. It does not determine which accounts should receive a deployment.

A tagging contract defines canonical keys, allowed values, ownership, and which resources must carry each key. For example, standardize Department=Finance, CostCenter=CC104, and Environment=Production. Spelling and capitalization matter: Environment and environment can be distinct resource tag keys. Use stable business identifiers, and keep secrets and sensitive personal data out of tags.

A tag-based resource group saves a query, not a fixed list of resource identifiers. Its TAG_FILTERS_1_0 query combines ResourceTypeFilters with TagFilters. A resource must pass the type filter and every tag filter. Membership changes as matching resources and their tags change; resources are not manually pinned into this kind of group.

AWS Service Catalog shares approved product definitions through portfolios. A product has provisioning artifacts, such as versions of a CloudFormation template. Sharing the portfolio makes those offerings available to a recipient account; it does not give that account access to resources previously provisioned from them.

An AWS RAM resource share associates supported resources, principals, and managed permissions. Principals identify the recipients; managed permissions define the actions those recipients can perform on the shared resource types. Ownership stays with the resource owner.

A portfolio share makes a publisher's approved products and provisioning artifacts available in another account. The publisher retains control of the shared definitions; recipients do not receive an independently editable copy. Portfolio sharing is Regional, so configure sharing in each Region where the products are needed.

A compliance requirement does not become an AWS responsibility simply because the workload runs on AWS. Identify the control activity, the layer where it operates, and the party authorized to perform it. AWS protects the underlying infrastructure; customers remain responsible for their data, identities, permissions, and customer-controlled configurations.

AWS Audit Manager has been in maintenance since 2026-03-31. It is closed to new customers; existing customers can keep using it. This lesson describes the service as AWS offered it, not as a recommendation for new workloads. AWS's migration guide is https://docs.aws.amazon.com/audit-manager/latest/userguide/audit-manager-availability-change.html.

AWS Artifact Reports provides access to AWS compliance documents, including SOC reports, PCI documentation, and ISO certificates. Choose the document that supports the control assertion you need to evaluate: a certificate and an auditor’s detailed report do not provide the same evidence.

AWS Audit Manager has been in maintenance since March 31, 2026: it is closed to new customers, while existing customers can continue using it. This lesson explains its existing assessment model, not a recommendation for new workloads. AWS's migration guide is https://docs.aws.amazon.com/audit-manager/latest/userguide/audit-manager-availability-change.html.

A security architecture review examines whether a workload's design and operating practices address its business and security requirements. The workload is the business capability, not merely its resources: it includes applications, infrastructure, data, procedures, and accountable people. Define the environment, accounts, Regions, data classifications, critical flows, and business impact before interpreting review answers.

An AWS Well-Architected Tool review evaluates a defined workload against a lens. For this lesson, use the AWS Well-Architected Framework lens and its Security pillar. Establish the workload boundary first: the application, environments, accounts, dependencies, and responsibilities being reviewed. Otherwise, evidence from one component can be mistaken for evidence covering the whole workload.

AWS Trusted Advisor security checks evaluate selected configuration conditions against AWS best practices. A resource-level result connects a condition to an identifiable resource, such as a security group or S3 bucket. Some checks instead evaluate account-level settings, so not every result describes an individual workload resource.

AWS Well-Architected Tool supports a questionnaire-based review of a defined workload against AWS architectural best practices. For security, it helps reviewers examine how identity, data protection, detection, and incident response work together. Its unit of reasoning is the workload: components and operational practices that deliver business value, potentially spanning multiple accounts.

AWS Trusted Advisor asks where an AWS environment could better follow AWS best practices. Its security recommendations sit alongside recommendations for cost, performance, reliability, and other operational concerns. A check identifies a condition worth reviewing and provides guidance; it is not inherently an assessment against a selected compliance standard.