SAP-C03 sample questions — 25 answered and explained

Athena partition projection computes partitions from table properties, bypassing catalog partition lookups and registration.

Two requirements must hold together: fast planning on a huge partition count and zero-delay availability without registration. Partition projection meets both because Athena derives partition values from the configured ranges and path template. Partition indexes fix only planning; event-mode crawls and MSCK REPAIR fix only (some of) freshness and still register partitions.

1. Split the requirement into planning speed and freshness without registration.
2. Test each option against both; most fix one.
3. Recognise that only projection removes catalog partitions from the query path.

Exam tip: Highly partitioned, predictable S3 layouts: partition projection gives fast planning and instant new partitions with no crawler.

Step Functions Standard workflows are exactly-once, long-running (up to one year) and keep execution history; Express workflows are short and at-least-once (async) or at-most-once (sync).

Six-day duration, a non-idempotent step and an audit history all point to a Standard workflow. Every Express variant is capped at five minutes and asynchronous Express can run a step more than once; a hand-built Lambda and SQS chain is also at-least-once and leaves the company to build its own execution history.

1. Check duration: anything over five minutes needs Standard.
2. Check execution semantics: non-idempotent steps need exactly-once.
3. Check audit needs: Standard keeps execution history in the service.

Exam tip: Long, non-idempotent, auditable workflow: Standard. Short, high-volume, idempotent: Express.

Express workflows trade exactly-once semantics and long duration for high rates and request/duration pricing.

The workload is short, very high volume, idempotent and fire-and-forget. That is the Express sweet spot, and because the caller does not wait, the asynchronous invocation type fits. Standard would be correct but expensive at this rate; synchronous Express adds a wait the caller does not need.

1. Check duration and volume: short and very high favours Express.
2. Check semantics: idempotent steps make at-least-once safe.
3. Check the caller: no need for the result means asynchronous invocation.

Exam tip: High-volume, short, idempotent, fire-and-forget: asynchronous Express workflows.

Long-running workflows use task tokens for external or human steps and Catch-driven compensation (sagas) for multi-service consistency.

Two needs: undo partial work and wait for a human without polling. Catch blocks that call cancellation tasks implement the saga, and a .waitForTaskToken task pauses the Standard workflow until the web app returns the token. Retries do not compensate, a polling loop is ruled out, and Express workflows cannot run long enough.

1. Treat partial failure across services as a saga: compensate, do not roll back.
2. Treat a human or external decision as a callback with a task token.
3. Check duration: a two-day wait needs a Standard workflow.

Exam tip: Human approval = task token callback; cross-service rollback = saga compensation in Catch.

Lambda durable functions provide checkpointed, long-running execution (up to a year) written in ordinary code, with no compute charge during waits.

The deciding constraint is "keep the workflow in our own code". Step Functions could run the process but in a separate definition. A durable function wraps the handler, checkpoints each step, and suspends on waits without compute charges. A single invocation cannot last three days, and a hand-built SQS loop recreates what the service provides.

1. Confirm a durable mechanism is needed: the process waits for days.
2. Apply the stated constraint: the workflow must stay in Python code.
3. Choose the option that is both durable and code-first.

Exam tip: Durable workflow, code-first, in Lambda: durable functions. Visual or cross-service orchestration: Step Functions.

Durable functions resume by replaying the handler from the beginning; completed steps return checkpointed results, but code outside steps runs again, so it must be deterministic.

The symptom (steps ran once, yet a value changed) is the replay model at work. Anything non-deterministic, such as a random ID or the current time, must be produced inside a step so its result is checkpointed and replayed. Timeouts, versions and warm environments do not change the fact that the handler body re-runs.

1. Recall that resumption means replay from the top of the handler.
2. Identify non-deterministic code outside a step.
3. Wrap it in a step so the checkpoint supplies the same value on replay.

Exam tip: In a durable function, anything random or time-based belongs inside a step; code outside steps re-runs on every replay.

ALB built-in authentication supports OIDC or a Cognito user pool; a user pool federates SAML 2.0 IdPs, so it bridges SAML-only IdPs to the ALB.

Two facts combine here. First, an ALB listener rule can authenticate users itself with authenticate-oidc or authenticate-cognito, so no application change is needed and unauthenticated requests stop at the load balancer. Second, the corporate IdP speaks only SAML 2.0, which authenticate-oidc cannot use. A Cognito user pool federates with SAML IdPs, so the ALB authenticates against the user pool, and the user pool sends users to the corporate IdP. Identity pools issue AWS credentials, not browser sessions, and signed cookies need custom code.

1. Find where authentication can happen without code: the ALB listener rule.
2. Check which protocols the ALB supports: OIDC or a Cognito user pool.
3. Bridge the SAML-only IdP through a Cognito user pool SAML provider.
4. Use authenticate-cognito before forward so unauthenticated requests never reach targets.

Exam tip: ALB authentication speaks OIDC; for a SAML-only IdP, put a Cognito user pool in between.

Cognito identity pools exchange user tokens for scoped temporary AWS credentials, and policy variables give each user their own resources.

To call S3 directly, the app needs AWS credentials. An identity pool exchanges the user pool token for temporary credentials of an IAM role, and the role's policy can use the identity ID policy variable so each user can write only under their own prefix. User pool tokens cannot sign S3 requests, whether sent to the bucket or to an access point, per-user access points do not scale, and presigned URLs need the signing service the company wants to avoid.

1. Note that S3 needs AWS-signed requests, not application tokens.
2. Use an identity pool to turn the user pool token into temporary AWS credentials.
3. Scope the role with the identity ID policy variable for per-user prefixes.
4. Reject options that send app tokens to S3, need per-user resources or need a signing backend.

Exam tip: User pool authenticates; identity pool hands out scoped AWS credentials. Use the identity ID variable for per-user access.

Machine-to-machine OAuth 2.0 uses the client credentials grant; Cognito resource servers define scopes that API Gateway enforces per method.

Partners' systems authenticate as themselves, not on behalf of a user, so the OAuth 2.0 client credentials grant fits. In Cognito, a resource server defines custom scopes, and each partner gets its own confidential app client that is allowed only its scopes and can be disabled on its own. A Cognito user pool authorizer with OAuth scopes on each method validates the access token and its scopes at API Gateway. API keys are not authorization, unauthenticated identity pools are open, and the authorization code grant needs a user.

1. Classify the caller: a backend system with no user, which means client credentials.
2. Define permissions as resource-server scopes and give each partner its own app client.
3. Enforce scopes at API Gateway with a Cognito authorizer and method OAuth scopes.
4. Reject API keys (throttling, not auth) and user-interactive grants.

Exam tip: No user in the loop: client credentials grant plus scopes, checked per method by the Cognito authorizer.

EKS Pod Identity maps a service account to an IAM role without OIDC providers, using one service principal that works in every cluster.

Pod Identity associations are configured in EKS, and every role trusts pods.eks.amazonaws.com, so the same role works in any cluster without editing its trust policy. That separates the IAM team's work (roles and policies) from the cluster team's work (associations) and needs no OIDC provider. IRSA works but requires an OIDC provider per cluster and trust-policy edits, node roles give every pod on a node the same permissions, and stored keys are long-term credentials.

1. Note the two constraints: no OIDC providers, no trust-policy edits per cluster.
2. Recall that IRSA relies on one OIDC provider per cluster.
3. Choose Pod Identity, whose roles trust one service principal.
4. Reject node-role and static-key designs for least privilege.

Exam tip: One role, many clusters, no OIDC provider: EKS Pod Identity.

External IDs stop the confused deputy problem only when the third party assigns a unique value per customer and the customer's trust policy requires it.

The vendor is a deputy acting for many customers with one identity. To stop customer A from steering it to customer B's role, the vendor generates a unique external ID per customer, shows it in that customer's console, and always passes it when acting for that customer. B's role requires B's ID, so a request on behalf of A fails. If customers choose the ID themselves, an attacker can reuse the victim's value. IP conditions and organization IDs cannot distinguish which customer the shared vendor role is serving. Trusting the specific vendor role instead of the account root is the tighter principal.

1. Recognise the confused deputy: one vendor identity, many customer roles.
2. Recall the control: sts:ExternalId in the customer's trust policy.
3. Check who generates it: the vendor, uniquely per customer, not the customer.
4. Prefer the vendor's specific role as principal over its account root.

Exam tip: External ID: unique per customer, generated by the third party, required in the customer's trust policy.

Safe delegation of IAM role creation needs a permissions-boundary condition on creation plus protection of the boundary itself.

The iam:PermissionsBoundary condition makes it impossible to create or change a role's permissions unless DevBoundary is attached as its boundary, capping every created role. That alone leaves two escalation paths: removing the boundary from a role, or editing the DevBoundary policy to widen it. Explicit denies close both. Bounding the developers' own role, or scoping their session, does not constrain the roles they create, and an SCP that denies creation fails the self-service goal.

1. Separate what developers can do from what the roles they create can do.
2. Cap created roles with an iam:PermissionsBoundary condition on create and attach actions.
3. Close the bypasses: removing the boundary and editing the boundary policy.
4. Reject controls that act only on the developer's own session or block creation entirely.

Exam tip: Delegated role creation = require the boundary on create, then protect the boundary from removal and edits.

Mixed instances policies split capacity between an On-Demand base, a percentage above it, and Spot; Capacity Rebalancing replaces at-risk Spot Instances proactively.

OnDemandBaseCapacity=4 guarantees four non-reclaimable instances, and OnDemandPercentageAboveBaseCapacity=0 makes all extra capacity Spot for the lowest cost. Capacity Rebalancing responds to EC2 rebalance recommendations, which usually arrive before the two-minute interruption notice, by launching a replacement and then terminating the at-risk instance, so capacity does not dip. Percentage 100 removes savings, a maximum price does nothing for capacity, and scheduled churn is unrelated to interruption risk.

1. Protect the four contracted instances with On-Demand base capacity.
2. Make everything above the base Spot with a 0% On-Demand share.
3. Use Capacity Rebalancing to launch replacements before reclaims.

Exam tip: On-Demand base for what must not be interrupted, 0% On-Demand above it, and Capacity Rebalancing to replace at-risk Spot early.

Lambda on arm64 (Graviton) is billed at a lower duration price than x86_64 and usually gives better price performance.

Switching the function's architecture to arm64 runs it on Graviton processors at a lower price per GB-second. With no native binaries or architecture-specific dependencies, the code needs no change. Provisioned concurrency and memory increases change performance characteristics and usually cost more, and reserved concurrency is a scaling limit, not a pricing lever.

1. Check for native or architecture-specific dependencies (none here).
2. Recall that arm64 Lambda has a lower duration price.
3. Switch the architecture setting and redeploy.

Exam tip: Interpreted Lambda code without native binaries can move to arm64 for a lower price with no code change.

Standard Workflows bill per state transition; Express Workflows bill per execution, duration and memory and suit short, high-volume, idempotent work.

Forty million six-state executions a day generate hundreds of millions of state transitions, the Standard pricing unit. Each run is short and idempotent, which matches Express Workflows (up to five minutes, at-least-once for asynchronous runs). The workflow type cannot be changed on an existing state machine, so the definition is deployed as a new Express state machine and the event source is pointed at it.

1. Identify the pricing unit driving cost: state transitions in a Standard Workflow.
2. Check fit for Express: under five minutes and idempotent.
3. Remember the type is immutable, so create a new Express state machine.

Exam tip: Short, high-volume, idempotent workflows belong on Express; switching means creating a new state machine because the type is immutable.

A Standard Workflow can host long waits and callbacks, while a Distributed Map can run its child workflows as Express executions to cut per-transition cost on high-volume steps.

The approval needs a Standard Workflow: it can wait for days and supports the .waitForTaskToken callback pattern, which Express does not. The enrichment is high-volume, short and idempotent, which is where per-transition pricing hurts. A Distributed Map state in the Standard parent can run its item processing as Express child workflows, billed by executions and duration. Making everything Express breaks the approval, and concurrency does not reduce transitions.

1. Find the long-running part (approval callback) and confirm it needs Standard.
2. Find the high-volume part (line enrichment) and confirm it suits Express.
3. Combine them: Standard parent, Distributed Map, Express children.

Exam tip: Mix types: Standard for long waits and callbacks, Express children under a Distributed Map for high-volume short steps.

MGN uses two paths from the source: TCP 443 to the MGN endpoint for control, and TCP 1500 to the replication servers for data.

The servers registering in the console proves TCP 443 to the MGN endpoint works. The data path is a separate outbound connection from the agent to the replication servers in the staging area subnet on TCP 1500, which an HTTPS-only firewall blocks. Opening inbound or reversed rules does not help because the agent initiates the connection, and S3 access concerns the staging subnet, which already works.

1. Use the symptom: registered in the console means the TCP 443 control path works.
2. Recall the data path: agent to replication server on TCP 1500, initiated by the source.
3. Open that port outbound from the source servers to the staging area subnet.

Exam tip: Console shows the server but sync never starts: open outbound TCP 1500 from the source servers to the staging subnet.

MGN replication defaults to the public internet with public IPs on replication servers; private routing is two explicit settings.

Two defaults have to be changed together. Data routing defaults to sending replicated data over the internet to the replication servers' public IPs; Use private IP sends it to their private addresses over Direct Connect (the option does not create the private connection, which already exists here). Separately, replication servers get a public IP by default; Do not create public IP removes it. Throttling, a default subnet and volume encryption don't control the path or exposure.

1. Recall the defaults: public IP on replication servers and data routed over the internet.
2. Change the data path to private IP so it uses Direct Connect.
3. Remove the public IP so the replication servers are not internet-reachable.

Exam tip: Private MGN replication = Use private IP for data routing + Do not create public IP.

Until a cutover is finalized it can be reverted; finalizing ends replication for good.

MGN lets you revert a launched cutover to Ready for cutover, optionally deleting the cutover instances, while replication keeps the staging copy current. Finalize is the point of no return: it stops replication, discards replicated data and terminates replication resources. Archiving is housekeeping after finalization, and reinstalling agents throws away the synced data.

1. Check whether the cutover has been finalized: here it has not.
2. Choose revert to return to Ready for cutover with replication intact.
3. Reserve finalize for after acceptance testing succeeds.

Exam tip: Problems after cutover but before finalize: revert to Ready for cutover; finalize only when the migration is accepted.

MGN automates the target build with two layers: EC2 launch templates for how the instance launches, post-launch actions for what runs on it afterward.

Two requirements need two mechanisms. Placement and identity (subnet, instance profile) belong in the launch settings and EC2 launch template that MGN uses for every test and cutover launch. Software and configuration changes on the launched instance belong in post-launch actions, which use Systems Manager documents (there is a predefined CloudWatch agent action, and custom documents run scripts). Replication settings only govern the staging area, a golden AMI would replace the migrated disks, and Control Tower doesn't execute instance scripts.

1. Separate launch-time settings (subnet, profile) from post-launch configuration (agent, script).
2. Map launch-time settings to the EC2 launch template MGN uses.
3. Map post-launch configuration to MGN post-launch actions (SSM documents).

Exam tip: MGN: launch template for where and how it launches; post-launch actions for what runs on it afterward.

Stack policies guard individual resources during stack updates; termination protection guards the stack itself from deletion.

Each requirement maps to one control. A stack policy is checked on every update, so denying Update:Replace and Update:Delete on the cluster makes those updates fail while an Allow on other resources keeps Lambda updates flowing. Termination protection blocks DeleteStack. DeletionPolicy and UpdateReplacePolicy decide what happens to the physical resource after it leaves the stack or is replaced; they do not stop the change. A manual approval for every change set works poorly with several daily deployments.

1. Separate the requirements: block replacement/deletion of one resource, allow others, prevent stack deletion.
2. Use a stack policy for resource-level update protection.
3. Use termination protection for stack-level delete protection.
4. Reject resource attributes that only preserve resources after the change happens.

Exam tip: Block a risky update: stack policy. Block stack deletion: termination protection. Keep data after a change: DeletionPolicy / UpdateReplacePolicy.

DeletionPolicy covers removal and stack deletion; UpdateReplacePolicy covers the old physical resource during a replacement.

Two different events are named, and each has its own attribute. DeletionPolicy applies when the resource is removed from the template or the stack is deleted; UpdateReplacePolicy applies to the old resource when an update replaces it. Snapshot on both takes a final DB snapshot and then deletes the instance, so a recoverable copy remains and nothing keeps billing. Retain on either would leave running instances. A long automated-backup retention period does not help, because automated backups are tied to the instance and are removed with it by default when it is deleted.

1. List the events: replacement, removal from the template, stack deletion.
2. Map replacement to UpdateReplacePolicy and removal/deletion to DeletionPolicy.
3. Choose Snapshot rather than Retain because old instances must not keep running.
4. Reject automated backups: they are deleted with the instance by default.

Exam tip: Snapshot on replace = UpdateReplacePolicy; snapshot on delete/removal = DeletionPolicy. You usually need both.

Standard change sets compare template to template; drift-aware change sets compare the live state with the desired template and revert drift.

Two facts decide it. A traditional stack update only acts on properties that changed between the previous and the new template, so out-of-band edits to unchanged resources survive the deployment. A drift-aware change set (DeploymentMode REVERT_DRIFT) performs a three-way comparison of actual state, previous deployment and desired template, shows what will be overwritten, and updates drifted resources back to the template, even when the template did not change them. Resource import keeps current values and the Config rule only reports.

1. Note that the template did not change, so a normal update has nothing to apply.
2. Recall that standard change sets do not account for drift.
3. Use a drift-aware change set (REVERT_DRIFT) to preview and revert live drift.
4. Reject import (adopts current state) and Config drift checks (report only).

Exam tip: To overwrite drift with template values, create a drift-aware change set (REVERT_DRIFT); a normal update ignores drift on unchanged resources.

Drift-aware change sets keep the live value of AWS-managed properties (such as scaling-managed desired capacity) unless the template changes them.

A drift-aware change set normally restores drifted properties to the template, but it recognises properties that AWS services are expected to change, such as desired capacity managed by an AWS::AutoScaling::ScalingPolicy or Application Auto Scaling. When the template does not modify those properties, the actual value is preserved and the change set reports them as ignored drift. So the group keeps 24 instances.

1. Identify the property: desired capacity set by a scaling policy.
2. Recall that drift-aware change sets treat such properties as AWS-managed.
3. Check that the template does not change the property.
4. Conclude the live value is preserved.

Exam tip: Drift-aware change sets revert real drift but leave AWS-managed properties (like scaled desired capacity) alone.

CloudFormation Hooks validate resources before provisioning; Guard Hooks do it with declarative Guard rules instead of code.

The stem asks for prevention before provisioning, declarative rules and no Lambda code. A Guard Hook evaluates CloudFormation Guard rules stored in S3 against resources before they are created or updated, and FAIL mode stops the operation. A Lambda Hook would also prevent the deployment but needs function code. AWS Config rules are detective (after creation), and proactive Config evaluation does not block deployments.

1. Identify the timing: before any resource is provisioned.
2. Identify the authoring constraint: declarative rules, no Lambda code.
3. Choose a Guard Hook with failure mode FAIL.
4. Reject detective Config rules and code-based Lambda Hooks.

Exam tip: Block non-compliant CloudFormation resources before creation with declarative rules: Guard Hook in FAIL mode.