Gigalogy Cloud Interview Sprint

Create an AWS interview pack with incident and rapid-fire drills.

Introduction

30 Second Summary

An interview can jump from drawing a system to handling a customer problem in seconds. Clear thinking matters most when the question is incomplete and the pressure is high.

In this project, you will build a role-specific cloud infrastructure interview pack in Visual Studio Code. You will use it to rehearse an AWS architecture pitch, an incident response, and a rapid-fire infrastructure round.

What You'll Build

Picture opening interview-pack.md with a complete architecture pitch, a scored incident response, a recovery plan, and concise rapid-fire answers ready to rehearse aloud.

By the end of this project, you'll have:

A six-sentence production architecture pitch that traces a request from Amazon Route 53 through AWS WAF and an Application Load Balancer to Amazon ECS tasks on AWS Fargate. It also explains monitoring with Amazon CloudWatch, scaling, health checks, and rollback.
A scored incident response that prioritizes customer impact, production evidence, reversible mitigation, stakeholder communication, and proof of recovery.
A compact rapid-fire answer bank for networking, Terraform, Docker, Linux, and CI/CD. You can use it to answer nine infrastructure prompts in no more than three sentences each.
Secret Mission: Deliver a calm six-sentence customer escalation update while the exact cause of a production slowdown remains uncertain.

Are there any prerequisites?

Beginner familiarity with cloud infrastructure is enough. The guide supplies every scenario, answer checkpoint, and scorecard.

The rehearsal stays inside Visual Studio Code. You do not install software or deploy cloud resources.

Before We Start

This opening checkpoint locks in the production system you are preparing to discuss. Your commitment to answer from current knowledge before reading each checkpoint reveals the gaps that need the most practice.

Set Up Your Interview Pack

Interview practice can easily scatter across separate notes. That makes weak answers harder to spot during your remaining preparation days.

A single Markdown file gives every interview round a permanent home. This step creates that file in Visual Studio Code so you can revisit one structured artifact.

In this step, get ready to:

Create the gigalogy-mock-interview folder in Visual Studio Code.
Add six named sections to interview-pack.md.
Define a reusable 0-2 score scale under Scorecard.

Create the rehearsal workspace

The project folder keeps your rehearsal pack separate from other files. Opening that folder as a workspace also keeps the pack easy to find during later drills.

Press Cmd+Space on macOS or the Windows key on Windows to open your search bar.
Type Visual Studio Code and press Enter to open it.
Click File in the top menu bar.
Select Open Folder....
Select Desktop in the folder picker.
Click New Folder.
Enter gigalogy-mock-interview and press Enter.

Your empty gigalogy-mock-interview folder now exists on your Desktop.

Select the gigalogy-mock-interview folder.
Click Select Folder.
Select Yes, I trust the authors if Visual Studio Code displays a Workspace Trust prompt.

Good start. The Explorer sidebar now shows gigalogy-mock-interview as your open workspace.

Click New File... in the Explorer sidebar.
Enter interview-pack.md and press Enter.
Press Cmd+S on macOS or Ctrl+S on Windows to save interview-pack.md.

You should see interview-pack.md open as a blank editor tab.

Folder or file missing?

Open the folder picker again if Explorer shows a different workspace.
Choose gigalogy-mock-interview from your Desktop.
Create interview-pack.md from the Explorer sidebar if the editor remains blank.

Help me fix my Visual Studio Code workspace.

Add the rehearsal sections

Each heading gives one interview activity a dedicated lane. This structure keeps your first attempt beside the checkpoints that assess it.

Add all six rehearsal sections to the blank interview-pack.md file by entering:

# Architecture Pitch

# Incident Drill

# Recovery Plan

# Rapid-Fire Answers

# Scorecard

# Final Reflection

How does this structure help?

Architecture Pitch holds your production request-path explanation.
Incident Drill captures your response under pressure.
Recovery Plan turns the incident lessons into a repeatable process.
Rapid-Fire Answers holds your concise infrastructure explanations.
Scorecard gives every answer the same assessment scale.
Final Reflection records the weakest area to revisit.

Save interview-pack.md by pressing Cmd+S on macOS or Ctrl+S on Windows.
Open the Markdown preview by pressing Cmd+Shift+V on macOS or Ctrl+Shift+V on Windows.

You should see six large section headings in the preview.

Headings showing as plain text?

Add # to the beginning of each heading if the text does not render as a heading.
Save interview-pack.md if the preview remains blank.

Help me fix my Markdown headings.

Define the scorecard and verify the pack

The project scale turns vague self-confidence into a repeatable assessment. Each score separates unsafe gaps from answers that include priorities plus trade-offs.

Return to the interview-pack.md editor tab.
Find the # Scorecard heading.
Place your cursor on the blank line below # Scorecard.
Add the three score definitions by entering:

- 0 = absent or unsafe.
- 1 = partly correct but vague.
- 2 = correct, prioritized, and explained with a trade-off.

What does the scale measure?

A score of 0 flags a missing answer or an unsafe response.
A score of 1 marks an answer with useful knowledge but weak detail.
A score of 2 rewards a correct answer with clear priorities plus a trade-off.

Save interview-pack.md by pressing Cmd+S on macOS or Ctrl+S on Windows.

✔️ Awesome, I've got everything!

Your saved interview pack is ready for its final visual check.

ⓧ I'd like to double check the full code

# Architecture Pitch

# Incident Drill

# Recovery Plan

# Rapid-Fire Answers

# Scorecard

- 0 = absent or unsafe.
- 1 = partly correct but vague.
- 2 = correct, prioritized, and explained with a trade-off.

# Final Reflection

How to use this reference

This reference shows the complete interview pack for this step. Any missing heading or scoring line points to the exact place to correct.

Before you check, where do you expect the three scoring levels to appear in the finished pack?

Return to the Markdown preview tab to inspect the saved interview-pack.md file.

What should I see?

You see all six section headings in the required order.
You see 0 = absent or unsafe under Scorecard.
You see 1 = partly correct but vague on the next scoring line.
You see 2 = correct, prioritized, and explained with a trade-off on the final scoring line.

Scorecard in the wrong place?

Move the three scoring lines directly below # Scorecard if they appear beneath Final Reflection.
Put each score definition on its own line if the preview shows one combined paragraph.

Help me correct my Scorecard layout.

That setup is complete. Your interview pack now gives every rehearsal answer a clear home plus a consistent scoring standard.

Your rehearsal workspace is ready. Next, you'll use Architecture Pitch to defend a production AI recommendation API from request entry through monitoring.

Defend Your Production AI API Architecture

Your structured interview pack is ready in Visual Studio Code. The Architecture Pitch section gives you one place to build a defensible production story.

Interviewers need to hear a coherent request path before they can trust individual service definitions. You will create a visible first-pass design that connects security, networking, containers, scaling, observability, and rollback.

In this step, get ready to:

Add the fictional interview prompt plus its request path.
Record health checks, a scaling assumption, observability, and rollback.
Deliver a six-sentence architecture explanation with one trade-off.

Map the request path

A request path turns a collection of services into one traffic journey. It also shows where each security boundary or operational control belongs.

Return to the Architecture Pitch heading in interview-pack.md.
Place your cursor on the blank line below the heading.
Add the interview prompt plus the architecture notes by pasting this block:

**Interview prompt**

"Design the AWS infrastructure for a real-time personalization API that must remain available during traffic spikes and failed deployments."

**Request path**

client -> Amazon Route 53 alias record -> AWS WAF web ACL associated with an Application Load Balancer in public subnets -> target group -> Amazon ECS service with AWS Fargate tasks in private subnets across Availability Zones

**Operational notes**

- Health checks: The Application Load Balancer routes requests only to healthy targets, while Amazon ECS monitors target health.
- Scaling assumption to test: Start with CPU utilization.
- Observability: Use Amazon CloudWatch metrics and logs for request latency, error rate, task health, CPU utilization, memory utilization, and deployment behavior.
- Deployment rollback path: Use the Amazon ECS deployment circuit breaker to detect a failed rolling deployment and roll back to the most recent completed deployment.

What does this architecture capture?

Amazon Route 53 provides the DNS handoff to the protected endpoint.
AWS WAF filters requests at the Application Load Balancer before traffic reaches the targets.
The target group uses health checks to keep requests away from unhealthy tasks.
Amazon ECS runs AWS Fargate tasks in private subnets across Availability Zones.
Amazon CloudWatch supplies the metrics and logs needed to follow service behavior.
Service auto scaling starts with CPU utilization as an explicit assumption to test.
The deployment circuit breaker provides a reversible path when a rolling deployment fails.

Save interview-pack.md.
Scan the request path from left to right.
Confirm that the path ends with AWS Fargate tasks in private subnets across Availability Zones.

You should now see one continuous route from the client to the private tasks. The operational notes should name health checks, CPU utilization, Amazon CloudWatch, and rollback.

Request path out of order?

Check that the AWS WAF web ACL is associated with the Application Load Balancer. Confirm that the target group appears before the Amazon ECS service.

Help me check my AWS architecture request path.

Write the six-sentence explanation

A strong spoken answer assigns one job to each sentence. This structure keeps your explanation concise while still covering the production decisions an interviewer can challenge.

Place your cursor below the operational notes in interview-pack.md.
Add the spoken architecture explanation by pasting this block:

**Six-sentence spoken answer**

1. A client reaches the personalization API through an Amazon Route 53 alias record that directs traffic to the Application Load Balancer protected by an AWS WAF web ACL.
2. The load balancer sits in public subnets, while the Amazon ECS service runs AWS Fargate tasks on private IP addresses across Availability Zones.
3. The target group's health checks keep traffic away from unhealthy tasks, while Amazon ECS monitors the load balancer's target-health reports.
4. I would start service auto scaling with CPU utilization as an assumption to test before production.
5. Amazon CloudWatch metrics and logs show request latency, errors, task health, CPU utilization, memory utilization, and deployment behavior.
6. The trade-off is that AWS Fargate reduces server management, while the team gives up direct control of the underlying servers.

How is the answer structured?

Sentence 1 explains the external request flow.
Sentence 2 defines the network boundaries.
Sentence 3 explains how unhealthy targets stop receiving traffic.
Sentence 4 labels CPU utilization as an assumption to test.
Sentence 5 names the operational evidence available to responders.
Sentence 6 states the control trade-off created by the managed container model.

Save interview-pack.md.
Count the six numbered sentences.
Match each sentence to its architecture topic.

You should see exactly six numbered sentences. Each sentence should cover one required part of the architecture explanation.

Six sentences not lining up?

Check for a missing numbered line after the operational notes. Make sure the trade-off remains sentence 6.

Help me verify my six-sentence architecture answer.

✔️ Awesome, I've got everything!

Your Architecture Pitch now contains the prompt, request path, operational notes, and six-sentence answer.

ⓧ I'd like to double check the full code

## Architecture Pitch

**Interview prompt**

"Design the AWS infrastructure for a real-time personalization API that must remain available during traffic spikes and failed deployments."

**Request path**

client -> Amazon Route 53 alias record -> AWS WAF web ACL associated with an Application Load Balancer in public subnets -> target group -> Amazon ECS service with AWS Fargate tasks in private subnets across Availability Zones

**Operational notes**

- Health checks: The Application Load Balancer routes requests only to healthy targets, while Amazon ECS monitors target health.
- Scaling assumption to test: Start with CPU utilization.
- Observability: Use Amazon CloudWatch metrics and logs for request latency, error rate, task health, CPU utilization, memory utilization, and deployment behavior.
- Deployment rollback path: Use the Amazon ECS deployment circuit breaker to detect a failed rolling deployment and roll back to the most recent completed deployment.

**Six-sentence spoken answer**

1. A client reaches the personalization API through an Amazon Route 53 alias record that directs traffic to the Application Load Balancer protected by an AWS WAF web ACL.
2. The load balancer sits in public subnets, while the Amazon ECS service runs AWS Fargate tasks on private IP addresses across Availability Zones.
3. The target group's health checks keep traffic away from unhealthy tasks, while Amazon ECS monitors the load balancer's target-health reports.
4. I would start service auto scaling with CPU utilization as an assumption to test before production.
5. Amazon CloudWatch metrics and logs show request latency, errors, task health, CPU utilization, memory utilization, and deployment behavior.
6. The trade-off is that AWS Fargate reduces server management, while the team gives up direct control of the underlying servers.

## Incident Drill

## Recovery Plan

## Rapid-Fire Answers

## Scorecard

- 0 = absent or unsafe.
- 1 = partly correct but vague.
- 2 = correct, prioritized, and explained with a trade-off.

## Final Reflection

What should match?

This reference preserves all six original headings plus the Scorecard scale. Only the Architecture Pitch section contains the new material from this step.

Rehearse the architecture pitch

A written design becomes interview-ready when you can explain its sequence without losing the request path. Reading it aloud reveals vague transitions before an interviewer does.

Before you read it aloud, which handoff do you expect to be the easiest to skip?

Read the six numbered sentences aloud from interview-pack.md.
Trace the request path with your cursor during the first sentence.
Listen for a clear scaling assumption during sentence 4.
Confirm that sentence 6 ends with a trade-off.

You should hear the request move from Amazon Route 53 to an AWS WAF-protected Application Load Balancer. It should continue through the target group to Amazon ECS tasks on AWS Fargate before naming health checks, scaling, monitoring, and rollback.

You have the core story now. Your Architecture Pitch connects each service to a production responsibility that you can defend aloud.

Your first-pass architecture is coherent and ready to present. Next, you will pressure-test its scaling assumption against a production incident.

Respond to the Production Incident

Your Architecture Pitch in Visual Studio Code now explains a complete request path. It also marks CPU utilization as an assumption to test.

This production incident puts that scaling assumption under pressure. The customer-facing symptoms rise soon after a deployment.

You will use incident response to decide which evidence matters first. Your first answer stays checkpoint-free so it exposes your real instincts.

In this step, get ready to:

Draft an unaided response to the post-deployment incident.
Build a five-action response that prioritizes evidence before capacity changes.
Score six checkpoints to identify your weakest item.

Answer the incident without checkpoints

A timed incident inject gives you incomplete evidence under pressure. Your first response reveals which signals you naturally prioritize.

Switch back to interview-pack.md in the open Visual Studio Code window.
Place your cursor beneath Incident Drill.
Add the incident inject by copying the prompt below:

Ten minutes after a deployment, recommendation latency triples and HTTP 5xx responses rise. CPU and memory remain low, but request concurrency and downstream timeouts rise. What do you do first?

What is this inject testing?

The inject gives you a specific change window. It also gives you conflicting operational signals.

Your response shows whether you establish impact before reaching for a familiar infrastructure change.

Write your immediate response beneath the prompt before continuing to the next substep.
Use only your current knowledge.
Save interview-pack.md.
Read your response aloud.

You now have an honest first pass. That draft gives the rest of the drill something real to improve.

Before you compare the signals, do you think low CPU is enough to call the service healthy? Hold your answer in mind.

Compare the CPU utilization assumption in Architecture Pitch with the incident's low CPU reading.

CPU remains low while request concurrency rises. A CPU-only scaling policy sees no reason to add tasks.

That gap is intentional. Low resource use does not establish health when downstream timeouts are constraining requests.

Build an evidence-led response

A strong response starts with customer impact. Evidence then guides the smallest safe intervention.

Evidence to compare first

Each signal tests a different failure path. Comparing them prevents one resource metric from overruling customer impact.

User-facing latency.
HTTP 5xx responses.
Request concurrency.
Target health.
Application logs.
Downstream timeouts.
Deployment events.

Replace your first draft with a numbered response that starts with customer impact and the deployment ten minutes earlier.
Write action 2 to inspect every evidence source in the callout before changing capacity.
Read the first two actions aloud.

You should hear impact first. The recent deployment should frame the investigation without becoming an unverified root cause.

Write action 3 to limit the blast radius.
Write action 4 to name a rollback or the smallest reversible mitigation.
Read actions 3 and 4 aloud.

Your containment now narrows customer harm. Your mitigation also gives the team a safe path back.

Write action 5 to verify recovery with user-facing evidence.
Add a sentence to action 2 stating that low CPU and memory do not establish health while downstream timeouts and concurrency rise.
Read all five actions from top to bottom.

The sequence should move from impact to evidence. It should continue through containment before ending with verified recovery.

Add a separate stakeholder update line beneath the five actions.
Save interview-pack.md.
Read the stakeholder update aloud.

Your response now includes communication as part of incident ownership. The update keeps stakeholders informed while the technical investigation continues.

Response feels out of order?

If your response jumps straight to scaling, move capacity changes after the signal comparison.
If your mitigation is too broad, replace it with a rollback or smaller reversible action.

Ask for help to reorder your incident response.

Score your incident response

A scorecard converts general confidence into a specific preparation gap. Your existing 0-2 scale rewards safe prioritization plus a clear trade-off.

Use six scoring lenses

Impact stated.
Evidence prioritized.
Blast radius limited.
Rollback or mitigation named.
Stakeholder update included.
Recovery verified.

Return to Scorecard in the same file.
Add one row for each checkpoint shown in the callout.
Score every row from 0-2 with your existing scale.
Scan the completed rows for six numeric scores.

You should see one score beside every checkpoint. Missing rows would hide part of your incident response from the review.

Write one short reason beside every score.
Record the lowest-scoring checkpoint here: your weakest scorecard item.
Compare your reasons with the five actions in Incident Drill.

The lowest score identifies the answer habit that needs another rehearsal. A tie points to the item with the least specific explanation.

Return to Final Reflection in the same file.
Write Weakest item: followed by your weakest scorecard item.

Final Reflection now names the exact checkpoint to revisit. Your score has become a concrete practice target.

Save interview-pack.md.

Before the final review, do you expect every required checkpoint to be visible? Hold that expectation while you check.

Review Incident Drill against the final checklist below.

What should you see?

A response containing exactly five ordered actions.
Customer impact plus the recent deployment in action 1.
User-facing signals in action 2.
Target health in action 2.
Application logs in action 2.
Downstream timeouts in action 2.
Deployment events in action 2.
An explicit statement that low resource use does not establish health while timeouts and concurrency rise.
Blast-radius containment in action 3.
A rollback or smallest reversible mitigation in action 4.
User-facing recovery evidence in action 5.
A stakeholder update beneath the response.
Six scores from 0-2 with a reason beside each one.
The weakest item recorded in Final Reflection.

Strong work. Your Incident Drill now contains a scored five-action response.

Your evidence order shows why low resource use can coexist with customer harm.

Your response now handles the incident in a defensible order. Next, you will turn its lessons into a recovery plan another responder can follow.

Create an Observable Recovery Plan

Your Incident Drill exposed a dangerous gap. Low CPU can sit beside rising latency when a downstream dependency constrains requests.

This step turns that lesson into an observable recovery plan. You will connect user symptoms to workload pressure before linking change events to a reversible response.

In this step, get ready to:

Build a five-row signal table for the incident.
Turn those signals into an ordered recovery sequence.
Add prevention actions that strengthen future response.

Build the five-row signal table

A reliable observability plan starts with what customers experience. Supporting signals reveal where pressure entered the system.

How the signal layers fit together

User experience: latency and errors.
Traffic or work: request concurrency or queue depth.
Resources: CPU and memory.
Dependencies: downstream timeouts and target health.
Change health: deployment status.

Switch back to the Recovery Plan section in the open interview-pack.md tab.
Build a two-column table with the five rows from the signal map above.
Save interview-pack.md.

That gives you a wider lens. Low CPU now sits beside the customer and dependency signals it missed.

Write the response sequence

Signals support decisions when responders inspect them in a deliberate order. The sequence below keeps containment ahead of risky changes.

1. Declare impact and severity.
2. Inspect recent changes.
3. Contain the blast radius.
4. Roll back or apply the smallest reversible mitigation.
5. Validate user-facing recovery.
6. Communicate status.
7. Preserve a timeline.

Create an owner-tagged ordered list from the seven response actions under your signal table.
Save interview-pack.md.
Trace the original incident scenario through the completed sequence.

You should be able to follow the incident from declared impact to preserved timeline. The recovery step should return your attention to user-facing evidence.

Does the sequence still feel vague?

Check that each line starts with a decisive action.
Name one owner for each line.

Ask for help tightening the sequence without changing its order: Help me make my recovery sequence specific enough for another incident responder to follow.

Prevent the same blind spot

Prevention turns incident evidence into changes that reduce repeat failures. Each action should address a weakness revealed by the drill.

Select a scaling metric only after load testing shows that it correlates with demand and changes with capacity.
Add an actionable alarm or dashboard.
Update the runbook after post-incident analysis.

Why load testing comes first

A useful scaling metric should rise with demand. It should also change in proportion to available capacity.

Load testing checks those properties before production traffic depends on the metric.

Create a Prevention Actions list from the three actions above.
Save interview-pack.md.

Before you read the plan aloud, do you think another responder can identify the next action without asking you for context?

Read the Recovery Plan from top to bottom.

You should hear a complete path from detection through validation into prevention.

That closes the blind spot. Another responder can act without guessing who owns the next move or what recovery looks like.

Your interview pack now connects customer symptoms to evidence and reversible action. Next, you will defend the infrastructure mechanics behind those decisions under rapid-fire pressure.

Practice Infrastructure Rapid-Fire Answers

Your Recovery Plan in Visual Studio Code now connects user symptoms to evidence. It also gives every response a reversible next move.

The rapid-fire round tests whether you can defend the mechanics beneath that plan without drifting into irrelevant detail. You will turn nine infrastructure prompts into concise interview answers.

In this step, get ready to:

Defend networking plus security decisions in three concise answers.
Explain Terraform plus CI/CD safety in three concise answers.
Troubleshoot Docker plus Linux symptoms in three concise answers.

Answer the networking and security prompts

A strong networking answer traces one request from DNS to the application. Your first draft reveals whether you can explain each boundary without checkpoint help.

Switch back to the Rapid-Fire Answers section in interview-pack.md.
Apply a limit of three sentences to every answer. Include at least one risk, validation step, or trade-off.
Write your answer to “Why place an Application Load Balancer in public subnets and tasks in private subnets?” Use Amazon ECS tasks as the private workloads.
Read that answer aloud with a three-sentence limit.
Write your answer to “What does an Amazon Route 53 alias record contribute?”.
Read that answer aloud with a three-sentence limit.
Write your answer to “Where does an AWS WAF web ACL attach, and what risk does it reduce?”.
Read that answer aloud with a three-sentence limit.

Networking and Security Checkpoint

Public load balancer plus private tasks: An internet-facing Application Load Balancer accepts controlled ingress in public subnets. Amazon ECS tasks keep private addresses behind the target group. I would validate healthy targets across Availability Zones because public reachability still depends on working backends.
Route 53 alias record: An alias record maps the API domain to the Application Load Balancer. It supports a root domain or a subdomain. I would validate DNS resolution plus a successful request because the load balancer must also remain healthy.
WAF web ACL: A regional web ACL attaches to the Application Load Balancer in the same AWS Region. Its rules allow or block requests before they reach the targets. I would review filtered requests because an overly strict rule can reject legitimate traffic.

Revise any networking answer that misses a checkpoint.
Save interview-pack.md.
Read the three revised answers aloud. Each answer should explain the request path without exceeding three sentences.

That gives you a defensible network story from DNS through filtering to private application tasks.

Answer the Terraform and CI/CD prompts

Terraform questions test whether you can predict infrastructure changes safely. CI/CD questions test how you control the path from a commit to production.

Write your answer to “What does terraform plan do?”.
Read that answer aloud with a three-sentence limit.
Write your answer to “Why use remote state and locking?”.
Read that answer aloud with a three-sentence limit.
Write your answer to “What belongs between commit and production?”.
Read that answer aloud with a three-sentence limit.

Terraform and CI/CD Checkpoint

Terraform plan: The terraform plan command compares configuration with infrastructure state. It previews create, change, or destroy actions without applying them. I would review unexpected destroy actions before approving a deployment.
Remote state plus locking: Remote state gives the team a shared source of infrastructure state. A supported backend locks state during write operations to prevent concurrent changes from corrupting it. I would validate the backend plus locking behavior before allowing multiple operators to deploy.
Commit-to-production path: A safe GitHub Actions path formats the code, validates configuration, runs tests, then reviews the plan. It gates the environment before deployment, then verifies user-facing health. It retains a known-good rollback artifact because a successful deployment job does not prove the application is healthy.

Revise any Terraform or CI/CD answer that misses a checkpoint.
Save interview-pack.md.
Read the three revised answers aloud. Each answer should name a safety control plus a concrete check.

You now have a concise explanation of how teams preview infrastructure changes, protect shared state, and release software with a rollback path.

Answer the Docker and Linux prompts

Docker plus Linux questions separate process state from usable service behavior. A running container needs a meaningful health check before it can be treated as ready.

Write your answer to “A container is running but unreachable. What do you inspect?”.
Read that answer aloud with a three-sentence limit.
Write your answer to “What is the difference between container state and application health?”.
Read that answer aloud with a three-sentence limit.
Write your answer to “What do you check when memory climbs?”.
Read that answer aloud with a three-sentence limit.

Docker and Linux Checkpoint

Running but unreachable: Compare the mapped host port with the container port. For service-to-service traffic, verify service-name DNS plus shared network membership. Inspect logs plus process binding before changing the network because the application may be listening on the wrong interface.
Container state versus application health: Container state reports whether the main process is running. Application health checks whether the service can handle its intended work. I would validate the health-check result because a running process can still return errors or fail dependencies.
Rising memory: Compare current memory use with the configured memory limit. Inspect process behavior plus logs for growth over time. Correlate the increase with recent changes before restarting or rolling back because a restart can hide the original cause.

Revise any Docker or Linux answer that misses a checkpoint.
Save interview-pack.md.
Read the three revised answers aloud. Each answer should move from evidence to a safe next action.

Your Rapid-Fire Answers section now covers all nine prompts with interview-ready explanations.

✔️ Awesome, I've got everything!

Your nine answers are saved in interview-pack.md. Each one stays within three sentences and includes a risk, validation step, or trade-off.

ⓧ I'd like to double check the full code

The complete coverage checkpoint for interview-pack.md is below.

Architecture Pitch, Incident Drill, Recovery Plan, Scorecard, and Final Reflection remain present.
The public-subnet Application Load Balancer provides controlled ingress to private Amazon ECS task addresses.
The Amazon Route 53 alias record directs the API domain to the load balancer.
The AWS WAF web ACL filters requests before they reach the targets.
The terraform plan answer explains the preview of create, change, or destroy actions.
The remote state answer explains shared state plus protection from concurrent writes.
The CI/CD answer covers format, validate, test, plan review, environment gates, deployment, verification, and a known-good rollback artifact.
The unreachable-container answer covers host ports, container ports, service-name DNS, network membership, logs, and process binding.
The container-health answer distinguishes a running process from a working application.
The memory-growth answer covers memory limits, process behavior, logs, and recent changes.

Before you run the full round, which answer do you expect to exceed three sentences or miss a concrete check?

Keeping each prompt visible while hiding its answer is a little fiddly. Cover one answer at a time so the rehearsal tests recall instead of reading.

Scroll this guide until the checkpoint callouts are out of view.
Read the first prompt in interview-pack.md.
Cover its answer text with your hand.
Deliver the answer aloud from memory.
Repeat the same rehearsal for the remaining eight prompts.
Check every response against its saved answer.

You should complete all nine answers without exceeding three sentences. Every answer should include at least one risk, validation step, or trade-off.

Secret mission

Handle the Customer Escalation Hot Seat

A major retail customer needs a clear update while personalized search remains degraded. Deliver six calm sentences that show ownership without guessing at the root cause.

Clean Up Your Resources

Your interview pack lives entirely on your Windows computer. Choose a cleanup option with no cloud bill to worry about.

Resources you used:

The local gigalogy-mock-interview folder stores the full project.
The interview-pack.md file contains your architecture pitch, incident drill, recovery plan, rapid-fire answers, scorecard, and final reflection.

Keep everything running

This option needs no cleanup. It suits another rehearsal in Visual Studio Code.

Save interview-pack.md so your completed answers stay current.
Keep the gigalogy-mock-interview folder on your computer for future mock interviews.
Revisit Final Reflection after each rehearsal to track your next weak answer.

Pause - I'll come back to this later

Pausing means closing the editor while leaving your local interview pack intact. No background service needs to keep running.

Save interview-pack.md.
Close Visual Studio Code with the window's close button.
Return to gigalogy-mock-interview/interview-pack.md when you are ready for another rehearsal.

Delete - I don't want to use this again

Permanent deletion removes your complete rehearsal pack from this computer. Your cloud account stays untouched because this project created no cloud resources.

Close Visual Studio Code with the window's close button.
Press the Windows key to open search.
Type gigalogy-mock-interview into search.
Select the folder result to open its location in File Explorer.
Select the gigalogy-mock-interview folder.
Press Shift+Delete to remove the selected folder permanently.
Confirm the permanent deletion in the Windows dialog.

One final search verifies that Windows no longer finds the interview pack.

Press the Windows key to open search.
Type gigalogy-mock-interview into search.

You should see no matching project folder. This confirms that interview-pack.md has also been removed.

Nice Work!

That is your interview rehearsal pack complete. You now have a role-specific artifact that shows how you reason about production architecture, operational failures, recovery, and customer communication.

You've learned how to:

Defend an AWS request path from Amazon Route 53 through AWS WAF and an Application Load Balancer to Amazon ECS tasks on AWS Fargate.
Build an evidence-led incident response that prioritizes customer impact, limits the blast radius, uses reversible mitigation, verifies recovery, and captures lessons learned.
Give concise rapid-fire infrastructure answers covering networking, Terraform, Docker, Linux, CI/CD, and GitHub Actions.
Complete the optional Secret Mission by delivering a six-sentence customer escalation update that separates facts from hypotheses, names a reversible response, and commits to the next communication.

Ready to quiz yourself?